Slow Domain Logon - XP Clients
I've been reseaching this problem for a couple of weeks and i'm not getting any nearer sorting it out! We have a Windows 2003 domain with around 70 XP clients. We pass IP config to clients using DHCP, and as far as I can see we have DNS set up properly (clients point to 2 internal DNS servers (both DCs), and extern ...
I've been reseaching this problem for a couple of weeks and i'm not getting any nearer sorting it out!
We have a Windows 2003 domain with around 70 XP clients. We pass IP config to clients using DHCP, and as far as I can see we have DNS set up properly (clients point to 2 internal DNS servers (both DCs), and external DNS (ISP) servers are set up in the Forwarding section of DNS). I have checked a number of clients IP info using ipconfig /all and all clients have the same setup.
We also use three GPs - but they are not doing anything special (1 sets up Windows Firewall, 1 sets up WSUS and the third sets up default domain security).
99% of all machines when logging on to the domain take between 3 and 5 minutes, and hang for the majority of the time on the 'Applying Computer Settings' dialog. Eventually - when the PC has booted it runs normally with no slow down.
However - for some reason my machine and a newly built PC dont suffer from this issue. If anyone logs onto my or the freshly built PC - the first time they log on is a bit sluggish - but after that there logon is quick. My PC and the newly built PC are no different to other PCs on the network though - and they reside in the same OUs as regards Group Policies etc.
I'm wondering if the NICs drivers could be updated (although some clients use Intel and some Broadcomm cards).
To be honest - I'm pretty stuck. Anyone had (and solved) a similar issue?
HELP!!!
We have a Windows 2003 domain with around 70 XP clients. We pass IP config to clients using DHCP, and as far as I can see we have DNS set up properly (clients point to 2 internal DNS servers (both DCs), and external DNS (ISP) servers are set up in the Forwarding section of DNS). I have checked a number of clients IP info using ipconfig /all and all clients have the same setup.
We also use three GPs - but they are not doing anything special (1 sets up Windows Firewall, 1 sets up WSUS and the third sets up default domain security).
99% of all machines when logging on to the domain take between 3 and 5 minutes, and hang for the majority of the time on the 'Applying Computer Settings' dialog. Eventually - when the PC has booted it runs normally with no slow down.
However - for some reason my machine and a newly built PC dont suffer from this issue. If anyone logs onto my or the freshly built PC - the first time they log on is a bit sluggish - but after that there logon is quick. My PC and the newly built PC are no different to other PCs on the network though - and they reside in the same OUs as regards Group Policies etc.
I'm wondering if the NICs drivers could be updated (although some clients use Intel and some Broadcomm cards).
To be honest - I'm pretty stuck. Anyone had (and solved) a similar issue?
HELP!!!
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
Do the clients who are experiencing this problem have additional network protocols installed? The more protocols required to load, the longer the logins take, which sometimes causes it to hang.
You also mentioned that you have 2 DCs. Any reason for this? That could be causing a problem, unless you have two seperate networks.
Just a crap-shoot here: do the affected machines have a setting (either local or global) which erases all user setup information upon logging out? I've been on networks where this setting was applied and it literally would take between 5 and 10 minutes to login each time; this was for security reasons and quite a pain to deal with.
You also mentioned that you have 2 DCs. Any reason for this? That could be causing a problem, unless you have two seperate networks.
Just a crap-shoot here: do the affected machines have a setting (either local or global) which erases all user setup information upon logging out? I've been on networks where this setting was applied and it literally would take between 5 and 10 minutes to login each time; this was for security reasons and quite a pain to deal with.
Hiya Myke,
I was thinking the same thing along the lines of policies info not being cached and therefore having to be loaded and setup on every boot. I assume this would be a global policy - since I haven't changed any local policies at all.
Also - we have two DCs as a means of redundancy. If one DC goes down users can still authenicate onto the network through the second DC. Is this not standard practice?
I was thinking the same thing along the lines of policies info not being cached and therefore having to be loaded and setup on every boot. I assume this would be a global policy - since I haven't changed any local policies at all.
Also - we have two DCs as a means of redundancy. If one DC goes down users can still authenicate onto the network through the second DC. Is this not standard practice?
In regards to the two DCs, I've encountered connectivity issues when the network thinks there are multiple DCs on a single network. To be completely honest, I've not tried having redundancy for DCs, with the expection of having two NICs on a single DC. You might be better off getting advice on that from someone more knowledgable than I.
Back to your main issue, though, it's probably a global policy. Why it isn't affecting the other two machines, I can only attribute that towards the time of setup. I had originally setup all clients to receive updates from our WSUS server and not allow them to go to the Windows Update site itself. Any clients added to the network post-WSUS setup did not have this policy attached to them, so they were free to visit/use the Windows Update site. Wierd, but it wasn't a huge deal (we're better off having that option available).
Hope that was somewhat helpful.
Back to your main issue, though, it's probably a global policy. Why it isn't affecting the other two machines, I can only attribute that towards the time of setup. I had originally setup all clients to receive updates from our WSUS server and not allow them to go to the Windows Update site itself. Any clients added to the network post-WSUS setup did not have this policy attached to them, so they were free to visit/use the Windows Update site. Wierd, but it wasn't a huge deal (we're better off having that option available).
Hope that was somewhat helpful.
Hey!
I fixed this - at last.
The annoying part about this is the problem turned out to be the first thing I tested 2 weeks ago! Grrrr! Talk about two weeks wasted.
Anyway - in my case the problem was indeed Group Policies. I have a GPO that just deals with WSUS and that's it. It was this GPO that was causing the troubles. I didn't realise that the GPRESULT command has a switch (/Z) called Super Verbose mode - that gives loads of info about when and how the various policies are run. I wish I had known about the switch two weeks ago ( )because using it enabled me to see that the WSUS policy was all messed up and was setting verious settings hundreds of times (instead of once).
Glad thats sorted!
I fixed this - at last.
The annoying part about this is the problem turned out to be the first thing I tested 2 weeks ago! Grrrr! Talk about two weeks wasted.
Anyway - in my case the problem was indeed Group Policies. I have a GPO that just deals with WSUS and that's it. It was this GPO that was causing the troubles. I didn't realise that the GPRESULT command has a switch (/Z) called Super Verbose mode - that gives loads of info about when and how the various policies are run. I wish I had known about the switch two weeks ago ( )because using it enabled me to see that the WSUS policy was all messed up and was setting verious settings hundreds of times (instead of once).
Glad thats sorted!
