TIPS: seven tips to help you successfully implement domain controller network migration

TIPS: seven tips to help you successfully implement domain controller network migration

Introduction: Changing the network settings on the domain controller is usually a dangerous process, so you 'd better avoid it. However, if you must do so, here are some "Tips" worth your reference ".

The Active Directory domain controller (Active Directory domain controllers) should be the least changeable service on the server. It is generally used to assist the domain to verify the user and the device. Therefore, it is best to keep the settings unchanged, especially when the corresponding host name or network details are involved.

Although the industry has once circulated a brainless asserted that renaming domain controllers will never happen. But in fact, in the course of enterprise operation, you will encounter this day sooner or later, and you must adjust the network settings accordingly. For example, when a company makes a merger, the corresponding subnet may be restructured or even eliminated. Meanwhile, the new subnet will be introduced, or, due to some other factors, each domain controller must also be reinforced.

If you have configured redundant domain controllers (as is often done by any experienced IT professional), IT is relatively easy to move a subnet to another place. When the two subnets are moved at the same time, and the client computers continue to search for domain controllers based on their previous IP addresses, but cannot find them, the pain points may arise. Therefore, I do not recommend this because it may cause various connection problems or even interrupt. However, if you have to do so, we will provide you with a "path" that deserves careful reference ".

Here we will list the seven tips for successfully migrating the domain controller network.

1. Check and establish your firewall rules

Firewall rules, especially in complex environments, may cause huge troubles. Therefore, you must ensure that the traffic required between subnets can be used for communication between the client and the domain controller and between the domain controllers.

Therefore, whether you want to create new access rules or simply expand your existing rules, firewall settings are critical. Otherwise, you will find some strange behaviors and phenomena in the system when these traffic and Domain Controller attempt to "talk.

Make sure that at least the following ports are enabled:

Microsoft also pointed out :"®In the 2003 Domain Controller environment, the default dynamic port range is from 1025 to 5000. Windows Server 2008 R2 and Windows Server 2008 increase the range of dynamic port connections, as recommended by Internet digital distribution agencies (Internet Assigned Numbers Authority, IANA. The new default range is from Port 49152 to port 65535 ."

This is a wide range and exceeds your real needs. Therefore, check the links set by Microsoft to ensure that the access connection is in place.

2. Configure the site and subnet on AD

If you want to change the subnet of the domain controller, follow these steps carefully (if you only want to change the IP address, if you keep it in the original network environment, you can ignore this step ).

The Active Directory uses established websites and subnets for communication, replication, and other background operational tasks.

Therefore, setting the corresponding subnet of the Active Directory is crucial to ensure that the domain environment can run continuously and healthily. You 'd better add subnets as needed and carefully review various configurations related to the domain environment. At the same time, do not remove any subnets that will be "retired" in advance (such as those that can still be used) until they are indeed discarded.

3. Focus on DNS

DNS records are one of the important conditions for the client to continuously communicate smoothly with their domain controllers. If you are using dynamic DNS, as long as you change the IP address of the domain controller, the DNS record will be updated accordingly. However, if you are using Static Records, then you need to manually adjust it after cutover (no matter which method, you should confirm that the corresponding record is accurate ). Check any other static records associated with these hosts, including forward and reverse DNS regions.

If your domain controller also provides DNS information for some backup servers, you need to consider not only the DNS records of the Active Directory, but also the various settings, to find more content to be updated.

4. Check host files

Although, on the surface, it is now very easy to manage and use DNS, and then worry that the host file update will be slightly redundant. However, whether you believe it or not, host files are still frequently used by the industry, especially in some production environments, or when domain name resolution is difficult due to DNS faults.

If you involve dozens or even hundreds of systems during the migration process, it is very cumbersome to check the host files of each machine one by one. You can use a simple Windows batch processing file (Note: You must have administrator permissions for each target system. In this example, the Windows folder is installed on drive C and shared by default in the form of C $ ).

• Create a folder named c: \ results.
• Create a text file containing all the target host names and save it to c: \ results \ computers.txt for check.
• Create a text file that contains the following lines:

  
  

   
   
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 running of this file will access the host file of each target system, copy it to the c: \ results folder, and name the file with the corresponding computer name.

Then, search for the IP address in the c: \ results folder based on your changes. You can also perform the same operation on the target system as needed. Obviously, this is complicated, and you may need to wait until the actual changes occur before proceeding. Therefore, we also provide a simple method to update host files: You can create a batch file named c: \ results \ hostupdt. bat. The 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 IP addresses of domain controllers, as well as subnet physical connections, and even generate various host files. However, the configuration management client may automatically correct some of your host file changes based on uniformity. Therefore, remember to manually retrieve the current IP address of your domain controller.

6. Ensure the existence and availability of virtual machine-related networks (if applicable)

If you migrate a domain controller to another subnet on a VM, make sure that the subnet has been set up in the virtual environment and can be discovered and called by the VM administrator.

Of course, if the client of each virtual machine only communicates with the domain controller (remember to allow such communication in the firewall rules in step 1 ), you do not need to add the subnet to the virtual environment. However, if you want to allow the client to communicate directly with the domain controller without checking the firewall rules, it is worth considering joining the virtual environment.

7. Develop and execute your plan

Now, the various settings are ready. You can start to develop and execute your migration plan. You should inform the user of the migration time in advance. Of course, it is best to put the migration time in non-working hours to minimize the impact.

Make sure that only one server is updated at a time in the new Network Setting environment. If necessary, you can make real-time adjustments, such as modifying configuration software, deploying host files, or updating DNS records.

If possible, monitor network traffic in real time during the conversion process to ensure that each client can continue to communicate with servers in the new environment. You can ping them, run the NSLOOKUP command, or access the domain control server in Windows Resource Manager to check whether SYSVOL and NETLOGON are shared. You can even shut down other domain controllers to ensure that you can log on to the domain and access resources in the Active Directory.

Once you have switched all the domain controllers, make sure that other systems that interact with the domain controller server, such as the standby DNS server, can still interact as usual. For example, you can check whether they can normally pull various regional files from the domain control server ).

If you encounter a problem that cannot be solved, but you may need to recover to the original domain controller and its original network settings, do not hesitate to do so. However, please remember that this is only a "slow strategy", and you still need to troubleshoot it gradually based on the actual situation. For example, you can study and discover clues based on errors in the event logs in the domain controller, so as to determine the next step 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, by Scott Matteson