Decommissioning Legacy Exchange Servers
PFE Pascal L'Huriec takes us through the steps to that are needed when decommissioning legacy Exchange servers.
Introduction
After mailboxes migration to another server, to a newer version, or to Office365 you might need to decommission an Exchange server running on-premises. This operation needs to be done carefully, and you must absolutely avoid the hard deletion of any object from Active Directory using ADSIEdit or similar tool. Hard deletion from AD could result in attributes populated with Deleted Object references and lead to unexpected behaviours.
I wrote this post to assist with proper decommissioning of an Exchange server, based on TechNet articles and different experiences. Uninstalling an Exchange server could look quite easy when running the uninstallation from ‘Uninstall a program’ in the ‘Control Panel’, but several checks are performed to allow the uninstallation to occur. If these checks are not successfully covered you could attempt to uninstall many times before succeeding.
This post has been written for Exchange 2007 as this is currently the most appropriate. It is probably the version that you need to decommission by this time, due to its support lifecycle, and also due to the Windows Server 2003 end of extended support, or simply to prepare the introduction of Exchange Server 2016. But most of the content applies to Exchange 2010 as well.
Order Of Uninstall
When upgrading (Service Pack or Rollup Update) Exchange servers in an AD site, it is important to upgrade the roles in the following order: CAS, HUB, UM (Unified Messaging, if any), and then Mailbox.
When uninstalling Exchange servers in an AD site, it is exactly the opposite order. Uninstall Mailbox servers first, then UM, HUB, and lastly CAS.
Correctly Set Management Scope
If you forest contains several AD domains, as a best practice, from the PowerShell session that you are going to use, change your scope.
If you query the $AdminSessionADSettings variable you will notice that the ViewEntireForestparameter is set to False by default:
If your forest contains several AD domains, it is better to set it to Truein order to see all objects from the entire forest, instead of a restricted scope.
Run the following : $AdminSessionADSettings.ViewEntireForest = $true
This is covered in How to Change the Recipient Scope
Remove Legacy Mailbox Databases
Before attempting an uninstallation, it is important to manually delete the mailbox databases on the server that you need to uninstall. As long as there is no mailbox anymore on that server, you should delete all the mailbox databases, except the first mailbox database (the one that contains the Microsoft System Attendant mailbox). It is not mandatory to remove the mailbox databases for the uninstallation program, but if you remove them manually you will save a lot of time if any mailbox remain in a database.
You can check if a mailbox remains on a database with the following cmdlet:
Get-MailboxStatistics –Database “ServerName\StorageGroupName\DatabaseName”
Against an empty database, that cmdlet above should return the following:
Here the database DB04 is empty. Only the SystemMailbox{guid} remain, this is expected.
The database DB04 can be removed.
In addition to the SystemMailbox, if you see the “Microsoft System Attendant” mailbox, it is then the first mailbox database of the server, you must maintain it up and running until the uninstallation of the server. On that picture below the “Microsoft System Attendant” mailbox is on the database named “Mailbox Database”, you need to keep that one up and running until the uninstallation. That “Mailbox Database” will be remove by the uninstallation program. You also need to remove the other mailboxes from “Mailbox Database” if any.
From the Exchange Management Console you can remove the mailbox database one by one, or you can use the Remove-MailboxDatabase cmdlet. If a mailbox (other than the SystemMailbox) remain on the database the deletion of the mailbox database will fail. Here I’m removing the DBB04 as it is empty:
And the expected warning, asking to remove the database file if you wish:
If any mailbox remain on the database that you attempt to remove, you will get the following warning:
To identify the remaining mailbox, run the “Get-Mailbox –Database <Database ID>” as mentioned in that dialog box. You can also run Get-MailboxStatisticswhich could help :
Get-MailboxStatistics –Database “ServerName\StorageGroupName\DatabaseName”
Most of the time the difficulties start here. You might receive the warning above telling that the database contains one or more mailboxes despite the Get-Mailbox or Get-MailboxStatistics cmdlet doesn’t return any mailbox.
First, if you have recently moved any mailbox from that database, wait for the Active Directory replication to complete.
If you have not recently moved any mailbox from that database, you might have a user account where an attribute still refers to that server or database. You can first check with LDP or ADSIEdit on the HomeMDBBL attribute against the database if any mailbox remain. This attribute contains all the Distinguished Name of the mailboxes hosted on that database. This attribute is a BackLink attribute, you can’t modify it, but at least you can check its value.
You can see on my database named DB02, the HomeMDBBL contains ‘User1 Move1’, ‘User2 Move2’, ‘User3 Move3’… and more
In case the deletion of the mailbox database would fail, you can check the user(s) reported in the HomeMDBBL attribute, if it is still valid or not, probably the removal of Exchange attributes has partially failed if he doesn’t have a mailbox anymore. Or a move mailbox has not completely terminated for that user. Sometime you can simply move that mailbox again to another database, and you get your homeMDBBL clean.
Also, and despite the HomeMDBBL doesn’t return any user on that database, its deletion might still fails, persisting in telling you that one or several mailbox remain on that database…. You probably have a user account where one of these attributes still refers to that server or database: HomeMDB, HomeMTA or msExchHomeServerName. As you don’t know which user account, you need to search for it. LDP is probably the most appropriate tool to query for the Active Directory attribute:
Connect and bind in LDP:
And Search at the domain level:
The query to use in the filter field is the following:
(&((objectclass=*)(msExchHomeServerName=/o=MyCompany/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=E2K7-MBX)))
The purple part of the query is basically the LegacyExchangeDNname of the server object, which you can easily Copy from here: (and then Paste in your LDP filter)
The query will return all mailboxes having msExchHomeServerName referring to that server, that will include the SystemMailbox, but you need to search in the output if any user mailboxes are expected or not.
You can also use a similar filter to query for the HomeMDB attributes, and also the HomeMTA:
(&((objectclass=*)(HomeMDB=cn=DB04,cn=First Storage Group,cn=InformationStore,cn=E2K7-MBX,cn=Servers,cn=Administrative Group (FYDIBOHF23SPDLT),cn=Adminsitrative Groups,cn=MyCompany,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=testdomain,dc=com)))
Here the purple part of the query is the distinguishedNameof the mailbox database to query. Copy/paste it for ease.
To query the HomeMTA attribute, the purple part of the query needs to be the distinguishedNameof the MTA object. For exemple: cn=Microsoft MTA,cn=E2K7-MBX,cn=Servers …….
Again, use copy/paste also for ease.
One of the query will return the faulty user(s), which is still populated with that server or database, and that you will need to fix manually. Depending on the situation the fix can be a move of the mailbox to another database, or editing its attribute and modify it to the correct value, or simply remove the value if that user doesn’t have a mailbox anymore (for instance).
Once you have been able to remove the mailbox databases (except the first one), you can also remove the empty Storage Groups.
Remove Legacy Public Folder Databases
You can have only one public folder database per server, or zero.
If you don’t have PF database you can forget that chapter. But if you have PF database, prior to decommission an Exchange Server 2007 it is better to delete its Public Folder database. It is not mandatory but same as for the Mailbox databases, you might need several attempt to be able to delete the database, so it’s better to delete manually prior to attempt any uninstallation from the ‘Uninstall a program’ in the ‘Control Panel’.
Before removing a Public Folder database you need to confirm that this database is not use as a “Default public folder database” on a mailbox database. Here when I look at the properties of my mailbox database DB02, from the “Client Settings” tab I can see that “Public Folder Database” from server E2K2-MBX is used as default. I won’t be able to remove “Public Folder Database” because of that. We need to mention another PF database as the default.
For ease, use the following command, you can see quickly the Default PF database used:
Get-MailboxDatabase | ft name,PublicFolderDatabase –AutoSize
Before removing a Public Folder database you also need to confirm that this database doesn’t have Public Folder content anymore, with Get-PublicFolderStatisticscmdlet:
On the above screenshot several Public Folders are replicated to that database, so I won’t be able to delete that PF database.
In order to delete a PF database, the Get-PublicFolderStatistics cmdlet against that server must return an empty list.
If the PF content needs to be kept, move it to another PF database/server. Either use the MoveAllReplica.ps1script provided with Exchange:
MoveAllReplicas.ps1 -Server Server01 -NewServer Server02
Be careful of the volumeof Public Folder to move. If you need to move 10 Gb of Public Folder content, that will generate 10 Gb of replication messages, flowing via SMTP, which might overload your Exchange servers in a very busy state, or even not responding. So if the volume to move is important, please do not move all at once, but rather split the move in several batches.
How to Move Public Folder Content from one Public Folder Database to Another Public Folder Database
You can also use the Exchange Management Console to add a replica to a new server, and then remove the existing server:
Wait for the PF replication to occur, and check later with the Get-PublicFolderStatistics cmdlet which should return an empty list.
If the PF content doesn’t need to be kept, you can delete them. You can use the EMC for that (remove all replica from that same screenshot above). You can also use the Remove-PublicFolder cmdlet.
If you need Public Folder anymore and wish to remove all Public Folder from your organization, you can check the following link, in the section “To delete user and system public folders”:
How to Delete Multiple Public Folders from Your Organization
Once you have moved all PF replica to another database, or delete the PF content, you must make sure that the Get-PublicFolderStatistics cmdlet returns an empty list. This can take some times depending on the volume to move and the latencies. But at least while you wait for the content to disappear you should be able to see it decreasing progressively.
When the PF Database is empty, you can simply delete it from the EMC as below, or “Remove-PublicFolderDatabase” cmdlet:
Offline Address Book
This step is slightly linked to the previous one (Removing the Public Folder Database). Depending on your environment you might need to work on the OAB before working on the Public Folder Database.
Before trying to uninstall a server it is important to make sure that this server is not a generator for any OAB (that’s part of the MBX role), otherwise the uninstallation program would fail. You can simply check that with the cmdlet:
Get-OfflineAddressBook | ft Name,Server
You will see immediately which server is in charge of the generation. You need to assign a different one. Here, let’s suppose you want to remove Exchange 2007, you can assign an Exchange 2010 server for the OAB generator from the EMC, simply “Move” the OAB:
Check also the OAB Distribution mode. It can be Web-based and/or Public Folder:
Since Outlook 2007 you should have only Web-based distributed OAB. If you are still having PF distributed OAB, make sure your Outlook clients are using the OAB virtual directories, and enable only Web-based distribution (in other words, disable the PF Distribution mode). Anyway if you wish to remove all PF databases in the organization you will need to disable the PF Distribution mode on all OABs before removing the last PF database in the organization.
In case a Public Folder distribution is not enabled anymore for an Offline Address Book, you can delete the content in the PF from the Public Folder Management Console, basically remove all the replica:
The content will not exist anymore, but it is not possible to delete the OAB root folder using Exchange Management Console. Please see:
Unable to delete the OAB system folders in Exchange 2007
Before trying to uninstall a server it is also important to make sure that this server is not used to distribute the OAB to the Outlook client (that’ part of the CAS role):
On the example above we will not be able to uninstall the server E2K10-B, neither E2K10-A, neither E2K7-CAS2 because they are used for Web-based distribution for the OAB named “Default Offline Address List”.
If you wish to verify which OAB is used or not used (in order to clear some old OABs), you can check easily with the following cmdlet which mailbox database is using which OAB:
Get-MailboxDatabase | ft name,OfflineAddressBook
If an OAB is not used, not needed anymore you can delete it.
Connectors
This is quite obvious, but it might save time also.
Before attempting any uninstallation of an Exchange server, that server must not be a bridgehead in any Send Connector.
Below, before uninstalling E2K7-HUB, we need to remove it as a source server from that Send Connector (or use Get-SendConnectorcmdlet)
Receive Connectors behave slightly different. They are attached to the server, and usually don’t cause any trouble for the uninstallation program. But it is clearly better and safer to remove the Received Connectors that you created before uninstalling Exchange server.
Also if you are using a load balancing device to balance the mailflow traffic between several servers, do not forget to remove that server from the pool.
Legacy Cluster Removal
If you are using any type of high availability Cluster in Exchange 2007 (CCR, SCC) the process to uninstall will vary. I’m not going to cover all the detailed steps for each Cluster types, as it might also be different depending on your environment (e.g. several CMS or single CMS in a SCC), but just give you a few tips.
Use the following TechNet articles, and make it suitable to your environment:
Uninstalling Clustered Mailbox Servers
If you are using SCC with several CMS, the first CMS installed in the Cluster got the msExchResponsibleMTAServer“role”. You need to identify that CMS, it must always be the last CMS to uninstall.
How to Determine the First Clustered Mailbox Server Installed in a Single Copy Cluster
You will have to do it only with from a cmd; for example, the cmd below will remove the CMS and uninstall the Mailbox role from the node. You can’t do it from graphical interface on a Cluster.
setup.com /mode:uninstall /removeCMS /CMSName:CMSName
Conclusion
Before attempting any uninstallation of Exchange Server 2007 software on a server from the Control Panel:
- First delete the mailbox databases (except the first database)
- Secondly remove the PF database (if that server has a PF database)
- Check the OABs if the server to uninstall is not a generator neither used for OAB distribution
- Check if the server to uninstall is not used as a Source Server on any Send Connector
- Check the client access protocols (OWA, ActiveSync, WebServices, Outlook Anywhere….) if no request are coming to that server. Remove from HLB pool.
- You also might have to uninstall other agents/products (third party or not) based on Exchange features, such as Antivirus, Backup, Monitoring….Quite often these components cause the Exchange uninstallation program to fail.
When all of that is done, you can proceed with the Exchange 2007 uninstallation by using Add or Remove Programs from Control Panel …just do not forget to close the Exchange Management Console and Exchange Management Shell.
The above content can be used to supplement the Removing The Last legacy Exchange Serverdocumentation on TechNet.
Published by MSPFE editor Rhoderick Milne.
Comments
- Anonymous
October 21, 2016
Thank you! This was very helpful. But I am dealing with GAL update issues with OAB 2, 3 and old PF's that couldn't be updated when issuing the cmd get-globaladdresslist | update-globaladdresslist - Anonymous
December 21, 2016
Administrators may be unable to uninstall a legacy server found in their Active Directory because the physical server has been lost. They may therefor resort to hard deletion. As an alternative, consider the procedure described at "How to Recover a Lost Exchange Server" (https://technet.microsoft.com/en-us/library/bb123496%28v=exchg.80%29.aspx?f=255&MSPPError=-2147217396) for rebuilding the lost server to allow for a proper removal. - Anonymous
December 12, 2017
Nice article. Help me understand a lot of things.