Multiple DCs and Sites (DNS returning DC IPs not reachable from all sites)

Posted on 2007-08-03
Last Modified: 2008-06-01
We are experiencing what appears to be DNS issues on our network.
Here's a summary of how everything is configured.

3 store locations (loc01 - loc03)
1 headquarters  (hq01)

Domain name:

All have Site Domain controllers with DNS and a global catalog.

Has Main Domain controller with DNS and global catalog

loc01-loc03 each have a VPN tunnel to hq01 (loc01-loc03 can all see hq01, but cannot see eachother)

Our problem is that for Group Policy replication the DC's try connecting via \\\\SysVol\\Policies\{~~GUID~~}\gpt.ini

From loc01, in nslookup will return the IPs for ALL DCs from ALL locations, but only loc01 and hq01 are reachable via VPN.  How can this be corrected so from each location only the local site DC and hq DC IP is returned when resolving ???

We are receiving an error indicating that the gpt.ini file is inaccessible (1058) (Windows cannot access the file gpt.ini for GPO)
  - We've concluded this is because DNS resolves our domain name to all DC IPs some of which are not accesible.  Therefore we need to have DNS only return the DC IPs that are reachable from said location.

As for Sites, each loc (loc01-loc03) is in a site and set for replication from the Main DC at hq01.  This part is working.
Question by:MemxIT

    Author Comment

    I think I've tracked a problem down.  the DNS zone is replicated in active directory.  There's A records for all DCs for as well as NS SRV records for all DCs... my question now, since this is replicated globally, how can you return the appropriate result from DNS based on the site doing the DNS lookup?

    Author Comment

    As an additional question to all this.... We currently use as our domain company wide.

    Should we have a child domain for each location since all locations cannot see eachother ?? therefore the DNS records for each location would be in seperate zones?

    ie. Domain, DNS
        Domain, DNS

    Ideally we'd like to maintain the single domain, but get each store location to act completely independant from everywhere else and replicate from the hq01 Domain controller for DNS and AD.
    LVL 19

    Assisted Solution

    A couple things for starters. In AD Sites and Services make sure the subnets are defined for each of your sites; this will ensure that  clients at those sites will use the local DC on their subnet.

    Also, since all of your DC's can't communicate with each other - again in AD Sites and Services, under Sites | Inter-Site Transports | right-click the IP container and you'll see a tick box for "Bridge all site links". When it's enabled, basically all of your sites will try to replicate with each other - if you disable that option then only the site links you manually define will replicate. (i.e. HQ <-> loc01 | HQ <-> loc02 | etc...)
    LVL 23

    Accepted Solution

    You don't need child domain in this case.

    Usually it IS DNS related, though sometimes it could be a result of screwed NTFRS replication of SYSVOL share.

    couple of tests that might help you pinpoint the problem:

    1) create a scheduled task on the client experiencing the problem, which will open an interactive cmd shell (by default will run as Local System account). When the window pops up, check if you can resolve/access the sysvol share.

    2) Check out the following KB:;EN-US;250842
    try enabling verbose logging and drill down the logs for any errors.
    (the article applies to W2K, so you might need to adjust it to your needs - gpotool is depricated in favor of gpupdate/gpresult)

    3) go over the system variables to determine the DC the client used to logon. Make sure the DC is resolvable by FQDN and it's hostname.

    4) Use ntfrsutl.exe with "ds" or "sets" options to make sure the SYSVOL is replicating ok.

    5) Check out that the comuter accounts have at least read access to SYSVOL and the folder where the GPT part of the GPO is located (both NTFS and share permissions)

    Do the dcdiag and netdiag
    What happens if you take the DC offline (force the clients to authenticate to other DC) ?
    LVL 70

    Assisted Solution

    You do not need child domains - but you do need to define your sites in Activie Directory.

    You should start by defining the subnets in AD sites ans services, then you can create AD sites and assign each subnet to a site.

    Once this onformation has been entered (and replicated) then clients will default to attempting to use a DC on their own site in preference to any other Dcs

    Author Comment

    In AD Sites and Services make sure the subnets are defined for each of your sites
       - Already done, all sites have their subnet defined

    In AD Sites and Services, under Sites | Inter-Site Transports | right-click the IP container and you'll see a tick box for "Bridge all site links"
      - Already disabled, and only links between servers that can see eachother are present

    I will try some of the things mboppe suggests when I have a change (today or tomorrow).

    Thank you guys.  I'm pretty sure it's just DNS related, as doing an nslookup on the domain name resolves to the IP for ALL DCs not just the reachable ones.  Under the domain zone in DNS there are A host records for the domain zone (one for each DC), I'm sure this is where it's getting the records from, but if I delete any A record, it'll replicate to all the Site controllers and the site's who's DC A record I delete will not return the IP for it's DC via DNS anymore.  I've assumed Microsoft was smart in the sense that even though all IPs are resturned when doing nslookup, because I have sites and subnets defined it will only use the IPs belonging to it's subnet, and if that's not reachable it'll use the other servers that are defined in the replication links (since you can set weight and priority on them etc.)

    Author Comment

    Create a scheduled task on the client experiencing the problem, which will open an interactive cmd shell (by default will run as Local System account).
      - I can't seem to run it as a Local System account, I also can't log in to windows locally either.  I only have the domain as an available login option, the local machine name doesn't show up, I assume because the server is a DC and is running Active Directory.

    Go over the system variables to determine the DC the client used to logon
      - UserDomain and UserDNSDomain both equal dom of course... but this info doesn't help since if it's logged into the domain anywhere it'll say dom (  I don't see any variable that tells what DC it logged into, only what domain.

    I'll continue to check the other things you've suggested, thank you

    Author Comment

    K, my bad.. just reread the environment variables, LOGONSERVER is correct, it's DC for that location.

    The GP replication error I have in Event Viewer states that it's replicating from \\dom\SYSVOL\........

    The issue is DNS nslookups on dom returns the IPs from all DCs instead of only the DC that's in the current site.  There's an A record for all DCs for the zone, which if I delete any of them they'll replicate to all site DNS's and that site will not get the IP for it's local DC returned.  Is there any setting that DNS will return records conditionally based on the site you're in?

    Author Comment

    Anybody know why I get all DC IPs for an nslookup on the domain name instead of just the IPs of servers specified in the site ??  how can I correct my DNS to resolve this?

    Author Comment

    Here's the root of my problem I'm trying to resolve... GPO replication errors:
    Event Type:      Error
    Event Source:      Userenv
    Event Category:      None
    Event ID:      1058
    Date:            8/7/2007
    Time:            8:57:51 AM
    User:            NT AUTHORITY\SYSTEM
    Computer:      ABD0-SRV-DC01
    Windows cannot access the file gpt.ini for GPO CN={02EAC0C9-59FE-43A5-93C3-A673E863076F},CN=Policies,CN=System,DC=MEMXDOM,DC=******,DC=COM. The file must be present at the location <\\MEMXDOM.******.COM\SysVol\MEMXDOM.******.COM\Policies\{02EAC0C9-59FE-43A5-93C3-A673E863076F}\gpt.ini>. (The system cannot find the path specified. ). Group Policy processing aborted.

    For more information, see Help and Support Center at

    I've read this page about how GPO replication works, and have determined my Active Directory replicates no problem, it's the File Replication Service (FRS) that is having issues.,289483,sid1_gci1206806,00.html

    Author Comment

    "FRS, unlike the Active Directory replication service, does not adhere to site boundaries and is not limited to a schedule. This makes the replication of the GPT fast and efficient between domain controllers."

    This could be my issues, since it's trying to replicate from a site DC that isn't reachable from the current site.

    Author Comment

    I've gotten rid of the GPO replication error, the FRS on our main DC stopped for some reason half a month ago, I restarted it and created a temp folder in \SYSVOL to trip a replication...  Now it is working for replicating the SYSVOL tree....

    We still have the issue that doing an nslookup of ping of our domain name resolves to all DCs (even ones that are not reacable).  What can I change via DNS to correct this?

    Featured Post

    Courses: Start Training Online With Pros, Today

    Brush up on the basics or master the advanced techniques required to earn essential industry certifications, with Courses. Enroll in a course and start learning today. Training topics range from Android App Dev to the Xen Virtualization Platform.

    Join & Write a Comment

    Remote Apps is a feature in server 2008 which allows users to run applications off Remote Desktop Servers without having to log into them to run the applications.  The user can either have a desktop shortcut installed or go through the web portal to…
    This is the first one of a series of articles I’ll be writing to address technical issues that are always referred to as network problems. The network boundaries have changed, therefore having an understanding of how each piece in the network  puzzl…
    This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
    This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

    745 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    19 Experts available now in Live!

    Get 1:1 Help Now