Upgrading Active Directory forests to Windows Server 2016 is a relatively straightforward process. In fact, there are a variety of ways in which you can go about performing the upgrade. Even so, Microsoft has established some best practice guidelines for upgrading Active Directory forests.
The basic idea behind Microsoft’s recommendations is that it is better to add Windows Server 2016 domain controllers and remove legacy Windows Server domain controllers than to try to perform an in-place upgrade on existing domain controllers. Admittedly, this approach is not always possible, and Microsoft does officially support certain in-place upgrade paths. However, Microsoft recommends replacing rather than upgrading domain controllers whenever possible.
Of course replacing your existing domain controllers with new ones is a big job, and it requires some careful planning. My goal in writing this article is to show you some of the tasks that may be required as a part of this process.
Upgrading Active Directory forests: First step
The first step in bringing a Windows Server 2016 domain controller into a legacy Windows Server domain is to install Windows Server 2016 onto a server that will eventually become a domain controller, and then join that server to the existing domain.
The next step in the process is to identify the current schema master for the Active Directory forest. You will also need to identify the infrastructure master for the domain that the Windows Server 2016 domain controller will be joined to. The easiest way to accomplish this is to open an administrative PowerShell window on a domain controller within the target domain and enter the following commands:
Get-ADForest | Select-Object SchemaMaster
Get-ADDomain | Select-Object InfrastructureMaster
You can see what this looks like in the figure below.
The reason why you need to know the name of the schema master and the infrastructure master is because the Windows Server 2016 machine will need to prepare the Active Directory schema and the Active Directory domain. Some administrators like to do this manually by using the ADPREP /FORESTPREP and the ADPREP /DOMAINPREP commands, but you don’t have to manually prepare the Active Directory unless you just want to. Converting the Windows Server 2016 server into a domain controller will cause the Active Directory to be automatically prepared. For this to work, however, the Windows Server 2016 server must be able to communicate with the schema master and the infrastructure master. That’s why it is important to identify the server that holds these roles. By doing so, you will be able to verify that the new domain controller is able to communicate with the infrastructure master and schema master before you attempt to upgrade the Active Directory.
Another thing that you will need to do before moving forward with a domain upgrade is to figure out what you want to do about DNS. Active Directory has a dependency on DNS. If you are going to be deprovisioning your legacy domain controllers, then this may mean that you are deprovisioning your DNS servers as well. In that type of situation, you can configure one or more of your Windows Server 2016 domain controllers to act as a DNS server, and then configure your DHCP server to use those server’s IP addresses as the organization’s DNS servers. Of course you may have to manually update any servers that are configured to use static IP addresses.
Add domain controller to the domain
To add a Windows Server 2016 domain controller to the domain, log onto the Windows Server 2016 machine, open Server Manager, and then launch the Add Roles and Features Wizard. Use the wizard’s role selection screen to install the Active Directory Domain Services and the DNS Server services (and any required features), as shown in the next figure.
When the installation process completes, open the Active Directory Domain Services Configuration Wizard, and use the option to add the domain controller to an existing domain, as shown in the figure below.
With the new Windows Server 2016 domain controller up and running, and network endpoints reconfigured to use the new DNS server, it is time to begin deprovisioning the legacy domain controllers. Before you do, however, it is a good idea to transfer all of the FSMO roles to a Windows Server 2016 domain controller. This used to be a really tedious task, but it has been made much easier thanks to PowerShell. So, from an administrative PowerShell window, enter this command:
Move-ADDirectoryServerOperationMasterRole -Identity “<your domain controller>” -OperationMasterRole 0,1,2,3,4
In case you are wondering about the numbers at the end of the command, each number corresponds to a specific role. You can see what this looks like in the figure below:
With the roles transferred, you can begin demoting your old domain controllers. In older versions of Windows, this means running the DCPromo command. In Windows Server 2012, you will have to use the Server Manager’s Remove Roles and Features Wizard to remove the Active Directory Domain Services. The first time that you try this, you will receive an error message like the one below. Notice however, that the error message gives you a link that you can use to demote the domain controller. Once the domain controller has been demoted, you can remove the Active Directory Domain Services role.
Once all of the legacy domain controllers have been removed, and the organization is running only Windows Server 2016 domain controllers, you can raise the forest and domain functional levels. Keep in mind that this means that you will not be able to add legacy domain controllers later on.
To raise the functional level, open the Active Directory Domains and Trusts console, and then right click on your domain and select the Raise Domain Functional Level command, as shown below. Once you have raised the domain functional level, right click on the Active Directory Domains and Trust container, and choose the Raise Forest Functional Level command to raise the forest functional level.
Remember, every AD is different
Upgrading Active Directory forests can be a big job. Although I have walked you through a sample migration, it is important to keep in mind that every AD environment is different. There will likely be steps that are unique to your own environment that will have to be performed as a part of the planning and migration process.