Working With the Domain Controller Diagnostic Utility (Part 3)

s 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

Working With the Domain Controller Diagnostic Utility (Part 2)

n the first part of this article series, I explained that if you wanted to diagnose problems with a domain controller, you could just enter the DCDIAG command, or you could use any of the numerous available command line switches as a way of getting the utility to test the specific properties of the domain controller that you are interested in. In that article, I began showing you a few command line switches, but there are a few more switches that I want to show you. In this article, I will talk about some additional switches, and will eventually go on to talk about some individual tests that you can run.

/C

I have already mentioned that you can just enter the DCDIAG command without any command line switches, and the Domain Controller Diagnostic Utility will perform a full battery of tests against your domain controller. Even so, there are a few tests that the Domain Controller Diagnostic Utility is capable of performing, but that it does not perform by default.

If you are not really sure what is going on with your domain controller, then I recommend running the DCDIAG command with the /C switch. This tells DCDIAG that you want to perform a comprehensive set of tests. This causes the Domain Controller Diagnostic Utility to run every test that it knows how to run, aside from the DCPROMO and the RegisterInDNS tests, which I will talk more about later on.

Keep in mind that running a comprehensive set of tests can take a long time to complete. If there are tests that you know that you do not need to run, then you can use the /C switch in conjunction with the /SKIP switch. Simply append a colon and the name of the test that you want to skip to the /SKIP switch, and the specified test will be omitted from a comprehensive scan.

/F

At the beginning of Part 1, I showed you what running DCDIAG without specifying any command line switches looks like. As you may recall, the output was fairly long. Of course when I created that screen capture, I simply ran a default set of tests against a healthy domain controller. The output can be a whole lot longer if you specify additional tests, or if the tests detect problems with the specified domain controller.

In some cases, reading the test results from the screen as the tests are run may not be practical. DCDIAG may spew data faster than you can read it. This is where the /F switch comes into play. The /F switch gives you the option of writing the test results to a log file. That way, you can read the results at your leisure. More importantly you will have a permanent copy of the output that you can refer back to for reference.

To use the /F switch, simply append a colon and the path and filename of the log file that you want to create. For example, if you wanted to create a log file named TEST.LOG, then you would enter DCDIAG /F:TEST.LOG. Keep in mind that when you specify the /F switch, the output is completely redirected to the log file. This means that the test output is not written to the screen at all. For operations involving multiple tests, the server may appear to lock up while the tests are performed.

/FIX

So far all of the command line switches that I have shown you are diagnostic in nature. When you use them, they cause DCDIAG to run its tests in certain ways, but DCDIAG only reports the test results. It does not attempt to correct any problems that it may find.

If DCDIAG does report problems you can attempt to correct those problems by specifying the /FIX switch. Even though this switch is simple in that it does not require you to provide any additional attributes, there are some very important things that you need to know about using this switch.

Before you use the /FIX switch, it is important to remember what you are really doing. You are telling an automated utility to make changes to your domain controller, which often means that you are blindly modifying the Active Directory. The Domain Controller Diagnostic Utility is designed so that when you use the /FIX switch, it will only make repairs that it deems to be safe. Even so, the simple fact using this switch involves blindly making changes to a domain controller leads me to recommend that you use the switch with extreme caution. The /FIX switch is designed to be safe, but any time that you are working with something as complex as a domain controller, things can go wrong.

That being the case, I recommend that you never specify the /FIX switch the first time that you run DCDIAG. Instead, you should run your tests, and take the time to evaluate the test results before you ever use the /FIX switch. If you do decide to use the /FIX switch, then I recommend making a full, system state backup of the target domain controller before doing so.

If you want to hedge your bets a bit, then one additional precaution that you can take before you attempt to fix a domain controller is to install Windows onto a spare PC, and then configure that PC to function as a domain controller. When you are done, wait for the replication process to complete, and then shut down and unplug the PC. That way, you have a healthy domain controller that you can use to rebuild your Active Directory if something should go horribly wrong during the repair process.

/TEST

