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

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.
Who is Participating?
Malli BoppeCommented:
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) ?
MemxITAuthor Commented:
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?
MemxITAuthor Commented:
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.
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

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...)
Brian PiercePhotographerCommented:
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
MemxITAuthor Commented:
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.)
MemxITAuthor Commented:
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
MemxITAuthor Commented:
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?
MemxITAuthor Commented:
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?
MemxITAuthor Commented:
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
MemxITAuthor Commented:
"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.
MemxITAuthor Commented:
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?
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.