Windows 7 / Getting Started

Running the Domain Controller Diagnosis Utility

The Domain Controller Diagnosis (DCDIAG) utility is installed with the Active Directory Domain Services roles in Windows 2008 and is used to analyze the state of a domain controller (DC) and the domain services. It runs a series of tests, analyzes the state of the DC, and verifies different areas of the system, such as the following:

  • Connectivity
  • Replication
  • Topology integrity
  • Security descriptors
  • Netlogon rights
  • Intersite health
  • Roles
  • Trust verification

DCDIAG should be run on each DC on a weekly basis or as problems arise. DCDIAG's syntax is as follows:

dcdiag.exe /s:<Directory Server>[:<LDAP Port>] [/u:<Domain>\<Username>
/p:*|<Password>|""]
[/hqv] [/n:<Naming Context>] [/f:<Log>] [/x:XMLLog.xml]
[/skip:<Test>] [/test:<Test>]

Parameters for this utility are as follows:

  • /h-Display this help screen.
  • /s-Use <Domain Controller> as the home server. This is ignored for DCPromo and RegisterInDNS tests, which can only be run locally.
  • /n-Use <Naming Context> as the naming context to test. Domains can be specified in NetBIOS, DNS, or distinguished name (DN) format.
  • /u-Use domain\username credentials for binding with a password. Must also use the /p option.
  • /p-Use <Password> as the password. Must also use the /u option.
  • /a-Test all the servers in this site.
  • /e-Test all the servers in the entire enterprise. This parameter overrides the /a parameter.
  • /q-Quiet; print only error messages.
  • /v-Verbose; print extended information.
  • /i-Ignore; ignore superfluous error messages.
  • /fix-Fix; make safe repairs.
  • /f-Redirect all output to a file <Log>; /ferr will redirect error output separately.
  • /ferr:<ErrLog>-Redirect fatal error output to a separate file <ErrLog>.
  • /c-Comprehensive; run all tests, including nondefault tests but excluding DCPromo and RegisterInDNS. Can use with /skip.
  • /skip:<Test>-Skip the named test. Do not use in a command with /test.
  • /test:<Test>-Test only the specified test. Required tests will still be run. Do not use with the /skip parameter.
  • /x:<XMLLog.xml>-Redirect XML output to <XMLLog.xml>. Currently works with the /test:dns option only.
  • /xsl:<xslfile.xsl or xsltfile.xslt>-Add the processing instructions that reference a specified stylesheet. Works with the /test:dns /x:<XMLLog.xml> option only.

The command supports a variety of tests, which can be selected. Some tests are run by default and others need to be requested specifically. The command line supports selecting tests explicitly (/test) and skipping tests (/skip). Table-9 shows valid tests that can be run consistently.

TABLE-9 DCDIAG Tests
Test NameDescription
AdvertisingChecks whether each DC is advertising itself and whether it is advertising itself as having the capabilities of a DC.
CheckSDRefDomChecks that all application directory partitions have appropriate security descriptor reference domains.
CheckSecurityErrorLocates security errors and performs the initial diagnosis of the problem. This test is not run by default and has to be requested with the /test option.
ConnectivityTests whether DCs are DNS registered, pingable, and have LDAP/RPC connectivity. This is a required test and cannot be skipped with the /skip option.
CrossRefValidationThis test looks for cross-references that are in some way invalid.
CutoffServersChecks for servers that won't receive replications because their partners are down. This test is not run by default and has to be requested with the /test option.
DCPromoTests the existing DNS infrastructure for promotion to the domain controller.
DNSChecks the health of DNS settings for the whole enterprise. This test is not run by default and has to be requested with the /test option.
FrsEventChecks to see if there are any operation errors in the file replication server (FRS). Failing replication of the sysvol share can cause policy problems.
DFSREventChecks to see if there are any operation errors in the DFS.
DFSREventChecks to see if there are any operation errors in the DFS.
LocatorCheckChecks that global role holders are known, can be located, and are responding.
IntersiteChecks for failures that would prevent or temporarily hold up intersite replication.
KcceventChecks that the Knowledge Consistency Checker is completing without errors.
KnowsOfRoleHoldersChecks whether the DC thinks it knows the role holders of the five FSMO roles.
MachineAccountChecks to see whether the machine account has the proper information. Use the /RecreateMachineAccount parameter to attempt a repair if the local machine account is missing. Use /FixMachineAccount if the machine's account flags are incorrect.
NCSecDescChecks that the security descriptors on the naming context heads have appropriate permissions for replication.
NetLogonsChecks that the appropriate logon privileges allow replication to proceed.
ObjectsReplicatedChecks that machine account and DSA objects have replicated. You can use /objectdn:<dn> with /n:<nc> to specify an additional object to check.
OutboundSecureChannelsVerifies that secure channels exist from all the DCs in the domain to the domains specified by /testdomain. The /nositerestriction parameter prevents the test from being limited to the DCs in the site. This test is not run by default and has to be requested with the /test option.
RegisterInDNSTests whether this domain controller can register the Domain Controller Locator DNS records. These records must be present in DNS for other computers to locate this domain controller for the <Active_Directory_Domain_DNS_Name> domain. Reports whether any modifications to the existing DNS infrastructure are required. Requires the /DnsDomain:<Active_Directory_Domain_DNS_Name> argument.
ReplicationsChecks for timely replication between domain controllers.
RidManagerChecks to see whether RID master is accessible and whether it contains the proper information.
ServicesChecks to see whether DC services are running on a system.
SystemlogChecks that the system is running without errors.
TopologyChecks that the generated topology is fully connected for all DCs. This test is not run by default and has to be requested with the /test option.
VerifyEnterpriseReferencesVerifies that certain system references are intact for the FRS and replication infrastructure across all objects in the enterprise. This test is not run by default and has to be requested with the /test option.
VerifyReferencesVerifies that certain system references are intact for the FRS and replication infrastructure.
VerifyReplicasVerifies that all application directory partitions are fully instantiated on all replica servers. This test is not run by default and has to be requested with the /test option.