The last switch that I want to talk about is the /TEST switch. So far, most of the command line switches that I have shown you are geared toward controlling the way that the Domain Controller Diagnostic Utility behaves when running various tests. You have also seen that the Domain Controller Diagnostic Utility runs a full set of tests by default, but that you can use either the /C switch or the /SKIP switch to run additional or fewer tests respectively.

The point that I am trying to make is that so far I have worked under the assumption that you will be running multiple tests. You do not have to run multiple tests. The /TEST switch allows you to simply specify the name of an individual test that you want to run. Just append a colon and the test’s name to the /TEST switch.

Keep in mind that you cannot use the /TEST switch to run multiple tests. As you can imagine, the /TEST switch is incompatible with the /SKIP switch, since the two switches do contradictory things.

Running the Domain Controller Diagnostic Utility

Running the Domain Controller Diagnostic Utility

If you want to keep things simple, you can run the Domain Controller Diagnostic Utility by entering the DCDIAG command into a Windows Command Prompt window. Upon doing so, the utility will perform a variety of tests against the domain controller that you're connected to. You can see an example of what these tests look like in Figure A.

Figure A: The Domain Controller Diagnostic Utility runs a variety of tests against a domain controller

By simply entering the DCDIAG command does get the job done, but this would not be much of an article if I just told you to run the command, and left it at that. There is a lot more to the Domain Controller Diagnostic Utility than meets the eye. Before you can really appreciate all the tool's capabilities you need to become familiar with the optional parameters that you can use in conjunction with the DCDIAG command. If you look at Figure B, you can see that the DCDIAG command’s syntax is too long to even fit on a screen capture. Like most things that are really complicated the command’s syntax is not as bad as it initially appears. Once you understand how the command works, using it becomes fairly easy.

Figure B: The DCDIAG command’s syntax is so long that it won’t even fit on the screen

Breaking Down the Syntax

As you can see in the figure above, the DCDIAG command’s basic syntax looks like this:

dcdiag.exe /s:[:] [/u:\
/p:*||""]
[/hqv] [/n:] [/f:] [/x:XMLLog.xml]
[/skip:] [/test:]

Although the screen capture shown in Figure B lists what each of the command line switches does, the explanation is a bit sparse. That being the case, I am going to try to give you a better explanation of what each of the command line switches does.

/H

If you run the DCDIAG command with the /H parameter, it simply displays the DCDIAG command’s syntax in the manner shown in Figure B. If you look closely at the figure, you will notice that you can also use the /? Switch to display the command’s syntax.

/S

The /S parameter allows you to specify a home server. Essentially, this means that you can use the /S parameter to specify the name of the domain controller that you want to run DCDIAG against. As you may recall, when I ran the DCDIAG command in Figure A, I did not have to specify a home server. If you do not specify a home server, then DCDIAG will just pick one automatically.

There are a couple of instances in which a specified home server will be ignored. The DCPROMO and the Register In DNS tests are run locally rather than being run against a domain controller. Therefore, if you try to specify a home server for these tests, it will be ignored. I will talk more about these tests later on.

/N

The /N parameter allows you to specify a domain naming context. In case you aren’t familiar with this term, every domain is represented by a domain naming context. The domain naming context stores objects for the domain such as users, computers, groups, etc. You don’t have to specify a domain naming context, but if you choose to use one, you can enter it is NetBIOS, DNS (fully qualified domain name), or distinguished name (DN) form.

/U

Unless you are logged on as an administrator of the domain that you are testing, you will have to supply the DCDIAG command with a set of administrative credentials that it can use. As you no doubt know, administrative credentials typically consist of a username and a password. The /U switch is used to specify the username. Since you are entering the name of an account with domain admin permissions, you will have to enter the username in domain\username format.

/P

The other switch that is used when entering a set of credentials is the /P switch. As you have probably already figured out, you would follow the /P switch with the password for the account that you specified through the /U switch.

/A

An Active Directory is often grouped into sites. A site typically represents a collection of domain controllers that all have reliable, high speed connectivity between them. For example, if an organization has two different facilities, connected together by a WAN link, each of the two facilities would typically be configured to act as its own site since the computers within the facility are on a common LAN, but there is no LAN connection between the facilities.

