locked
Active Directory Sites and Services choosing wrong site RRS feed

  • Question

  • We have had our AD setup using site and services for 6 months without any problem, but now I am upgrading our vpn and that is causing Site and Services to show the machines in the wrong office.  We were running a vpn between the two cisco routers we had in each office, the new vpn is using openvpn.

    Basically if I am on the cisco vpn everything operates as expected.  As soon as I switch to the openvpn connection the machines all think they are in the other office.  If I run nltest /dcgetsite it shows the other site, the logon server shows the correct local server and when I do DNS lookups it goes through the local server correctly.  When I do a dns lookup of the domain it resolves to the local server.

    Now if I just disconnect the vpn between the offices everything resolves to the correct site but as soon as it is back up the machines all think they are in the other office again.

    In site and services I have the subnets of the openvpn connection and each local subnet pointing to the correct site.

    At this point I am at a complete loss and can't figure out what to do and I have not seen or heard of someone experiencing a similar issue.  I am thinking it is some sort of routing issue but I have not been able to find too many details on how the site and services actually work to pick the correct site other then the machine's subnet.

    Monday, July 15, 2013 7:01 PM

All replies

  • The mechanism of locating a DC, either in its own or remote site is called DClocator process.

    http://blogs.technet.com/b/arnaud_jumelet/archive/2010/07/05/domain-controller-locator-an-overview.aspx

    Quoted from here DC Locator

    It is important to know how a Windows computer selects a domain controller. The computer, during startup, determines the Active Directory site in which it belongs. Windows accomplishes this by examining the subnet of its current network configuration. Then, the computer queries a domain controller that hosts the computer object(using the Windows API DsGetSiteName). The domain controller answers this query with the name of the site associated with the computer's currently configured subnet. This is all done by the NetLogon service, which runs the DC Locator code at boot and periodically rechecks the domain controllers’ location.

    As long as sites,subnets, site links are configured properly & proper DNS is specified in the preferred and alternate DNS server, there is no issue. With windows 2008, there is new setting which can be configured via GPO for locating a DC effectively "try next closest site". It is applicable only to windows 2008/Vista & above.

    http://blogs.technet.com/b/askds/archive/2011/04/29/sites-sites-everywhere.aspx



    Awinish Vishwakarma - MVP

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    • Proposed as answer by Meinolf Weber Tuesday, July 16, 2013 6:52 AM
    Tuesday, July 16, 2013 2:18 AM
    • Proposed as answer by Mr XMVP Tuesday, July 16, 2013 1:48 PM
    Tuesday, July 16, 2013 6:54 AM
  • Thank you for the information but after reading it still appears that things are just not working they way they are supposed to.  When I am on my old VPN everything works fine, when I switch to the new one the machines authenticate against the local DC but then still show up as the wrong site.  That to me sounds like DC Locator is working correctly but the wrong site is still returned.
    Tuesday, July 16, 2013 1:25 PM
  • Thank you for the resources, I had actually already gone though these and was still not able to figure out what was going on.  The remote office is in use today and tomorrow so I can't take down the connection and switch VPNs and do additional testing again till Thursday.
    Tuesday, July 16, 2013 2:14 PM
  • The link given by Awinash is recommendable and moreover you can have a look at these link also for the same..

    http://technet.microsoft.com/en-us/library/bb727049.aspx

    http://technet.microsoft.com/en-us/library/cc731907.aspx

    Thanks.

    Tuesday, July 16, 2013 2:56 PM
  • You can do one more thing like using wireshark or netmon to monitor and capture the real time traffic for analysis what's happening behind the scene.

    Also, check what are the records present in all the _msdcs folder in the DNS & make sure there is no records of the demoted DC is present. I presume catch all subnet is not configured.


    Awinish Vishwakarma - MVP

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Wednesday, July 17, 2013 12:48 AM
  • Under the domain _msdcs  folder didn't contain any of my DCs except a very old one.  I updated it with the current DCs and I am testing now.
    Thursday, July 18, 2013 2:14 PM
  • That didn't fix the issue.  I can listen with wireshark to see what is happening but I am not really sure what I should and should not be seeing.
    Thursday, July 18, 2013 2:34 PM
  • I know this is a very old thread, but I just wanted to mention that I had the *exact* same behavior you described at 1 of our 3 sites for about 4 months. We, too, were using an OpenVPN connection and we had a handful of stubborn PC's that would continue to wind up in the wrong (foreign) site on occasion. We double, triple, quadruple checked all the Active Directory and related settings imaginable and kept having the same issue. Not every day, not with every PC, but it was enough of a reoccurrence and inconvenience that there was clearly something wrong.

    I stumbled across this thread mentioning PC's in wrong AD sites + OpenVPN and it was basically the only lead I could find. About a month ago, we upgraded to SonicWALL firewalls throughout the organization and are now using the SonicWALL IPsec VPN to connect our sites. Since we dropped OpenVPN, we have yet to  experience a PC winding up in the wrong site.

    I'd like to see it be problem-free for another month before declaring it resolved, but if we experienced the same behavior as the original poster in this thread, I have to believe OpenVPN is playing a role here. Perhaps a misconfiguration with our OpenVPN deployment, but still, way too coincidental IMO.

    Hope you were able to get your problem resolved eventually, OP.

    Wednesday, July 30, 2014 12:43 AM