Domain joined Windows PC not able to resolve AD Site

MichaelOBrien
MichaelOBrien used Ask the Experts™
on
We have a WAN site say site_A where the workstations are all domain joined and AD authentication works fine as well as other AD services, but we have a login script that relies on the Site to determine drive mappings etc and the site is showing as the main AD Site where the domain controllers are located.

So these workstations are no resolved the AD site correctly.  When running gpresult, we can see the site is returned is not the actual AD site. Other WAN sites 40+ correctly detect Site name.

I have checked and rechecked the Site ip settings etc in AD Sites and services and it appears correct.

There is a leased AT&T private cloud we use for our WAN connectivity
This one site we are seeing this issue is unique in that it uses a Point to point T1 from site_A to site_B (a bigger site close by) and site_a's traffic is routed layer2 to the WAN back to our mainsite.

Any ideas on the best way to troubleshoot?  We could do a net trace if we know what to look for etc.

Best Regards,

Michael
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Is there connectivity between the sites?  I.E can you ping stuff?  If not I would recommend looking at the routing equipment i.e routers to see whats up.  Did you perform a tracert?  IF so does it succeed?  If it does not, it will tell you the IP it stops at.  

Author

Commented:
Bill,

Thanks for the comment!   Yes ping works, and connectivity appears working fine. Drive mappings to a server at site_B work for example. Users are able to authenticate to AD etc, it appears this one thing is the only item broken or not working correctly.  Oddly gpresult returns all the correct GPO's etc, however it returns the main_site as the site.  

thanks again for looking at this.  MO
asuming that the client has the ip address assigned to the site it belongs to

i would check the priority and weight  of SRV records of the dcs in DNS server ..
dc with  "lower priority  and higher weight "will be choosen by client  out of all dcs listed in responce to query from the client to the dns server
if client does not know what site does it belogns ... the dc it got to should be telling the client that they belong to other site and give them the fqdn of the dc in clent's site




Author

Commented:
Good point.  In our topology, it works  best for us to keep the DC's for this domain in one location, so we have 3 dc's in the main_site two of these are dns servers for the domain, and then about 50 sites in ADSS on the WAN, none of which have a local dc, we use sites for mainly logical reasons, login scripts etc.

On all the other sites on the WAN, any dc is able to correctly return the site the workstation belongs. This one site, site_A cannot.  Can you tell me what I should look at next? Thanks again for your input on this  MO
Are the domain controllers at the site in question Global Catalog servers?  They need to be Global Catalog servers in order for clients to authenticate to them.

Author

Commented:
bill, thanks for the comment.
Turns out this issue was caused by two things:
First the GPO for this site was corrupt, we recreated it and the login script worked fine.
Second, we didn't understand how gpresult worked.  Basically it reports the site of the closest DC, and we were thinking it would report the site of the client.
Thanks for the help!!!
MIchael

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial