Public Folder replication from Exchange 2007 to 2010 failing, it's not a pretty fix

If, like me, you have an infrastructure that has a considerable history, then it will have been Exchange 2003 in the past.  The work detailed below was a late night oepration and my documentation skills were not up to the usual levels.  But hopefully you can get enough from this to fix your setup (now you've found this article!)

I've previously blogged about the migration to 2007, and the fun in preparing for 2010, but having made the transition I found that the Public Folder hierarchy would not replicate, let alone the replicate the content.  I was getting errors 1020 on the MS Exchange Store Driver.  In addition on trying to add the PF hierarchy to a new Public Folder Mailbox using AddReplicaToRecursive.PS1 I was getting a lot of errors.

After some investigations and work, I have an answer - your mileage might vary, but:

Firstly, I am indebted to the following pages for providing insight and information on what to look at and try!
Public Folder Mayhem (pointer to an ADSIEDIT required)
The inevitable TechNet article (explanation of that ADSIEDIT - and note NO PLANNED FIX)
and zerohoursleep (another pointer to the same problem)

The first clue from the Public Folder Mayhem was the empty Exchange 2003 legacy object in Active Directory.  The object is
CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=NetBIOS name>,DC=TLD>
this object (which had permissions like this - scuse the obfuscation of some details):

That object was then very carefully documented - permissions, ACL details, ownership, attributes using various PowerShell commands (including Quest's AD addon Get-QADObjectSecurity) and LDP.  These were all filed away.
Some people in that article considered deleting the entire First Administrative Group.  I chose not to, as there are three other leaves in there (Advanced Security, Folder Hierarchies, and Routing Groups).  I saw no point in deleting more than might be necessary, even if those leaves are (or are going to be) unnecessary.  Note that the TechNet article supports this approach.  If you want to delete it - use the interface for Exchange not ADSIEDIT.

So I deleted the object from ADSIEDIT, and replicated around the network (checking that all was good).  This all worked fine.

Now to get the PF replication under way.

Previously I had tried to use .\AddReplicaToPFRecursive.PS1 (with parameters -TopPublicFolder \ -ServerToAdd MBX server NetBIOS name> as supplied by the Exchange Team to speed up the process. This still failed.

Over to the new PF hosting MBX server and the following quickly got things in place:
Get-MailboxServer -identity MBX server NetBIOS name> | update-publicfolderhierarchy 
this gets the heirarchy into the new server

Even now adding the replicas
.\AddReplicaToPFRecursive.PS1 -TopPublicFolder \ -ServerToAdd MBX server NetBIOS name>
failed!

Bryant's fail safe to restart all exchange services on both MBX servers was then applied.
It then worked.

So I now had a PF hierarchy and content on the Exchange 2010 server.

A few days later I was investigating something else, and noticed that at a Microsoft Outlook client having opened Exchange Connection Status (right click the Outlook icon on the System Tray, Connection Status) that the PF connection was to the old MBX box (image below shows results after the fix, but you get the picture).

One last trick is required though:  you need to associate the new PF database to the new Mailbox data.  So go to your Exchange Admin tools, right click properties on the 2010 Mailbox database for users.  Client Settings tab
Browse to the new PF store and select it thus:

Now, finally I have Public Folders replicated to Exchange 2010, and users connecting to the new PF location.

just some tidying up, and then i can start to decommission the 2007 world!