0

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?

3

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.

  • 1
    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. – charleswj81 Jan 18 '14 at 4:20
  • Good point Charles. – Ryan Bolger Jan 18 '14 at 18:30
0

Authentication and active directory traffic is going to depend on what you have setup in AD Sites and Services, it's isn't dependent on DNS. By setting up the various subnets on your network and assigning them to the appropriate sites, you can control the domain's AD traffic and replication topology.

  • 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. – MDMarra Jan 18 '14 at 0:58
  • 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. – user3208219 Jan 18 '14 at 2:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.