If Domain Controllers Cannot Be Found

If clients or servers are receiving a message telling them that the DC cannot be reached, you should first use ping on the affected computers to test whether a connection to the IP address of the server works. If this works, make sure the IP address of a DNS server that can resolve the DC is set in the network settings of the servers. In the network settings of the DCs themselves, the DNS servers must be defined such that name resolution works.

If name resolution is still not working after completing these basic checks, the DC records may be missing in the DNS zones. You will find these settings below _msdcs on the DNS servers. On the DCs, you will discover such errors fastest by typing dcdiag at the command prompt. Also use nltest /dsgetsite to check that the DC is assigned to the correct AD site (Figure 4). Typing

nltest /dclist:<NetBIOS name of domain>

Figure 4: Parameters to the nltest command let you check the status of DCs.

displays a list of all DCs in a corresponding domain. The entries should be listed as FQDNs. The command

nltest /dsgetdc:  NetBIOS name of domain

is also important and lists the name, IP address, GUID, AD FQDN, and other information. All information should be free of errors.

Use net start netlogon and then net stop netlogon to start and stop the NetLogon service on the new DC. On startup, the service attempts to re-register the data from the netlogon.dns file. If it encounters problems, you will find an entry in Administrative Tools | Services | System Event Notification Service Properties that can help you determine the problem.

Also, nltest /dsregdns often helps with DNS registration problems. If re-registration does not work by restarting the NetLogon service, delete the DNS _msdcs zone and delegation. The next time you restart the NetLogon service, it reads the data from netlogon.dns, recreates the _msdcs zone, and writes the entries back into the zone. You can then use dcdiag to see whether the problems are fixed or perform an extended test with dcdiag /v.

Checking DCs

To troubleshoot AD replication, make sure that name resolution is working on the network. Name resolution is a basic precondition for AD replication. The dcdiag /v command lets you perform a thorough check of AD. If errors appear here, you may well have found the cause of the replication errors. Enter the error in a search engine for information on troubleshooting. dcdiag /a checks all DCs at the current AD site, whereas dcdiag /s checks all the DCs in the forest. To display only the errors, use dcdiag /q. If you want to test only a single DC over the network, use:

dcdiag /s:<name of DC>

If you see any errors, you should first restart the server and then see which entries are in the Event Viewer and whether all services started (e.g., the system services for the DNS Server and AD).

Review all the errors in dcdiag and search for them on the Internet. Typing

dcdiag /v >c:\temp\<filename>.txt

redirects all the data to a text file, from which you can copy and check for errors.

The various advertising tests and flexible single-master operations (FSMO) role tests need to work correctly in all cases. By using nslookup and ping, you can test name resolution and communications between the DCs. The repadmin /showreps command shows the DC replication setup. If individual DCs cannot replicate, you will quickly see which DC is the root cause. Typing

repadmin /showreps >c:\<filename>.txt

lets you redirect the data to a text file, and

repadmin /showreps * /csv > c:\<filename>.csv

redirects output to a CSV file You can import this into Excel, for example, for better troubleshooting.

Use the Active Directory Sites and Services Microsoft Management Console (MMC) to check Sites | <name of site> | Servers and see whether all your DCs are listed. You will find an NTDS Settings entry below each DC. Click on this to see the replication connections to other DCs in the window to the right. The connections are generated automatically. You can start replication manually from the context menu (Replicate Now ). If an error is displayed, you need to check why the DCs are unable to communicate.

Additionally, you will want to check that all the DCs are registered properly in the AD. To do this, use nltest /dclist:contoso. Check the individual DCs to see whether they know their own locations with nltest /dsgetsite.

Make sure that all DCs are shown with their DNS names. If this is not the case, check whether the correct DNS server is registered on the DC, the DNS server has the server and its IP address, and finally, name resolution works with nslookup.

The Knowledge Consistency Checker (KCC) connects to the DCs at the different sites and automatically creates a replication topology based on the defined schedules and site links. If a replication connection does not work, read the server GUID for each server with repadmin /showreps. Each server displays the DSA object GUID in the window. You need to use this to add a connection and then use the GUIDs with the repadmin /add command. The domain name in this example is contoso.int , and the server GUIDs for the two DCs are:

