Wrong Logon server when changing sites.

Question

We are configuring servers for a client. We have a test lab (pre production) setup. We have 2 AD/DC setup on 2 different networks. We have sites and services setup with subnets defined. We can see in the registry that the "DynamicSiteName" changes when we move to the laptop from one network to the other. But if we log off and move the computer to the other network(even though the registry changes) the laptop will still list (when using "set l") the old server on the other network. If you restart the computer or log of and on a few times this will resolve itself. but if we move back to the other network same thing happens.

We were testing this as if it was a laptop user moving from one store to another. We want them to use the local DC to the site.

I know there will be questions that will need to be answered to other users. Ask away. We have gone through most everything that we can read.

Thanks again for all the help!

Answer 1

Just an update. We have been testing for hours. Even if you make it so the client computer cannot access the opposite site DC, it will still cache the logon server and the group policy. If you run nltest /dsgetdc:ourdomain it shows the correct info. Once computer is restarted everything shows correctly.

We are currently trying to give the client more time before we login again (15 minutes disconnected from all networks) we will then connect to different site and test to see if it worked.

Answer 2

Another update..... We have gone to extremes to find the issues. Someone mentioned that it was the DC that responded the fastest. We did not believe this to be the case so to prove that we removed the link between the 2 sites. Now the sites were not able to talk physically (network cables removed)

When moving the client between sites, we tried many ways, just logging off and tried to complete shutdown before moving networks.

When shutdown, move to new site, boot computer on new site. The GPOs were updated, both the user and computer. When running "gpresult /r" and the site shows correct. But when you run "set l" it shows the old site logon server. If you then log off and back on it does change and show correct when you run "Set l"

When you just logoff the client and move sites the "gpresult /r" shoes wrong site and the computer policy show from wrong site. The user GPO shows that it came from the correct DC. we expect this behavior because the computer GPO does not update unless you force a GPO update or the computer is started on the site.

We don't know if this will cause issues or not but we want to resolve any issues we find now before it is an issue.

Answer 3

Another Update after much more testing.

First off we know that the Group policies for computers ONLY updates on computer startup when connected to a site.

The testing we are doing is in regards to users with laptops moving between sites and how it will behave based on what users will tend to do with the laptops (just shutting the lid and leaving to another site).

We gapped the networks (network disconnected) for testing only. Knowing that the other site was not available to see what the client computer would report with the "Set l" command. This proved to us that it was cached and not correctly showing what server was really used because the other site was physically not available.

We have found that if you do not let the client computer cache the login credentials at all (registry change) then the problem mostly goes away with the "set l" command. It does not show the wrong login server when moving sites. But with that ability removed for the client computer, it will stop the login at all if there is no connection to any domain controller(not wanted).

We also found by using Wireshark and Netlogon logs, even though the client computer shows wrong logon server with the "set l" it does SEEM to use the correct DC for authentication.

We know that the users should log off and shut down before changing sites. We were trying to see what all would happen when they don't follow the rules as most user will tend to do.

At this point we feel the largest issue is that the "set l" command is not showing the correct logon server, it seems to only be reporting the last one used. We completed a test as follows. Move client computer to site 2, login and run "set l" it showed site 1 as the logon server. logged off, shut down moved to site 1, started back up, logged in and ran "set l" it then showed site 2 as the logon server. Again it was the last server it used, not the current server. Was able to recreate over and over.

All of this testing is because we went down the rabbit hole of trusting the "set l" command at first. We have this question posted on other forms and have see so many responses like "who cares unless you are seeing some sort of an issue" Our outlook is we do not want any issues that could have been avoided with some time and care before production.

Thanks to anyone who does post to this and gives any sort of suggestions. We again are testing like this because we know users don't follow directions well with the use of technology and best practices at this point.