Windows Clients connecting to DC in wrong site?

Question

Ok so Sites are separated by WAN

 Domain            : production.contoso.local


 SITE A
       Site network:  192.168.0.0/16
       Site DCs    :  DC1-SiteA, DC2-SiteA
       Client      :  serverA
 SITE B
       Site network:  172.16.0.0/16
       Site DCS    :  DC1-SiteB, DC2-SiteB
       Client      :  serverB

Randomly servers seem to resolve the domain name to DC in another site.

I will logon to a serverA(192.*) and ping our domain "production" and it will resolve to the ip of a DC in a different site(DC1-SiteB, 172.16.0.0/16), while on the other hand if I ping the domain using the full fqdn "production.contoso.com" then I will resolve to the correct DC(DC1-SiteA, 192.168.0.0/16)

If I flushdns, then the situation reverses it's self, "production" resolves to DC1-SiteA(192*) and "production.contoso.com" resolves to DC1-SiteB(172.*).

All Clients and Servers are reporting as being in the correct site via http://www.powershellmagazine.com/2013/04/23/pstip-get-the-ad-site-name-of-a-computer/

DCDiags checkout on all DCs

All DNS records and _msdcs look correct.

Is this..normal?..?

If the domain resolves to a DC in another site, is it pullling policies and authenticating to those, thus slowing logon/reboot times?

Any other avenue I need to check?

Solution

Your problem is that the ping command is not Active Directory site aware. When you issue a ping command against your domain's FQDN, it issues a simple DNS query for the name which returns the IPs of all DCs. It then chooses one round robin from the results to actually use for the ping.

What are you trying to test/accomplish by pinging the domain? If it's just to check whether the server is using the right domain controller for auth, the quickest way I know is using the set command from a command prompt. Look for the LOGONSERVER environment variable. With a little more typing, you can get it directly by typing echo %LOGONSERVER%.

If you need to account for services or applications connecting to the domain that aren't site aware, you need to do a little more work. A super-cheap way we've done this in some of the companies I work for is to manually create site aliases in DNS. In your case, you'd create 4 additional A records in your DNS server:

• sitea.production.contoso.local -> <IP of DC1-SiteA>
• sitea.production.contoso.local -> <IP of DC2-SiteA>
• siteb.production.contoso.local -> <IP of DC1-SiteB>
• siteb.production.contoso.local -> <IP of DC2-SiteB>

We've done this in some of the companies I work for to account for things like web sites that have AD integration via LDAP. The LDAP protocol by itself is not site aware*. So if the server hosting the site is in Site A and you set the LDAP configuration to use the FQDN of the domain, it may choose to use one of the DCs in Site B. With the additional DNS records, you can set the LDAP configuration to use sitea.production.contoso.local instead. Then as long as you keep those records up to date as you add/remove DCs, you don't ever have to reconfigure the application.

Comments

[MDMarra]

While the information that you've written here is accurate, it doesn't answer the actual question or explain the behavior that the OP is seeing.

[user3208219]

He specifically asked "If the domain resolves to a DC in another site, is it pullling policies and authenticating to those, thus slowing logon/reboot times?", hence my response.

[charleswj81]

Good answer, however be careful relying on the logonserver variable. It is the server that serviced the logged-on user's logon. The server may very well have used/be using a different server. The user session may have moved on to a different server, but the value will never update until you log off and log on again. Further, other portions of the logon process may or may not use the same server, including the Group Policy GPT's (Sysvol/DFS) and GPC's (AD/LDAP). The only way I've ever found to /truly/ determine the currently utilized DC is via network capture.

[Ryan Bolger]

Good point Charles.