How Domain Controllers Are Located in Windows

This article describes the mechanism used by Windows to locate a domain controller in a Windows-based domain.

This article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center is a starting point for planning your migration strategy from Windows 2000. For more information, see the Microsoft Support Lifecycle Policy.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: В 247811

Summary

This article details the process of locating a domain by its DNS-style name and its flat-style (NetBIOS) name. The flat-style name is used for backward compatibility. In all other cases, DNS-style names should be used as a matter of policy. This article also addresses troubleshooting the domain controller location process.

More information

This sequence describes how the Locator finds a domain controller:

On the client (the computer that is locating the domain controller), the Locator is initiated as a remote procedure call (RPC) to the local Netlogon service. The Locator DsGetDcName application programming interface (API) call is implemented by the Netlogon service.

The client collects the information that is needed to select a domain controller and passes the information to the Netlogon service by using the DsGetDcName call.

The Netlogon service on the client uses the collected information to look up a domain controller for the specified domain in one of two ways:

For a DNS name, Netlogon queries DNS by using the IP/DNS-compatible Locator—that is, DsGetDcName calls the DnsQuery call to read the Service Resource (SRV) records and «A» records from DNS after it appends the domain name to the appropriate string that specifies the SRV records.

A workstation that is logging on to a Windows-based domain queries DNS for SRV records in the general form:

Active Directory servers offer the Lightweight Directory Access Protocol (LDAP) service over the TCP protocol. Therefore, clients find an LDAP server by querying DNS for a record of the form:

For a NetBIOS name, Netlogon performs domain controller discovery by using the Microsoft Windows NT version 4.0-compatible Locator (that is, by using the transport-specific mechanism (for example, WINS).

In Windows NT 4.0 and earlier, «discovery» is a process for locating a domain controller for authentication in either the primary domain or a trusted domain.

The Netlogon service sends a datagram to the computers that registered the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP User Datagram Protocol (UDP) search. (UDP is the connectionless datagram transport protocol that is part of the TCP/IP protocol suite. TCP is a connection-oriented transport protocol.)

Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.

UDP allows a program on one computer to send a datagram to a program on another computer. UDP includes a protocol port number, which allows the sender to distinguish among multiple destinations (programs) on the remote computer.

• Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.
• The Netlogon service caches the domain controller information so that subsequent requests need not repeat the discovery process. Caching this information encourages consistent use of the same domain controller and a consistent view of Active Directory.

When a client logs on or joins the network, it must be able to locate a domain controller. The client sends a DNS Lookup query to DNS to find domain controllers, preferably in the client’s own subnet. Therefore, clients find a domain controller by querying DNS for a record of the form:

After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client. If the client is communicating with a domain controller that is not in the closest (most optimal) site, the domain controller returns the name of the client’s site. If the client has already tried to find domain controllers in that site (for example, when the client sends a DNS Lookup query to DNS to find domain controllers in the client’s subnet), the client uses the domain controller that is not optimal. Otherwise, the client performs a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.

After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.

After the client has established a communications path to the domain controller, it can establish the logon and authentication credentials and, if necessary for Windows-based computers, set up a secure channel. The client then is ready to perform normal queries and search for information against the directory.

The client establishes an LDAP connection to a domain controller to log on. The logon process uses Security Accounts Manager. Because the communications path uses the LDAP interface and the client is authenticated by a domain controller, the client account is verified and passed through Security Accounts Manager to the directory service agent, then to the database layer, and finally to the database in the Extensible Storage engine (ESE).

Troubleshooting the Domain Locator Process

To troubleshoot the domain locator process:

Check Event Viewer on both the client and the server. The event logs may contain error messages indicating that there is a problem. To view Event Viewer, click Start, point to Programs, point to Administrative Tools, and then click Event Viewer. Check the System log on both the client and the server. Also, check the Directory Service logs on the server and DNS logs on the DNS server.

Check the IP configuration by using the ipconfig /all command at a command prompt.

Use the Ping utility to verify network connectivity and name resolution. Ping both the IP address and the server name. You may also want to ping the domain name.

Use the Netdiag tool to determine whether networking components are working correctly. To send detailed output to a text file, use the following command:

netdiag /v >test.txt
Review the log file, looking for problems, and investigate any implicated components. This file also contains other network configuration details.

To fix minor problems, use the Netdiag tool with the following syntax: netdiag /fix .

Use the nltest /dsgetdc:domainname command to verify that a domain controller can be located for a specific domain.

Use the NSLookup tool to verify that DNS entries are correctly registered in DNS. Verify that the server host records and GUID SRV records can be resolved.

For example, to verify record registration, use the following commands:
nslookup servername. childofrootdomain. rootdomain.com
nslookup guid._msdcs. rootdomain.com

If either of these commands does not succeed, use one of the following methods to reregister records with DNS:

• To force host record registration, type ipconfig /registerdns.
• To force domain controller service registration, stop and start the Netlogon service.

To detect domain controller problems, run the DCdiag utility from a command prompt. The utility runs a number of tests to verify that a domain controller is running correctly. Use this command to send the results to a text file: dcdiag /v >dcdiag.txt

Use the Ldp.exe tool to connect and bind to the domain controller to verify appropriate LDAP connectivity.

If you suspect that a particular domain controller has problems, it may be helpful to turn on Netlogon debug logging. Use the NLTest utility by typing this command: nltest /dbflag:0x2000ffff . The information is then logged in the Debug folder in the Netlogon.log file.

If you still have not isolated the problem, use Network Monitor to monitor network traffic between the client and the domain controller.

References

For more information, see the Windows Resource Kit, Chapter 10, «Active Directory Diagnostic, Troubleshooting, and Recovery.»

Install a Replica Windows Server 2012 Domain Controller in an Existing Domain (Level 200)

Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

This topic covers the steps necessary to upgrade an existing forest or domain to Windows Server 2012, using either Server Manager or Windows PowerShell. It covers how to add domain controllers that run Windows Server 2012 to an existing domain.

Upgrade and Replica Workflow

The following diagram illustrates the Active Directory Domain Services configuration process when you previously installed the AD DS role and you have started the Active Directory Domain Services Configuration Wizard using Server Manager to create a new domain controller in an existing domain.

Upgrade and Replica Windows PowerShell

ADDSDeployment Cmdlet	Arguments (Bold arguments are required. Italicized arguments can be specified by using Windows PowerShell or the AD DS Configuration Wizard.)
Install-AddsDomainController	-SkipPreChecks

-DomainName

-Credential

The -credential argument is only required if you are not already logged on as a member of the Enterprise Admins and Schema Admins groups (if you are upgrading the forest) or the Domain Admins group (if you are adding a new DC to an existing domain).

Deployment

Deployment Configuration

Server Manager begins every domain controller promotion with the Deployment Configuration page. The remaining options and required fields change on this page and subsequent pages, depending on which deployment operation you select.

To upgrade an existing forest or add a writable domain controller to an existing domain, click Add a domain controller to an existing domain and click Select to Specify the domain information for this domain. Server Manager prompts you for valid credentials if needed.

Upgrading the forest requires credentials that include group memberships in both the Enterprise Admins and Schema Admins groups in Windows Server 2012. The Active Directory Domain Services Configuration Wizard prompts you later if your current credentials do not have adequate permissions or group memberships.

The automatic Adprep process is the only operational difference between adding a domain controller to an existing Windows Server 2012 domain and a domain where domain controllers run an earlier version of Windows Server.

The Deployment Configuration ADDSDeployment cmdlet and arguments are:

Certain tests perform at each page, some of which repeat later as discrete prerequisite checks. For instance, if the selected domain does not meet the minimal functional levels, you do not have to go all the way through promotion to the prerequisite check to find out:

Domain Controller Options

The Domain Controller Options page specifies the domain controller capabilities for the new domain controller. The configurable domain controller capabilities are DNS server, Global Catalog, and Read-only domain controller. Microsoft recommends that all domain controllers provide DNS and GC services for high availability in distributed environments. GC is always selected by default and DNS server is selected by default if the current domain hosts DNS already on its DCs based on Start of Authority query. The Domain Controller Options page also enables you to choose the appropriate Active Directory logical site name from the forest configuration. By default, it selects the site with the most correct subnet. If there is only one site, it selects automatically.

If the server does not belong to an Active Directory subnet and there is more than one Active Directory site, nothing is selected and the Next button is unavailable until you choose a site from the list.

The specified Directory Services Restore Mode Password must adhere to the password policy applied to the server. Always choose a strong, complex password or preferably, a passphrase.

The Domain Controller Options ADDSDeployment arguments are:

The site name must already exist when provided as an argument to -sitename. The install-AddsDomainController cmdlet does not create sites. You can use cmdlet new-adreplicationsite to create new sites.

The SafeModeAdministratorPassword argument’s operation is special:

If not specified as an argument, the cmdlet prompts you to enter and confirm a masked password. This is the preferred usage when running the cmdlet interactively.

For example, to create an additional domain controller in treyresearch.net domain and be prompted to enter and confirm a masked password:

If specified with a value, the value must be a secure string. This is not the preferred usage when running the cmdlet interactively.

For example, you can manually prompt for a password by using the Read-Host cmdlet to prompt the user for a secure string:

As the previous option does not confirm the password, use extreme caution: the password is not visible.

You can also provide a secure string as a converted clear-text variable, although this is highly discouraged.

Finally, you could store the obfuscated password in a file, and then reuse it later, without the clear text password ever appearing. For example:

Providing or storing a clear or obfuscated text password is not recommended. Anyone running this command in a script or looking over your shoulder knows the DSRM password of that domain controller. Anyone with access to the file could reverse that obfuscated password. With that knowledge, they can logon to a DC started in DSRM and eventually impersonate the domain controller itself, elevating their privileges to the highest level in an Active Directory forest. An additional set of steps using System.Security.Cryptography to encrypt the text file data is advisable but out of scope. The best practice is to totally avoid password storage.

The ADDSDeployment cmdlet offers an additional option to skip automatic configuration of DNS client settings, forwarders, and root hints. You cannot skip this configuration option when using Server Manager. This argument matters only if you installed the DNS Server role prior to configuring the domain controller:

The Domain Controller Options page warns that you cannot create read only domain controllers if your existing domain controllers run Windows Server 2003. This is expected, and you can dismiss the warning.

DNS Options and DNS Delegation Credentials

The DNS Options page enables you to configure DNS delegation if you selected the DNS server option on the Domain Controller Options page and if pointing to a zone where DNS delegations are allowed. You may need to provide alternate credentials of a user that is a member of the DNS Admins group.

The DNS Options ADDSDeployment cmdlet arguments are:

For more information about whether you need to create a DNS delegation, see Understanding Zone Delegation.

Additional Options

The Additional Options page provides the configuration option to name a domain controller as the replication source, or you can use any domain controller as the replication source.

You can also choose to install the domain controller using backed up media using the Install from media (IFM) option. The Install from media checkbox provides a browse option once selected and you must click Verify to ensure the provided path is valid media. Media used by the IFM option is created with Windows Server Backup or Ntdsutil.exe from another existing Windows Server 2012 computer only; you cannot use a Windows Server 2008 R2 or previous operating system to create media for a Windows Server 2012 domain controller. For more information about changes in IFM, see Simplified Administration Appendix. If using media protected with a SYSKEY, Server Manager prompts for the image’s password during verification.

The Additional Options ADDSDeployment cmdlet arguments are:

Paths

The Paths page enables you to override the default folder locations of the AD DS database, the database transaction logs, and the SYSVOL share. The default locations are always in subdirectories of %systemroot%.

The Active Directory Paths ADDSDeployment cmdlet arguments are:

Preparation Options

The Preparation Options page alerts you that the AD DS configuration includes extending the Schema (forestprep) and updating the domain (domainprep). You only see this page when the forest and domain have not been prepared by previous Windows Server 2012 domain controller installation or from manually running Adprep.exe. For example, the Active Directory Domain Services Configuration Wizard suppresses this page if you add a new domain controller to an existing Windows Server 2012 forest root domain.

Extending the Schema and updating the domain do not occur when you click Next. These events occur only during the installation phase. This page simply brings awareness about the events that will occur later in the installation.

This page also validates that the current user credentials are members of the Schema Admin and Enterprise Admins groups, as you need membership in these groups to extend the schema or prepare a domain. Click Change to provide the adequate user credentials if the page informs you that the current credentials do not provide sufficient permissions.

The Additional Options ADDSDeployment cmdlet argument is:

As with previous versions of Windows Server, automated domain preparation for domain controllers that run Windows Server 2012 does not run GPPREP. Run adprep.exe /gpprep manually for all domains that were not previously prepared for Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2. You should run GPPrep only once in the history of a domain, not with every upgrade. Adprep.exe does not run /gpprep automatically because its operation can cause all files and folders in the SYSVOL folder to re-replicate on all domain controllers.

Automatic RODCPrep runs when you promote the first un-staged RODC in a domain. It does not occur when you promote the first writeable Windows Server 2012 domain controller. You can also still manually adprep.exe /rodcprep if you plan to deploy read-only domain controllers.

Review Options and View Script

The Review Options page enables you to validate your settings and ensure that they meet your requirements before you start the installation. This is not the last opportunity to stop the installation using Server Manager. This page simply enables you to review and confirm your settings before continuing the configuration.

The Review Options page in Server Manager also offers an optional View Script button to create a Unicode text file that contains the current ADDSDeployment configuration as a single Windows PowerShell script. This enables you to use the Server Manager graphical interface as a Windows PowerShell deployment studio. Use the Active Directory Domain Services Configuration Wizard to configure options, export the configuration, and then cancel the wizard. This process creates a valid and syntactically correct sample for further modification or direct use.

Server Manager generally fills in all arguments with values when promoting and does not rely on defaults (as they may change between future versions of Windows or service packs). The one exception to this is the -safemodeadministratorpassword argument. To force a confirmation prompt omit the value when running cmdlet interactively

Use the optional Whatif argument with the Install-ADDSDomainController cmdlet to review configuration information. This enables you to see the explicit and implicit values of the arguments for a cmdlet.

Prerequisites Check

The Prerequisites Check is a new feature in AD DS domain configuration. This new phase validates that the domain and forest are capable of supporting a new Windows Server 2012 domain controller.

When installing a new domain controller, the Server Manager Active Directory Domain Services Configuration Wizard invokes a series of serialized modular tests. These tests alert you with suggested repair options. You can run the tests as many times as required. The domain controller process cannot continue until all prerequisite tests pass.

The Prerequisites Check also surfaces relevant information such as security changes that affect older operating systems.

For more information about the specific prerequisite checks, see Prerequisite Checking.

You cannot bypass the Prerequisite Check when using Server Manager, but you can skip the process when using the AD DS Deployment cmdlet using the following argument:

Microsoft discourages skipping the prerequisite check as it can lead to a partial domain controller promotion or damaged AD DS forest.

Click Install to begin the domain controller promotion process. This is last opportunity to cancel the installation. You cannot cancel the promotion process once it begins. The computer will reboot automatically at the end of promotion, regardless of the promotion results.The Prerequisites Check page displays any issues it encountered during the process and guidance for resolving the issue.

Installation

When the Installation page displays, the domain controller configuration begins and cannot be halted or canceled. Detailed operations display on this page and are written to logs:

%systemroot%\debug\netsetup.log (if server is in a workgroup)

To install a new Active Directory forest using the ADDSDeployment module, use the following cmdlet:

See Upgrade and Replica Windows PowerShell for required and optional arguments.

The Install-AddsDomainController cmdlet only has two phases (prerequisite checking and installation). The two figures below show the installation phase with the minimum required arguments of -domainname and -credential. Note how the Adprep operation happens automatically as part of adding the first Windows Server 2012 domain controller to an existing Windows Server 2003 forest:

Note how, just like Server Manager, Install-ADDSDomainController reminds you that promotion will reboot the server automatically. To accept the reboot prompt automatically, use the -force or -confirm:$false arguments with any ADDSDeployment Windows PowerShell cmdlet. To prevent the server from automatically rebooting at the end of promotion, use the -norebootoncompletion argument.

Overriding the reboot is discouraged. The domain controller must reboot to function correctly.

To configure a domain controller remotely using Windows PowerShell, wrap the install-addsdomaincontroller cmdlet inside of the invoke-command cmdlet. This requires using the curly braces.

For more information on how the installation and Adprep process works, see the Troubleshooting Domain Controller Deployment.

Results

The Results page shows the success or failure of the promotion and any important administrative information. If successful, the domain controller will automatically reboot after 10 seconds.