Just a quick blog post about something I saw recently. I was at a customer site performing an ADRAP and I ran into one of the customer’s domains where FRS was not converging. Among the troubleshooting steps I tried to verify that DNS had records for the DCs which it did and I verified using nslookup from the ADRAP machine I was using for gathering data from the DCs.

To cut a long story short the customer had a host file on the DCs of that domain in the following format.

10.1.1.1 DC1 DC1.Domain.Com

10.2.3.1 DC2 DC1.Domain.Com

As both IP addresses were bound to the same FQDN, FRS on each DC was having issues pulling updates from its partner. However AD replication was working fine. The reason for this is the DCs were using the <GUID>._msdcs.forestFQDN and therefore DNS was resolving the record.

Note to self, when troubleshooting name resolution always do the test from the host machine directly.

HTH

M

I’ve been doing some research to prepare for my upcoming first delivery of AD Troubleshooting workshop. The agenda of content includes DCLocator and Netlogon content. Hence this post.

For the real detail on dsgetdcname and details on the nltest /dsgetdc flags, please see http://msdn.microsoft.com/en-us/library/ms675983(VS.85).aspx.

I made a lab environment which consisted of a single domain forest and 1 x Vista and 1 x XP client. Here are my observations.

If the Vista client’s IP address is from a subnet known by AD, a Windows Server 2008 DC will provide the closest site info details as well. It does not do this for XP. Presumably other down-level OS editions are also not given this detail but I didn’t check.

Here is the LDAP filter one of the UDP based CLDAP ping performed by the Vista client.

Filter: (&(DnsDomain=adatum.com)(Host=ADTMCLIENT1)(DomainGuid={AEF3F962-37E0-D147-8611-D8CA1AAED85E})(NtVer=16:00:00:00))

And the response back from the Windows Server 2008 DC is as follows.

Frame: Number = 86, Captured Frame Length = 200, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-03-FF-0D-FA-00],SourceAddress:[00-03-FF-A5-9B-45]

+ Ipv4: Src = 10.1.1.2, Dest = 10.1.1.6, Next Protocol = UDP, Packet ID = 3904, Total IP Length = 186

+ Udp: SrcPort = LDAP(389), DstPort = 58266, Length = 166

+ Cldap: (CLDAP)Search Result Entry, MessageID: 1, Status: Success

- NetlogonAttribute: LogonSAMLogonResponseEX (SAM Response to SAM logon request): 23 (0x17)

- SamLogonResponseEx: ADTMDC1.adatum.com

Opcode: LogonSAMLogonResponseEX

Sbz: 0 (0x0)

+ Flags: 0x000013FD

DomainGuid: {62F9F3AE-E037-47D1-8611-D8CA1AAED85E}

DnsForestName: adatum.com

DnsDomainName: adatum.com

DnsHostName: ADTMDC1.adatum.com

NetbiosDomainName: ADATUM

NetbiosComputerName: ADTMDC1

UserName:

DcSiteName: HQ

ClientSiteName: HQ

Unknown: Binary Large Object (7 Bytes)

+ Version: 0x00000015 NT Version 5 Client

+ LmNtToken: Windows NT Networking: 0xFFFF

+ Lm20Token: OS/2 LAN Manager 2.0 (or later) Networking: 0xFFFF

The italic Unknown: Binary Large Object (7 Bytes) has hex details corresponding to the following.

05 53 69 74 65 32 00

.Site2.

Here is the site topology created using the ADTD Visio tool.

Currently Netmon 3.2 with latest parsers decodes as above. Wireshark as of v1.0.5 did not decode this.

Please note that the above “Unknown: Binary Large Object (7 Bytes)” field is NOT available if the DC cannot see a subnet that the Vista machine belongs to. Netlogon.log on the client shows that the client did not use any try_next_closest_site flags. Yet the DC still presents the information. It can do this as the filter has a NtVer=16:00:00:00 string identifying the Client OS. XP for example would use NtVer=06:00:00:00. Hence a Windows Server 2008 DC will not respond with closest site info to them.