Migrating Active Directory from 2008 R2 to 2016

For this post I just wanted to note down my thoughts and plan that I recently used to migrate a client from Active Directory 2008 R2 to Active Directory 2016.  For this work the servers involved were four Windows 2008 R2 servers which all ran AD, DNS, DHCP and NPS.  These roles were being migrated to four Windows 2016 servers.  The servers are spread out geographically and are on different networks but are all part of a single AD domain.  All of the servers are Global Catalog servers.  This is not designed to be low-level guide with all the intricate details but more of an overview (with some useful commands thrown in).

Setting up the new servers

This stage was pretty easy as we were using VMware, all I had to do was create four new Windows 2016 servers from a template.  I then checked the domain health on the existing domain controllers using dcdiag /c and verified that there were no nasty errors in the event logs.  I next installed the Active Directory Domain Services and DNS roles on all of the servers.

Migrating the FSMO roles

To migrate the FSMO roles I used ntdsutil.  You can actually do this in the gui but I prefer to use the command-line so that I can verify everything as I go.  Here are the commands I used:

netdom query fsmo

ntdsutil
roles
connections
DC05.domain.local
quit

To transfer the Infrastructure Master role:

Transfer Infrastructure master

I then ran the below command after every transfer to confirm that it has worked successfully:

Netdom query fsmo

To transfer the domain naming master role:

Transfer naming master

To transfer the PDC emulator:

Transfer PDC

To transfer the RID Master role:

Transfer RID master

To transfer the Schema Master role:

Transfer schema master

DNS

As long as you are using AD integrated DNS like I was here there shouldn’t be anything to configure in DNS.  Verify that the zones have all replicated successfully and then point a desktop at the new DNS server to confirm it is working correctly.  If you have any specific DNS logging options set on the existing DNS servers you may want to replicate these on the new servers.

Once you are happy that the new DNS servers are working ok you will need to make the necessary changes in the DHCP scope options for your clients.  You will then need to change anything with the entries statically set (servers, printers, photocopiers etc.)

DHCP

To migrate the DHCP servers I used the same netsh commands that I have used or years and on many previous migrations.

Here is a quick run-down of the steps required to migrate the DHCP database. We need to carry this out on the two new Windows 2016 DHCP servers.

1. Log on to the old/existing DHCP server.
2. Click Start, click Run, type cmd in the open box, right-click, and then “Run as Administrator”.
3. Type the below:

netsh dhcp server export C:\temp\dhcp.txt all

and then press ENTER.

4. Install the DHCP role on the new ( Windows 2016) DHCP server using Server Manager.
5. Copy the exported DHCP text file to the C:\temp folder of the new DHCP server.
6. Verify that the DHCP service is installed and started on the new DHCP server.
7. Click Start, click Run, type cmd in the Open box, right-click, and then “Run as Administrator”.
8. Type the below:

netsh dhcp server import C:\temp\dhcp.txt all

and then press ENTER

9. Open DHCP console on the new server.
10. In the console tree, right-click DHCP.
11. Select “Authorize”.

Migrating the CA (Certificate Authority)

Information from various articles online suggests that migrating from a Microsoft CA to a server with a different name is not a good idea. The consensus seems to be to either build a new root CA or to do an in-place upgrade.  As I do not like doing in-place upgrades (due to past problems) I decided to just build a new CA and migrate everything across to it.  This was actually not as scary as it sounds.

Essentially it involved the below steps:

• Stopping and disabling the CA services on the existing CA.  (obviously check that you have no urgent need to issue any certificates before doing this!)
• Install the AD CA role on one of the new Windows 2016 servers and configure it the same way as the existing server.
• Create a new template that allows you to reenrol all certificate holders
• Export and re-issue the new root CA certificate to all client machines via group policy.
• Change any NPS policies that currently reference the old certificate and update to the new one (this was necessary for me as the client used 802.1x authentication for their WiFi authentication.
• Lastly update any client systems/applications (i.e. the internal antivirus server) that use a certificate to verify their identify.

None of this was actually disruptive at all because the old certificates remained intact throughout the process.

A quick tip – make sure that you enable the new certificate template after you have created it by opening the CA console>Right clicking on Certificate Templates and clicking New>Certificate Template to issue.

To force your machine to poll the CA and pick up the new certificate you can open a command prompt and type:

certutil -pulse

Migrating the NPS role

To migrate the NPS role I had to:
1. Install the NPS role on all of the new domain controllers
2. Export the NPS configuration from the existing NPS using the command:

netsh nps export filename="C:\temp\Config.xml" exportPSK=YES

3. Import the NPS configuration to the new domain controllers using the command:

netsh nps import filename="C:\temp\Config.xml"

We also had to make a change to enable MD5 in NPS for compatibility with the phones (that logged into the switches using 802.1x authentication and had been setup on the old server).  For this I found this article that was very useful.  This was essentially a harmless registry change as below:

The contents of the registry change are:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\4]
"RolesSupported"=dword:0000000a
"FriendlyName"="MD5-Challenge"
"Path"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
  00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,52,00,\
  61,00,73,00,63,00,68,00,61,00,70,00,2e,00,64,00,6c,00,6c,00,00,00
"InvokeUsernameDialog"=dword:00000001
"InvokePasswordDialog"=dword:00000001

Decommissioning the old servers

Before decommissioning the old/existing domain controllers I wanted to make sure that the new servers were functioning correctly.  I therefore ran a dcdiag /c and verified that the FSMO roles and Global Catalog servers were all correct and working ok.  I then disabled the netlogon service on the old domain controllers.  After a couple of days with the netlogon service disabled I shut the servers down completely.  Once I was happy that all was working well with out the old servers I started to decommission them.

This should have been an easy task, I ran DCPROMO and was very careful not to select the checkbox to remove the entire domain (fortunately this has been removed from 2012 onwards).

I was then greeted with an error unfortunately that stated ‘Active Directory could not transfer the remaining data in directory partition.’  This was a bit of a pain to fix and I have done a write-up of this here.  In short the problem stemmed from someone not correctly removing and old domain controller many many ions ago.  The only way to fix it was to remove all references to the old DC manually.  Once I had sorted this I was able to remove Active Directory and upgrade the functional level.