Windows Server


Active Directory Diagnostic Logging    



Active Directory Diagnostic Logging


Active Directory Diagnostic Logging


AD Logs

Summary of Log Files Used in Active Directory

Windows 2000 maintains specific log files that pertain to Active Directory. For example, when installing or removing Active Directory by using the Active Directory Installation Wizard (also known as dcpromo), several log files are created in the %SystemRoot%\Debug that you can use to investigate the actual process. You need to be familiar with the information provided in these files because they provide relevant facts about Active Directory performance and services. The default location for the log files is the % SystemRoot %\Debug folder. For more information about Windows 2000 log files, see the Microsoft TechNet Web link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources . Search the Technical Support section of this site for Knowledge Base articles and other sources of technical information.



The DcpromoUI.log file contains a detailed progress report of the Active Directory installation and removal processes. Its default location is the % SystemRoot %\Debug folder on Windows 2000–based servers. Logging begins when the Active Directory Installation Wizard is opened and continues until the summary screen appears; regardless of whether it terminated prematurely or completed successfully. If the installation or removal failed, detailed error messages appear in the log immediately after the step that caused the failure. When the installation or removal process is successful, the log provides positive confirmation of that fact.

Additionally, the DcpromoUI.log file includes the following useful information, about the installation or removal of Active Directory:

The name of the source domain controller for replication.


The directory partitions that were replicated to the target server


The number of items that were replicated in each directory partition


The services configured on the target domain controller


The access control entries (ACEs) set on the registry and files


The SYSVOL directories


Applicable error messages


Applicable selections that were entered by the Administrator during the installation or removal process

For more information about the Dcpromoui.log, see "Active Directory Installation and Removal Issues" later in this chapter.



The %windir%\debug\dcpromos.log is created by the user interface during the graphical user interface mode setup when a Windows 3. x –based or Windows 4.0–based domain controller is promoted to a Windows 2000 domain controller.



The DCPromo.log file is created by using the Active Directory Installation Wizard. Its default location is the %SystemRoot%\Debug folder on Windows 2000–based servers. It also records settings used for the promotion or demotion, such as the site name, the path for the Active Directory database and log files, time synchronization, and information about the computer account. The DCPromo.log file captures the creation of the Active Directory database, SYSVOL trees and the installation and modification of services.

For more information about the Dcpromo.log see "Active Directory Installation and Removal Issues" later in this chapter.



When joining a computer to a Windows 2000 domain, the Networking Setup (NetSetup) installs all the necessary Microsoft supported networking components. The Netsetup.log file provides information about the attempts to join domains and records any errors that might be preventing the join from being successful. Also, to install networking components not directly supported by Microsoft, the NetSetup tool provides a way to connect into the setup process for third-party components.

For more information about Netsetup.log, see "Authentication" earlier in this chapter.



The Net Logon service responds to network logon requests. The Net Logon service dynamically creates records in the DNS database that are used to locate a server.

The Netlogon.log file is created whenever the service is used. For more information about the Net Logon service, see "Name Resolution in Active Directory" in this book. For more information about Netlogon.log, see "Active Directory Architecture" earlier in this chapter.



The File Replication service (FRS) text-based log file is the Ntfrsapi.log file. It resides in the % SystemRoot %\Debug folder. It tracks replication problems and contains events that take place during the installation or removal of Active Directory, for example, creating the NTFRS registry keys. For more information about FRS and the Ntfrsapi.log file, see the "File Replication Service" in this book and the Microsoft Personal Online Support link on the Web Resource page at http://windows.microsoft.com/windows2000/reskit/webresources .



The output of this log file can be helpful in troubleshooting problems with user profiles and Group Policy processing. The log file resides in the % SystemRoot %\Debug folder.

Following is an example of the userenv.log file showing a failure to return a string representing the user guid of the current user.

USERENV (b8.a0) 17:02:31:274 GetUserGuid: Failed to get user guid with 1332.

USERENV (b8.a0) 17:02:31:584 GetUserGuid: Failed to get user guid with 1332.

USERENV (b8.a0) 17:02:31:584 GetUserGuid: Failed to get user guid with 1332.

USERENV (b8.cc) 17:02:31:715 ProcessGPOs: Starting user Group Policy processing...

USERENV (b8.cc) 17:02:31:765 ProcessGPOs: User Group Policy has been applied.

USERENV (b8.c0) 18:43:31:980 ProcessGPOs: Starting user Group Policy processing...

USERENV (b8.c0) 18:43:32:030 ProcessGPOs: User Group Policy has been applied. 


Active Directory Diagnostic Logging

Active Directory records events in the directory services log in Event Viewer. You can use the log to monitor the activity level of Active Directory or to investigate problems.

By default, Active Directory records only critical error events. To instruct Active Directory to record other events in the directory service log, modify the registry. For more information about how to use the Windows 2000 registry editors, see the Windows 2000 Server Help.



Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your computer. Editing the registry directly can have serious, unexpected consequences that can prevent the computer from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or MMC whenever possible.

The registry entries that manage diagnostic logging are stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Each entry represents a type of event that Active Directory can log. The value of the entry determines the level of detail of the events that are logged and ranges from 0 (records default-level errors and standard verbosity) to 5 (most verbose and records all activity).Table 10.10 describes each of these values.


Table   10.10 Values for the Diagnostics Registry Entry





0 (None)

Only critical events and error events are logged. This is the default and should be changed only if a problem occurs.


1 (Minimal)

Very high-level events are recorded in the event log. These might include one message for each major task performed by the service. Use this setting to begin an investigation when the location of the problem is in doubt.


2 (Basic)

Events with a logging level of 2 or lower are logged.


3 (Extensive)

