By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
- Replication doesn't work
- Users can't log in
- Error message about not being able to locate a domain
- Not being able to promote additional domain controllers
- Not being able to demote domain controllers
- Not being able to create a trust relationship
- Group policies not being applied
All of these issues generally revolve around not being able to locate the services in the Windows 2003 domain. This all begins with DNS. Windows 2000 and Windows 2003 rely heavily on DNS to be able to register and locate services – "services" not servers.
Let's start by understanding DNS for the world and then DNS as Microsoft sees it. DNS has traditionally been a UNIX operation. Versions of BIND are used in conjunction with zone files to create tables that can then be queried by systems looking for particular servers. Server records (A records) are you typical name = IP address. A PTR record is the reverse, given IP address find name.
Microsoft likes standards, but likes expanding on them even more. Microsoft leveraged the SRV record (RFC 2782) and the dynamic updates (RFC 2136) to the DNS table. UNIX systems that support these RFC's most commonly use BIND version 8.1.2 at a minimum. While BIND will support the RFC's, it still doesn't much appreciate Microsoft's avid use of the underscore in the service names. Note also that Microsoft Windows NT's DNS does not support RFC 2136.
When a workstation like Windows XP is looking for a domain controller, it is NOT searching for the A-record of you domain controller. It is looking for the SRV record that describes the LDAP and Kerberos services that are available. The records look like:
A UNIX server can find this to be a rather distasteful query. Therefore, it is usually better to have Windows 2000 and Windows 2003 servers hosting the INTERNAL DNS zones used by the workstations. Now that the design lesson is over, back to the problem at hand. How do we know when the DNS is the problem and what types of things can be do about it.
There are a couple of tools in the Windows 2003 Support tools that will allow you to determine if DNS or other networking issues are the problem. I usually run these prior to going any further. The first is NETDIAG.exe. Running NETDIAG –v will provide you with an excellent detail of what it the configuration and potential issues on the server. I would run this on the domain controllers.
If it does appear that the DNS records are not in the DNS zones, you can validate by using the DNS MMC. Look for the DC and GC SRV records like the one above. For more information on the format of the records you are looking for see this article:
If you need to re-register the Domain Controllers SRV records, there are two ways in Windows 2003:
1. Stop and Start the NETLOGON service
2. Run NETDIAG /fix
The NETDIAG /fix option is from Windows 2003. With Windows 2000 you only have the choice of stopping and starting the NETLOGON service. Note that IPCONFIG /REGISTERDNS has the effect of updating the A and PTR records, not the SRV records.
After you have done this, run the NETDIAG again to see if the DNS issues are dissipated. If not, you will need to check the IP configuration of your servers to make sure that you are completely aware of which DNS server they are pointing to and that it is the right server to be pointing to.
Next, you will want to check that there are no errors on the DNS server in the Event log and that the DNS services are really running. If there are errors, you will need to investigate them. Stopping and starting the DNS services may help at
Dig Deeper on Domain Name System (DNS)
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.