Working With the Domain Controller Diagnostic Utility (Part 6)

Discussing the remaining tests that you can perform against your domain controllers.

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:

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.

Working With the Domain Controller Diagnostic Utility (Part 5)

More tests that the Domain Controller Diagnostic Utility can perform.

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: /N:

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:

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.

Working With the Domain Controller Diagnostic Utility (Part 4)

Demonstrating some additional tests that Domain Controller Diagnostic Utility can perform.

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. In this article, I want to pick up where I left off and talk about more tests that you may perform.

DCPROMO

Some of the tests that are available through the Domain Controller Diagnostic Utility tend to be a bit obscure to say the least. In contrast though, the DCPROMO test is actually very useful. It is designed to let you test a server’s readiness prior to promoting the server to a domain controller. Granted, promoting a server to a domain controller is a fairly simple process. You just enter the DCPROMO command, click Next a few times, and you are on your way. Even so, I have created hundreds of domain controllers over the years, and it has been my experience that every once in a while the process goes belly up because of something unexpected. Personally, I would rather know up front whether or not the server was prepared to be promoted to a domain controller, then to try the promotion, have something go wrong, and have to figure out why. Of course if the domain controller promotion process does end badly, then you can always use the DCPROMO test after the fact to help you to figure out what happened.

If you are going to use the DCPROMO test, then you are going to have to use at least two command line switches with it. The first switch that you have to use is the /DNSDomain switch. You must use this switch to tell the Domain Controller Diagnostic Utility which domain the server is going to be made a domain controller in.

You have to follow the /DNSDomain switch with a secondary switch that tells the Domain Controller Diagnostic Utility what your intentions are for the server. For example, if the server is going to be a domain controller in a new forest, then it would need to be tested differently than it would if it were going to be an extra domain controller in an existing domain.

The switches that you use to tell the Domain Controller Diagnostic Utility how the new domain controller will fit into the existing Active Directory structure are self explanatory for the most part. The switches are:

/NewForest
/NewTree
/ChildDomain
/ReplicaDC

For example, if you wanted to use the server as an extra domain controller in an existing domain named Contoso.com, then the command’s full syntax would be:

DCDIAG /test:DCPROMO /DNSDomain:Contoso /ReplicaDC

One caveat that I do want to mention is that if you use the /NewTree switch, then you will have to use a third switch named /ForestRoot. Simply follow the /ForestRoot switch with a colon and the name of your root domain (/ForestRoot:Contoso.com)

DNS

It is easy to think of the Domain Controller Diagnostic Utility as a mechanism for running diagnostic tests against your domain controllers. Even so, this utility comes with a whole series of tests designed to help you to diagnose problems with your DNS servers. This should really come as no surprise. After all, the Active Directory is completely dependent on the Domain Name Services, and the first domain controller in a forest is usually configured to act as a DNS server.

The DNS test is actually made up of quite a few individual tests, any of which can be performed individually. If you choose to call the DNS test without specifying any additional switches, then the Domain Controller Diagnostic Utility will run all but one of the sub tests. The test that gets skipped involves resolving external domain names. I will talk more about this test in a moment. Before I do, I want to give you a list of the tests that are performed when the DNS test is run without any extra switches. Figure A shows what some of the default DNS tests look like when executed.

Test Name	Switch for performing the test manually	Description of the test
Basic diagnostic test	/DNSBasic	This is a basic diagnostic test, which is performed any time that you perform a DNS test. This test cannot be skipped, regardless of which command line switches are used.
Forwarder and root hint test	/DNSForwarders	This test checks the DNS server’s forwarders and it’s root hints.
Delegation test	/DNSDelegation	This test checks the DNS server’s delegation
Dynamic Update Test	/DNSDynamicUpdate	This test checks to see which portion of the DNS namespace the DNS server is authoritative over.
Record Registration Test	/DNSRecordRegistration	This test verifies that records can be registered on the DNS server.

Figure A

Figure B: This is what it looks like when you perform a default DNS test

Earlier, I mentioned that the only test that is not run by default when you specify that you want to test the DNS configuration is the external name resolution test. There are a few switches that you can use if you want to run the external name resolution test though.

One option is to use the /DNAAll switch. This switch tells the Domain Controller Diagnostic Utility to run all of the DNS related tests, including the external name resolution test. The full syntax of this command is:

DCDIAG /TEST:DNS /DNSAll

You also have the option of explicitly calling the external name resolution test rather than just bundling the test with every other DNS related test that the Domain Controller Diagnostic Utility can run. If you want to explicitly call the external name resolution test, then you can do so by specifying the /DNSResolveExtName switch.

