Admins have a few options to upgrade their servers, but whether they choose cloud or on premises, the update process involves the same steps to transition old servers and avoid issues.
An Exchange Server migration is often an arduous process with more to do than you would expect, but using a checklist can eliminate some of the stress. Even after selecting a new destination, you must check compatibility, prepare your mailboxes and applications, and plan new certificates and licenses.
Exchange Server 2010 will reach its end of life in 2020, and the appeal of a hosted cloud service is strong for organizations that want centralized management, high availability and scalability. To that end, organizations have more reasons to migrate Exchange Servers to Exchange Online, Office 365 or a hybrid deployment.
Editor’s note:A Sept. 16 blog on the Exchange Team site indicated Microsoft would push the extended support of Exchange Server 2010 from Jan. 14, 2020 to Oct. 13, 2020 "to give Exchange Server 2010 customers more time to complete their migrations. This extension also aligns with the end of support for Office 2010 and SharePoint Server 2010." Administrators who run Exchange Server 2010 workloads on Windows Server 2008 will need to make adjustments due to the Jan. 14, 2020, end-of-life for that server operating system.
No matter what your organization chooses, navigating server setup and protocols takes time and planning.
Step 1: Take stock and check compatibility
Whether you plan on moving to a hybrid configuration or making a full move to the cloud, you must understand your current Exchange Server configuration. Monitor the mail flow connectors, learn the configuration of email gateways, and double-check that all the OSes and applications meet the compatibility requirements before you begin; otherwise, you could run into problems later.
Older Office suites, such as Office 2010, also prevent new functionality, such as Office Groups, from working with newer versions of Exchange. Outlook versions before 2013 can also create connectivity and security issues.
A move is also the perfect time to take stock of what services your organization actually uses and cut costs. For example, organizations often pay to license advanced functionality that employees don't need. Check these applications and services prior to a migration and make updates where needed:
Upgrade Microsoft Office and Outlook prior to a migration and install the latest cumulative updates and patches.
Ensure that Active Directory runs on a minimum of Windows Server 2008 R2 if you want to use Azure AD Connect with password write back.
Confirm third-party applications and VoIP platforms are compatible with Exchange Online and Office 365.
Plan any new licenses and certificates you will need.
Take note that modern applications often use Exchange Web Services, but Microsoft will no longer develop or update that functionality as of Oct. 13, 2020. If vendors have not adjusted their applications or prepared their VoIP platform for Exchange Online, you will have to plan around their unsupported products or work with them to find a solution.
Step 2: Set up your new deployment
Once you understand your current configurations, it's time to prepare your new destination. For a hybrid deployment, your organization will likely only need two Client Access Mailbox servers if everything -- other than relays left on premises for security -- has been moved to Office 365.
First, use a service account to import third-party certificates, and then install Exchange. To relay email, create and deploy entries from the old servers.
Next, set relay connector permissions for SMTP-Accept -Any-Recipient to send messages outside of the organization. Then, reset the relays and any gateways to direct mail flow to the new server IPs and virtual directories configured to the right domain names. Also, check the virtual directory names on the old Exchange servers.
Finally, run the Hybrid Configuration wizard to complete the setup.
Step 3: Plan for hurdles specific to your destination
Whether you are moving to a new on-premises server, a hybrid environment or fully to the cloud, you must investigate the nuances of your Exchange Server migration. For example, Exchange Online offers an appealing alternative to on-premises servers, but moving to the hosted messaging application presents its own challenges.
Exchange Online cannot maintain access for department groups from Active Directory unless you configure the Exchange Servers to sync to Azure AD, set a mail-enabled security group and then classify it as a universal group. You cannot fix this with PowerShell because Exchange Online does not recognize group members from a non-mail-enabled security group.
Even if everything seems to be working, wait a few weeks before you decommission your old server to make sure that all the mailboxes, archives and public folders made the trip successfully.
Administrators will no longer be able to appoint users to add or remove members on distribution lists through the Outlook address book. In this regard, admins gain another task to choose the best option between giving users limited access to Exchange utilities, selecting a third-party product to give users the ability to manage groups in AD or moving groups to Office 365. If none of these options work for your organization, your help desk might have to take on the task.
Mailbox performance slows down when you migrate Exchange Servers away from on premises, which is why Microsoft recommends setting mailboxes to cached mode. In secondary mailboxes, cached mode makes any email from before the switch off of online mode inaccessible in Outlook. Currently, there is no solution for this issue.
Step 4: Decommission your Exchange Servers
Even if everything seems to be working, wait a few weeks before you decommission your old server to make sure that all the mailboxes, archives and public folders made the trip successfully. The old server can also provide a failback option if a prerequisite, update or connection was overlooked.
Before you decommission a server, you should perform the following tasks:
In the Exchange Admin Center, check the status of the new servers and remove old servers.
Send test emails to external and internal accounts to make sure the mail flow works.
Connect established remote PowerShell scripts to the new servers.
Make sure your Autodiscover settings point your new servers to the Autodiscover URL.
Check the Client Access Server settings for virtual directories in the Exchange Admin Center.
Reboot the server with some downtime or recycle MSExchangeAutodiscoverAppPool via IIS without downtime.
To decommission servers such as Exchange 2013, you must transfer the arbitration mailboxes to your new server database. Find out what system mailboxes you have with Get-Mailbox -Arbitration, and then uninstall the remaining programs and features. Finally, reboot Exchange 2013, and then shut it down for the final time.
