Computer authenticating with incorrect DC...sort of

I have a login script that uses the LOGONSERVER environment variable. I have several remote offices. There is one file server/DC in each office and each office is their own site. So when a user logs in to an office they should authenticate with that domain controller.

The problem I have been seeing is that some computers in an office (not all) will authenticate with a random DC from another office some days, but some days it will be fine. So for example, a guy logs in to office 16, he should authenticate with SERVER16, however he authenticated with SERVER13. When I checked event viewer on his computer, I can see that the time synchronized with the correct server (SERVER16) however his drives mapped to SERVER13 and when running set from a command prompt it shows his LOGONSERVER as SERVER13.

So how can a computer sync time with the proper DC for it's site, but still authenticate with a server in a different site? I have checked AD Sites and Services and DNS. Each site only has one DC, the correct one, and the DNS site records for each site are correct. By all logic there is no reason why this should happen, unless I'm missing something. Also, we are running mixed 2003/2008 Windows environment and it doesn't matter what the platform of the server is.

From serverfault $pageUsers[$entry.posts[0].author].name

• We have seen this for a couple of different reasons:

  1. DNS/WINS is not set correctly on the clients. Make sure that they don't have a secondary DNS/WINS server that isn't on their local network.
  2. Make sure the cost across the links is set higher than default in AD Sites and Services. If it isn't and the local DC is busy, the remote DCs might answer sooner because the cost across the link is set low enough that thinks it should respond as the nearest DC.
  From Scott Lundberg

• This is actually more common than you may think. Check the following to see if it helps:

  http://serverfault.com/questions/109056/how-to-force-machines-in-an-ad-site-to-authenticate-against-a-gc-in-their-own-sit/109141#109141

  Greg Askew : Sorry for the late reply. I'm not sure. I know that between any two points, AD prefers a link with a lower cost. What this means in your topology, I don't know. Why someone would manually create these two links...? We usually stick with automatic site links, there is no way we could manage a strategy of individual one-offs based on certain criteria. You may try adjusting the RegisterDNSARecords so that a remote site would prefer the central DC if the local DC is unavailable. You may want to perform packet captures before and after any changes to confirm the results of your changes.
  From Greg Askew