9

I'm having a hard time diagnosing intermittent slow logins on domain PCs.

A bit of information about the network that has this problem:

  • My domain spans 5 sites, all with VPN connections.
  • DCs are a mixture of 2003, 2008 and 2012. Domain functional level is 2003.
  • Clients are mostly Windows 7 x64.
  • We use group policies, including ones that use WMI, group preference item level targeting, and GPP printer deployment.
  • We do not use roaming profiles.

For the most part, logins work fine and quickly for people who have used the machine before. The first login to a new computer is always slow, but that's expected.

The problem seems to be mostly with laptops. If they are used at home with a non-domain network connection, or moved to a different location (still on a domain network, but different AD site, and doesn't seem to matter wired or wireless) logins can take as long as 3 minutes from the time the user enters their password, until the time it actually starts showing the desktop. Our terminal server also intermittently experiences slow logins.

Unfortunately, its an intermittent issue, and I haven't found any reliable way to reproduce it. My suspicion is that it has to do with the group policy preferences, but I don't really have any proof of that. I have seen a microsoft KB article blaming certain types of item level targeting for slow logins, but it doesn't give any guidance to determining if that is actually the cause.

What logs and tools can I use to figure out what is causing the slow logins?

What group policy settings should I use or avoid if possible to speed up logins?

Grant
  • 17,671
  • 14
  • 69
  • 101
  • Look at the logs on the client machines. You'll usually see what's causing the slowdown, like network timeouts, in the client-side logs. – HopelessN00b Feb 10 '14 at 16:00
  • Are your sites and subnets set up in ADS&S? – joeqwerty Feb 10 '14 at 16:57
  • I would start with dcdiag /v /e and check for any errors – Dusan Bajic Feb 10 '14 at 17:05
  • I would check repadmin to check replication between DCs. My thinking goes along the lines of password changes not being synced forcing the dc to auth the user and then query the PDC to try and organise what the most up to date password is. –  Feb 10 '14 at 17:25
  • @joeqwerty all the sites are setup properly in sites and services. – Grant Feb 10 '14 at 18:10
  • @timalexander Replication is working properly - we had some issues with it not long ago so after fixing it I went over dcdiag and repadmin with a fine tooth comb to make sure it was all working again. Though I'll check again to see if any new issues have cropped up. – Grant Feb 10 '14 at 18:11
  • Sniff the traffic. It's the only way to be sure. – Evan Anderson Feb 10 '14 at 23:40
  • 1
    This link may be helpful but I do feel that you are up against it without some semblance of being able to reproduce the problem. http://social.technet.microsoft.com/wiki/contents/articles/10130.root-causes-for-slow-boots-and-logons-sbsl.aspx –  Feb 11 '14 at 14:52
  • Have you checked the event viewer if you run into a timeout on processing group policies ? – Becks TibiaFun Mar 25 '14 at 16:06
  • Could it be the case that the laptop image is not configured with sysprep to make the client unique after imaging, e.g. mini-setup? – Evolutionise May 07 '15 at 14:02
  • Try to enable branch cache this would optimize your clients connections to the remote servers, I read all the comments and I see that almost every thing is ok. Let me know if this help you. – ravasquezgt Dec 09 '15 at 23:09

2 Answers2

1

Basically, I'm heading in the same direction as joeqwerty

I have experienced the symptoms you are describing at a few companies. In my experience, it usually happens when there is more than one site. One way to troubleshoot a potential issue with sites and services is the following. On a computer which just experienced a slow logon, go to command prompt, type echo %logonserver% If the response is not a server in the same site as the laptop or workstation, then my experience has been that subnets are not set up and assigned the correct site in active directory sites and services.

Another way to troubleshoot is to look at this log file on your domain controllers %SystemRoot%\debug\netlogon.log

If you see entries such as this, the specific subnet needs to be entered into sites and services and assigned a site.
05/16 22:57:31 [4068] AD: NO_CLIENT_SITE: specificserverhostname 172.16.10.104

Microsoft workstations and domain controllers have the ability to make certain that they go to the correct domain controllers for authentication and policies because of sites and services.

If this is the case and it leads to an adjustment of sites and services, please know that the replication of the changes to/from domain controllers can take some time. Also, it will take even more time for the endpoint workstations to see the new changes. The default replication time is set in sites and services for 1 hour between domain controllers. Depending on the distance in geography and size of your AD forest, I usually set it to 15 minutes or so.

thereisnothername
  • 11
  • 3
0

An answer that might fit the question or simply a note for myself for later:

We experienced extreme delays on logins for a few of our sub nets. Turned out that those sub nets were missing reverse DNS zones in the AD server. We added the reverse zones, AD added PTR entries automatically, and haven't experienced the delay since. May be coincidence too.

Zachary Scott
  • 227
  • 2
  • 14