In case you are wondering, the external name resolution test attempts to resolve the domain name Microsoft.com. You can however, specify a different external domain name to be resolved by adding the /DNSInternetName switch, in conjunction with the name that you want to resolve.

SysVolCheck

One of the simpler tests that the Domain Controller Diagnostic Utility can perform is the SysVolCheck. This test performs some basic tests against various Active Directory partitions including the forest DNS zones, the domain DNS zones, the schema, the configuration partition, and on the domain partitions. You can see what the SysVolCheck test looks like when executed in Figure C.

Figure C

The SysVolCheck test performs some initial connectivity tests, and then tests the various Active Directory partitions.

FrsEvent

The last test that I want to mention in this article is the FRSEvent test. In Windows FRS refers to the File Replication Service. As such, this test checks to see if the File Replication Service is experiencing any operational errors. This is important, because if the FRS is malfunctioning, then the domain controllers can become out of sync, which can cause policies not to be applied properly until the problem is fixed.

Conclusion

In this article, I have discussed a few more tests that you can run by using the Domain Controller Diagnostic Utility. In the next article in this series I will show you some more tests that you can run.

Working With the Domain Controller Diagnostic Utility (Part 3)

This article continues the series on working with the Domain Controller Diagnostic Utility by examining some of the individual tests that can be performed.

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.

Working With the Domain Controller Diagnostic Utility (Part 2)

This article continues the series on working with the Domain Controller Diagnostic Utility by examining some additional command line switches.

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.

Conclusion

In this article, I have shown you some additional command line switches that you can use with the Domain Controller Diagnostic Utility. In the next article in this series, I will turn my attention to the individual tests that you can run.

Working With the Domain Controller Diagnostic Utility (Part 1)

This article explains how the Domain Controller Diagnostic Utility can be used to troubleshoot problems with the Active Directory.
Domain controllers are the backbone of just about any Windows network. After all, if your domain controllers are not working then the Active Directory does not work either. If the Active Directory does not work, then users cannot log on, group policies cannot be enforced, and a whole slew of other features become unavailable. Fortunately, Windows ships with a tool that you can use to keep your domain controllers running smoothly. This tool is called the Domain Controller Diagnostic Utility. In this article, I will show you how to use this tool to perform basic maintenance and diagnostic tasks on your domain controllers.

The Domain Controller Diagnostic Utility has been a part of Windows for quite some time now. For the purposes of this article, I will be working with the version of this utility that comes with Windows Server 2008. Most, if not all of the features that I will be talking about are also available in the Windows Server 2003 SP1 version. DCDIAG existed prior to Windows Server 2003 SP1, but many of the commands that are available today were first introduced in Windows Server 2003 SP1.

You can access the Domain Controller Diagnostic Utility by running the DCDIAG command from a Windows command prompt.

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.

Install Windows from a USB drive

One might need to reinstall an operating system from time to time, but the netbooks and ultra-portable laptops gaining popularity today have no optical drives.

What do you do when there is no optical drive in your PC and you want to install a new operating system on it? Before you invest in an external drive, we will tell you about a more cost-effective solution. Why not install Windows XP or Windows Vista from a USB flash drive instead? All you need are the following items:

A desktop or laptop with Windows XP/Vista (according to the OS required to be dumped onto the USB flash drive).

• An optical drive in the PC.
  
• The original Windows XP or Vista installation disk.
  
• A 1 GB or 4 GB USB flash drive for Windows XP/Vista respectively.
• A software called ‘Komku-SP-usb.exe’

download code :
http://www.mediafire.com/?zlvkwwzmjmt

Installing Windows XP from a USB flash drive

Step 1: Download the software ‘Komku-SP-usb.exe’ from the websites mentioned earlier and execute it. The executable file will extract the necessary utilities to a folder called ‘C:komku’.

Step 2: Once the package has been extracted, go to the folder ‘C:komkuPeToUSB’ using Windows Explorer. Execute the file ‘PeToUSB.exe’. Plug in the USB flash drive and make sure you choose the following (see image below) before clicking the start button. Select ‘USB removable’, ‘Enable Disk Format’, ‘Quick format’, ‘Enable LBA (Fat 16x)’ and finally give the drive a name under ‘Drive Label’. Once it’s done, click start to let the utility format the drive.

Step 3: Next you will need to start the command prompt. Click ‘Start | Run’, type ‘cmd’ and press [Enter]. Then go to the ‘bootsect’ directory by typing the command ‘cd C:komkubootsect’ and pressing [Enter]. Now type the command ‘bootsect /nt52 F:’ and press [Enter]. (The ‘F:’ is the USB flash drive letter represented in ‘My Computer’. Check to verify the drive letter used by your USB flash drive). Let the utility do the needful. Do not exit the Command Prompt yet.

