If you would like to read the other parts in this article series please go to:
- Working With the Domain Controller Diagnostic Utility (Part 1)
- Working With the Domain Controller Diagnostic Utility (Part 2)
- Working With the Domain Controller Diagnostic Utility (Part 3)
- Working With the Domain Controller Diagnostic Utility (Part 4)
- Working With the Domain Controller Diagnostic Utility (Part 5)
Introduction
So far in this article series, I have shown you quite a few different tests that you can perform on your domain controllers by using the Domain Controller Diagnostic Utility. Even so, there are still some tests that I have not talked about yet. In this article, I want to wrap things up by showing you the remaining tests.
Register in DNS
If you have been working with Windows for a while, then I am sure that you know that the Active Directory is completely dependent on the DNS services, and that every host on your network requires a Host (A) record on the organization’s DNS server. What a lot of people do not realize though, is that when you create the first domain in a forest, there are some domain specific DNS records that are created within a folder named DomainDnsZones. This folder is located within the Forward Lookup Zones in your domain folder.
The DomainDnsZones folder mains records for each domain controller. Without these records, other servers on the network will not be able to locate the domain controller’s directory resources. It is therefore essential that each domain controller be able to register itself within the DNS. This is where the Register in DNS test comes into play. This test verifies that the domain controller is able to register a directory server locator record
You can perform the Register in DNS test by entering the following command:
DCDIAG /Test:RegisterInDns /DnsDomain:<Active Directory Domain DNS Name>
For example, if your domain were named Contoso.com, the command would look like this:
DCDIAG /Test:RegisterInDns /DnsDomain:Contoso.com
Replications
As I am sure you know, Windows 2000 Server and every subsequent version of Windows Server use a multimaster domain model. This means that each domain controller has its own copy of the Active Directory database, and updates can be made directly to any of these copies. When an update is made to the Active Directory database, the update is then replicated to the other domain controllers.
The Replications test checks to make sure that these updates are occurring in a timely manner. If there is excessive latency in the update process, then domain controllers will remain out of sync for an extended period of time, and there is a greater potential for conflicts to occur.
You can perform the Replications test by entering the following command:
DCDIAG /TEST:Replications
RID Manager
Any time that you create a new Active Directory object, such as a user or a group, Windows assigns it a unique Security Identifier (SID). That SID is made up of a domain SID that is common for all objects within a domain, and a relative identifier (RID) that is unique within the domain. The RID master provides each domain controller within a domain a pool of RIDs that it can use when new objects are created. When the pool nears depletion, the domain controller issues a request to the RID master for additional RIDs. If the domain controller is unable to contact the RID Master, then no additional objects will be able to be created on that domain controller once the pool of RIDs has been exhausted.
The RID Manager test allows you to verify that a domain controller can identify and contact the RID Master, and that the RID Master contains the appropriate information. You can run this test by entering the following command:
DCDIAG /Test:RidManager
Services
In Windows Server 2008, the Active Directory is now listed as a service within the Service Control Manager. As you might have guessed, the Active Directory is a bit more complex than it initially appears. The Active Directory Domain Service has a number of dependency services, some of which include the DNS Server (if it is present on the server), Kerberos Key Distribution Center, Intersite Messaging, and the File Replication Service.
You can use the Services test to make sure that the Active Directory Domain Service and all of its supporting services are running. To do so, issue this command:
DCDIAG /Test:Services
System Log
According to Microsoft’s documentation, the System Log test examines the system to make sure that no errors are being generated. This makes it sound as though this test parses the System event log looking for errors. Perhaps on some level it does, but that isn’t what appears to happen when you actually perform the test.
When you run the system log test, the Domain Controller Diagnostic Utility begins by identifying the home server and the Active Directory forest. It then performs a connectivity test, a system log test (which I can only assume looks for critical events in the system log), and a series of partition tests on various Active Directory Partitions (ForestDnsZones, DomainDnsZones, Schema, Configuration, etc.)
You can run the System Log test by entering the following command:
DCDIAG /Test:SystemLog
Topology
Windows Server uses something called the Directory System Agent (DSA) to provide access to the data store. The Directory Service Agent is made up of various services and processes that facilitate that access. The DSA is a part of the Local System Authority subsystem, and is typically accessed through the LDAP protocol.
When multiple domain controllers are in use, each domain controller must have topology information that links it to other DSAs. The Topology test validates that the topology that Windows has generated is fully connected for all DSAs.
One important thing to know about the Topology test is that it is one of the few tests that is not run by default. It must be manually executed. You can perform this test by entering the following command:
DCDIAG /Test:Topology
Verify References
The Verify References test makes sure that the system references required by the File Replication Service and that the general replication infrastructure are intact. You can perform this test by entering the following command:
DCDIAG /Test:VerifyReferences
Verify Enterprise References
The Verify Enterprise References test is very similar to the Verify References test that I just discussed. Like the Verify References test, the Verify Enterprise References test checks to make sure that references required by the File Replication Service and that the general replication infrastructure are intact. What makes this command different from the Verify References command is that it checks file replication service references and the general replication infrastructure across all of the domain controllers in the entire enterprise.
This is another one of those tests that are not run by default. You can perform this test by entering the following command:
DCDIAG /Test:VerifyEnterpriseReferences
Verify Replicas
The Verify Replicas test is another test that is not run by default, and must be manually executed. The basic idea behind this test is that Windows allows you to create application directory partitions, and those partitions can be replicated to other servers. The test allows you to make sure that all of the replica servers contain the appropriate replicas. You can perform this test by entering the following command:
DCDIAG /Test:VerifyReplicas
Conclusion
As you can see, the Domain Controller Diagnostic Utility is capable of performing numerous tests. In my opinion, DCDIAG is one of the most underrated diagnostic tools that Microsoft has ever created.
If you would like to read the other parts in this article series please go to:
- Working With the Domain Controller Diagnostic Utility (Part 1)
- Working With the Domain Controller Diagnostic Utility (Part 2)
- Working With the Domain Controller Diagnostic Utility (Part 3)
- Working With the Domain Controller Diagnostic Utility (Part 4)
- Working With the Domain Controller Diagnostic Utility (Part 5)
