The end of support date for Exchange 2007 is fast approaching. At this time all of your migration projects to transition to a newer version should be done. Note that Exchange 2007 will exit out of extended support on the 11th of April 2017. The Office 2007 suite has a slightly later end of extended support date which is the 10th of October 2017.
It is necessary to properly decommission Exchange 2007 in a supported manner. In short this means that you use the Exchange 2007 setup routine to perform the uninstallation on each Exchange 2007 server which will then remove and clean up the necessary objects. Do NOT use ADSIEdit to “uninstall” Exchange servers. Unfortunately this is something that is still carried over in consultant’s minds from Exchange 2003 days. Even with that said, note what the latest revision of that KB states:
If you cannot install or run Exchange System Manager, you can use the Active Directory Service Interfaces (ADSI) Edit snap-in to manually remove enough of the server attributes so that you can try a successful reinstallation. This method does not perform cleanups of references to the server object outside the server's own container. We do not recommend that you use this method unless you intend to immediately reinstall the server in the same administrative group. This is because you may have to manually remove or edit many attributes on objects throughout Active Directory.
Exchange 2003 is no longer supported, this is included for the sole purpose of illustrating issues with ADSIEdit.
You will not find documented steps to remove Exchange 2007 or newer using ADSIEdit. This is illustrated in How to remove Exchange 2007 from a computer and How to Completely Remove Exchange 2007 from a Server.
Exchange Upgrades
As always there are many planning steps and considerations to ensure that this project is successful. For example, all user mailboxes must be moved off Exchange 2007. Transport connectors may need to be adjusted so that all mail flow is via Exchange 2010 or 2013. And Public Folders, if you plan to continue using them, must also be migrated off Exchange 2007. While we are at it, also ensure that your Exchange 2003 migration steps were also properly completed. Even in the year 2017 AD, I am still finding customers who failed to complete all of the Exchange 2003 decommissioning steps. For example, Remove the Last Legacy Exchange Server from an Exchange 2010 Organization has not been fully followed. Non-Universal groups are still being used for mail purposes, Email Address Policies not updated and sometimes the OAB and GAL generation was not moved on over.
You should also review the additional planning points which are mentioned in How To Easily Add Public Folder Replicas To Exchange 2010. You may run into a Public Folder replication issue if replicating Public Folders to Exchange 2010 if there is an empty servers container in the Exchange organisation. The steps to resolve this issue are included in that post.
It is on the Public Folder point where this post comes in. The customer believed that they had added replicas of all of their Public Folders to Exchange 2010, and were a little bit surprised by the below error which stated the Exchange 2007 server could not be uninstalled. This was the last step on the project plan before they could commence uninstalling Exchange 2007.
For the search engines:
Mailbox Role Prerequisites
Failed
Error:
Uninstall cannot continue. Database 'Public Folder Database': The public folder database "EXCH-2007Second Storage GroupPublic Folder Database" contains folder replicas. Before deleting the public folder database, remove the folders or move the replicas to another public folder database. For detailed instructions about how to remove a public folder database, see http://go.microsoft.com/fwlink/?linkid=81409.
Recommended Action: http://go.microsoft.com/fwlink/?linkid=30939&l=en&v=ExBPA.12&id=b6e3b32a-8848-46cb-9567-72288ac15f60
The reason they were a tad surprised about this error, is that they had already ran the below commands to add Public Folder replicas to Exchange 2010. This is a repro on one of my labs and is not the production environment.
.AddReplicaToPFRecursive.ps1 -TopPublicFolder "NON_IPM_SUBTREE" -ServerToAdd Exch-2010
.AddReplicaToPFRecursive.ps1 -TopPublicFolder "" -ServerToAdd Exch-2010
The command completed successfully so we are all good to remove the 2007 replica, right?
Removing Exchange 2007 Public Folder Replica – Failed
Well. No, not really.
After receiving the previously mentioned error in the Exchange 2007 uninstallation routine, No problemo they said, let us just remove the replicas off that 2007 server. To do this they used another of the built-in Exchange scripts - RemoveReplicaFromPFRecursive.ps1. However this did not go swimmingly.
.RemoveReplicaFromPFRecursive.ps1 -Server exch-2010 -TopPublicFolder "" -ServerToRemove Exch-2007
Cannot complete the operation because there isn’t an available public folder database on server ‘Exch-2010’
Houston, we’ve had a problem……
Public Folder Database, Where Art Thou?
It was at this point they realised that something kind of important had been overlooked. Well I said two things, but let’s go with their one point and I will add mine at the end of this post in the verification section.
When they went to see which servers had a Public Folder database, note that *ONLY* the Exchange 2007 server had one. They had forgotten to create a public folder database on Exchange 2010.
DOH!
Create Exchange 2010 Public Folder Database
Initially they wanted to use the name "Public Folder database" on Exchange 2010, but that will not work as the name must be unique.
New-PublicFolderDatabase -Name "Public Folder Database" -Server Exch-2010
Note the name must be unique. Also remember to mount it….
In this case they wanted something similar so the new Exchange 2010 public database was called "Public-Folder-Database" - note the hyphens.
New-PublicFolderDatabase -Name "Public-Folder-Database" -Server Exch-2010
Mount-Database "Public-Folder-Database"
Adding Replicas
Now that we have a Public Folder database on the Exchange 2010 server, time to add the replicas. We add replicas for both the IPM and NON_IPM_SUBTREE.
.AddReplicaToPFRecursive.ps1 -TopPublicFolder "NON_IPM_SUBTREE" -ServerToAdd Exch-2010
.AddReplicaToPFRecursive.ps1 -TopPublicFolder "" -ServerToAdd Exch-2010
And now we must perform the below section – verification!
Bootnote – Verification
If they had followed the process outlined in the previous post How To Easily Add Public Folder Replicas To Exchange 2010 then they would have immediately discovered the issue. Verification is a critical step in any change request process. Verification is the item they completely missed. The below could have been used to verify the replication status:
.Get-PublicFolderReplicationReport.ps1 -AsHTML output.html
The below shows that in the first image, there are only replicas on the Exchange 2007 server. After enabling replication to Exchange 2010, the folders are on both servers. Just by eyeballing the first report they would have immediately noticed that something was not quite right.
If all was as they had intended the report should have looked like the below with all replication partners specified.
Cheers,
Rhoderick
replicas cannot be delete ... wtf ?