Monthly Maintenance

It is recommended that you perform the tasks examined in the following sections on a monthly basis.

Maintaining File System Integrity

CHKDSK scans for file system integrity and can check for lost clusters, cross-linked files, and more. If Windows 2008 senses a problem, it will run CHKDSK automatically at startup.

Administrators can maintain FAT, FAT32, and NTFS file system integrity by running CHKDSK once a month. To run CHKDSK, do the following:

  1. At the command prompt, change to the partition that you want to check.
  2. Type CHKDSK without any parameters to check only for file system errors. No changes will be made.
  3. If any errors are found, run the CHKDSK utility with the /f parameter to attempt to correct the errors found.

Testing the UPS

An uninterruptible power supply (UPS) can be used to protect the system or group of systems from power failures (such as spikes and surges) and keep the system running long enough after a power outage so that an administrator can gracefully shut down the system. It is recommended that an administrator follow the UPS guidelines provided by the manufacturer at least once a month. Also, monthly scheduled battery tests should be performed.

Validating Backups

Once a month, an administrator should validate backups by restoring the backups to a server located in a lab environment. This is in addition to verifying that backups were successful from log files or the backup program's management interface. A restore gives the administrator the opportunity to verify the backups and to practice the restore procedures that would be used when recovering the server during a real disaster. In addition, this procedure tests the state of the backup media to ensure that they are in working order and builds administrator confidence for recovering from a true disaster.

Updating Documentation

An integral part of managing and maintaining any IT environment is to document the network infrastructure and procedures. The following are just a few of the documents you should consider having on hand:

  • Server build guides
  • Disaster recovery guides and procedures
  • Checklists
  • Configuration settings
  • Change configuration logs
  • Historical performance data
  • Special user rights assignments
  • Special application settings

As systems and services are built and procedures are ascertained, document these facts to reduce learning curves, administration, and maintenance.

It is not only important to adequately document the IT environment, but it's often even more important to keep those documents up to date. Otherwise, documents can quickly become outdated as the environment, processes, and procedures change as the business changes.

Quarterly Maintenance

As the name implies, quarterly maintenance is performed four times a year. Areas to maintain and manage on a quarterly basis are typically fairly self-sufficient and self-sustaining. Infrequent maintenance is required to keep the system healthy. This doesn't mean, however, that the tasks are simple or that they aren't as critical as those tasks that require more frequent maintenance.

Checking Storage Limits

Storage capacity on all volumes should be checked to ensure that all volumes have ample free space. Keep approximately 25% free space on all volumes. Running low or completely out of disk space creates unnecessary risk for any system. Services can fail, applications can stop responding, and systems can even crash if there isn't plenty of disk space.

Changing Administrator Passwords

Administrator passwords should, at a minimum, be changed every quarter (90 days). Changing these passwords strengthens security measures so that systems can't easily be compromised. In addition to changing passwords, other password requirements such as password age, history, length, and strength should be reviewed.

[Previous] [Contents]