Seven tips to help you successfully perform a domain controller network migration

【51CTO.com Quick Translation】Introduction: Changing network settings on a domain controller is usually a dangerous process, so it is best to avoid it. But if you must do it, here are some "tips" worth referring to.

Active Directory domain controllers are the last thing that should change on a server. They are used to authenticate users and devices to the domain, so once set up, it is best to leave them unchanged, especially when it comes to their corresponding hostnames or network details.

Although there is a brainless assertion in the industry that renaming domain controllers will almost never happen, in fact, in the operation of an enterprise, you will sooner or later encounter this day, and you must make corresponding adjustments to the network settings. For example, when a company undergoes a merger, its corresponding subnets may also be reorganized or even eliminated; at the same time, new subnets will be introduced, or due to some other factors, each domain controller must also be reinforced.

If you have set up redundant domain controllers (as any seasoned IT professional will do), it is relatively easy to move one subnet to another. The pain point can arise when both subnets are moved and client computers continue to look for domain controllers based on their old IP addresses and can't find them. I don't recommend doing this because it can cause all kinds of connectivity problems and even outages. But if you must do this, here is a "path" that is worth careful reference.

Here are seven tips for a successful domain controller network migration.

1. Check and create your firewall rules

Firewall rules, especially in complex environments, can be a huge hassle, so you need to ensure that the necessary traffic between subnets is available for communication between clients and domain controllers, and between domain controllers.

So whether you are creating new access rules or simply expanding your existing rules, firewall settings are critical. Otherwise, you will find that when these traffic attempts to "talk" to the domain controller, the system will have some very strange behaviors and phenomena.

Please ensure that at least the following ports are open:

Microsoft also notes: "In an environment with Windows Server® 2003-based domain controllers, the default dynamic port range is from 1025 to 5000. Based on recommendations from the Internet Assigned Numbers Authority (IANA), Windows Server 2008 R2 and Windows Server 2008 increase the range of dynamic port connections. The new default range is from ports 49152 to 65535."

This is a wide range and may even be more than you need, so please check the Microsoft settings link above to make sure that access is in place.

2. Configure sites and subnets on AD

If you want to make substantial changes to the subnet where the domain controller is located, please follow the steps below carefully (of course, if you just want to change the IP address and keep it in the original network environment, you can ignore this step).

Active Directory uses defined sites and subnets to perform communication, replication, and other background operational tasks.

Therefore, setting up the corresponding subnets for the Active Directory is crucial to ensure that the domain environment can continue to operate healthily. You'd better add subnets as needed and carefully review various configurations related to the domain environment. At the same time, please do not remove any subnets that are about to be "retired" in advance (if they can still be used) until they are really abandoned.

3. Focus on DNS

DNS records are important to ensure that clients can continue to communicate with their domain controllers. If you are using dynamic DNS, then any change to the domain controller's IP address will update the DNS records accordingly; if you are using static records, then you will need to manually adjust them after the cutover (either way, you should make sure that the records are correct). Also be sure to check any other static records associated with these hosts, including forward and reverse DNS zones.

If your domain controller also provides DNS information for some backup servers, you need to consider more than just the DNS records for Active Directory. You need to check various related settings to find out more about what needs to be updated.

4. Check the hosts file

Although it seems that it is now very easy to manage and use DNS, and worrying about the update of hosts files is a bit redundant, believe it or not, hosts files are still frequently used in the industry, especially in some production environments, or when DNS fails and domain name resolution is difficult.

If you are migrating dozens or even hundreds of systems, checking the hosts file of each machine one by one will be a very tedious process. You can use a simple Windows batch file to achieve this (Note: You must have administrator privileges on each target system. In this example, the Windows folder is installed on the C drive and is shared by default in the form of C$).

• Create a folder called c:\results.
• Create a text file containing all the target host names and save it to c:\results\computers.txt for review.
• Create a text file with the following line in it:

 FOR /F " tokens = 1 " %%i in (computers.txt) do xcopy \\%%i\c$\windows\system32\drivers\etc\hosts c:\results\%%i.txt

• Save the file as c:\results\hostck.bat
• Run c:\results\hostck.bat.

The file will access the hosts file of each target system and copy it to the c:\results folder, naming it after the corresponding computer name.

Then search for the relevant IP addresses in the c:\results folder according to your changes. You can also do the same on the target system as needed. Obviously, this is a bit tedious, and you may have to wait until the actual changes are made before you do the steps. Therefore, we also provide a simple method to update the host file: You can create a batch file named: c:\results\hostupdt.bat, and its content is as follows:

 FOR /F " tokens = 1 " %%i in (computers.txt) do xcopy c:\results\%%i.txt \\%%i\c$\windows\system32\drivers\etc\hosts /y

5. Configuration management software

Configuration management software such as Puppet or Chef can capture the IP address of the domain controller, as well as the physical connection of the subnet, and even generate various hosts files. However, configuration management clients will sometimes automatically correct some of your hosts file changes based on consistency, so remember to manually retrieve the current IP address of your domain controller.

6. Ensure that the VM-related network (if applicable) exists and is available

If you are migrating a domain controller to another subnet on a virtual machine, make sure that the subnet has been set up in the virtual environment and can be discovered and called by the virtual machine's hypervisor.

Of course, if the clients of each virtual machine only communicate with the domain controller (remember to allow such communication in the firewall rules in step 1), you don't necessarily need to add this subnet to the virtual environment. However, if you plan to allow the client to communicate directly with the domain controller without having to check it through the firewall rules, it is still worth considering adding it to the virtual environment.

7. Develop and execute your plan

Now that all the settings are in place, you can start making and executing your migration plan. You should inform your users of the migration time in advance, and it is best to do it during non-working hours to minimize the impact.

Please ensure that you only update one server at a time in the new network setup. If necessary, you can make real-time adjustments such as modifying configuration software, deploying hosts files, or updating DNS records.

If possible, monitor network traffic during the conversion process to ensure that clients can continue to communicate with the servers in the new environment. You can try to ping them, run the NSLOOKUP command, or access the domain controller in Windows Explorer to confirm that you can see the SYSVOL and NETLOGON shares. You can even shut down other domain controllers to confirm that you can log in to the domain and access Active Directory resources.

Once you have completed the switchover of all domain controllers, please confirm that other systems that originally interacted with the domain controller, such as the backup DNS servers, can still interact normally. For example, you can confirm whether they can pull various zone files from the domain controller in a normal manner.

If you encounter a problem that you cannot resolve and you may need to restore the original domain controller and its original network settings, then do not hesitate to do so. However, please remember that this is only a "delaying tactic" and you still need to investigate step by step according to the actual situation. For example, you can study and find clues based on the errors in the event log of the domain controller to determine the next course of action and further complete the migration project.

Title: You shouldn't change domain controller network settings, but here's how to do it if you must, Author: Scott Matteson

[Translated by 51CTO. Please indicate the original translator and source as 51CTO.com when reprinting on partner sites]