Domain – Windows Clients connecting to DC in wrong site

active-directorydomaindomain-controller

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?

Best Answer

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.

Related Topic