I am facing a puzzle:
My company has several branches, each branch's subnets have been defined in their own respective site, and each branch has its own RODC.
However, when pinging to the domain name (let's say, "example.com
"), instead of resolving to the site's RODC, it resolves to the one of the main DCs on the Head Office.
AFAIK, when a computer on a site tries to resolve the domain name itself (e.g., when trying to access \\example.com\netlogon
), it should resolve to the site's domain controller.
So, why am I seeing this behavior here?
Additional info:
- The main DCs on Head Office are a mix of 2008 and 2008 R2
- The RODC on the branches are 2008 R2
Any suggestion will be helpful. TIA.
More Information:
The problem was that the WAN link between Head Office and Branches are very slow (bandwidth costs a fortune in my country). There are several large files that we replicate through \\example.com\netlogon
, and because some branch computers resolve example.com
into the IP address of the Head Office DC, they're pulling those files through the slow WAN link instead of accessing the replica on the branch RODCs.
In our DNS, all of the DCs are listed in the DNS as ourdomain.com. I believe this is expected behavior. If you are worried about how logins are being handled, then you are looking at the wrong DNS entries. For a description of how clients find their site's DCs, take a look at the following article.
http://technet.microsoft.com/en-us/library/cc978016.aspx
If the issue is the DFS location of a local share, you might take a look at this thread: http://www.activedir.org/ListArchives/tabid/55/forumid/1/postid/35786/view/topic/Default.aspx
As uSlacker mentioned, this may not actually adversely affect operation of Windows clients and certain functions such as ldap communication. This is due to how the internal Windows dc locator process functions, which among other things, prioritizes selected domain controllers by site.
A straight dns lookup at the command prompt is just that - a DNS lookup. If a domain controller has registered it's A record in the domain zone, it may be returned as a response to a DNS query. You may want to inspect your DNS zone and confirm which domain controllers have registered an A record.
If a packet capture reveals that branch computers are using a domain controller in another site, it may be due to it is common to configure domain controllers in spoke sites (branch offices) to use DNS mnemonics, that instructs a domain controller which DNS records to avoid registering. In large directories, it is actually quite common for spoke domain controllers to not register an A record in their DNS zone. If the branch office location also does not have a site associated with it's subnet, that may explain an affinity for the main site domain controllers.
More information:
How to optimize the location of a domain controller that resides outside of a client's site
http://support.microsoft.com/kb/306602