With deploying the new Windows Server 2025 domain controllers and their successful replication, it is time to gradually shift the workload and client connections to these new servers. This transition should occur smoothly, ensuring that the older Windows Server 2016 domain controllers are relieved of their duties without causing disruptions such as login or lookup failures.
In Active Directory, clients locate domain controllers primarily through DNS SRV records. These records advertise domain controller services (such as LDAP, Kerberos, GC) for the domain. By adjusting these records and making some network configuration changes, we can influence which domain controllers clients will prefer. This process is often referred to as “draining” a server—similar to draining connections from a server behind a load balancer before taking it offline.
Understanding SRV Records and Priority/Weight
When a client needs to locate a domain controller (for logon purposes or LDAP queries), it queries DNS for records like ldap.tcp.dc._msdcs.contoso.com. DNS returns a list of all domain controllers for the domain, including each DC’s priority and weight values. By default, all DCs register with priority zero and weight 100. Clients randomly choose among the lowest priority records, with weights influencing selection among those of equal priorities.
Priority: Lower values indicate higher priority. Clients always attempt to connect with the domain controller having the lowest priority number first. For instance, if one DC has priority zero and another has priority 1, all clients will prefer the former until it becomes unavailable.
Weight: Among records with the same lowest priority, weight determines probability. For example, two DCs with priority 0: if one has weight 100 and the other has weight 50, the first will handle approximately two-thirds of client requests (100/(100+50)).
To make clients favor the new domain controllers:
- Raise the priority of the old DCs’ SRV records (making them less preferred).
- Optionally, you can also reduce the weight of old DCs or increase the weight of new DCs, fine-tuning the distribution.
This approach ensures that the old DCs remain available as backups while clients gravitate towards the new ones.
Adjusting DNS SRV Records for Domain Controllers
Let us implement this scenario:
Assume we have two old DCs (DC2016-1 and DC2016-2) and two new DCs (DC2025-1 and DC2025-2). Initially, all have a priority of 0 and a weight of 100 in DNS.
Determine new values: We prefer the new DCs. The simplest method involves setting the old DCs to priority 10 and keeping the new DCs at priority 0. This means clients will select the new ones unless none are available, in which case they will fallback to the old ones.
Modify the SRV records: Open DNS Manager and navigate to your domain’s msdcs records. Precisely, under your forward lookup zone (contoso.com), locate the folders: tcp (contains SRV for LDAP, Kerberos for the entire domain), sites -> Default-First-Site-Name -> tcp (site-specific records), _gc, etc.
You need to edit multiple records for each DC:
- ldap.tcp.contoso.com (generic LDAP SRV in _tcp) – list of all DCs.
- ldap.tcp.Default-First-Site-Name._sites.contoso.com (site-specific).
- kerberos.tcp… similarly.
- gc.tcp… (for global catalog advertisement, if GC).
Edit the records corresponding to DC2016-1 and DC2016-2:
- For each SRV record, double-click it in DNS Manager, which opens properties where you can adjust priority and weight.
- Change the Priority from 0 to 10.
- (Optional) Change Weight to 50 or even 0, reducing the chance of a new DC sharing the same priority.
- Save the changes.
Perform this for all of those DCs’ service records. While manually updating can be repetitive, it is straightforward. Alternatively, you can use PowerShell cmdlets such as Add-DnsServerResourceRecord or Set-DnsServerResourceRecord from the DNS module to script modifications.
Verify changes: Once adjusted, rerun the NSLOOKUP query:
nslookup -q=SRV ldap.tcp.dc._msdcs.contoso.com
You should see the list of DCs and their priorities/weights. The new DCs should display priority 0, while the old ones should show priority 10.
Consequently, any new client searching for a DC will almost always be directed to the new DCs. The old DCs remain accessible but are ranked lower. If a new DC is busy or unreachable, clients can still utilize an old DC, maintaining high availability.
Impact: This SRV change does not disrupt existing client connections immediately. Clients connected to an old DC may continue using it for a while. However, new connections and periodically refreshed queries will prefer the new DCs. Over time, the old DCs’ usage will naturally diminish.
Transition DNS and Other Services
Beyond SRV priority, another major factor influencing client interactions is how DNS servers are assigned. Often, clients, via DHCP or static configuration, use the IP of a DC as their DNS server. If all clients point to the old DC’s IP for DNS, they will continue sending name queries to the old DC.
Update DHCP scopes: Update the scopes to list the new DC’s IP as the primary DNS and perhaps keep an old DC as secondary. For example, if DHCP was handing out DNS = [192.0.2.10 (old DC), 192.0.2.11 (old DC2)], change it to [192.0.2.20 (new DC1), 192.0.2.21 (new DC2)]. Clients renewing their leases will pick up the new DNS server settings.
Static IP clients/servers: Do not overlook servers or devices with static DNS configurations. Update those to use the new DC IPs for DNS.
DNS delegation and forwarding: Update any external DNS or other systems referencing the old DC’s IP.
Application-specific: Reconfigure applications explicitly binding or querying certain DCs to use the new DC or a neutral name.
Administrative Tip: To identify who still uses an old DC, monitor its Network / CPU usage or event logs after making the above changes. Enable auditing of logon events on the old DC. Clients may not have updated DNS or cached it if significant logons occur.
Draining Authentication Traffic
In addition to DNS adjustments, directly discourage the use of the old DC:
- Stop the Net Logon service on the old DC temporarily.
- Unmark it as a Global Catalog in AD Sites and Services.
- Exclude from load balancers or VIPs if applicable.
With these measures, the new DCs should handle authentication and directory lookups while the old DCs serve as backup.
Replication Topology: Ensure new DCs have appropriate replication connections. New DCs should fully integrate into the replication mesh.
Real-World Insight: Gradually removing a DC from service helps identify dependencies, as seen when a multi-function printer broke due to hard-coded LDAP address book lookups. Monitor old DCs for error events and update configurations accordingly.
The new Windows 2025 DCs are operationally dominant at this stage, setting the stage for transferring the FSMO roles to the new servers. This process will be addressed next using PowerShell commands.
Cristal Kawula, Checkyourlogs.net
