Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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
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 for details. – Striker_84 Jan 23 '13 at 11:53
Mark Russinovich has some great links for troubleshooting slow logons. 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

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.

share|improve this answer
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). – Twisty Jun 1 '15 at 19:20

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.

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

Value: BufferPolicyReads
Value: 1

share|improve this answer

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.

share|improve this answer
"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 you should use something like 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 3:34
@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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.