Events with a logging level of 3 or lower are logged.

Messages are sent to the event log to record steps taken to run a task. This provides more information than the minimum level but not the detail of the maximum level. Use this when the problem has been narrowed to a service or group of categories


4 (Verbose)

Events with a logging level of 4 or lower are logged.


5 (Internal)

All events are logged, including debug strings and configuration changes received.

Provides a complete log of the operation of the service. Use this level when the problem is traced to a particular category or a small set of categories.

All of the entries in the Diagnostics subkey have the REG_DWORD data type and a default value of  0 .


Logging levels should be set to 0 (None) unless a problem is being investigated.

All fatal and critical errors are logged at level 0, and no user action is required to view them.

Increasing the level increases the detail of the messages and the number of messages emitted. Setting the value of entries in the Diagnostics subkey to greater then 3 can degrade server performance and is not recommended. The application event log fills up quickly when the logging level is increased.


Table 10.11 contains a list of registry entries in the Diagnostics subkey that store the directory service logging levels.


Table   10.11 Registry Entries in the Diagnostics Subkey

Registry Entry




Knowledge Consistency Checker (KCC)

The KCC derives its input configuration from objects in the directory (for example, sites, servers and site links). The KCC reports if these objects are incorrect or missing.

Events occurring during a run of the KCC. Messages fall into the following categories:

KCC runtime errors, such as inconsistencies, resource errors or directory access problems.

KCC output configuration problems. The new configuration cannot be built or is incomplete in some way. Perhaps too many servers are down to build a complete topology at this time.


Security Events

Events related to Windows 2000 Security, such as a user who tries to read or write an attribute with insufficient permissions, a user binding through MAPI, or a domain that has been changed to native mode.


ExDS Interface Events

Events related to communication between Active Directory and Exchange clients.


MAPI Interface Events

Events related to communication between Active Directory and Exchange clients.


Replication Events

Events related to outbound replication, where changed objects are found and inbound replication, where these changes are applied to a local database. "Normal" errors during the course of replication, such as a domain controller being down, are not logged. They are kept as status and are available through the replication tools. The errors logged during replication are generally critical inconsistencies that require user intervention, as database errors. The other kind of events logged by the replication category are information about which objects and attributes were updated and why.

Note that many attributes are updated each time replication occurs. Logging detail about attributes can generate a great deal of messages very quickly. A level of 1 is safe and might be informative as to the general types of operations occurring for replication. A level higher than level  2 can result in filling up the log file and performance degradation.


Garbage Collection

Events generated when objects marked for deletion are actually deleted.


Internal Configuration

Interpretation and display of the internal directory service operations.


Directory Access

Reads and writes directory objects from all sources.


Internal Processing

Events related to the internal operation of Active Directory code such as processing security descriptor propagation. Error events in this category might be an indicator of serious problems in Active Directory.

When the directory returns the status of "internal error," this category can be used to identify the problem for Microsoft support. Set this category to 1 on all computers involved (client and server) and reproduce the problem. Note the point in the code where the internal error was raised.


Performance Counters

Events related to loading and unloading the NTDS performance object and performance counters.



Events related to starting and stopping Active Directory.


Service Control

Processes Active Directory service events.


Name Resolution

Resolution of addresses and Active Directory names.



Events related to the backup of Active Directory. Specifically, errors occurring when ESE database records are read or written for backup purposes. Generally only logged when a backup operation is underway.


Field Engineering

Internal debugging trace.


LDAP Interface Events

Events related to LDAP. An example of events logged include the following: the LDAP server closed a socket to a client, unable to initialize LDAP Simple Bind Authentication, and LDAP over SSL is now available.



Events related to running the Active Directory Installation Wizard.


Global Catalog

Events related to Global Catalog. For example, "Promotion of this server to a Global Catalog will be delayed for % 1 minutes. This delay is necessary so that the required partitions can be made ready before the GC is advertised.

The operations that occur during this time include the KCC being run to generate the new topology, all read-only partitions in the enterprise being added to this server, and the contents of these partitions being replicated into this system.

If you want to promote the GC immediately without enforcing this precondition, set the registry variable HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\GlobalCatalogDelayAdvertisement (sec) to a DWORD value of 0. The GC will be promoted on the next attempt to check preconditions. This value can also be set to the maximum number of seconds that the DSA will wait before promoting to a GC."


Inter-site Messaging

These messages are logged by the "Intersite Message" service, which is a separate service from the directory itself. There are two kinds of messages that are generated in this category:

The ISM Service is responsible for transporting replication messages between sites.

The ISM Service is also responsible for calculating site routes for the KCC to use. Note that the messages in this category are either fatal configuration errors, or informational messages about the amount of traffic being carried.






Understanding Log Files



Understanding Log Files

Before effective troubleshooting of Microsoft Deployment can begin, team members should have a clear understanding of the many logs used during an operating system deployment. When it is clear which .log files must be researched for what failure condition and at what time, certain issues that were once mysterious and difficult to understand may become clear and understandable.