• DC1 GUID = e8b4bce7-13d4-46bb-b521-8a8ccfe4ac06
• DC5 GUID = d48b4bce7-13d4-444bb-b521-7a8ccfe4ac06

Go to Active Directory Sites and Services and delete all the connection objects. Next, create a new connection from the defective DC to a working DC:

repadmin /add "cn=configuration, dc=contoso,dc=int" e8b4bce7-13d4-46bb-b521-8a8ccfe4ac06._msdcs.contoso.int d48b4bce7-13d4-444bb-b521-a8ccfe4ac06._msdcs.contoso.int

Use the appropriate server GUIDs and domain names for your environment. During this procedure, error 8441 (distinguished name already exists ) may appear. In this case, the connection already exists. Perform a full replication of the connection you created with:

repadmin /sync cn=configuration,dc=contoso,dc=int DC1 e8b4bce7-13d4-46bb-b521-8a8ccfe4ac06 /force /full

Then, in the Active Directory Sites and Services snap-in, make sure that automatically generated connection objects from the defective machine to a functioning DC again exist and make sure that replication works in all directions. Also check whether the individual FSMO roles are known on the network. You can view these in a single action using:

netdom query fsmo

For an individual view, use the following commands:

• PDC-Master: dsquery server -hasfsmo pdc
• RID-Master: dsquery server -hasfsmo rid
• Infrastructure Master: dsquery server -hasfsmo infr
• Schema Master: dsquery server -hasfsmo schema
• Domain Naming Master: dsquery server -hasfsmo name

Troubleshooting Problems with Group Policy

Group Policy can fail for a variety of reasons, so you must investigate where the problem lies step by step. Preferably, you have created different group policies for the different settings and linked them to the appropriate organizational unit (OU) or the whole domain. The following points will help you with this investigation:

• Make sure the clients use the DNS server on which the AD SRV records are stored.
• Use nslookup to see whether Windows Server can be resolved on the client.
• Check the Event Viewer for errors.
• Determine that the user or computer is in the correct OU to which the policy applies.
• Make sure you are not trying to apply the policy directly to a security group.
• Find out whether inheritance has been set up correctly by looking at the order in which the Group Policy objects (GPOs) start.
• Look to see whether you have changed something in the default inheritance of the policy.
• Check to see whether inheritance has been enabled or enforced somewhere.
• Type gpresult > gp.txt at the command prompt as a logged-in user to view the results of the policy.

The Windows Resultant Set of Policy (RSoP) MMC snap-in provides a graphical interface and evaluates the applied policy. You can view the RSoP on a workstation from the MMC with File | Add/Remove Snap-In | Resultant Set of Policy . Another way is by typing rsop.msc in the search box of the Start menu.

If group policies are not applied correctly to individual computers, use the free Microsoft Group Policy Log View tool [1] to home in on the error. Install the tool on the computer that you want to analyze; then, open a command prompt with administrator privileges and change to the directory in which you installed the tool. Use the following command to monitor Group Policy:

gplogview -o gpevents.txt

The tool parses all the Group Policy entries and displays a text file in which the GPO errors are collected. You can also run the tool from any computer using a logon script. If the logon script saves the file with the evaluation results on a share, you can monitor the use of Group Policy on multiple computers in a targeted way. In this case, do not just save the evaluation file on the network, but add the respective hostname of the evaluated machine to the file name:

gplogview -o \\<server>\<share>\<computername>-gpevent.txt

You can also create an HTML file as a report:

gplogview -h -o \\<server>\<share>\<computername>-gpevent.html

The tool also uses color highlighting in the HTML report. The redder the entry in the Activity Id field, the more serious the error. The tool can also monitor the application of Group Policy in real time by opening a command prompt with administrator privileges and starting real-time tracking with gplogview**-m.

The tool now monitors the local machine for the application of Group Policy. Opening a second command line and running gpupdate /force brings up a Group Policy Log View window, in which you will see the policy evaluation.