If your organization is divided into sites, then you will be interested in the /A switch. Using this switch tells DCDIAG to test all of the domain controllers in the current site.

/E

The /E switch is similar to the /A switch, except that instead of telling DCDIAG to test all of the domain controllers in the current site, it tells DCDIAG to test every domain controller in the entire enterprise.

/Q

As you have already seen, the DCDIAG command’s output is pretty long. It can be easy for error messages to get lost in such a long output. If this happens to you, you can use the /Q switch to run DCDIAG in Quiet more, which will cause it to only list error messages.

/V

The /V switch is kind of the opposite of the /Q switch. While the /Q switch reduces the size of the output, the /V switch increases it. That way you can get more detailed (verbose) information on the problem that you are trying to correct.

/I

Sometimes DCDIAG will produce meaningless error messages that can really be confusing to less experienced administrators. If this happens to you, you can use the /I switch to tell DCDIAG to suppress any unimportant error messages.

Conclusion

In this article, I have introduced you to some of the basic commands used by the Domain Controller Diagnostic Utility. In Part 2, I will continue the discussion by showing you how to use a few additional command line switches, and how to specify specific tests that you would like to run.

Creating a Lab Deployment Point

Creating a Lab Deployment Point

Creating a Lab deployment point on your technician computer is straightforward. Open the Deployment Workbench, right-click on the Deployment Points node under Deploy, and select New to launch the New Deployment Point Wizard. Select Lab or Single-Server Deployment as shown in Figure 1:

Figure 1: Creating a Lab deployment point

Next give your deployment point a descriptive name (Figure 2):

Figure 2: Give the deployment point a descriptive name

The next page of the wizard lets you configure whether users will be allowed to install additional applications during an upgrade computer scenario. If you select the checkbox shown in Figure 3 below, the Windows Deployment Wizard running on the destination computer will display a page that prompts the user to select additional applications to install. Leaving the checkbox cleared will suppress this wizard page:

Figure 3: Allow users to select additional applications on upgrade

If you select the checkbox on the next page shown in Figure 4 below, the Windows Deployment Wizard running on the destination computer will display a page that lets you choose whether to capture an image of the destination computer after the operating system has been deployed onto the system:

Figure 4: Allow image capture

If the checkbox is selected on the next page (Figure 5) the Windows Deployment Wizard running on the destination computer will display a page that prompts the user to specify the password for the local Administrator account for the destination computer:

Figure 5: Specify the local Administrator password

If the checkbox is selected on the next page (Figure 6) the Windows Deployment Wizard running on the destination computer will display a page that prompts the user to specify the product key for the destination computer:

Figure 6: Specify the product key

The next page of the New Deployment Point Wizard is called Network Share, but for a Lab deployment point what you're really specifying here is the share name for the distribution share folder (see Figure 7). By default, the C:\Distribution folder is shared as a hidden share named Distribution$:

Figure 7: Network share page

The next page shown in Figure 8 specifies how user state information should be migrated during an Upgrade Computer scenario or Replace Computer scenario deployment. We will examine user state migration in more detail in a future article.

Figure 8: Configure user state migration

When you finish the wizard, your new Lab deployment point is displayed in the Deployment Workbench (Figure 9):

Figure 9: The Lab deployment point has been created

Double-clicking on the deployment point displays its properties. The General tab (Figure 10) displays descriptive information and lets you choose which platforms are supported for the deployment point. For a Lab or Network deployment point, you can also enable multicast deployment if you are using MDT together with Windows Deployment Services:

Figure 10: General tab of deployment point properties

Tip:
Run the Deployment Workbench on an x86 computer if you need to install both x86 and x64 versions of Windows Vista SP1.

The Rules tab (Figure 11) shows the contents of the CustomSettings.ini file, which is used to configure the various pages of the Windows Deployment Wizard as it runs on the destination computers. You can also click the button at the bottom right of this tab to view or edit the Bootstrap.ini file. We briefly examined how to modify the CustomSettings.ini file in Part 27 of this series and will revisit this topic again in a future article.

Figure 11: Rules tab of deployment point properties

