It is common knowledge that in AD environment client (like workstation) will always (at least it should) try to connect to most optimal domain controller. Optimal from network and AD infrastructure configuration standpoint. This process is based on DNS queries and information stored in AD configuration and in perfect case should lead to situation when client has contacted most optimal DC at given moment.

So we have all subnets defines, connected with appropriate sites and DCs placed in these sites or covered in other way. And suddenly some clients from some small location are starting to use some random DCs instead one we designated for them in our bright and shiny configuration.  In such case sys admin is entering his most favorite mode … troubleshooting

 

(cc) trriseesthings

AD configuration has been extensively reviewed and checked, network checked … event logs are not giving us a clue … what next (besides calling cavalry of some sort :) )?

In such case we have at least one additional troubleshooting mechanism which might be extremely useful in this process, which is enabling debug logging for DC locator process. In each Windows version netlogon service comes with ability to log debug information. What has to be done is enabling this mechanisms through registry change and settings some flags … these flags are described in  KB 109626 Enabling debug logging for the Net Logon service.

When this will be done netlogon service will start to log diagnostic data in %widir%\debug\netlogon.log. These information might be very useful in troubleshooting process or at least should give us idea what is going on during this process. Sample netlogon.log part (slightly modified for better reading) from my lab environment is presented below .

[SITE] Setting site name to '(null)'
[SESSION] \Device\NetBT_Tcpip_{33941FFA-DFED-4744-BF9A-972228BC6FF0}: Transport Added (192.168.1.10)
[SESSION] Winsock Addrs: 192.168.1.10 (1) List used to be empty.
[SESSION] V6 Winsock Addrs: (0)
[CRITICAL] Address list changed since last boot. (Forget DynamicSiteName.)
[SITE] Setting site name to '(null)'
[DNS] Set DnsForestName to: w2k.pl
[DOMAIN] W2K: Adding new domain
[DOMAIN] Setting our computer name to wss wss
[DOMAIN] Setting Netbios domain name to W2K
[DOMAIN] Setting DNS domain name to w2k.pl.
[DOMAIN] Setting Domain GUID to ce28b6f7-a26a-4e0f-9f39-0e63e525493e
[MISC] Eventlog: 5516 (1) "wss" "W2K"
[INIT] Replacing trusted domain list with one for newly joined W2K domain.
[SITE] Setting site name to '(null)'
[LOGON] NlSetForestTrustList: New trusted domain list:
[LOGON]     0: W2K w2k.pl (NT 5) (Forest Tree Root) (Primary Domain) (Native)
[LOGON]        Dom Guid: ce28b6f7-a26a-4e0f-9f39-0e63e525493e
[LOGON]        Dom Sid: S-1-5-21-1855823386-3643518527-1754427229
[INIT] Starting RPC server.
[SESSION] W2K: NlSessionSetup: Try Session setup
[SESSION] W2K: NlDiscoverDc: Start Synchronous Discovery
[MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c00ffff1
[INIT] Join DC: \\resfs.w2k.pl, Flags: 0xe00013fd
[MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c00ffff1
[MAILSLOT] NetpDcPingListIp: w2k.pl.: Sent UDP ping to 192.168.1.1
[MISC] NlPingDcNameWithContext: Sent 1/1 ldap pings to resfs.w2k.pl
[MISC] NlPingDcNameWithContext: resfs.w2k.pl responded over IP.
[MISC] W2K: NlPingDcName: W2K: w2k.pl.: Caching pinged DC info for resfs.w2k.pl
[INIT] Join DC cached successfully
[SITE] Setting site name to 'Default-First-Site-Name'
[MISC] NetpDcGetName: w2k.pl. using cached information
[PERF] NlAllocateClientSession: New Perf Instance (001E6688): "\\resfs.w2k.pl"
    ClientSession: 00237D58
[SESSION] W2K: NlDiscoverDc: Found DC \\resfs.w2k.pl
[SESSION] W2K: NlSetStatusClientSession: Set connection status to 0
[DOMAIN] Setting LSA NetbiosDomain: W2K DnsDomain: w2k.pl. DnsTree: w2k.pl. DomainGuid:ce28b6f7-a26a-4e0f-9f39-0e63e525493e
[LOGON] NlSetForestTrustList: New trusted domain list:
[LOGON]     0: W2K w2k.pl (NT 5) (Forest Tree Root) (Primary Domain) (Native)
[LOGON]        Dom Guid: ce28b6f7-a26a-4e0f-9f39-0e63e525493e
[LOGON]        Dom Sid: S-1-5-21-1855823386-3643518527-1754427229
[SESSION] W2K: NlSetStatusClientSession: Set connection status to 0
[SESSION] W2K: NlSessionSetup: Session setup Succeeded
[INIT] Started successfully

Does it look useful??? I think so … happy troubleshooting and don’t forget that Network Monitor or WireShark will tell  You the truth about what’s going on on a wire. And this is ultimate troubleshooting tool.