Step 4: Now you will need to change to the directory ‘Usb_Prep8’ by using the command ‘cd C:komkuusb_prep8’ and pressing [Enter]. Here execute the command ‘usb_prep8’ and press [Enter]. Press any key to continue and you will see a welcome screen with a menu appear in the Command Prompt.

Step 5: Now at this stage, you will have to insert the Windows XP installation disk into your optical drive. At the Command Prompt menu, type ‘1’ and press [Enter]. A new popup will appear asking you to choose the location (path) of the Windows installation disk. Select the optical drive and click ‘OK’. Next choose ‘2’ from the menu and change the drive letter to any drive letter which has not been taken. It is drive ‘T:’ by default and you can ignore this step unless you do have a ‘T:’ drive on your computer.

After this, choose ‘3’ from the menu and enter the drive letter of your USB flash drive (in this case it would be ‘F’). Finally choose ‘4’ from the menu and press [Enter]. Wait for a few seconds for the process to complete and you will see a prompt to allow the utility to format the USB flash drive. Type ‘Y’ and then press [Enter] at this stage to let the utility proceed and install the necessary files from the Windows XP installation disk to the USB flash drive. This process will take a few minutes and depends on the speed of the flash drive.

Step 6: After the files are copied, you will see a popup window asking you for permission to copy files from the temp drive to the USB flash drive. Select ‘Yes’.

Step 7: Next there will be another popup window asking you to allow the utility to change the boot drive letter of the USB flash drive from ‘F:’ to ‘U:’. Select ‘Yes’.

Step 8: Finally, after all the processes are complete, you will see yet another popup window asking if you want to unmount the virtual drive. Select ‘Yes’. Exit the Command Prompt now and you will see that your flash drive is ready to install Windows XP to another computer.

To install Windows XP to the computer, you will have to go to the BIOS and enable the option of booting from a USB removable device. This option is usually found under the boot sequence menu of the BIOS. Plug in the USB drive to the computer before you turn it on. Now your computer will boot from the USB flash drive and will be ready to install Windows XP. Follow the necessary steps to install Windows XP and your computer will be up, raring and ready to go and running Windows in no time.

Installing Windows Vista from a USB flash drive

Making a bootable Windows Vista installation USB drive is far simpler than doing so for Windows XP because the utility is built into the operating system and can be deployed from the Command Prompt itself. All you would need is a computer running the Windows Vista operating system, the original Windows Vista installation DVD and at least a 4 GB USB flash drive. Follow the simple steps ahead to make your own Windows Vista bootable USB drive.

Step 1: Start Windows Vista, insert the pen drive into the computer’s USB port. Start Command Prompt, type ‘diskpart’ and press [Enter].

Step 2: Type ‘list disk’ and press [Enter]. Carefully note down the USB flash drive’s disk number listed here. In this case it would be ‘Disk 1’

Step 3: Type ‘Select disk 1’ and press [Enter]. Here the Diskpart utility is instructed to choose the disk 1 as the drive to be worked on.

Step 4: Type ‘Clean’ and press [Enter]. This command clears out all the information of the volumes, partitions, boot sectors and the MBR from the USB flash drive.

Step 5: Type ‘Create partition primary’ and press [Enter]. This command will create a primary partition on the USB flash drive.

Step 6: Type ‘Select partition 1’ and press [Enter]. This command instructs the Diskpart utility to select the newly created partition.

Step 7: Type ‘Active’ and press [Enter]. This command will make the current partition (primary) active to enable the USB flash drive to boot from.

Step 8: Type ‘Format fs=fat32’ and press [Enter]. This command formats the selected drive partition using the FAT32 file system.

Step 9: Type ‘Assign’ and press [Enter]. This command assigns a drive letter to the newly formatted partition. As there is no drive letter specified in the command line, the next available drive letter is assigned to the drive.

Step 10: Exit from the Diskpart utility using the ‘exit’ command and pressing [Enter]. Now insert the Windows Vista DVD in the optical drive and type the command ‘xcopy e:*.* /s /e /f F:’ and press [Enter]. This command will dump all the contents of the Windows Vista DVD onto the USB flash drive. Your USB drive is now ready to install Windows Vista on any computer. Just set the boot sequence in the BIOS of the system to boot from the USB, insert
the USB flash drive into the computers USB port and turn on the computer. Follow the regular installation for Windows Vista.

Note: To know more about the Diskpart utility commands, browse through the URL ‘http://support.microsoft.com/kb/300415’.

Installing Windows XP or Windows Vista from a USB flash drive is much faster as compared to installing from a CD/DVD. A high-speed flash drive would make a difference.