The Windows PE tab (Figure 12) lets you specify which types of images will be created when the deployment point is updated (discussed later below). This tab is also where you select which driver group contains the device drivers needed for this deployment group (driver groups were discussed in Part 28 of this series) and lets you perform other customizations of your Windows PE images such as adding a background bitmap image or additional folders containing files or tools you may need.

Figure 12: Windows PE tab of deployment point properties

Creating a Network Deployment Point

Creating a separate deployment share or Network deployment point is similar to creating a Lab deployment point as shown above. The main differences are that the default name given to the deployment point is Network, and you have to fill in the name of the local or remote computer and the share name (see Figure 13). The underlying folder for the share will be created on the specified computer when you update the deployment point (discussed later below).

Figure 13: Configuring a Network deployment point

Creating a Removable Media Deployment Point

Creating a removable media deployment point is similar to creating a Network deployment point. The differences this time are that the default name given to the deployment point is Media, and you have to fill in the name of the local or remote computer and the share name (see Figure 14). The underlying folder for the share will be created on the specified computer when you update the deployment point (discussed next below).

Figure 14: Creating a removable media deployment point

Updating a Deployment Point

After you create a deployment point, you must update it. Updating a deployment point is when the deployment point is actually created on the file system of the local or remote computer. To update a deployment point, right-click on it and select one of the following two options (see Figure 15 below):

• Update – Creates the folder structure for the deployment point (if needed), copies various MDT scripts and tools to the deployment point, and creates Windows PE .iso and .wim images for deploying Windows manually or deployment Windows using Windows DS. You generally use this option when first updating a deployment point or when you need to generate new Windows PE images for the deployment point.
• Update (files only) – Does everything the first option does except that it doesn’t create the Windows PE images. You generally use this option when you have made changes to your CustomSettings.ini or Bootstrap.ini files but don't need to generate new Windows PE images.

Figure 15: Updating a deployment point

Conclusion

In this article and the previous ones we have looked at how to configure distribution shares and deployment points in MDT 2008. The next article of this series will examine how to configure Task Sequences.

If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

Readers interested in understanding how to perform image-based unattended installs of Windows Vista using Windows Automated Installation Kit (Windows AIK) tools such as Windows System Image Manager (Windows SIM), the Windows Preinstallation Environment (WinPE), the System Preparation Tool (Sysprep) and ImageX are referred to articles 1 through 13 of my Deploying Vista series here on WindowsNetworking.com.

Readers interested in understanding how to use Windows Deployment Services (Windows DS) for server-based unattended installs of Windows Vista are referred to articles 14 through 23 of my Deploying Vista series.

For more information on using Microsoft Deployment Toolkit for deploying Windows Vista, see the following articles in this series:

Creating a Lab Deployment Point

Creating a Lab Deployment Point

Creating a Lab deployment point on your technician computer is straightforward. Open the Deployment Workbench, right-click on the Deployment Points node under Deploy, and select New to launch the New Deployment Point Wizard. Select Lab or Single-Server Deployment as shown in Figure 1:

Figure 1: Creating a Lab deployment point

Next give your deployment point a descriptive name (Figure 2):

Figure 2: Give the deployment point a descriptive name

The next page of the wizard lets you configure whether users will be allowed to install additional applications during an upgrade computer scenario. If you select the checkbox shown in Figure 3 below, the Windows Deployment Wizard running on the destination computer will display a page that prompts the user to select additional applications to install. Leaving the checkbox cleared will suppress this wizard page:

Figure 3: Allow users to select additional applications on upgrade

If you select the checkbox on the next page shown in Figure 4 below, the Windows Deployment Wizard running on the destination computer will display a page that lets you choose whether to capture an image of the destination computer after the operating system has been deployed onto the system:

Figure 4: Allow image capture

If the checkbox is selected on the next page (Figure 5) the Windows Deployment Wizard running on the destination computer will display a page that prompts the user to specify the password for the local Administrator account for the destination computer:

Figure 5: Specify the local Administrator password

If the checkbox is selected on the next page (Figure 6) the Windows Deployment Wizard running on the destination computer will display a page that prompts the user to specify the product key for the destination computer:

Figure 6: Specify the product key

