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 4)
- Working With the Domain Controller Diagnostic Utility (Part 5)
- Working With the Domain Controller Diagnostic Utility (Part 6)
Hopefully by now, you understand that the Domain Controller Diagnostic Utility has a lot of difference which is that you can use to configure the utility to run in the way that makes the most sense for your individual situation. Now that I have gone over the command line switches, I want to turn my attention to the individual tests that the utility is capable of running.
Advertising
The first test that you can run is the advertising test. This test performs a check to find out whether or not each Directory System Agent is advertising itself. If the Directory System Agent is being advertised, then the test makes sure that the advertisement lists the domain controller as having the capabilities of a Directory System Agent.
In case you are not familiar with the concept of a Directory System Agent, a Directory System Agent (often abbreviated as DSA) is actually a collection of multiple services and processes that run on a domain controller. Its job is to provide access to Active Directory Database. The DSA is a sub component of the Local System Authority (LSA). The reason why it involves multiple processes and services is because it provides multiple mechanisms through which it can be accessed by clients.
Probably the best-known of these mechanisms is the Light Weight Directory Access Protocol, more commonly known as LDAP. LDAP is the protocol through which most of the more recent Windows operating systems query the Active Directory. Older clients still require access to the DSA, but typically do so through the Security Account Manager (SAM). These are not the only mechanism through which the DSA is accessed. For example, Microsoft exchange communicates with the DSA using MAPI-based RPC calls. DSAs also communicate with each other by using remote procedure calls.
CheckSDRefDom
This particular test verifies that all of your application directory partitions have the appropriate security descriptor referenced domains. I am guessing that this particular test is going to be meaningless for anyone who is not an Active Directory expert. Therefore, I want to take a couple minutes and explain what this test is.
As I am sure you probably know, every object in the Active Directory contains a security descriptor. The security descriptors job is to maintain a list of access control information. Normally, the built-in security descriptor works pretty well for maintaining a record of who has access to what. Problems can occur if one organization starts using application directory partitions (previously known as Active Directory Application Mode or ADAM). The reason for this is that application directory partitions are domain independent. In fact, it is possible to create an application directory partition, and then replicate that partition to other domain controllers across multiple domains. Because of this problem, Windows assigns a security descriptor reference domain to each application directory partition when it is created.
The security descriptor reference domain tells the application directory partition which domain name to use when a domain value needs to be entered into a security descriptor. Windows has lots of rules that determine what domain name is used. To put it simply, if you create a new application directory partition that is not a child of any other partition, and the security descriptor reference domain uses the forest root domain as the domain name to use within the various security descriptors. If the application directory partition is a child of another object, then it takes on the security descriptor reference domain of its parent object.
CheckSecurityError
The next test that I want to talk about is the Check Security Error test. Unlike the previous test that I talked about, the Check Security Error test is not run by default. If you want to run this test, you will have to specify it manually within the DCDIAG command.
When you run this test, DCDIAG locates any security related errors, as well as errors that may possibly be related to security, and then attempts to diagnose the problem. There is one optional parameter that you can use with this switch. The /ReplSource switch allows you to specify a particular domain controller to run the test against. You can use any domain controller that you want, regardless of its error status or of whether or not it is a current partner. Simply enter the name of the test (CheckSecurityError), and append the /ReplSource switch, a colon, and the name of the domain controller that you want to test.
Connectivity
The Connectivity test is one of the most useful tests that you can run. In fact, this test is so important that DCDIAG does not even allow you to skip it. If you run a default instance of DCDIAG, the Connectivity test is run automatically.
The connectivity test checks to see whether domain controllers are registered in the DNS. It also checks to see if it can ping each domain controller, and whether or not it can establish LDAP and RDP connectivity.
CrossRefValidation
I have to be honest and tell you that I have not been able to find a lot of documentation on this particular test. What I can tell you is that the test looks for cross references that are invalid in some manner. If you do happen to receive a cross reference validation error, the problem can often be solved by using ADSI edit to remove the offending object.
I also want to point out that if you use ADSI edit incorrectly, you can destroy your Active Directory. Therefore, I would recommend making a full, system state backup of your domain controllers prior to making any changes with ADSI edit.
CutOffServers
The last test I want to talk about in this article is the Cut off Servers test. The basic idea behind this test is that in most cases, domain controllers have one or more replication partners. If a domain controller’s replication partner is down then the domain controller may not be able to be updated with Active Directory updates, and DCDIAG will report a Cut off Servers error.
The trick to being able to solve these types of problems is that you have to be able to figure out what the replication partners were a domain controller are. The actual method varies from one version of Windows to another, but in Windows Server 2003 you can look up the replication partners through the Active Directory Site and Services console.
When the console tree opens, expand the Site container to display a list of the sites in your Active Directory. Next, double-click on the site containing the domain controller that you want to examine. Next, expand the Servers folder, followed by the folder corresponding to the name of the domain controller that you are interested in. Finally, double-click on the NTDSSettings container, and Windows will display a list of connection objects. This list displays the replication partners in the From Server column.
Conclusion
In this article, I have begun discussing some tests that you can run using DCDIAG utility. In the next part of this article series, I will continue the discussion by showing you some more tests that you can perform.
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 4)
- Working With the Domain Controller Diagnostic Utility (Part 5)
- Working With the Domain Controller Diagnostic Utility (Part 6)
