How does a client system in an Active Directory network find in which site it resides?

The answer is that the first time a client ever authenticates to Active Directory, it doesn't know what site it is in.

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 that it binds to - that is the first DC it authenticates with.

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

Active Directory tells the client what its AD site is, and the client stores that in its own registry in the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName registry value. That way, the next time the client boots up, it knows what site-specific DNS query to make so that it gets only the DCs that are in that site.

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

The Netlogon service will periodically refresh its AD site info, so if you move to a different network, your client will get its new site automatically. This can be adjusted in the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteNameTimeout registry value. (Link)

There actually several inter-related functions/API's. Even though they are long, it's actually some of the more interesting Active Directory reading.

Regardless of the explanation below, there are two things that you need to be aware of:

• If a DC in the local site does not respond for any reason, it is expected that the client will contact any domain controller in the domain. This is normal, and it's always been the default behavior. Sometimes it is not apparent why it is occurring.

• That can be suboptimal. Consider the following scenario: Three sites: New York City ( hub/datacener - fast), Los Angeles (spoke to NYC - fast), and Kazakhstan (spoke to NYC - definitely not fast). If your client in the LA site cannot contact it's local DC for whatever reason, it's not inconceivable that it will authenticate with Kazakhstan.

There are a couple of solutions. You can do either or both.

• Microsoft created the Group Policy/registry setting aptly named TryNextClosestSite. That means the LA client should try NYC before roaming the planet looking for DC's. Brilliant! It took eight years, but we finally got that with Vista/2008. Remember, not enabled by default, you need to create a GPO to enable this.

• For spoke sites where you really don't want that DC to serve clients in other sites, you can create a Group Policy/registry setting that specifies which DNS records should not be registered. This is referred to as DNS Mnemonics.

Finding a Domain Controller in the Closest Site (DsGetSiteName API)
http://technet.microsoft.com/en-us/library/cc978016.aspx

Mapping IP Addresses to Site Names

"During Net Logon startup, the Net Logon service on each domain controller enumerates the site objects in the Configuration container. Net Logon on each domain controller is also notified of any changes made to the site objects. Net Logon uses the site information to build an in-memory structure that is used to map IP addresses to site names.

"When a client that is searching for a domain controller receives the list of domain controller IP addresses from DNS, the client begins querying the domain controllers in turn to find out which domain controller is available and appropriate. Active Directory intercepts the query, which contains the IP address of the client, and passes it to Net Logon on the domain controller. Net Logon looks up the client IP address in its subnet-to-site mapping table by finding the subnet object that most closely matches the client IP address and then returns the following information:

• The name of the site in which the client is located, or the site that most closely matches the client IP address.

• The name of the site in which the current domain controller is located.

• A bit that indicates whether the found domain controller is located (bit is set) or not located (bit is not set) in the site closest to the client.

"The domain controller returns the information to the client. The response also contains various other pieces of information that describe the domain controller. The client inspects the information to determine whether to try to find a better domain controller. The decision is made as follows:

"If the returned domain controller is in the closest site (the returned bit is set), the client uses this domain controller.

"If the client has already tried to find a domain controller in the site in which the domain controller claims the client is located, the client uses this domain controller.

"If the domain controller is not in the closest site, the client updates its site information and sends a new DNS query to find a new domain controller in the site. If the second query is successful, the new domain controller is used. If the second query fails, the original domain controller is used.

"If the domain that is being queried by a computer is the same as the domain to which the computer is joined, the site in which the computer resides (as reported by a domain controller) is stored in the computer registry. The client stores this site name in the DynamicSiteName registry entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters. Therefore, the DsGetSiteName API returns the site in which the computer is located."

DsGetDcName function
http://msdn.microsoft.com/en-us/library/ms675983%28VS.85%29.aspx

Types of Locators
http://technet.microsoft.com/en-us/library/cc978019.aspx

Directory Service Functions
http://technet.microsoft.com/en-us/subscriptions/ms675900%28v=vs.85%29.aspx

How DNS Support for Active Directory Works
http://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx

How to optimize the location of a domain controller that resides outside of a client's site
http://support.microsoft.com/kb/306602