You shouldn’t change domain controller network settings, but here’s how to do it if you must
1 year ago
Active Directory domain controllers (DCs) are probably the most change-averse types of servers out there. Used for authenticating users and devices to the domain, these are best set up and left as is — especially when it comes to their host name or network details.
While it’s pretty much a no-brainer to state that renaming a domain controller is almost never going to be necessary, unfortunately, there may come a time when you have to change the network settings. Perhaps a subnet is being reorganized or retired, a company acquisition has occurred and new subnets are being introduced upon which domain controllers must be consolidated, or some other factor is at play.
If you’re set up redundant domain controllers (as any seasoned IT professional must do), moving one to a different subnet is easy. The pain points may arise when both are moved over and client computers continue searching for – and failing to find – the domain controllers at their former IP addresses. I don’t recommend it, since it can cause all sorts of connectivity problems or even outages, but if it must be done there’s a careful path to tread.
SEE: Quick glossary: Software-defined networking (Tech Pro Research)
Here are seven tips for successful domain controller network migrations.
1. Check and establish your firewall rules
Firewall rules, especially in complex environments, are likely to pose a huge headache. You need to ensure that traffic between the necessary subnets is appropriate for communication between clients and your domain controllers, and possibly between domain controllers and other domain controllers. Whether you’re setting up new access or simply expanding what you already have, this is a key element, otherwise you’ll see some very odd and confusing behavior on the part of systems attempting to talk to DCs.
At a minimum, these ports will need to be opened:
Microsoft also states that “in a domain that consists of Windows Server(r) 2003-based domain controllers, the default dynamic port range is 1025 through 5000. Windows Server 2008 R2 and Windows Server 2008, in compliance with Internet Assigned Numbers Authority (IANA) recommendations, increased the dynamic port range for connections. The new default start port is 49152, and the new default end port is 65535.”
That’s a big range and that might not even be all you need, so check that Microsoft link above and ensure the appropriate access is in place.
2. Configure Sites and Subnets in AD
If you’re actually changing the subnet of the domain controller, it’s important to follow this step (if you’re only changing the IP address but keeping it on the same network you can skip this).
Active Directory utilizes defined sites and subnets for communication, replication, and other tasks which operate behind the scenes. This guide explains how to set them up.
Getting the appropriate subnets set up in Active Directory is critical to ensure the continued healthy operation of your environment. Add subnets as needed and otherwise double-check to make sure everything is configured as it should be. Don’t remove any soon-to-be-retired subnets (if applicable) until they’re actually decommissioned, of course.
3. Focus on DNS considerations
DNS records are one of the single most important factors in ensuring clients can communicate with domain controllers. When you actually change the IP address of the domain controller the DNS records should update – as long as you are using dynamic DNS – but static records will need to be manually adjusted at the time of cutover (either way you should confirm the appropriate records are in place). Also make sure to check for any other static records pertaining to these hosts – and include the forward as well as reverse DNS zones.
It may not be just Active Directory DNS records you have to worry about; if your domain controllers are providing DNS information to secondary servers you need to examine the settings for those as well to find out what might need to be updated.
SEE: IT pros guide to the Windows 10 Fall Creators Update (free PDF) (TechRepublic)
4. Check host files
On the surface it may sound absurd to worry about updating host files when DNS is so much easier to manage and use. Believe it or not, host files are still very much in use, particularly in production environments – the most critical of all – whereby a DNS failure can cause massive difficulties.
If you have dozens or hundreds of potentially impacted systems, checking each machine’s host file can be a tedious process. You could use a simple Windows batch file to take care of that (note you must have administrative rights on the target systems, the C: drive holds the Windows folder and has been shared as C$).
- Create a folder called c:results.
- Create a text file containing all the target host names to check, then save it to c:resultscomputers.txt.
- Create a text file containing this line:
FOR /F “tokens=1” %%i in (computers.txt) do xcopy \%%ic$windowssystem32driversetchosts c:results%%i.txt
- Save the file as c:resultshostck.bat
- Run c:resultshostck.bat.
This will access each target system’s host file then copy it to the c:results folder and name the file after the computer in question.
You can then search the c:results folder for any relevant IP addresses you may need to change, then do so on the desired target systems as needed. Obviously you don’t want to do this until the actual change has been made, and one easy method to do so is to update the host files in the c:results directory, then create a batch file there called c:resultshostupdt.bat with these contents:
FOR /F “tokens=1” %%i in (computers.txt) do xcopy c:results%%i.txt \%%ic$windowssystem32driversetchosts /y
5. Configuration management software
Configuration management software such as Puppet or Chef may have the domain controller IP addresses/subnet hard-wired in somewhere, perhaps even to generate host files. It won’t do you much good to change those host files if your configuration management client is just going to change them back, so make sure to search for the current IP addresses of your domain controllers
6. Ensure virtual machine networks (if applicable) exist and are available
If you’re moving a domain controller to another subnet and it is a virtual machine, make sure the subnet exists in your virtual environment and is available to the hypervisor systems.
You won’t necessarily need to add this subnet to your virtual realm if it merely hosts clients which will communicate with the domain controllers (that’s what your firewall rules should permit in step #1), but it may be worth considering if you intend to add systems which you’d like to talk directly to the domain controllers without dealing with firewall considerations.
SEE: Open source champion Munich heads back to Windows (free PDF) (TechRepublic)
7. Develop and execute your plan
Now that the right components are in place, you can develop and carry out your plan. You should announce the work to users in advance and plan to do so after hours when there will be the least impact.
Make sure to update one server at a time with the new network settings and make any real-time adjustments as needed, such as configuration software changes, host file deployments or DNS record updates.
If possible, monitor network traffic during the conversion process to ensure clients are able to communicate with the server at it’s new location. You might try pinging it, running nslookup commands against it, accessing the server in Windows Explorer to confirm you can see the SYSVOL and NETLOGON shares, or even shutting down the other DCs then confirming you can log into the domain and access Active Directory resources.
Once you have all your domain controllers switched over, make sure other systems which interact with them are operating the way they should be, such as secondary DNS servers. Confirm they are pulling down the zone files from the DCs and otherwise behaving normally.
If problems arise which can’t be resolved, you may need to revert the DC back to its original network settings. Don’t hesitate to do so, but make sure it’s only a temporary situation. Revisit these steps in that scenario and research the symptoms/clues such as errors in the DC event logs to determine the next course of action to complete the project.