18

We are racking our brains trying to figure this problem out an are currently stuck!

Basically we are having issues with some users taking ages to log in in the mornings, some times up to 20 minutes, we have tried correcting this problem looking at a variety of methods, we have checked DNS (seems to be fine, although not my strongest point I will accept suggestions), checked network speed (seems fine), the users in question are not using roaming profiles and there are no policies pointing to unavailable mapped network drives.

This is now a major problem as so many users are complaining that they can make a cup of coffee before the computer logs on.

Daryl Liney
  • 181
  • 1
  • 1
  • 3
  • 3
    Do you guys have an ntp server, and sync all your clocks with this ntp-server? I nearly lost my mind because we didn't have an ntp Server and all our AD Maschines where slightly out of sync and this causes insane network traffic and really long authentification times. – Harrys Kavan Jan 23 '13 at 10:43
  • 1
    although you've mentioned DNS, please verify that your clients are pointing to your Windows server’s DNS and WINS services. You could also try to configure DNS entries on a local system. see [link](http://www.oregontechsupport.com/microsoft-windows/windows-domain-login-slow/) for details. – Striker_84 Jan 23 '13 at 11:53
  • 6
    Mark Russinovich has some great links for [troubleshooting slow logons](http://blogs.technet.com/b/markrussinovich/archive/2010/01/13/3305263.aspx). You may consider starting there to gather some more information about your specific problem. – jscott Jan 23 '13 at 12:43
  • I have two questions about the problem : Are you sure that you don't download the entire user directory at login (files, documents, music, etc.) from the domain controller, and not just the configuration files? Is the logout slow too? – Str82DHeaD Jan 26 '13 at 18:57
  • CHeck Network traffic. Roaming porifle + Gigabytes of data = slow logon. – TomTom Jan 26 '13 at 19:02
  • Str82DHeaD in answer to you question, no. None of our users are on roaming profiles so all files are stored on the local machine, log out is not slow at all, takes around 30 secs – Daryl Liney Jan 29 '13 at 10:40

4 Answers4

3

We had a similar issue where workstations were taking about 10 minutes to log in. However, if the network cable was unplugged and the PC rebooted then they logged in right away.

We found that the slow logons were caused by a printer driver that was being installed but which required user input, which obviously couldn't be provided because the user was not logged in yet.

Try turning on Verbose Welcome Screen in GPO. This might show you where the PC is getting stuck.

I say Reinstate Monica
  • 3,100
  • 7
  • 23
  • 51
user239341
  • 31
  • 2
  • As a slight variation to this solution, I solved the same problem the OP had by removing a GP Preference item that was attempting to install a printer that no longer existed (rather than requiring user input). – I say Reinstate Monica Jun 01 '15 at 19:20
  • this does not seem to do anything! I enabled this in gpedit.msc but logout and login screen look the same on server w2k16! – Vitas May 04 '20 at 17:18
2

You may want to test the "BufferPolicyReads" registry setting. This setting is enabled by default in Windows 7, but needs to be specified for Windows XP.

http://support.microsoft.com/kb/319440

Key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Value: BufferPolicyReads
Type: DWORD
Value: 1

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
1

To add to what others have posted, I've seen this sometimes when the client machines DNS are set to something other than an AD server (or internal DNS server), this is especially true if your local domain is using a .com or .net or something that is in the Public DNS domain.

MDMarra
  • 100,183
  • 32
  • 195
  • 326
OrganizedChaos
  • 184
  • 1
  • 5
    `"this is especially true if your local domain is using a .com or .net or something that is in the Public DNS domain."` - No. This is wrong. You **should** be using the subdomain on a registered domain that you own for your AD. So if your site is `example.com` you should use something like `ad.example.com` for your Active Directory. As long as the clients are configured to use the Domain Controllers for DNS, there's no reason to ever discourage anyone from using a .net, .com, .edu or any other registered TLD. Under no circumstances should you *ever* use a fake TLD like .local, .lan, or .corp. – MDMarra Jan 28 '13 at 03:34
  • 2
    @MDMarra so.... I went to lookup your answer to prove you wrong, because in the past this was widly considered best practice. I see that now, it's recommended to go with a public DNS name and use the subdomain like you mentioned because it's unique. If your company were to merge, you wont have any issues with merging two AD's with the same name etc... – OrganizedChaos Jan 28 '13 at 11:57
-3

Try netsh int ipv4 reset & netsh winsock reset & ipconfig /flushdns, this did it in my case

gonzo
  • 1