Domain Controller Migration - intermediate concepts

This article assumes you have the basics of DC migration down pat - as documented here - https://www.experts-exchange.com/articles/36874/Domain-Controller-migration-intermediate-concepts.html

This article expands upon some sections and adds some new methods and suggestions for larger or more complex environments - which may require less downtime or more analysis.

Tools
In larger environments, using repadmin or the AD replication status tool to verify replication status is advisable.

Multi-domain forests
Nothing too complex here - the main difference between this and single domain forest is that we need to be sure the changes have replicated everywhere in the forest/domain before proceeding.

• You need to update your forest first (which will update the schema etc)
• Depending on your replication topology, you may need to wait some time for full replication to occur - only you can know how long full replication takes in your environment.
  • In order to check, you can use the LDP tool to verify the schema version on each DC
  • Run LDP.exe | Connection | Bind
  • View | Tree | CN=Schema,CN=Configuration,DC=<DomainName>,DC=<Com>
  • Click OK to run the LDP query against the above LDAP path.
  • In the right pane, check objectVersion attribute. 
  • When they all match - the changes have replicated
  • Here are the versions for reference - https://social.technet.microsoft.com/wiki/contents/articles/37395.active-directory-schema-versions.aspx

Realistically, for companies which have 50+ DCs (although those are rare these days) - you won't check them all, but probably some core DCs and the outliers that you know are the slowest to replicate.

Use DNS record weight and priority to direct traffic away from the "old" DCs
Once the IP swap is completed, but the "old" DCs are still online, you can minimise traffic directed to these DCs.

You can read about DC weight and priority here - https://dirteam.com/paul/2010/07/09/changing-the-weight-and-priority-of-a-domain-controller-within-a-site/

My recommendation is to change the priority of the "old" DCs to 10 (from the default of 0). The result of this is that the DCs you have changed this on should receive no auth traffic from lookups, but they will still receive auth traffic that is directly and specifically sent to that DC. This can help us to find if any 3rd party apps or appliances have been specifically configured to use one of these DCs by name.

Tracking LDAP or other connections
Some environments will have products that connect to AD via LDAP, LDAPS, NTLM etc with hard coded configuration entries.
In larger environments, particularly those with a high staff turnover, the details of what is talking to AD via what method may get lost over the years.

Where these products are configured with IP addresses, they should continue to "just work" - assuming you are using the IP swap method.... however, tracking these down to verify removes risk from your migration.

In my opinion, the following steps should be performed on the "old" DCs once the IP swap and DC weight change has been completed. This means you will only find relevant entries for apps that are still pointing to the "old" DCs

Set the following registry entries in order to increase logging for your desired protocol:

LDAP(see linked article for logging level references)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\16 LDAP Interface = 3

Look in the security log for these events

Kerberos

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\LogLevel = 1

Look in the system log for these events

NTLM
Set NTLM logging via local policy via
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all

Look in the "NTLM Auditing" event log for these events

Important: Once you are done - remember to reset these additional logging settings!

Ensure NTP is configured on your PDCe
Since the DC that is hosting your PDCe role will have moved, ensure that NTP is configured on this server, as it is now the primary time source for your domain.

I like to create a WMI filter to target the PDCe specifically, as outlined here - http://www.cloudyfuture.net/2016/01/26/configure-pdc-emulator-ntp-settings-using-gpo/

Shutting down old DCs
Once the old DCs are demoted and shutdown, keep them around in a shutdown state for a period of time. If you do have an issue because something is pointing to one of these DCs - it can be pretty quick to start the server up and re-promote it in order to minimise impact to the business.

It is important that you don't raise the domain and forest functional levels until after this period has expired - otherwise you will not be able to re-promote older DCs

SMB 1
While unlikely, it is possible that some services on your network are still using SMB1. While this is not installed by default on 2016/2019/2022, it can be easily and quickly added if required.

If you wish to determine if SMB1 is in use - you can enable SMB auditing as per https://docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3

Cleaning up
Removing the old DC from AD sites and services is easy enough, but in large environments you may have a large number of DNS reverse lookup zones....  in order to clean the old DCs out of these you can use

Get-DnsServerZone -ComputerName <one of the new DCs> | where {$_.IsReverseLookupZone -eq "True"} | ForEach-Object {Try {Remove-DnsServerResourceRecord -ZoneName $_.ZoneName -RRType "NS" -RecordData "<name of one of the old DCs>" -Name "@" -force} catch {"$_"}}