A. A client computer ascertains which site it currently resides in when the computer starts. As part of the initial startup traffic, clients attempt to locate a domain controller (DC) for their domain. (This search occurs early in the startup process; if you use DHCP, it occurs just after the address is leased or renewed.) If the client currently has no DynamicSiteName registry value--which indicates the site in which the client was located when it was last started--the client performs a generic DNS query for any Lightweight Directory Access Protocol (LDAP) service by using the DNS query format
_ldap._tcp.dc._msdcs.
If the client previously resided in a site and therefore has a DynamicSiteName registry value, the DNS query tries to find a DC in that site by using the following query format:
_ldap._tcp.._sites.dc._msdcs.
When the client finds a DC, the client issues a UDP LDAP request asking for Netlogon-service information from the DC; the DC returns a SearchResponse (4) message, which lists the DC's local site and the client's site name, according to the client's IP address, if the queried DC isn't from the client's current local site. If the DNS query can't match a client's IP address to a defined site, it doesn't return a recommended site, only the DC's current site. The following sample packets show three types of DNS query responses. The first example shows the results of a client querying a DC that's within the client's IP-calculated site:
00000020 30 84 00 00 00 8B 0..... 00000030 02 01 02 64 84 00 00 00 82 04 00 30 84 00 00 00 ...d.......0.... 00000040 7A 30 84 00 00 00 74 04 08 6E 65 74 6C 6F 67 6F z0....t..netlogo 00000050 6E 31 84 00 00 00 64 04 62 17 00 00 00 FD 01 00 n1....d.b....... 00000060 00 68 CC 80 31 3C AF B7 4F B7 43 EF 17 8D F4 4F .h..1The next example shows the results of a client querying a DC that isn't local to the client's site:
00000020 30 84 00 00 00 90 0..... 00000030 02 01 02 64 84 00 00 00 87 04 00 30 84 00 00 00 ...d.......0.... 00000040 7F 30 84 00 00 00 79 04 08 6E 65 74 6C 6F 67 6F 0....y..netlogo 00000050 6E 31 84 00 00 00 69 04 67 17 00 00 00 7D 01 00 n1....i.g....\}.. 00000060 00 68 CC 80 31 3C AF B7 4F B7 43 EF 17 8D F4 4F .h..1..o.c....o>Notice that the query initially returns a site named Dallas, then returns a second site, Allen. In this case, Dallas is the site of the DC (savdaldc01), but the response is telling the client that it should instead find a DC in the Allen site (which it would find via a DNS query specifying the Allen site).
The final sample packet shows the response when the DNS query can't match the client's IP address with sites defined in the Active Directory (AD):
00000020 30 84 00 00 00 8A 0..... 00000030 02 01 02 64 84 00 00 00 81 04 00 30 84 00 00 00 ...d.......0.... 00000040 79 30 84 00 00 00 73 04 08 6E 65 74 6C 6F 67 6F y0....s..netlogo 00000050 6E 31 84 00 00 00 63 04 61 17 00 00 00 7D 01 00 n1....c.a....\}.. 00000060 00 68 CC 80 31 3C AF B7 4F B7 43 EF 17 8D F4 4F .h..1..o.c....o>Notice in these examples that if the client's IP address matches the queried DC's site, a "P" (preferred) character appears after the site name, as line 19 in the first example shows; if there's no match, the "P" doesn't appear and because the preferred site name is blank, the response means the DNS query found no matching site. Thus the client doesn't reside within the boundary of any known site and will therefore randomly use any existing DC.
You can also determine a client's site either by running the command
nltest /dsgetsiteor by using the following code in a script:Set oSysInfo = CreateObject("ADSystemInfo") MsgBox oSysInfo.SiteNameTo reset the client and discover information about the client's site, run the following command:
nltest /sc_reset:domain-name\local-dcIt's important that client machines don't have IP addresses outside of defined sites. Certain services, such as the Microsoft Exchange System Attendant, won't start if the site's membership can't be discovered.
..o.c....o>