Yet another Exchange legacy Public Folders replication issue: Old content not replicating to new PF databases

If you´re reading this post, chances are you´re stuck with a public folder replication issue. I´ve seen all sorts of issues with the replication of legacy public folders, but none without solution, so hopefully your solution is here 🙂

My scenario:

  • Exchange 2010 Service Pack 2 in 3 servers (2 existing and 1 new)
  • CAS/HT/Mailbox roles on all servers
  • Each server has a public folder mailbox
  • One server in Asia, one in America and one in the EMEA region

My problem:

The new public folder database was not getting all the existing public folder replicas/content.

Instead of going direct to my issue, let me guide you through all the steps you should take to make sure you understand why your replicas are not being pushed to the new PF database:

Have you added all the replicas (or the ones you need) to your new public folder database?

AddReplicaToPFRecursive.ps1 -Server <ExistingServer> -ServerToAdd <NewServer> -TopPublicFolder “\”

AddReplicaToPFRecursive.ps1 -Server <ExistingServer> -ServerToAdd <NewServer> -TopPublicFolder “\NON_IPM_SUBTREE”

The script above is on the Exchange scripts folder, and can be ran from an Exchange Management Shell. Look here for more details on the script.

You can check which replicas a public folder has, by running:

GetPublicFolder -Identity ‘\’ –Recurse | fl Name, Replicas

Get-PublicFolder -Server <NewServer> -Recurse

Is the above done and your public folder database is still not up to date?

If you do have the replicas pushed to the new server, and the content is still not being replicated, then please also check if the mail flow between the source and destination server is working.

In my case of course it was working, because as stated on the title of this post, only the old content of the public folders was not being replicated. New content was fine, which means that issues like mail flow or invalid replicas were ruled out.

An example:

UserA was connecting to a database on the new server that was using the new public folder database. Via OWA UserA opened the Public Folders, and created a new item. The item was replicated to all the Public Folder databases on all servers. UserA can only see a very limited number of items on the Public folders, all recent and created after the creation of the new PF Database.

So lets take a closer look at the statistics of a specific folder:

pferror1

The Public Folder “US” had zero items in the new server and 1087 on the old one. An item created now would replicate to both the new and the old server, but nothing was happening to old content.

Now before I continue, it´s mandatory for me to recommend you read an excellent Public Folder Troubleshooting article from the Ehlo Blog.

The next step is to raise the event log level on both the new and the old server. The logs you need to set to expert are under the “MSExchangeIS > 9001 Public” and are named “Replication Incoming Messages” and “Replication Outgoing Messages”.

pferror2

Now let’s force an update on a public folder by running on the new server Exchange Management Shell:

Update-PublicFolder -identity “\US” -server <OldServer>

And on the new server event viewer you can see the 0x20 Status Request event (see the troubleshooting guide provided above for more info on event codes).

pferror3

On the old server you can see the status request reply:

pferror4

But what you never see is an event like the one below, with status 0x4 that indicates that content is being replicated.

pferror5

So what is the solution? Update all the content using the ExFolders tool.

Click here to download it, and for full instructions on how to run it.

Once you have the Exfolders opened and connected to the old server, select the folders you want to update (in my case I selected the route because I wanted to update all) and click on “Modify All Items”.

pferror6

IMPORTANT NOTE: This will cause a replication storm, which means that all public folders on all databases will be updated and replicated. If you have a large public folder infrastructure you might want to consider doing this procedure during off work hours.

You will then see the folders being updated.

pferror7

And once that is done, wait for the replication to take place and run the public folder statistics cmdlet again.

pferror8

All up to date!

Hope that the above was helpful..

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s