Migrating Public Folders from Exchange 2007 to 2010

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.

cd $exscripts

.\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.


Chris Blackburn

Learn More →

10 thoughts on “Migrating Public Folders from Exchange 2007 to 2010

  1. Michael Schipp January 9, 2012 at 3:38 pm

    \AddReplicaToPFRecursive.ps1 -TopPublicFolder “\” -ServerToAdd E2010

    should be

    \AddReplicaToPFRecursive.ps1 -server OLD2007Server -TopPublicFolder “\” -ServerToAdd E2010

    1. Chris Blackburn January 19, 2012 at 6:28 am

      Michael, I guess it really depends on if you want to target the data from a single replica, if you have an E2007 environment with multiple PF databases and different replica sets. If you look at the help for the command (AddReplicaToPFRecursive.ps1 -help), you’ll see that -Server is an optional command, and without it the command defaults to a “convenient” server. If the Exchange topology is healthy, this command shouldn’t be necessary.

  2. Charles Jones May 12, 2012 at 1:47 am

    Nice guide, best one I’ve seen. My question is shouldn’t you be running the:

    Get-PublicFolder -Recurse | fl Name, Replicas

    Command on the old server? Didn’t realize why I wasn’t seeing the hierarchy/replicas show up immediately on the new server until I understood (from this post http://social.technet.microsoft.com/Forums/vi-VN/exchange2010/thread/44b29a93-0149-4734-8e19-6679ad7701ce by Anonymous1029384756) that this command was to be run on the old server.

  3. Migrate Public Folder to Exchange 2010 | Brain-Cluster.com July 7, 2012 at 11:23 pm

    […] https://memphistech.net/?p=147 […]

  4. Wesley November 7, 2013 at 1:31 pm

    Thanks for the detailed breakdown. I’m migrating a small office from SBS 2008 (Exchange 2007) to SBS 2011 (Exchange 2010). I’m using the official TechNet instructions on how to migrate, and I hit upon the error: “The public folder database “SBS2008\Storage Group\Public Folder Database” contains folder replicas. Before deleting the public folder database, remove the folders or move the replicas to another public folder database.”

    It turned out to be the ExchangeV1 folder in the NON_IPM_SUBTREE that was not moving. Following your instructions and waiting about an hour for the replication to complete was the solution. I’m not sure exactly which step caused things to move forward in a way different from Microsoft’s official instructions here: http://support.microsoft.com/kb/927464

    Also note that according to Microsoft documentation the ExchangeV1 folder doesn’t need to replicate to the new server anyway, so it would be valid (in theory) to leave it behind and decommission the old server or simply dismount and delete the public folder database once everything else had been removed. At least, that’s what I heard on some TechNet articles. Microsoft’s own documentation has had its veracity called into question several times in this ordeal. =)

    Thanks again Chris!

  5. Jéan April 4, 2014 at 4:13 am

    Chris, brilliant work. I’m in the process of migrating SBS2008 to SBS2011 and this is helping a lot with the dreaded Public Folder replication. The hierarchy has now been created on the server, so I just need to populate it now. Thanks again!!

  6. Exchange PubliC folder Migrate June 1, 2014 at 11:54 pm

    […] […]

  7. Ryan July 13, 2015 at 1:21 pm

    Thank you for this blog post. Would it hurt anything to run AddReplicaToPFRecursive.ps1 after many of the replication targets were manually created?

    I have this issue where clients are still making connections to an only 2007 system that doesn’t have any mailboxes on it.

    Thanks in advance,


    1. Chris Blackburn July 23, 2015 at 11:27 am

      Hi Ryan – If you have “many” but not “all” of the replica targets added to all folders it shouldn’t hurt. It won’t add it if it’s already there and should target the ones that are missing.

  8. Migrating Public Folders from 2010 to 2016 | Just a Tech from Memphis October 19, 2016 at 7:40 pm

    […] little over 5 years ago I wrote a blog https://memphistech.net/?p=147 on how to migrate public folders from Exchange 2007 to 2010, hoping that that would be the last […]


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.