The Domain Name System (DNS) is an Internet standard for mapping Internet computer names (called “host names”) to numerical Internet Protocol addresses (called “IP addresses”). The DNS server contains a database of all of the host names for a domain.
Active Directory uses DNS to locate the domain controllers in a domain.
|Note: Incorrect configuration of DNS is the number one cause of problems with Active Directory. If DNS is configured incorrectly, domain controllers will not be able to locate each other for replication. Client computers will not find their domain controller(s), and users will not be able to log on.|
A domain controller uses DNS to connect back to itself. If DNS is incorrectly configured, the domain controller will not be able 'see' itself, causing loopback errors that will prevent the DC from connecting to its own local AD database.
U-Move moves all DNS settings by default
Because DNS is critical for Active Directory, U-Move is careful to move all DNS settings from the source computer to the destination computer when cloning AD. This includes the following:
- Client DNS settings
- Server DNS settings
- Server DNS zone data files (\Windows\system32\dns\*)
- Hosts and lmhosts text files (\Windows\system32\drivers\etc\*)
By moving all DNS settings, U-Move prevents potential DNS errors due to differences in the DNS settings between the old and new computers.
Option: Skip moving the Client DNS Settings
If you choose do not copy the IP addresses, U-Move will skip moving the client DNS settings, the hosts file, and the lmhosts file from the old computer to the new computer This can be useful when moving AD to another network (such as the cloud).
U-Move will display the current client DNS settings and ask you to review and confirm them during the interview.
Types of moves: Clone versus Upgrade
When cloning AD using an emergency move or a planned move, the DNS settings and zones will carry over transparently to the new computer. The only issue is re-registering dynamic DNS records written more than 7 days ago (see below).
When upgrading AD (swing migration), the DNS settings and zones will carry over transparently to the new computer.
Troubleshooting DNS Problems
To troubleshoot DNS run Dcdiag to verify DNS connectivity:
dcdiag /v /test:DNS
The following is an example of a successful run of Dcdiag:
Directory Server Diagnosis Performing initial setup: Trying to find home server... Home Server = MyServer * Identified AD Forest. Done gathering initial info. Doing initial required tests Testing server: Default-First-Site-Name\MyServer Starting test: Connectivity ......................... MyServer passed test Connectivity Doing primary tests Testing server: Default-First-Site-Name\MyServer Starting test: DNS DNS Tests are running and not hung. Please wait a few minutes... ......................... MyServer passed test DNS Running partition tests on : ForestDnsZones Running partition tests on : DomainDnsZones Running partition tests on : Schema Running partition tests on : Configuration Running partition tests on : MyDomain Running enterprise tests on : MyDomain.com Starting test: DNS Test results for domain controllers: DC: MyServer.MyDomain.com Domain: MyDomain.com Summary of test results for DNS servers used by the above domain controllers: Summary of DNS test results: Auth Basc Forw Del Dyn RReg Ext _________________________________________________________________ Domain: MyDomain.com MyServer PASS PASS PASS PASS PASS PASS n/a ......................... MyDomain.com passed test DNS
If Dcdiag reports a failed DNS test, you should first
check network connectivity
with the DNS server. Use the commands
verify that the DNS server is visible on the network and can resolve
the DNS records.
Not all failed DNS tests indicate errors. For example if you are running AD on an isolated network for offline testing in your lab, Dcdiag will fail the DNS test because there are no DNS forwarders that can reach the Internet. This is normal and expected.
Another common failed DNS test is the lack of a reverse PTR record. PTR records are optional; many sites to not configure them. PTR errors are normal and can be ignored.
Troubleshooting: The DNS Client service
The DNS Client service caches results from the DNS service. This includes “negative” results where an address is not found. You should flush the cache of the DNS Client service before troubleshooting any changes to your DNS configuration:
To assist you in troubleshooting DNS problems, upon each boot
the domain controller will write a copy of its desired DNS records
to a text file. The text
file is named
You can inspect this file (use NOTEPAD.EXE) in order to verify that your
DNS server contains the correct
A, PTR, and SRV records for the domain controller.
If your DNS server does
not contain the records listed in
netlogon.dns, you need
to find the cause and correct it. If you are using dynamic DNS updates,
to investigate why the domain controller failed to update the dynamic
records (for example, the NIC has the wrong DNS client IP address).
If you are using static DNS, you may need to manually recreate the
necessary A, PTR, and SRV records.
The DNSLint Utility
can be used to diagnose DNS errors. On the moved domain controller type the command
dnslint /ad 127.0.0.1 /s localhost /v
Immediate re-registration of DNS records
If you see errors in the Event Log due to problems with locating a domain controller in DNS that has failed to dynamically register its DNS address, and you do not want to wait 5-10 minutes for automatic re-registration, you can force the domain controller to immediately register its IP address with the DNS server. Open an administrative console and type the following commands:
The ipconfig command will tell the computer to send ("register") its DNS A and PTR records to the DNS server. The nltest command will register the SRV records. The SRV records are used to locate domain controllers.
Ipconfig and Nltest are built-in utilities.
|U-Move for Active Directory|