The Microsoft Deployment .log file format is designed to be read by Trace32, which is part of the Systems Management Server 2003 Toolkit 2 (available for download from http://www.microsoft.com/downloads/details.aspx?FamilyID=61e4e21f-2652-42dd-a04d-b67f0573751d). This tool should be used whenever possible to read the logs, because it makes finding errors much easier.

The rest of this section details the .log files created during the deployment as well as during Windows Setup. This section also provides examples of when the files can be used for troubleshooting.


Microsoft Deployment Log Files

Each Microsoft Deployment script automatically creates log files during its execution. The names of these log files match the name of the script—for example, ZTIGather.wsf creates a log file namedZTIGather.log. Each script also updates a common master log file (BDD.log) that aggregates the contents of logs that Microsoft Deployment scripts create. Microsoft Deployment logs reside in the C:\MININT\SMSOSD\OSDLOGS folder during the deployment process. Depending on the type of deployment being conducted, the logs are moved at the completion of the deployment to either the %WINDIR%\SMSOSD folder or the %WINDIR%\TEMP\SMSOSD folder. Microsoft Deployment creates the following log files:

  • BDD.log. This is the aggregated Microsoft Deployment log file that is copied to a network location at the end of the deployment if the SLShare property is specified in the Customsettings.ini file.
  • DeployUpdates_ Platform. log. This file is created when deployment points are updated or when updating Windows PE. Platform represents the platform being updated—either x86 or x64. This log is useful when troubleshooting Windows PE driver-integration issues. It resides in the %TEMP% folder.
  • LiteTouch.log. This file is created during LTI deployments. It resides in the %WINDIR%\Temp\BDDLogs folder unless the /debug:true option was specified.
  • Scriptname .log. This file is created by each Microsoft Deployment script. Scriptnamerepresents the name of the script in question.
  • SMSTS.log. This file is created by the Task Sequencer and describes all Task Sequencer transactions. Depending on the deployment scenario, it may reside in %TEMP%, %WINDIR%\System32\ccm\logs, or C:\SMSTSLog.
  • Wizard.log. The deployment wizards create and update this file.
  • WPEinit.log. This file is created during the Windows PE initialization process. This log file is useful for troubleshooting errors encountered while starting Windows PE.
  • ZeroTouchInstallation.log. This file is created during ZTI deployments. It may reside in C:\Temp\SMSOSD or C:\SMSOSD unless the C:\MININT\Archive_OSD.SMS file is found.


Operating System Logs

Team members must review several Windows Setup log files during troubleshooting activities.

Windows Vista

The following list is a subset of the Windows Setup log files that are most useful for troubleshooting deployment issues. For more detailed information about Windows Vista Setup log files, see the Microsoft Help and Support article, “Windows Vista setup log file locations,” athttp://support.microsoft.com/kb/927521.

  • Netsetup.log. Resides in %WINDIR%\Debug; useful when troubleshooting domain join issues
  • Setupact.log. Resides in %WINDIR%\panther; lists installation actions and is useful when investigating failed installations
  • Setupapi.dev.log. Resides in %WINDIR%\inf; useful when investigating failed driver installations
  • Setuperr.log. Resides in %WINDIR%\panther; details errors that occurred during installation

Windows XP

The following log files, located in the %WINDIR% folder, are the most useful when troubleshooting Windows XP with Service Pack 2 (SP2):

  • Netsetup.log. Resides in %WINDIR%\Debug; useful when troubleshooting domain join issues
  • Setupact.log. Lists installation actions; useful when investigating failed installations
  • Setupapi.log. Contains information about hardware detection during the installation; useful for investigating failed driver installations
  • Setuperr.txt. Contains information about Setup errors during the installation
  • Setuperr.log. Details errors that occurred during installation
  • Setuplog.txt. Contains information about Setup actions during the installation


SMS 2003 OSD Feature Pack Logs

The following logs, located in the C:\MININT\SMSOSD\OSDLOGS folder, are created during the deployment phases of the SMS 2003 OSD Feature Pack. After the log name is the information contained in the log:

  • IDUser.log. Provides information about user notifications
  • IDUserNotification.log. Provides information about user notifications
  • MachineState.log. Contains computer state migration information (computer name, IP address, registered owner and organization)
  • OSDAgent.log. The primary log; the first place to look to determine which step failed
  • OSDBootstrap.log. Will contain errors if the Advanced Client Network Access account is not configured correctly
  • OSDEnv.log. Details which SMS 2003 OSD Feature Pack environment variables are set
  • OSDInstallWIM.log. Details image-installation options
  • OSDInstallWizard.log. Details startup operations
  • OSDLaunch.log. Will contain errors if the Advanced Client Network Access account is not configured correctly
  • OSDShell.log. Details the start of the OSD Install Wizard
  • OSDSWDProgramExec.log. Details the running of the Run SWD Program actions
  • OSDUsmtLoadstate.log. Details USMT Restore operations
  • OSDUsmtScanstate.log. Details USMT Capture operations
  • ScanState.log. Details USMT ScanState information
  • SMSCMT.log. Details Systems Management Server 2003 client migration information such as site code and client globally unique identifiers (GUIDs)
  • WinPEInstall.log. Details Windows PE installation information

Note   The C:\minint folder is lost during the disk partitioning process. To troubleshoot issues that occur before this point, disable the disk partitioning task in the Task Sequencer.



When executing USMT operations, Microsoft Deployment automatically adds the logging switches to save the USMT logs to the Microsoft Deployment log file locations. The logs and when they are created are as follows:

  • USMTEstimate.log. Created when estimating the USMT requirements
  • USMTCapture.log. Created by the USMT when capturing data
  • USMTRestore.log. Created by the USMT when restoring data


Sample Log Review

Failure to Access the Database

An error occurred while executing a deployment that used a CustomSettings.ini file containing numerous sections and specifying, via the Priority property, the priority of each section to be processed. BDD.log contained the following error messages:

  • ERROR - Opening Record Set (Error Number = -2147217911) (Error Description: The SELECT permission was denied on the object 'ComputerAdministrators', database 'AdminDB', schema 'dbo'.)
  • ADO error: The SELECT permission was denied on the object 'ComputerAdministrators', database 'AdminDB', schema 'dbo'. (Error #-2147217911; Source: Microsoft OLE DB Provider for SQL Server; SQL State: 42000; NativeError: 229
  • ERROR - Unhandled error returned by ZTIGather: Object required (424)

Note   For clarity, the .log contents above have been represented as they appear while being viewed using Trace32.

The issue, as pointed out on the first line of the .log sample, is that permission to access the database was denied. Therefore, the script could not establish a secure connection to the database, because OSDConnectToUNC.exe was not available; nor was a user ID and password. As a result, the database access was attempted using the computer account. It was determined that the easiest way to work around this issue was to grant everyone Read access to the database.

Implement the Windows Update Script

If team members decide to implement the ZTIWindowsUpdate.wsf script to apply software updates during deployment, note that this script communicates directly with the Microsoft Update Web site to download and install the required Windows Update Agent binaries, scan for applicable software updates, download the binaries for the applicable software updates, and then install the downloaded binaries. This process requires that the organization’s networking infrastructure be configured to allow the target computer to gain access to the Microsoft Update Web site.

If the target computer does not have appropriate Internet access, the following error is reported in the ZTIWindowsUpdate.log and BDD.log files: wuredist.cab not found.



Get the Microsoft Deployment Solution Accelerator




Join and Authentication Issues



Join and Authentication Issues

If you can't join a computer to an Active Directory domain, or if a computer can't communicate with any other computer in the network, the situation might be the result of join and authentication problems.

This section discusses diagnostic tools and gives examples of possible authentication problems, along with suggested solutions. The first step toward identifying and diagnosing Active Directory join and authentication problems is to review how a Windows 2000–based computer joins a domain, what permissions are required by a user, and how a secure channel is established.

Joining a Computer to a Domain

To review, when you join either a Windows NT 4.0–based or a Windows 2000–based client to a domain, the following occurs:

·         The domain name is validated.

·         A domain controller in the domain is located through a call to DsGetDcName.

·         A session is established with the domain controller under the security context of the passed-in credentials that are supplied in the Network Identification tab under System Properties inControl Panel .

·         The computer account is enabled. If the flags are so specified (NETSETUP_ACCT_CREATE), the APIs create the computer account on the domain controller.

·         The local password for this account is created in the Local Security Authority (LSA).

·         The local primary domain information LSA policy is set to refer to the new domain. This includes the domain name and the domain SID.

clip_image001 Note

For a Windows 2000–based client only, the LSA policy consists of the domain name, domain SID, DNS domain name, DNS forest name, and domain GUID.

·         The name of the DNS name assigned to the local computer is updated.

·         The local group membership is changed to add members of the Domain Admins group to the Local Accounts Administrators group.

·         The Net Logon trusted domain cache is initialized to the trusted domains domain list.

·         For Windows 2000–based clients only, the Windows Time Service is enabled and started.

·         The Net Logon service is started.


Changes Occurring on Domain Controllers in the Domain That the Client is Joining

When a client joins a domain, the following changes occur on Windows NT 4.0–based and Windows 2000–based domain controllers:

·         A computer object is created. The name of this object is generated by appending a dollar sign ($) to the name (uppercase letters) of the client.

·         On Windows 2000–based domain controllers only, the Net Logon service creates Service Principle Names (SPNs) on the computer object.


Identifying Whether You Have a Problem Authenticating

You can identify whether you have a problem authenticating (or joining) a computer to a domain by verifying that the local workstation is working. Do this by running the Netdiag tool. Read the output from the top, and look for the words "ERROR" or "FATAL." (Many failures are not relevant to the domain itself; but you should follow up on them because they involve network connectivity issues.) If you don't find these words in the output, continue as follows:

·         Run netdiag /v (verbose mode). Do you receive any specific error messages or FATAL errors?

·         If the answer to the preceding question is "No," run netdiag /debug . Do you receive any specific error messages or FATAL errors?

·         If Netdiag displays an error or failure with the domain itself, check the % SystemRoot%\debug\netsetup.log file for join errors.

clip_image001[1] Note

If the local workstation is functional, examine the Netsetup.log file that is located in the % SystemRoot%\debug folder. (This is where the join process is logged.) Are any specific error messages logged?


Format of Netsetup.log File

A typical line in Netsetup.log is formatted as follows:

< time-stamp > < function-name >: < description of operation >: < status code in hexadecimal code >.

An example is the following:

08/11 14:08:29 NetpJoinDomain: status of connecting to dc '\\DC9': 0x0

The description of the join operation is usually self-explanatory. The status code is NET API_STATUS or a Win32 error code. A "0x0" code indicates success; any other code indicates an error.


Specific Join Issues

You might encounter problems when you join your computer to a domain. Even though these problems are reported as join problems, some of the most frequently reported ones are not related to the join process. Looking at the Netsetup.log is sufficient to quickly spot such cases.

The following are some of the most common errors that relate to join issues:

·         Failure to find or to connect to a domain controller.

·         Transient network conditions or having specified an incorrect domain name.

·         Failure to create a computer account.

The error code shown in Table 10.6 comes under this category.

Table   10.6 " Failure to find a domain controller " Error Code


Actual Error

Error Code

Failure to find or connect to a domain controller.



The following is an example of this error:

07/20 16:51:10 NetpDsGetDcName: trying to find DC in domain 'verylongdomain1', flags: 0x1020

07/20 16:51:11 NetpDsGetDcName: failed to find a DC having account 'A-USHAS2-80C$': 0x525

07/20 16:51:11 NetpDsGetDcName: failed to find a DC in the specified domain: 0x54b

07/20 16:51:11 NetpDoDomainJoin: status: 0x54b

The join process usually tries to find a domain controller that already has a computer account for the computer that is currently being joined to the domain. If such a domain controller is not found, it tries to find another domain controller. The preceding example shows that the join domain operation failed because a domain controller was not located for the specified domain.

To investigate further, run nltest /dsgetdc:< domain-name > and examine the output. If you still receive errors, either the domain really does not exist or there is a transient net error that is preventing domain controller discovery. By running Netdiag.exe and examining the output, you usually can determine the cause. A "Failure to connect to a domain controller" message usually means that transient net errors or insufficient credentials are the cause. Table 10.7 shows some error codes that come under this category.

Table   10.7 " Failure to connect to a domain controller " Error Codes


Actual Error

Error Code

Bad credentials.



Time skew that can cause failure of Kerberos authentication.



Failure to connect to a domain controller.



No domain controller found.



The following is an example of this type of error code:

07/20 14:47:34 NetpDsGetDcName: trying to find DC in domain 'reskit', flags: 0x1020

07/20 14:47:50 NetpDsGetDcName: failed to find a DC having account 'TO_A$': 0x525

07/20 14:47:50 NetpDsGetDcName: found DC '\\reskit' in the specified domain

07/20 14:47:50 NetUseAdd to \\reskit\IPC$ returned 1326

07/20 14:47:50 NetpJoinDomain: status of connecting to dc '\\reskit: 0x52e

07/20 14:47:50 NetpDoDomainJoin: status: 0x52e

The previous example shows a failed attempt to find a domain controller having the account "TO_A$". This is not a fatal error because the code then tries to find any domain controller in the specified domain. After a domain controller is found, an attempt is made to connect to it by using the credentials that are supplied. This attempt failed with error 0x52e (ERROR_LOGON_FAILURE). This indicates that the credentials that were supplied do not have sufficient access rights for connecting to the domain controller.

To investigate the problem of failing to find a domain controller, run an equivalent command from the command prompt to confirm the preceding analysis.

net use \\dcname\ipc$ /u:< domain\user > < password >

clip_image001[2] Note

You need to perform the net use if you failed to connect to the domain controller. If you failed to find the domain controller, you should perform nltest /dsgetdc: to try to locate the domain controller.

If this fails with the same error, a Network Monitor sniffer trace of the join operation would be helpful in diagnosing the failure.

If you receive the error "Failure to create a computer account," it usually means that either the account already exists or that there are insufficient access rights available to the user who is trying to join. Table 10.8 shows the error codes that come under this category.

Table   10.8 " Failure to create a computer account " Error Codes


Actual Error

Error Code

Computer account usually exists already, and security on that account does not allow you to join — usually because the computer was joined previously by using different computer account credentials.



The user has joined so many computers that he has exceeded the default per user computer quota (by default, 10).



The specified user already exists.



The following example indicates an access denied error.

08/11 14:08:30 NetpManageMachineAccountWithSid: NetUserAdd on '\\DC9' for 'A-ERINCO-TBCB$' failed: 0x5

The following example indicates there is no error.

08/11 14:08:30 NetpManageMachineAccountWithSid: NetUserAdd on '\\DC9' for 'A-ERINCO-TBCB$' failed: 0x8b0

08/11 14:08:30 NetpManageMachineAccountWithSid: status of attempting to set password on '\\DC9' for 'A-ERINCO-TBCB$': 0x0

This is not an error because the NetUserAdd operation fails with 0x8b0 (NERR_UserExists), which indicates that the computer account already exists on that domain controller.

clip_image001[3] Note

Failure usually occurs when the account already exists. Error 5 occurs if the user does not have access on the account, in which case an attempt is made to set a new password on the account that succeeds.

To investigate further, you have to acquire the security descriptor and view the permissions on the computer account object. You can use either the Active Directory User and Computers MMC console or the Ldp tool.

For more information about how to view permissions and access control entries on specific objects with the Active Directory User and Computers console, see Windows 2000 Server Help. For more information about access control entries and security descriptors, see "Access Control" in this book.

To investigate further, connect to the domain controller by using the Ldp tool. Acquire the security descriptor on the computer account and determine whether the user trying to join has sufficient permissions to gain access to the computer account.

To use Ldp to acquire the security descriptor

1.      From the Start menu, click Run , and then type the following: 

2.      Connect and bind to a domain controller in the domain whose security descriptor you are searching for.

o    To connect, on the Connection menu, click Connect , and then type a server name.

o    To bind, on the Connection menu, click Bind , and then type an account name, password, and domain if you want to connect to a domain other than the domain to which you are currently logged on.

3.      On the Browse menu, point to Security , and click Security Descriptor .

4.      Provide distinguished name of the computer object whose security descriptor you are looking for.

Here is a sample output:

Revision: 1

Sbz1: 0

Control: (0x8c04)












Revision: 4

Sbz1: 0

Size: 972

No of Aces: 24

Sbz2: 0


Type: (0)


AceSize: 0x24

AceFlags: (0x0)

Mask: 0x000f01ff



DDS\Domain Admins


Type: (5)


AceSize: 0x28

AceFlags: (0x0)

Mask: 0x00000010

Flags: 0x1


Object Type:

(in HEX)(59ba2f42-79a2-11d0-90-20-00-c0-4f-c2-d3-cf)




NT AUTHORITY\Authenticated Users

For more information about interpreting mask, ACE types and flags, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources . Follow the links to ntsam.h.

The following example shows a successful attempt to join a computer to a domain in the Netsetup.log file:

NETSETUP.log file

07/30 13:58:35 NetpDoDomainJoin

07/30 13:58:35 NetpMachineValidToJoin: 'USER1'

07/30 13:58:35 NetpGetLsaPrimaryDomain: status: 0x0

07/30 13:58:35 NetpMachineValidToJoin: status: 0x0

07/30 13:58:35 NetpJoinDomain

07/30 13:58:35 Machine: USER1

07/30 13:58:35 Domain: RESKIT

07/30 13:58:35 MachineAccountOU: (NULL)

07/30 13:58:35 Account: RESKIT\reskit

07/30 13:58:35 Options: 0x40001

07/30 13:58:35 OS Version: 5.0

07/30 13:58:35 Build number: 2089

07/30 13:58:35 NetpCheckDomainNameIsValid [ Exists ] for 'RESKIT' returned 0x0

07/30 13:58:35 NetpValidateName: name 'RESKIT' is valid for type 3

07/30 13:58:35 NetpDsGetDcName: trying to find DC in domain 'RESKIT', flags: 0x1020

07/30 13:58:50 NetpDsGetDcName: failed to find a DC having account 'USER1$': 0x525

07/30 13:58:50 NetpDsGetDcName: found DC '\\RESKIT-DC-08' in the specified domain

07/30 13:58:51 NetpJoinDomain: status of connecting to dc '\\RESKIT-DC-08': 0x0

07/30 13:58:51 NetpGetLsaPrimaryDomain: status: 0x0

07/30 13:58:51 NetpLsaOpenSecret: status: 0xc0000034

07/30 13:58:52 NetpJoinDomain: status of setting machine password: 0x0

07/30 13:58:52 NetpJoinDomain: status of setting netlogon cache: 0x0

07/30 13:58:52 NetpGetLsaPrimaryDomain: status: 0x0

07/30 13:58:52 NetpSetLsaPrimaryDomain: for 'RESKIT' status: 0x0

07/30 13:58:52 NetpJoinDomain: status of setting LSA pri. domain: 0x0

07/30 13:58:53 NetpJoinDomain: status of managing local groups: 0x0

07/30 13:58:54 NetpJoinDomain: status of starting Netlogon: 0x0

07/30 20:58:55 NetpJoinDomain: status of setting ComputerNamePhysicalDnsDomain 'reskit.reskit.com': 0x0

07/30 20:58:55 NetpDsSetSPN: Setting DnsHostName 'USER1.reskit.reskit.com' on 'CN=USER1,CN=Computers,DC=reskit,DC=microsoft,DC=com'

07/30 20:58:55 NetpDsSetSPN: Setting SPN 'HOST/USER1.reskit.reskit.com' on 'CN=USER1,CN=Computers,DC=reskit,DC=microsoft,DC=com'

07/30 20:58:55 NetpJoinDomain: status of disconnecting from '\\RESKIT-DC-08': 0x0

07/30 20:58:55 NetpDoDomainJoin: status: 0x0


Permissions on Computer Account Objects

This section describes the security on domain computer accounts before and after an upgrade to Windows 2000 Server. This information can be used in troubleshooting permissions on computer account objects in Active Directory and in determining which user created the computer account before the upgrade.

The Discretionary ACL (DACL) contains access control entries (ACEs) that define permissions on a specific object. In Windows NT 4.0, when a computer account is created, the Domain Administrators local group becomes the owner of the computer account. The user who created the computer account is stored as part of its data, and the DACL on the computer account includes limited rights for the user (such as deleting the account).

When you upgrade a Windows 2000–based server, the following changes occur on each computer account:

·         A computer account object is created in the default Computers container. The original owner (for example, administrator) of the computer account remains the same. The privileges that the original owner had on the computer object in Windows NT 4.0 are retained as part of the upgrade.

·         The DACL on the computer account is reset to the default that is defined for objects of thecomputer class in the schema. This DACL includes an entry for Creator Owner and, when viewed with ACL Editor, displays the name of the appropriate user.

clip_image001[4] Note

Note that other ACEs can be present if users or groups are added or if permissions are changed on parent containers in Active Directory, which results in additional inherited permissions

·         The following default DACLs apply to new computer accounts:

·         Self:

o    Create All Child Objects

o    Delete All Child Objects

·         Authenticated Users:

o    Read

o    Read Public Information

·         System:

o    (Full Control)

·         Creator Owner:

o    (Full Control)

·         Domain Administrators:

o    (Full Control)

·         Cert Publishers:

o    (no permissions)

·         Enterprise Administrators (inherited permissions):

o    Read

o    Write

o    Create All Child Objects

o    Change Password

o    Receive As

o    Reset Password

o    Send As

o    Read Public Information

o    Write Public Information

·         Account Operators:

o    (Full Control)

·         Print Operators:

o    (no permissions)

·         Everyone:

o    Change Password

clip_image001[5] Note

If the account is created by using the privilege add workstations to the domain, then the rights of the Creator Owner are limited. Specifically, the Creator Owner is not allowed to change the DACL nor to delete the account. In addition, a quota check limits the number of objects that can be created by the person who is using the quota.

For more information about Default DACLs, see "Access Control" in this book.


Secure Channel Issues

For each Windows 2000–based client or server that is a member of a domain, there is a discrete communication channel, known as the secure channel. This secure channel is used by the Net Logon service on the client and on the domain controller to communicate with each other. The Netdom tool is used to reset the secure channel. If the computer account's password and the local password are not synchronized, the Net Logon service logs one or both of the following errors messages:

The session setup from the computer DOMAINMEMBER failed to authenticate. The name of the account referenced in the security database is DOMAINMEMBER$.

The following error occurred: Access is denied.

NETLOGON Event ID 3210:

Failed to authenticate with \\DOMAINDC, a Windows   NT domain controller for domain DOMAIN.

The Net Logon service on the domain controller logs the following error message when the password is not synchronized:

NETLOGON Event 5722:

The session setup from the computer % 1 failed to authenticate. The name of the account referenced in the security database is %2. The following error occurred: % n % 3


Resetting Secure Channels and Computer Accounts

The following tools are available to reset the secure channel and the computer account:

·         Resource Kit tools:

o    Netdom.exe

o    Nltest.exe

·         Active Directory Users and Computers console


Using Netdom to Reset the Secure Channel

By using the Netdom.exe command-line tool, which is provided in the Windows 2000 Resource Kit, you can reset the secure channel between the domain's member workstation and the domain controller. For example, suppose you have a domain member named DOMAINMEMBER. You can reset the member's secure channel by running the following command:

netdom reset member /domain:domain

You can run this command on the member DOMAINMEMBER. To run this command on any other member or domain controller in the domain, you must provide an account that has administrator access to DOMAINMEMBER.

For example:

Netdom reset member /domain:domain /usero:member-admin /passwordo:member-pw


Adding a Workstation or Member Server to a Domain

To add a workstation or member server to a domain, do the following:

1.      Add the workstation Work1 to the Windows NT 4.0 domain Domain1.

2.      Netdom add /d:domain1 work1/ ud:domain1\admin /pd:password.

3.      Add the workstation Work1 to the Windows 2000 domain reskit.com in the organizational unit my-computer, as shown here:

Netdom add /work1 /d:reskit.com /OU:OU=my-computers,DC=reskit,DC=com

clip_image001[6] Note

The /OU parameter requires a complete distinguished name as specified by RFC 1779. If the /OU parameter is not specified, the computer account is created in the Computers container.


Joining a Workstation or Member Server to a Domain

To join a workstation or member server to a domain, you can use the Netdom tool. For example, to join a workstation called Work1 to the reskit.com domain in the my-computers organizational unit, carry out the following:

Netdom join /d:reskit.com /OU:OU=my-computers,DC=reskit,DC=com /reboot:120.

In addition to adding the computer account to the domain, the workstation is modified to contain the appropriate shared secret to complete the Join procedure. If the Join procedure can be completed, the /reboot switch causes the computer to be automatically shut down and restarted after giving the user two minutes to save work in progress.


Using Nltest to Reset the Computer Secure Channel

By using the Nltest.exe command-line tool, you can reset secure channels that computers have with domain controllers in their domains. Nltest.exe can be used to test the trust relationship between a computer that is running Windows 2000 and is a member of a domain and a domain controller on which its computer account resides, as shown in the following example:


Usage: nltest [/OPTIONS]

/SC_QUERY:<DomainName> - Query secure channel for <domain> on



/SC_RESET:<DomainName> - Renegotiates the secure channel in the specified domain for a local or remote workstation, server, or domain controller

An example to reset the secure channel:

nltest /sc_query:reskit /server:Server22

Flags: 30

Connection Status = 0 0x0 NERR_Success

Trusted DC Name \\Server1.reskit.com

Trusted DC Connection Status Status = 0 0x0 NERR_Success

The command completed successfully

nltest /sc_reset:reskit /server:Server2

Flags: 30

Connection Status = 0 0x0 NERR_Success


Trusted DC Name \\server.reskit.com

Trusted DC Connection Status Status = 0 0x0 NERR_Success

The command completed successfully


Using the Active Directory Users and Computers Console to Reset Computer Account Passwords

By using Windows 2000, you can also reset the computer account password in the Active Directory Users and Computers console. Right-click the computer object in the Computers folder or other appropriate container, and then click Reset Account . The Reset Account context menu resets the computer account password back to a starting password. This is used only if the computer has been taken offline and been completely reinstalled. Resetting the account password allows the (rebuilt) computer to rejoin the domain using the same name. If this command is carried out when the computer has not been reinstalled, the computer cannot authenticate in the domain.

clip_image001[7] Note

Resetting the password for domain controllers by using this method is not allowed.


Using Nltest to View Trusted Domains

Different data about the trust relationship is kept in several key attributes of each trustedDomain object. The following are the key attributes:

flatName . Contains the NetBIOS name of the domain for this trust relationship.

trustDirection . Contains the direction of the established trust relationship:

·         0=Disabled

·         1=Inbound (Trusting domain)

·         2=Outbound (Trusted domain)

·         3=Both (Trusted and trusting domains)

trustPartner . Contains a string that represents the DNS-style name of the domain if it is a Windows 2000 domain or the NetBIOS name of the domain if it is trust relationship between a Windows 2000 domain and a non-Windows 2000 domain.

trustType . Contains the type of trust relationship that has been established to the domain.

·         1=A trust relationship between a Windows 2000 domain and a Windows NT 4.0 or earlier domain.

·         2=A Windows 2000 trust relationship.

·         3=A trust relationship between a Windows 2000 domain and a non-Windows Kerberos realm.

By using the Nltest command-line tool, you can display the current list of trusted domains known by a specified server. Nltest.exe is available with Windows 2000 Server Support Tools. (To use Nltest, install the tools that are located in the Support\Tools folder on the Windows 2000 Server operating system CD. To install the tools, double-click the Setup icon in that folder. For more information about using Nltest, see Windows 2000 Support Tools Help.)

Use the /domains_trusts option to list the domains that have trust relationships with the current domain. For each domain listed in the results, the following data is displayed:

·         Trust Index (a number that identifies an entry in the enumerated list of trusts).

·         NetBIOS domain name of the trusted domain (for example, reskit).

·         DNS domain name of the trusted domain (for example, reskit.com).

·         Trust type (NT 4 for trust relationship with a Windows NT domain), NT 5 (for a trust relationship with a Windows 2000 domain), or MIT (for a trust relationship with a non-Windows Kerberos realm). For more information about types of trust relationships, see "Active Directory Logical Structure" in this book.

·         In addition, the following values are reported where applicable:

o    Forest Tree Root: Identifies the forest root domain.

o    Forest Trust Index: Indicates the domain that is the forest root.

o    Primary Domain: Identifies the domain in which the contacted server is located.

o    Direct Outbound: Identifies the domain as being directly trusted by the primary domain.

o    Direct Inbound: Identifies the domain as directly trusting the primary domain.

o    Attr: Returns the bits specifying the value in the trustAttributes attribute on the trustedDomain object. This value determines, for example, whether the trust relationship is transitive or nontransitive.

o    Native: Identifies a primary domain that is running in native mode. Where no value is displayed for primary domain, the primary domain is running in mixed mode.

For example, the following Nltest command is executed on a computer that is a member of the noam.reskit.com domain returns.

D:\>nltest /domain_trusts

List of domain trusts:

0: RESKIT reskit.com (NT 5) (Forest Tree Root) (Direct Outbound) (Direct Inbound) ( Attr: 0x400000 )

1: AVIONICS avionics.reskit.com (NT 5) (Forest: 0)

2: EUROPE europe.reskit.com (NT 5) (Forest: 0)

3: NOAM noam.reskit.com (NT 5) (Forest: 0) (Primary Domain) (Native)

The command completed successfully

This output indicates the following:

·         Reskit.com is the forest root domain.

·         All of the domains are in the same forest as reskit.com (identified by the index number 0).

·         All of the trust relationships are Windows 2000 trust relationships (indicated by "NT 5").

·         Noam.reskit.com is the domain of the server that is running Nltest.

·         Noam.reskit.com, which is a primary domain, is running in native mode.

To run a query on a specific server, type nltest /server: <servername> domain trusts . For example, the "domain that is trusted" list might be displayed if a query is run on a domain controller in the root domain of the forest. (This example shows root.com as the root domain.)

0: TESTDOMAIN testdomain.root.com (NT 5) (Forest: 3) (Direct Outbound)

1: CHILD child.root.com (NT 5) (Forest: 3) (Direct Outbound)

2: GRANDCHILD grandchild.child.root.com (NT 5) (Forest: 1)

3: ROOT root.com (NT 5) (Forest Tree Root) (Primary Domain)

4: NT4DOMAIN (NT 4) (Direct Outbound)

5: NEWROOT newroot.com (NT 5) (Forest Tree Root) (Direct Outbound) ( Attr:

0x800000 )

clip_image001[8] Note

Note that Nltest shows trusted domains with transitive trust relationships as Windows 2000 trust relationships without the Direct Outbound tag.

Another way to view domains and trust relationships is by using ADSI Edit.

To view trusted domains and trust relationship properties by using ADSI Edit

1.      In ADSI Edit, expand the domain directory partition node and navigate to the System container.

2.      In the console details pane, use the Class column to identify all objects with the typetrustedDomain .

3.      To view properties, right-click the trustedDomain object, and then click Properties .

4.      In the Select which properties to view box, click Both to view both optional and mandatory attributes.

5.      In the Select a property to view box, select a property. Its value is displayed in the Value(s)box.


Checking Trust Relationships Authenticated By the Kerberos v5 Protocol

Use the Netdom tool to verify the Kerberos v5 authentication protocol between a client and a target domain. The Netdom tool trust verification option with the /Kerberos switch allows you to obtain a session ticket from the Kerberos authentication service in the target domain. If successful, the conclusion is that Kerberos operations such as Key Distribution Center (KDC) referrals, are operating correctly between the workstation and the target domain. Upon failure, the list of referral tickets currently cached, are displayed. If you do not receive the session ticket, the cause of failure can be determined by tracing the list of referral tickets from the KDCs located on the path toward the target domain.

To verify the Kerberos authentication protocol issue the following command:

NETDOM TRUST <trusting_domain_name> /d: <name of the trusted domain>/Kerberos /UserO :<User account for making the connection with the trusted domain> /PasswordO: <Password of the user account specified by /UserO >/UserD: <User account used to make the connection with the domain specified by the /domain argument > /PasswordD: <trusted_domain_user_password>

clip_image001[9] Note

Both users must be specified because the command will attempt a Kerberos v5 authentication of those users.

The above command will verify the following:

·         The trust passwords are correct (for example, determine if the passwords match).

·         The users can be located in Active Directory.

·         The users can be authenticated through the issuance of Kerberos v5 tickets.

For more information on the Netdom tool, see Windows 2000 Support Tools Help. For more information on Kerberos v5 authentication, see " Authentication " in this book.


Fail Logons in Absence of Global Catalog Servers

For Windows 2000 in native mode a Global Catalog is required for the logon process. If the domain controller cannot contact a Global Catalog server, the user is not be able to log on. An exception is made only for the administrator account in the domain (RID 0x1F4). This account is allowed to log on even without a Global Catalog, so that in an emergency situation a Global Catalog can be configured.

Specifically, group expansion during token creation when the user is logging onto a workstation is as follows:

1.      Add the user's SID in the token.

2.      Add the global groups that the user is part of in the token.

3.      Add the universal groups to which the user's SID and the global groups belong in the token.

4.      Add the domain local groups to which the preceding accounts belong to the token. This step is performed at a domain controller for the domain to which the workstationbelongs. 
Domain local groups are not added to the token, if this domain is in mixed mode.

5.      Add the local and built-in local group memberships for the groups in the workstation of the set computed in steps 1 through 4. If the user is connecting to or logging on to a domain controller, this step addresses only the built-in local groups; if the domain local groups were evaluated in step 4.





No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/2926

Leave a comment


Author Bio          ★★★★★

Author Name:         administrator
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011