Any Exchange 2016 migration project should begin with a thorough review of the existing environment. It’s important that you discover any elements of the environment that might impact the migration, or that don’t meet the requirements for deploying Exchange 2016 that are documented on TechNet.
The environment requirements for deploying Exchange 2016 include:
- Coexistence with existing Exchange servers
- Supported hybrid deployments
- Active Directory and domain controller requirements
- DNS requirements
- Supported Outlook client versions
Exchange 2016 Coexistence with Existing Exchange Servers
If you have existing Exchange servers in your organization, the minimum supported versions for coexistence with Exchange 2016 are:
- Exchange Server 2010 SP3 with UR11
- Exchange Server 2013 CU10
Those are the minimum versions that need to be deployed to all servers within the organization, but you should review the latest Exchange Server build numbers and make sure you’re up to date. For example, even though CU10 is the minimum version of Exchange 2013 supported for coexistence, CU10 is actually out of support right now.
There is no support for coexistence with Exchange 2007 or earlier. If you have Exchange 2007 or earlier servers deployed in your organization, you’ll need to remove those servers first. Usually this involves an intermediate upgrade to a version of Exchange that is supported for Exchange 2016 coexistence. For example, an Exchange 2003 environment can migrate to Exchange 2010 first, or an Exchange 2007 organization can migrate to Exchange 2013 first. Only after that first migration has been completed can the Exchange 2016 servers be deployed.
For the Not Real University environment, the current versions of Exchange deployed can be reviewed by running Get-ExchangeServer from the Exchange Management Shell.
[PS] C:\>Get-ExchangeServer | Select Name,AdminDisplayVersion
NREXCH10 Version 14.3 (Build 123.4)
NREXCH13 Version 15.0 (Build 1210.3)
NREDGE13 Version 15.0 (Build 1210.3)
You can use the Exchange Server build numbers page on TechNet to interpret the results. The build numbers displayed will need leading zeros added to translate to the build numbers on TechNet. For example, “Version 14.3 (Build 123.4)” is “14.03.0123.004”, which is Exchange Server 2010 SP3. Similarly, “Version 15.0 (Build 1210.3)” is “15.00.1210.003”, which is Exchange Server 2013 CU13.
Exchange 2010 build numbers do not reveal the update rollup number that has been installed on the server. For that information you can review the list of installed updates on the server, by navigating to Control Panel, Programs and Features, and then selecting View installed updates.
If there are Edge Transport servers in the environment, as there are for Not Real University, then you will need to be aware of how the build numbers will be reported by Get-ExchangeServer. The build number stored in Active Directory for an Edge Transport server is whatever version it was running at the time the Edge Subscription was created. Because the Edge Transport server is not a domain member, and because EdgeSync is a one-way process, any updates to the Edge Transport server don’t update the build number stored in Active Directory. If Exchange 2016 setup detects an unsupported build number in Active Directory it will block the installation of Exchange 2016, even if the Edge Transport server is actually running a build that is supported for coexistence. The solution to this problem is to update the Edge Subscription by following the same steps used to create it initially, which will update Active Directory with the current build number for the Edge Transport server.
For Not Real University all existing Exchange servers meet the minimum requirements for coexistence with Exchange 2016.
Installing Exchange 2016 is supported for hybrid Exchange deployments. A support condition for hybrid deployments is that they stay up to date with the supported builds of Exchange. For example, an Exchange 2013 server in a hybrid environment must be running at least CU12 today (and that will be unsupported once CU14 has been released). Since the requirements for a hybrid configuration with Exchange 2013 are much the same as Exchange 2016, if you already have an Exchange 2013 hybrid configuration then deploying Exchange 2016 should go fairly smoothly. You should review the Exchange 2016 hybrid deployment prerequisites anyway, just to make sure nothing has been missed. After Exchange 2016 has been fully deployed it will be a good opportunity to re-run the Hybrid Configuration Wizard and update the hybrid configuration to use Exchange 2016. Eventually you will need to re-run the HCW anyway, so that the hybrid configuration can be updated to utilize the Exchange 2016 server, and before the legacy servers can be decommissioned.
Not Real University does not currently have a hybrid configuration in place.
Active Directory and Domain Controllers
Exchange 2016 can be installed in existing Active Directory environments that meet the following minimum requirements:
- Forest functional level of Windows Server 2008 or higher
- All domain controllers in the forest must be running Windows Server 2008 or later
- At least one domain controller in the site where Exchange 2016 is being deployed must be a global catalog
It is supported, but not recommended for security and performance reasons, to install Exchange 2016 on a domain controller. Exchange also does not support read-only domain controllers (RODC), so there must be at least one writeable domain controller in each Exchange site.
To review the Active Directory environment you can run the Get-ADInfo.ps1 script in PowerShell. The output of the script includes the forest and domain modes (functional levels), FSMO role holders, and UPN suffixes, as well as a list of global catalog servers per site. For the Not Real University environment the output of the script is as follows.
PS C:Admin> .Get-ADInfo.ps1
*** Forest: notrealuniversity.com ***
Forest Mode: Windows2008R2Forest
Schema Master: NRDC01.notrealuniversity.com
Domain Naming Master: NRDC01.notrealuniversity.com
Additional UPN Suffixes:
*** Domain: notrealuniversity.com ***
NetBIOS Name: NRU
Domain Mode: Windows2008R2Domain
PDC Emulator: NRDC01.notrealuniversity.com
Infrastructure Master: NRDC01.notrealuniversity.com
RID Master: NRDC01.notrealuniversity.com
*** Global Catalogs by Site/OS ***
Site, OS Count
Default-First-Site-Name, Windows Server 2012 R2 Datacenter 1
For Not Real University the minimum Active Directory requirements have been met, and no changes are required.
Microsoft includes disjoint namespace guidance for Exchange deployments that aligns with the overall recommendations for Active Directory. The three scenarios for disjoint namespace are:
- Primary DNS suffix and DNS domain name of domain controllers are different
- Primary DNS suffix of the Exchange server is different from the DNS domain name
- NetBIOS name of domain controllers differs from the subdomain of its DNS domain name
When installing Exchange 2016 into an existing Active Directory and Exchange environment it’s likely that any genuine impact of a disjoint namespace scenario has already been addressed. However, if you’re not sure then you can review Microsoft’s disjoint namespace guidance for Exchange 2016.
The most common disjoint namespace is a mismatch between the NetBIOS name and the DNS domain name, for example with Not Real University the NetBIOS name is NRU, and the DNS domain name is notrealuniversity.com. Microsoft’s guidance does include that scenario, however in the real world I’ve never found it necessary to implement the suggested fix.
For Not Real University, no steps to address the disjoint namespace will be performed.
Supported Outlook Client Versions
Exchange Server 2016 can be used with the following versions of Outlook:
- Outlook 2016
- Outlook 2013
- Outlook 2010 with KB2965295
- Outlook for Mac for Office 365
- Outlook for Mac 2011
Those are the minimum requirements, however you should ideally be updated to the latest patches and service packs for the versions of Outlook in your environment to ensure the best user experience.
If your environment has no software inventory solution in place and you’re unsure about the versions of Outlook that are deployed, then you can use tools such as ExMon and Log Parser to collect information from Exchange about which versions of Outlook are connecting.
Not Real University is running supported versions of Outlook, so there is no client remediation required before continuing the migration project.
In this post we’ve looked at collecting information about the existing environment to compare to the system requirements for Exchange 2016. In the next part of this series, we’ll look at information that can be collected from the existing Exchange servers to help with the design and planning of the Exchange 2016 deployment.