Working With the Domain Controller Diagnostic Utility (Part 5)

by [Published on 12 March 2009 / Last Updated on 12 March 2009]

More tests that the Domain Controller Diagnostic Utility can perform.

If you would like to read the other parts in this article series please go to:

Introduction

I ended the previous article in this series by talking about some of the individual tests that you could run by using the Domain Controller Diagnostic Utility. Although I have talked about quite a few tests so far, there are plenty of more tests that you can perform. In this article, I want to pick up where I left off, and talk about a few more tests that the Domain Controller Diagnostic Utility can perform.

Locator Check

The Locator Check is one of the more important tests that you can perform using DCDIAG. As I am sure you probably know, the Active Directory assigns various Flexible Single Master Operations (FSMO) Roles to certain domain controllers within the forest. The global FSMO roles are initially assigned to the first domain controller in the forest. There are also some domain level FSMO roles that are assigned by default to the first domain controller in each domain.

The Locator Check test performs tests to make sure that the servers that are hosting the global FSMO roles are known, and that those servers can be located. More importantly, it checks to make sure that the servers hosting global FSMO roles are responding to requests.

Performing a locator check is simple. All you have to do is enter the following command:

DCDIAG /TEST:LocatorCheck

Of course this is just the simplest example of how you would run a locator check test. You have the option of specifying a particular domain controller and a set of authentication credentials just as you can for any other test.

The Intersite Test

Depending on your Active Directory’s topology, the Intersite test may also be an important one. When you run the Intersite test, the Domain Controller Diagnostic Utility performs a series of tests to see if there are any problems with bridgeheads that could cause Active Directory information from replicating across site boundaries.

The syntax used for running the intersite test is almost identical to the one used for the locator check. If you want to perform an intersite test, just enter this command:

DCDIAG /Test:Intersite

The KCCEvent Test

Another replication related test is the KCCEvent test. This test is used to make sure that the Knowledge Consistency Checker (KCC) is functioning, and that it is completing without producing any errors. You can run the KCCEvent test by entering the following command:

DCDIAG /Test:KCCEvent

The KnowsofRoleHolders Test

The Knows of Role Holders test checks to see if the Directory Service Agent knows which servers are hosting the various Flexible Single Operations Master Roles. If you just want to run a quick test, then you can do so by entering this command:

DCDIAG /Test:KnowsOfRoleHolders

Although that test will usually get the job done, you may sometimes want to actually want to check to see which domain controllers that the Directory Service Agent thinks are holding the roles. If you want to identify the individual servers, then you will need to run this rest in verbose mode. To do so, enter this command:

DCDIAG /Test:KnowsofRoleHolders /v

The Machine Account Test

In an Active Directory environment, servers and workstations are joined to a domain. This process of joining a machine to a domain causes a machine account to be created. Like a user account, a machine account has a corresponding password and a number of other attributes that are designed to identify the individual machine. If the machine account becomes corrupted or falls out of sync with the Active Directory, then the corresponding machine will not be able to connect to the domain. Fortunately, there is a test that you can use to check the integrity of a domain controller’s machine account. You can perform this test by entering the following command:

DCDIAG /Test:MachineAccount

In all of the years that the Active Directory has been around, I have only run into a few situations in which a problem with a machine account kept a machine from functioning correctly. In most of those cases, the problem was caused by the machine account’s password getting out of synch with the password for the machine account that is stored in the Active Directory database.

If a machine account does have problems though, there are a couple of optional switches that you can use to correct the issue. One such switch is the /FixMachineAccount switch, which resets the accounts various flags. If that does not correct the problem, then you can always try recreating the machine account by using the /RecreateMachineAccount switch.

The Naming Context Security Descriptors Test

One of the more obscure tests is a check to see if the security descriptors on the naming contexts are correct. If the security descriptors are invalid, then replication may fail. You can run this test by entering the following command:

DCDIAG /Test:NCSecDesc

NetLogons

A similar test related to replication is the NetLogons test. It checks to see that replication is not failing because of insufficient logon privileges. You can run this test by entering the following command:

DCDIAG /Test:NetLogons

The Objects Replicated Test

Another important test related to the replication process is the Objects Replicated test. This test is primarily used to confirm that machine accounts have replicated across all of your domain controllers, but it can also be used to check to see if other types of objects have replicated as well.

In order to use this test, you are going to have to know the distinguished name (DN) of the object that you want to test. If the object that you are looking up is something other than a machine account, then you will also have to know the object’s naming context. The syntax for this test looks something like this:

DCDiag /Test:ObjectsReplicated /ObjectDN:<object’s distinguished name> /N:<object’s naming context>

The Outbound Secure Channels Test

As the machines that store user passwords and various other security settings, domain controllers are some of the most sensitive servers on a network. As such, Microsoft has configured the domain controllers to communicate with each other over a secure channel whenever possible. This prevents people from using a packet sniffer to steal Active Directory information as it replicates from one domain controller to another.

By definition, a secure channel is an authenticated remote procedure call (RPC) connection between two machines in a domain with an established security context used for signing and encrypting RPC packets.

It should therefore come as no surprise that the Domain Controller Diagnostic Utility provides a test for checking outbound secure channels. This is one of those tests that is not run by default, so you will have to run it manually if you want to use it. The syntax looks like this:

DCDIAG /Test:OutboundSecureChannels /TestDomain:<yourdomain>

Normally, this test will only check the domain controllers within the current site. You can force the test to check external sites by adding the /NoRestriction switch to the test.

Conclusion

In this article, I have talked about several of the tests that you can perform against your domain controllers by using the Domain Controller Diagnostic Utility. Believe it or not, we are not done yet. There are still several more tests that I want to talk about. In the next article in the series, I will wrap things up by talking about the remaining tests.

If you would like to read the other parts in this article series please go to:

Advertisement

Featured Links