Domain computer Boot up Process and site info

When first joining the domain, the client makes general DNS and LDAP queries and gets a list of all the domain controllers In the domain, and it goes down the list, trying LDAP binds, and the first successful DC so it binds to-that is the F Irst DC it authenticates with.

After the client has joined the domain, Active Directory would tell the client which site it belongs to. Active Directory knows this because the administrator have put the IP subnet of the client in AD Sites & Services and a Ssociated it to a Site.

Active Directory tells the client what it AD site is, and the client stores this in it own registry in theHklm\system\currentcontrolset\services\netlogon\parameters\dynamicsitenameRegistry value. That is, the next time the client boots up, it knows what site-specific DNS query to make so that it gets only the DCs th At is in that site.

Of course the full behavior are documented in KB247811 and if you want to see it for yourself, you could run Wireshark or NetMon and do a packet trace, and then joins a domain while the trace is running. You'll see the exact sequence of the DNS queries and LDAP binds. Subsequent DNS queries and LDAP binds is made to the site-specific sub-zones because the client have been told by AD Site it belongs to.

The Netlogon service would periodically refresh its AD site info, so if you move to a different network, your client would g Et its new site automatically. This can is adjusted in the Hklm\system\currentcontrolset\services\netlogon\parameters\sitenametimeout registry value.

------------------------------------------

The detail:

This sequence describes how the Locator finds a domain controller:
1. On the client (the computer-locating the domain controller), the Locator is initiated as a remote procedure CA LL (RPC) to the local Netlogon service. The Locator DsGetDcName application Programming Interface (API) call was implemented by the Netlogon service.

2. The client collects the information that's needed to select a domain controller and passes the information to the NETL Ogon service by using the DsGetDcName call.

3. The Netlogon service on the client uses the collected information-to-look up a domain controller for the specified d Omain in one of the ways:
for a DNS name , Netlogon queries DNS by using the ip/dns-compatible locator--that are , 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's logging on to A windows-based domain queries DNS for SRV records in the general form:
_service._protocol. DnsDomainName
Active Directory servers offer the lightweight Directory Access Protocol (LDAP) service over the TCP protocol. Therefore, clients find a LDAP server by querying DNS for a record of the form:
_ldap._tcp. DnsDomainName

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

In Windows NT 4.0 and earlier, "discovery" are a process for locating a domain controllers for authentication in either the Primary domain or a trusted domain.

4. 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 are implemented as an LDAP User datagram Protocol (UDP) search. (UDP is the connectionless datagram transport protocol, that's part of the TCP/IP protocol suite. TCP is a connection-oriented transport protocol.)

5. Each available domain controller responds to the datagram to indicate, it is currently operational and returns the Information to DsGetDcName.
Note that 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.

6. Each available domain controller responds to the datagram to indicate, it is currently operational and returns the Information to DsGetDcName.

7. The Netlogon service caches the domain controller information so, 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 is 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:
_ldap._tcp.dc._msdcs.domainname

After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Director Y. As part of this negotiation, the domain controller identifies which site the client is in based on the IP subnet of tha T client. If the client is an communicating with a domain controller, which is not in the closest (most optimal) site, the domain control Ler returns the name of the client ' s site. If the client has already tried to find domain controllers in this site (for example, when the client sends a DNS Lookup q Uery to DNS to find domain controllers in the client's subnet), the client uses the domain controller that's 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 at the optimal site, the client flushes the cache after fifteen minutes and discards the C Ache entry. It then attempts to find a optimal domain controller in the same site as the client.

After the client had established a communications path to the domain controller, it can establish the logon and Authentica tion credentials and, if necessary for windows-based computers, set up a secure channel. The client then was 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 are authenticated by a domain controller, the client Account was verified and passed through Security Accounts Manager to the Directory service agent, then to the database lay Er, and finally to the database in the Extensible Storage Engine (ESE).

Troubleshooting the Domain Locator Process

To troubleshoot the domain locator process:
1. Check the Event Viewer on both the client and the server. The event logs may contain error messages indicating this there is a problem. To view the 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.

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

3. Use the Ping utility to verify network connectivity and name resolution. Ping both the IP address and the server name. Also want to ping the domain name.

4. Use the Netdiag tool to determine whether networking components is 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 the other network configuration details.

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

6. Use the Nltest/dsgetdc:domainname command to verify, a domain controller can be located for a specific domain.

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

For example, to verify record registration, use the following commands:
nslookup-qt=srv _ldap._tcp. westdistrict . _sites.dc._msdcs.sulancn.com

Nslookup-qt=srv _ldap._tcp.dc._msdcs.sulancn.com

8. 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.

9. To detect domain controller problems, run the DCdiag utility from a command prompt. The utility runs a number of tests to verify, 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 this a particular domain controller has problems, it could 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 has not isolated the problem, use Network Monitor to monitor Network traffic between the client and the Domain controller.

On Windows 7 client:

nslookup-qt=srv _ldap._tcp. westdistrict . _sites.dc._msdcs.sulancn.com
Nslookup-qt=srv _ldap._tcp.dc._msdcs.sulancn.com
Nltest/dsgetdc:sulancn.com
Nltest/sc_query:sulancn.com
Nltest/dclist:sulancn.com
Nltest/dsgetsite
Nltest/dsaddresstosite:sc-test1

Pls refer to:

https://support.microsoft.com/en-us/kb/247811

Http://serverfault.com/questions/486518/how-does-a-client-system-in-an-active-directory-network-find-in-which-site-it-re

This article is from the "Sulan Network" blog, so be sure to keep this source http://zhangfang526.blog.51cto.com/8588740/1712205

Domain computer Boot up Process and site info