One domain user on our network takes up to 5 minutes to log on to one particular PC (the other domain users can log in in around 10 seconds, and local accounts take only a couple of seconds to sign in on this PC).

This is a well-known error- but what makes this unusual is that only 1 particular domain user account is affected, and only on one particular PC:

enter image description here

This is a clean install of Windows XP Professional, with almost no software installed. The only twist is that this is a remote computer connecting to the main site (where the domain controller is located) via a Hamachi VPN gateway network.

Once logged in, the user with the slow logon is also unable to browse network shares on the server at the main site (although pinging hosts on the central site is successful). Simply typing "\\server" does not show the network shares (as it should for a domain user), instead Windows asks for domain credentials as if a local (rather than a domain) user account is trying to access it.

Initially I suspected DNS to be the problem, however everything in DNS looks the same when logged in as either user- I am unable to find anything different in the problematic user account:

enter image description here

enter image description here

It's definitely not a corrupted profile- it was only created 2 days ago (signed in for the first time using that account this week). Also, I have just deleted and recreated the profile from scratch- and the issue still persists.

Both users are in the same OU in Active Directory, so I can't see how this would be related to Group Policy.

I can log in as any other user, and everything goes back to normal again. The issue is 100% repeatable.

Any ideas would be much appreciated. This has me stumped.

  • Can you clarify - is there one physical PC (remote), and the behaviour differs depending on which user ID is used to login from that PC? – EightBitTony Jul 5 '13 at 6:29
  • That's correct. There is only one physical PC, and only one (of many) domain user accounts is getting stuck at the logon screen for a few minutes each time (sometimes as much as 5-10 minutes). Deleting the user profile on this PC (folder structure and registry key) did not make any difference. – Austin ''Danger'' Powers Jul 5 '13 at 7:31
  • What about the server profile? How big is it? – krissi Jul 5 '13 at 7:53
  • @krissi: server profile size? How do you mean? We don't have roaming profiles if that's what you're wondering. – Austin ''Danger'' Powers Jul 5 '13 at 8:27

It seems that your problem is SMB / CIFS: I suspect that this particular user has Network Shares mapped, which of course are being connected at logon - or at least, are being tried to be connected. Which fails, and the timeouts are quite high for this.

However, while this causes a slow logon, it is not necessarily the root of your problems; as you have reported, this user has problems to connect to shares at all. I'd recommend to investigate this issue. Don't exclude network problems yet; being able to ping does not mean you're able to mount shares. Confirm with a different, working account.

  • 1
    I think you could be onto something. At the main site, all users can log on to any PC and their drives get mapped. At the remote site, there is a very long delay and a failure for drives to be mapped (I saw it work once or twice, but it they fail to map 95% of the time). I just did a test, and the account took 105 seconds to log on when the user had access to a security group (causing a script to attempt drive mapping at logon). When the user was removed from this group, logon time went down to 35 seconds (not fast, but maybe that's all I can hope for over VPN). – Austin ''Danger'' Powers Jul 5 '13 at 8:38
  • I'm going to create a new OU in Active Directory for the remote site, and exclude this PC (and others as they are set up at that location) from the drive mapping script. Only 3 domain users need this PC, so manually mapping the drives isn't too bad. Something else I forgot to add: the remote site connects via 3G. It's a very remote site... – Austin ''Danger'' Powers Jul 5 '13 at 8:40
  • A well thought out investigation. It seems your client is starved for bandwidth. You should try to get a better connection if the users need to access the shares regularly. – Roman Jul 5 '13 at 8:52
  • As a non-profit organziation with a limited budget, they are probably stuck with this 3G connection at that remote site. Fortunately, thanks to some great answers to my follow-up question (regarding using Group Policy to selectively map drives only when users log on to computers in the main office) I now have an elegant solution: Group Policy loopback processing: serverfault.com/questions/521145/gpo-not-applying-to-an-ou – Austin ''Danger'' Powers Jul 6 '13 at 0:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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