The time approaches. Exchange 2010 has almost transitioned out of its extended support lifecycle phase, and multiple organisations are completing the final components of their Exchange 2010 migration.
The last act is to uninstall Exchange 2010 once all of the resources have been moved to a newer version of Exchange. There are a few things to consider though and this is post to help organisations map out the tasks.
Some of these tasks will vary greatly between different customers, and some will be the same. Change control is one prime example. Some organisations have very well defined change control processes. Others resemble more like a scene from the Wild West.
Prior to being able to uninstall and decommission Exchange 2010 multiple items must have been addressed. We will split these tasks into three sections:
-
Pre-Decommission Tasks
-
Decommission Tasks
-
Post-Decommission Tasks
Depending on the organisation and their appetite for risk, the time between steps can be adjusted. Also, if you want to power an Exchange 2010 server down for a couple of days as a scream test there is nothing stopping your from doing that.
Maintain Exchange 2010
Continue to service and support Exchange 2010 – stay abreast of security updates.
If you have issues with moving mailboxes to Exchange Online expect push back from support if you are still on Exchange 2010 SP3 RU 5. Your security team should also be doing a better audit job as well...
Pre-Decommission Tasks
The tasks in this section are all of the work items which will allow you to get to the point of section #2 which is actually running the Exchange uninstall routine.
The steps include:
Move Mailboxes
All user mailboxes must be moved to a newer version and no mailboxes are to remain on Exchange 2010.
Move Arbitration Mailboxes
Moving all arbitration mailboxes to a newer version – not this should not be happening now. This should have been done prior to moving the first user mailboxes to that newer Exchange version. See this post for more details on arbitration mailboxes and how they map out. However this is sometimes missed as the option is not present in the UI.
Clean Orphaned Mailbox Attributes
It is very likely that there will be some user objects which have orphaned mailbox attributes. This can happen for a number of reasons. The actual mailbox is gone, but an attribute persists which makes Exchange believe that the mailbox still exits. This will block the removal of that particular mailbox database. You can deal with this reactively, or try to be proactive and preemptively scan AD DS for such objects.
Update Mail Flow
Update Receive Connectors
Review the SMTP protocol logs to ensure that applications and services are not still sending through Exchange 2010.
Do not just carry forward some of the changes that were previously made to the existing Exchange 2010 Receive Connectors. This is an opportunity to review the security and configuration.
This is especially true for the heinous Externally Secured option.
Update Send Connectors
Send connectors to the Internet may need to be updated so that any Exchange 2010 source servers are replaced with Exchange 2013/2016 servers. Review the network considerations as part of this change.
Review Exchange Transport Rules
When Exchange 2013/2016 was installed, the existing Transport Rules were imported to the new version of Exchange. In effect there are two copies of the rule, one in the Exchange 2010 container and the other in the Exchange 2013 container. This is a one time operation and you need to ensure that any changes made to the Exchange rules were added
Review CAS Connectivity
When the initial cut over was done to Exchange 2013/2016 the HTTP namespaces should have been moved at that time. No end user traffic should be present on Exchange 2010.
Review all CAS namespaces to ensure that the URLs are correctly set as per your CAS namespace design.
As part of this, please:
- Review IIS Logs
- Review POP/IMAP Logs
Public Folders
This could be one of the most painful parts of the project. In so many organisations, a decision was never made and public folders were just migrated from one version of Exchange to the next with no oversight. Time to pay for that now!
Depending upon the approach taken, public folders could be migrated to a newer version of Exchange or deleted.
Migrate public folders to a new version of Exchange
Even if you decive to move public folders using this method, please create a project item to actually review the content, folder structure and delete/archive content that is no longer needed. This will take time. Plan for it. One migration where the Christmas holiday pictures from 2003 and the issues they caused is permantently stuck in my brain!
Delete Public Folders
Delete public folders, and transition the business processes to a use a different communication methodology.
This will require documenting and understanding how public folders are using in the organisation. Do not underestimate the work and time lines involved in this task. Some organisations used public folders to share contacts. Some allowed users (inadvertently) to use public folders as a dumping ground for their email content as they forgot to set quotas on the public folders.
Decommission Tasks
Remove Exchange 2010 CAS Components
When you are sure there are no more Exchange 2010 users, and that the protocol logs are clean then you can move to decomissioning the Exchange 2010 CAS components.
- Remove CAS Array using Exchagne 2010 PowerShell
Hint -- Don't forget about this and then try to do if from Exchange 2016 PowerShell.
Remove Exchange 2010 Mailbox Components
We verified earlier that there are no remaining Exchange 2010 mailboxes. All of the mailbox databases can now be removed along with the Exchagne 2010 DAGs. Steps here will include:
- Remove Exchange 2010 DAG
- Removed all database copies
- Remove server from DAG
- Remove DAG & FSW
- Remove Exchange 2010 OAB
Uninstall Exchange 2010 Servers
Some considerations when we get to actually uninstalling Exchange from a server.
- Run setup from elevated cmd prompt if running command line tasks
- Disable AV
- Disable additional HIDS/HIPS solutions running on the server
- Reboot after removal completes
Post-Decommission Tasks
There are tasks that will need to be done after Exchange 2010 has been decomissioned. Some items will vary by environment, and this list is intended as a suggestion and is not fully complete.
For example:
- Remove monitoring
- Remove DNS entries
- Remove backup
- Remove from AV
- Remove redundant ASA (if applicable)
- Remove server from AD and clean up the computer object as per your process
- Server hardware recycling
- Asset management system update
- Disk scrubbing / destruction
Cheers,
Rhoderick