The next page of the New Deployment Point Wizard is called Network Share, but for a Lab deployment point what you're really specifying here is the share name for the distribution share folder (see Figure 7). By default, the C:\Distribution folder is shared as a hidden share named Distribution$:

Figure 7: Network share page

The next page shown in Figure 8 specifies how user state information should be migrated during an Upgrade Computer scenario or Replace Computer scenario deployment. We will examine user state migration in more detail in a future article.

Figure 8: Configure user state migration

When you finish the wizard, your new Lab deployment point is displayed in the Deployment Workbench (Figure 9):

Figure 9: The Lab deployment point has been created

Double-clicking on the deployment point displays its properties. The General tab (Figure 10) displays descriptive information and lets you choose which platforms are supported for the deployment point. For a Lab or Network deployment point, you can also enable multicast deployment if you are using MDT together with Windows Deployment Services:

Figure 10: General tab of deployment point properties

Tip:
Run the Deployment Workbench on an x86 computer if you need to install both x86 and x64 versions of Windows Vista SP1.

The Rules tab (Figure 11) shows the contents of the CustomSettings.ini file, which is used to configure the various pages of the Windows Deployment Wizard as it runs on the destination computers. You can also click the button at the bottom right of this tab to view or edit the Bootstrap.ini file. We briefly examined how to modify the CustomSettings.ini file in Part 27 of this series and will revisit this topic again in a future article.

Figure 11: Rules tab of deployment point properties

The Windows PE tab (Figure 12) lets you specify which types of images will be created when the deployment point is updated (discussed later below). This tab is also where you select which driver group contains the device drivers needed for this deployment group (driver groups were discussed in Part 28 of this series) and lets you perform other customizations of your Windows PE images such as adding a background bitmap image or additional folders containing files or tools you may need.

Figure 12: Windows PE tab of deployment point properties

Creating a Network Deployment Point

Creating a separate deployment share or Network deployment point is similar to creating a Lab deployment point as shown above. The main differences are that the default name given to the deployment point is Network, and you have to fill in the name of the local or remote computer and the share name (see Figure 13). The underlying folder for the share will be created on the specified computer when you update the deployment point (discussed later below).

Figure 13: Configuring a Network deployment point

Creating a Removable Media Deployment Point

Creating a removable media deployment point is similar to creating a Network deployment point. The differences this time are that the default name given to the deployment point is Media, and you have to fill in the name of the local or remote computer and the share name (see Figure 14). The underlying folder for the share will be created on the specified computer when you update the deployment point (discussed next below).

Figure 14: Creating a removable media deployment point

Updating a Deployment Point

After you create a deployment point, you must update it. Updating a deployment point is when the deployment point is actually created on the file system of the local or remote computer. To update a deployment point, right-click on it and select one of the following two options (see Figure 15 below):

• Update – Creates the folder structure for the deployment point (if needed), copies various MDT scripts and tools to the deployment point, and creates Windows PE .iso and .wim images for deploying Windows manually or deployment Windows using Windows DS. You generally use this option when first updating a deployment point or when you need to generate new Windows PE images for the deployment point.
• Update (files only) – Does everything the first option does except that it doesn’t create the Windows PE images. You generally use this option when you have made changes to your CustomSettings.ini or Bootstrap.ini files but don't need to generate new Windows PE images.

Figure 15: Updating a deployment point

Conclusion

In this article and the previous ones we have looked at how to configure distribution shares and deployment points in MDT 2008. The next article of this series will examine how to configure Task Sequences.

If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

Readers interested in understanding how to perform image-based unattended installs of Windows Vista using Windows Automated Installation Kit (Windows AIK) tools such as Windows System Image Manager (Windows SIM), the Windows Preinstallation Environment (WinPE), the System Preparation Tool (Sysprep) and ImageX are referred to articles 1 through 13 of my Deploying Vista series here on WindowsNetworking.com.

Readers interested in understanding how to use Windows Deployment Services (Windows DS) for server-based unattended installs of Windows Vista are referred to articles 14 through 23 of my Deploying Vista series.

For more information on using Microsoft Deployment Toolkit for deploying Windows Vista, see the following articles in this series: