As support for Exchange 2010 wanes and the bell is tolling for Exchange Server 2007’s useful life, a lot of organizations are taking a look at moving to Exchange Server 2016. Earlier we described how to proceed mailbox move request in Exchange 2010, now let’s take a look at how to deal with three most common showstoppers for Exchange migration, i.e. namespace issues, version control, and certificate problems.
1. Namespace issues
The migration to Exchange 2016 presents a great opportunity to consolidate some of the namespaces your company is using—that is, the domain names that you currently have in place for your users to access Exchange via Outlook’s remote procedure call (RPC) over HTTP functionality, Outlook Web App (OWA), the Exchange Control Panel, connections for smartphones, tablets, and newer versions of Outlook through ActiveSync, apps and extensions that interface with Exchange through Exchange Web Services (EWS), the Offline Address Book (OAB), and the Autodiscover service that helps clients automatically connect to Exchange without a bunch of confusing configuration information being required up front. Many smaller organizations combine all of those particular services under one “mail.domain.com” domain, but larger organizations, especially those that have grown up among a number of Exchange versions, might have them split apart.
Exchange Server 2016 requires that you bring all of these individual domains into Exchange if those domains are located in the same Active Directory geographical site. That’s fine for a couple of domains, but if you have six or seven, it may be a different story. You will need to prepare DNS changes (new A records or, better yet, CNAME records so that you can switch up servers without hanging new aliases out) and new SSL certificates for the services, and if you are using load balancing, you will need to switch up that profile as well.
Perhaps this is a great time to consolidate namespaces for your organization to make the migration much less complex?
2. Outlook (on the desktop) version control
The version of Outlook installed on the desktops that your clients use may very well drive your migration timeline. Outlook 2003 and 2007 cannot connect to Exchange Server 2016, namely due to the Autodiscover service that changes how it responds to client requests in 2016 in a way that these older versions of Outlook do not currently understand. These desktop versions of Outlook will not be updated to work with Exchange 2016. Interestingly, you can still use Outlook 2007 with Office 365, even though Office 365’s Exchange version is based on the 2016 product, but that could change at any time.
For larger organizations, this will generally mean running a parallel Exchange 2007, 2010, or 2013 operation while introducing some Exchange Server 2016 machines into the mix as well as scheduling user migrations for those clients who are already on later versions of Outlook for the first wave of migrations. For smaller shops, this may mean you focus on upgrading Office first before you proceed down the migration path. To get those stragglers on your new Exchange environment, you will need to also schedule them for Outlook upgrades or relegate them to using their mobile devices and Outlook Web App (ahem, excuse me, “Outlook on the web”).
Additionally, read: how to detect who accessed a shared mailbox in Office 365 in order to secure your data from being stolen.
3. Certificate problems
One of the most common issues you will encounter during or just after a migration is a certificate error on your clients. This mainly relates to the fact that Exchange, during installation, registers a service connection point (SCP) in Active Directory for the Autodiscover service, but it registers using the server’s actual domain name and not an alias for the service that you may have chosen (and may have used to register and purchase the certificate you are using from a trusted third party certification authority). You will need to switch this SCP registration for the domain name you used in the certificate so that they match, and the warning will go away.
The fix is a quick PowerShell command away. First, see what the current SCP registration domain is:
Get-ClientAccessService -Identity YOUREXCHANGEMACHINE | Select AutodiscoverServiceInternalUri
Then, change it to the one that matches your certificate namespace. In the following example, I’ll assume you have consolidated your namespaces into the generic “mail”:
Set-ClientAccessService -Identity YOUREXCHANGEMACHINE -AutoDiscoverServiceInternalUri https://mail.yourdomain.com/Autodiscover/Autodiscover.xml
Restart internet information services (IIS) on the affected machine just for good measure.
Need more tips regarding Exchange security? Our expert Jonathan Hassel shared visibility tips on how to protect shared mailbox from unauthorized access.
