Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
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. –  zwarag 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 for details. –  Striker_84 Jan 23 '13 at 11:53
5  
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

2 Answers 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

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
3  
"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 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

 
discard

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.