If you’re like me and you’ve migrated from Exchange 2007 to 2010, you’re left with the last piece of the migration – moving the public folder tree over to the Exchange 2010 server. You’ve also followed the text book process on Technet to move the hierarchy properly, and have run into a number of headaches.
Moving public folders has never been an easy chore, giving the unusual way you have to replicate the contacts between servers, and once that is done move the Outlook Address Book (OAB) generation over to the new server. Shew!
Run these commands on the new E2010 server, part of the built-in Exchange scripts that is found on E2007 and E2010. NOTE: These commands automate adding the new server as a replica to all public folders, versus having to open each one the manually.
.\AddReplicaToPFRecursive.ps1 -TopPublicFolder “\” -ServerToAdd E2010
.\AddReplicaToPFRecursive.ps1 -TopPublicFolder “\NON_IPM_SUBTREE” -ServerToAdd E2010
The next step is to verify that the public folder hierarchy has copied over to the new public folder databases:
Get-PublicFolder -Recurse | fl Name, Replicas
Verify here that each public folder shows a replica for your new E2010 public folder databases. If all looks good here, then the next step is to wait for the public folders to replicate. At this point is where things can go from bad to worse. Here’s a good example:
You run the AddReplicaToPFRecursive.ps1 script. After a few hours, or in some cases the next day, you check and see the full public folder structure listed on your new servers however all of the folders have a 0kb size. This most likely is caused when the hub transports on both the old E2007 server and the new E2010 server cannot communicate.
The way to confirm this is by opening the Queue Viewer on either server and looking for the Hub Version 8 queue (on the E2010 server) and the Hub Version 14 queue (on the E2007 server) that is hanging with a Retry status with pending messages.
In my example the other “monkey wrench” in the situation was the fact that I had already created a few receive connectors that were being used for SMTP relay purposes. It’s especially nasty if the accepted IP range includes any of the Exchange servers, which it was on mine.
The easiest work around was to simply create a new SMTP connector on each server, only allowing connectivity from the IP address(es) of the other E2007 server(s). On the Authentication tab check TLS/Exchange Server, and on the Permission tab check Exchange server as well. Once this is done you can set the Queues to retry and they should empty out.
There’s another situation where nothing happens, and the hierarchy we see by running Get-PublicFolder on the E2007 server never appears on the E2010 server.
After waiting an until the next morning, I checked the Event log and finally this nugget appears every hour:
Log Name: Application
Source: MSExchange Store Driver
Event ID: 1020
The store driver couldn’t deliver the public folder replication message “Status Request (PublicFolderDatabase@domain.com)” because the following error occurred: The Active Directory user wasn’t found..
Well after some digging there are others with the same issue, and way down in the midst of the feedback a diamond in the rough:
It seems this only really happens in environments where a previous migration from Exchange 2003 to 2007 had occurred. While the old server had been properly removed from Active Directory, something with the Servers folder inside of the old administrative group is hanging things up.
Since it’s empty, we can safely delete CN=Servers to resolve this issue.
The Microsoft Exchange team has recognized this issue as well:
However there are no plans for a fix announced – what gives!
After working through these issues and we see no more errors in the event log and by running the Get-PublicFolders command, the hierarchy is there properly.
Now we can verify all of the replicas are on the new server
Get-PublicFolder \ -Recurse | ft name,parentpath,replicas
Once you’ve verified public folder replication is in place, it’s time to retarget the replicas. To target the primary public folder database, run the Moveallreplicas.ps1 command on the E2010 server, however when we try running it on the E2007 folder it executes but throws a number of NON_IPN_SUBTREE messages (which is OK, since the E2007 server is still in the mix)
.\Moveallreplicas.ps1 –server E2007 -newserver E2010
We then force an update of the hierarchy on the new server by using the following command
Update-PublicFolderHierarchy -Server E2010
Finally, to verify that the hierarchy has been moved, we run this on the
Get-PublicFolder \ -Recurse | ft name,parentpath,replicas
And if we check the content of the public folders on the new server
Get-PublicFolderStatistics -server E2010
And even more importantly, check the replica status on the Exchange 2007 folder. You’ll want to make sure it’s completely empty.
Get-PublicFolderStatistics -server E2007
Even if you have a few replicas listed on the Exchange 2007 server, you’re work is not done yet. Typically waiting a little longer, or even doing something as easy as dismounting and remounting the public folders on both sides can do the trick. On the extreme ends, you’ll have to add all of the replicas on both ends, even after moving them over to the Exchange 2010 server. From there, use the Update Content option on that folder in the Public Folder Management Console. Eventually all replicas should disappear from the Exchange 2007 server. If it doesn’t, and you’re confident that the Exchange 2010 servers have all of the replicated public folder content you need, you can go as far as to remove the public folder databases via ADSIEDIT.
Finally, with the public folder content replicated, we’ll want to move the OAB generation over to the new server:
Move-OfflineAddressBook “Default Offline Address List” –Server E2010
So now all that we have left is to make sure that the old mailbox databases have been removed (or that they have been updated to use the Public Folder database on the new server) and we’re ready to remove the public folder store.