Browse All Articles > Migrating Exchange 2007 public folders to Exchange 2010
The below article is designed to point out some key tips and tricks for migrating public folders from Exchange 2007 to 2010. This should help those of you that find it difficult to remove the old public folders database from Exchange 2007 after replicating to 2010, especially, if you have corrupted 2007 databases. It also contains tips for when the un-install of Exchange 2007 gets stuck.
Another fun and exciting project has come to an end. I just finished the City’s upgrade from Exchange 2007 to Exchange 2010. The prerequisites, installation and moving of server roles to the new server were all pretty straight forward and easy, until I got to Public Folders. Public folders are optional in Exchange 2007 and 2010, unless you still have Outlook 2003 clients… which we do. I created the Public Folders database on the 2010 server and mounted it, then told the 2010 mailbox store to use it as its default public folders database. So far so good. In EMC I open the public folders manager and begin to replicate the public folders. To ensure I didn’t miss any public folders I ran the following script in Powershell:
This script will move a single folder tree replication to the new server.
Okay so all is well, I can see the public folders are replicating and showing up in Exchange 2010. My 2003 clients stop getting error messages and all is good, or so I thought. I waited a few hours to make sure that all folders had replicated properly and then I went back to my Exchange 2007 box to remove the public folders database and low and behold I get this error:
The public folder database Database_Name cannot be deleted.
Error: The public folder database specified contains folder replicas. Before deleting the public folder database, remove the folders or move the replicas to another public folder database.
So I run the script:
Get-MailboxDatabase | ft Name,PublicFolderDatabase
After running the script I see that all public folder replicas show up as the 2010 server, so now I am stumped. I go searching online and looking for solutions to the problem to no avail. I am simply unable to remove the public folders database and therefore unable to remove Exchange 2007 from the organization… As a last resort I turn to ADSIEdit.msc to forcefully remove the public folder information from active directory.
I browse under Services => Microsoft Exchange => “My Organization” => Administrative groups => Exchange Administrative group => Servers => “EX2K7 Server name” => Information Store => Public Folders
And then I delete the entry for the public folders database. I go back to Exchange and try to delete the PF database and BAM a new error stating that I cannot remove the PF database because “the object no longer exists on the domain controller”. After a few expletives I quickly realize that I had not restarted the Information Store service after deleting the PF information from ADSI. I restart the service, my database disappears and I am able to finally delete the storage group and uninstall EX2K7. I run the uninstall from add/remove programs and everything goes good, until its gets to “Remove Exchange Files”. the progress bar gets clear to the end but it never finishes. I let it run for 18 hours then decided I had better see what’s going on. I found a Microsoft Technet article that explains the problem. It tells me that EX2K7 can get stuck during the uninstall because the powershell process gets stuck, and will show that it is using 25% of the CPU. I go into task manager => Processes and see powershell.exe is stuck and showing 25 in the CPU column. I end the process, it restarts itself and the uninstall immediately finishes.
Hopefully this information will help those of you in the same situation, after reading the article you should be able to finish your migration to 2010, by removing public folders and unistalling MS Exchange 2007.
This is a good article. Thanks. One question just to confirm. If I do the ADSI edit to the location above, that won't affect my E2k10 PF replicas, right? Those are stored in Services => Microsoft Exchange => “My Organization” => Administrative groups => Exchange Administrative group => Databases. So, I'm guessing it won't affect it.
Comments (2)
Commented:
Thanks.
Author
Commented: