Last week one of our stores had a problem with seemingly slow starting workstations. These workstations where hanging for at least 15 minutes on “Applying computers settings”.
The workstations that where affected at first seemed to be randomly.
Because the local admin had created a new master-copy a few weeks earlier, and he couldn’t remember whether the machines that where affected had received this new image I decided to first investigate the master before attempting to monitor the network.
All dynamic DHCP settings where okay, netsh int ip reset didn’t work, neither did deleting the whole network card and re-adding it.
So after that didn’t work I port-mirrored one of the workstations that had this problem onto my laptop and ran WireShark ( network packet capture program) while the workstation was booting.
After analysing the logs I discovered the problem.
The workstation would request from the DNS server the nearest domain controller for our domain, but instead of getting the one it was supposed to, it received a DC in a completly different country.
Because packets aren’t allowed to traverse from one country to another directly, it could obviously not reach the DC and tried another until it got one that it could reach and after that the user was allowed to logon.
Now knowing the problem, I started investigating the cause of it. Obviously, this had to do something within the AD / sites and services; and right then it hit me: we recently started using a second subnet for clients in this store and I guessed something went wrong with adding the networks to the site.
After verifying my suspicion, it turned out the person who had created the site used a /24 instead of a /23 subnet mask in the sites configuration, and therefore the clients in the second subnet had no idea to which site they belonged.
After changing the site to the correct subnet all clients worked fine.
Tags: linkedin
Another “Good” one.
One of our remote sites was having a 30 minute login time.
After chasing it for a while, opening a call with microsoft,
and lots of traces, found that the keberos handshake was failing.
After digging a bit futher, found it was a security change to drop fragmented packets, which translates that kerberos can never work in a windows domain properly.