Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Perhaps one of the most frustrating issues to troubleshoot is a system that sits at the “Applying Computer Settings …” screen for what seems like forever before (eventually) getting to the point that you can log in. Interestingly, although several of these cases are routed to the Performance team as a perceived system hang, the fact of the matter is that the system really isn’t hung at all. In the overwhelming majority of the cases, the system is trying to complete an operation and is waiting for a response. With that having been said, the unfortunate reality is that there are literally hundreds of possible causes – but today, we’re going to go over a couple of them, and show you some quick troubleshooting shortcuts. So without further ado …
Before we get too deep into what’s going on with “Applying Computer Settings”, let’s take a quick look at the boot sequence for a client machine joined to an Active Directory domain that receives a dynamic IP Address:
Now, that’s the high level overview of the startup process. So where does the “Applying Computer Settings” piece come into play? Where you’re most likely to experience that issue is between steps 4 and 5. The system has located a Domain Controller, and is querying it for a list of group policies that should be applied.
Now that we know where the problem is occurring in our process, how can we best troubleshoot it? There are a couple of different approaches to take. Believe it or not, one of the quickest ways to isolate if the problem is occurring locally or caused by something requiring network resources is simply to unplug the network cable. By “breaking” the network connection, the network requests should time out nearly instantaneously and the logon process should continue. You could also use the MSCONFIG.EXE utility to temporarily prevent non-Microsoft services from starting up the next time the system boots. To do this, launch the System Configuration Utility, and on the Services tab, hide all non-Microsoft Services, and then select “Disable All”. When you reboot the system, if the problem does not recur, then you now have a much smaller list of potential culprits to troubleshoot.
The majority of instances that we tend to run into however, revolve around group policy processing. We wrote a couple of posts last year on Group Policies (see the links below), but the best way to really troubleshoot a problem like this is to enable USERENV logging and then review the log file. Each of the entries in the log file has a timestamp, so you will be able to tell if there are any processing delays or issues locating a specific Group Policy etc. Our Directory Services support team has plenty of experience looking at USERENV logs and troubleshooting issues where systems are stuck at “Applying Computer Settings”, so if you run into one of these situations that you just can’t quite seem to isolate – give us (well, the Directory Services guys) a call so we can help you get it resolved!
With that, another post comes to an end. Until next time …
- CC Hameed
Small Typo; Should read:
You could also use the MSCONFIG.EXE utility to temporarily prevent non-Microsoft services from starting up the next time the system boots. To do this, launch the System Configuration Utility, and on the Services tab, check "hide all Microsoft Services", and then select “Disable All”. When you reboot the system, if the problem does not recur, then you now have a much smaller list of potential culprits to troubleshoot.
Thanks Jason! I corrected it.
I had this happen quite a bit a couple years ago. Users were getting extremely frustrated. I FINALLY discovered that certain PCs weren't getting their DHCP IP addresses fast enough, so it would would just hang for 20-45 minutes (no lie) "Applying Computer Settings". Of course, GPOs were never applied either. Events were logged regarding not being able to get an IP from DHCP, so I eventually figured out what the problem was, but nothing online how to fix it.
In MY situation, the fix ended up being to enable "Portfast" on our Cisco switches for all affected ports. The network ports became active much faster, so during DORA the NIC was up and ready.
Glad to hear that you were able to identify the issue and resolve it. I wasn't aware of the "Portfast" issue myself, but it's good that the Event Log messages helped to point you in the right direction!
Thank you for sharing your experience - I'm sure that some of our other readers will be able to benefit from it.
Portfast is used on a Cisco switch to essentially disable Spanning Tree when the interface starts up. Without it, the interface is disabled for 50 seconds, assuming the default settings while the switch verifies it doesn't have a loop. Not sure how that 50 seconds delay translates into a 20 to 45 minute delay on startup, but apparently it did in this case.
Gotta be associated with the Nic starting while the interface was still down, causing Windows to hang while it waited for things to timeout, but sure seems excessive. Windows does like to chat, and lot of things like to phone home when the machines start up, so a nic being down could cause a lot of things to be hanging.
I m using Svr 2008 as a Vista Replacement & for learning processes
My sys takes about 50sec frm d win boot screen to desktop (autologin)
mostly wasting time at "Applying Computer Setings"
I tried ur suggestion of physically removing d cable &
voila! it takes 10 sec for d same thing
Plz can u point me out in right direction to proceed frm here
There's two ways to approach this, but they focus on slightly different causes.
The first is to run MSCONFIG and temporarily disable the non-Microsoft services from starting. If the problem is a service making network request, then you should see an improvement following the reboot. At that point, you'll need to do a bit of elimination work to determine which service is causing the issue.
The second method would be to enable USERENV logging and review the output to see if there is a GPO that is responsible for the delay - perhaps some sort of startup script, for example.
In addition, check the Event Logs for clues - Seth pointed out in an earlier comment that enabling PortFast resolved his issue. The teltale sign was the fact that systems weren't able to get an IP Address from DHCP.
If you're unable to pinpoint the cause, I'd definitely recommend opening up a support incident with us so we can assist you.
Hope this helps - and please let us know if you resolved the issue and what it was!
Hello, I'm trying to pinpoint some 'Applying Computer Settings' slowness but I think I'm stuck. I've gathered machines from all across the network, and as you can see they all have a signifcant delay before 'InitializePolicyProcessing'. What goes on before this? Any idea on how to find out, packet sniffers aren't showing much, and I'm 99% sure DNS is correct. Thanks
USERENV(16b0.16b4) 08:25:42:210 LibMain: Process Name: C:\WINDOWS\system32\wuauclt.exe
USERENV(4d4.4d8) 08:26:30:375 InitializePolicyProcessing: Initialised Machine Mutex/Events
USERENV(514.e8c) 13:23:33:300 MIDL_user_free enter
USERENV(518.51c) 13:25:10:885 InitializePolicyProcessing: Initialised Machine Mutex/Events
USERENV(1528.10e8) 07:51:28:102 LibMain: Process Name: C:\WINDOWS\system32\wuauclt.exe
USERENV(4fc.500) 07:52:17:421 InitializePolicyProcessing: Initialised Machine Mutex/Events
USERENV(3d4.910) 08:22:22:181 MIDL_user_free enter
USERENV(3d4.3d8) 08:23:09:468 InitializePolicyProcessing: Initialised Machine Mutex/Events
USERENV(5d4.a0c) 08:21:51:790 UnloadUserProfile: returning 1
USERENV(5ac.5b0) 08:23:09:122 InitializePolicyProcessing: Initialised Machine Mutex/Events
USERENV(1c0.d08) 18:54:18:157 LibMain: Process Name: C:\WINDOWS\system32\wuauclt.exe
USERENV(53c.540) 18:54:48:671 InitializePolicyProcessing: Initialised Machine Mutex/Events
USERENV(1080.10e0) 18:42:08:562 LibMain: Process Name: C:\WINDOWS\system32\wuauclt.exe
USERENV(53c.540) 18:42:36:437 InitializePolicyProcessing: Initialised Machine Mutex/Events
MMM, i'm a bit stuck here with this issue too.
We've had over 200 XP machines deployed in Germany where the German team had taken the default image, installed the German MUI on top of it and re sysprepped ti. No sweat.. wouldn't it be that they've applied 'German' to all Default users (Regional and Language options-> Advanced-> 'Default User account settings"
As a result, the domain workstartion startup scripts no longer function correctly. Some of them use the "Time/T" in a bat file and the English D for Day becomes T for Tag !!!
cut the long story short, the build in System account S-1-5-18 is set to German and i tried to set it to English with a registry fix.
That worked... but the machine takes 9 minutes now to get to the Control ALT Del instead of 1 min.
EventDebug shows 50 sec delays on some steps
There's clearly more involved than just this registry to set the language back correctly but i've not seen a tool that allows us to do it automatically, i 'm no fan of visiting all these machines again one by one
I'm having some similar issue and mine appears to be with reading the policy and it almost appears to be to many machines reading the policy at once or some machine is locking the policy. If I unplug the NIC on the machine that is freezing up, it will immediatly come up.
I found the fix is to Change the computer name and change it to Workgroup restart the PC then go to Change Computer name and then re-join the domain.
This fixes the problem
My fix was to remove the external USB hard drive. I believe it is corrupted or has hardware problems that prevented the computer from performing as it should have.
I removed it from server and plugged it into a Vista Ultimate laptop and had similar trouble.
I must have changed my computer settings...for the worst
I get a email.....the email opens find...can read it...but the document sent in the attachemnt ..opens in my notebook and is scrambled....please help
I have a MS 2003 Server running MS SBA. Hangs at "Applying Settings" unplug netowork cable and it goes right to login screen. Plug the cable in and I have full network access but no internet. All other systems on the network do have inernet access.
Was able to pull in off domain and put into workgroup. No internet access - full network access - Tried to re join domain - error message "Account not found" Scratching my head on this one?? Thoughts??
We have a slightly different variation of this issue. Two Windows 2003 servers, service pack 2. One is a sql server, one a file server. Both started exhibiting these symptoms a few days ago. What happens is the server will be functioning fine, if you're at the console you might be running a couple of tasks, after about 30 minutes or longer all of your applications start to slow down and eventually the whole desktop locks up. At this point the server is "locked up" and no one else can login. If they try to login it hangs at "applying settings" after they put their password in. The only fix is to power off the computer and back on. At that point everyone can login fine until it locks up again.
Hardware seems fine, there are no errors in the event log, you can still access the server remotely through mmcs. The sql database and other file functions still work fine.