Our help desk is constantly getting complaints that it takes several minutes from the time the user logs in to the time they get to their desktop.  This also happens on my workstation. 

I have tried moving my computer into a OU with no policies applied and it still takes a long time.  I enabled logging and have done a packet capture.  I do not see any errors in the event log or in the userenv.log file.  Using sysprosoft's Policy Log Viewer to view my userenv.log file, I can see that policy processing starts out normal.  In the first fraction of a second, it performs the ping to the server, and determines that it is a fast link.  The next entry occurs 86 seconds later, and it identifies "network name is example.domain.com".  The domain controller it's contacting is in the same domain and site as my workstation. 

During this logging process, I was performing a packet capture, and do not see anything unusual going on, like DHCP still trying to acquire an address or any communication to one of our other sites. 

As another test, I assigned my workstation a static IP address with DNS pointing to our internal DNS servers.  I still get the long delay.

Roaming profiles are not involved, and our clients recieve IP addressing from DHCP with DNS pointing to internal DNS servers.  Our Domain Controllers point to internal DNS servers as well.

This issue seems to have started sometime after SP3 was deployed.  Management has sprung for a load of new computers, thinking it's going to solve the slowdown, but it does not.  Any ideas as to why computer policy takes so long to process? 

Thanks,
Joel

Oh, the client OS is Windows XP SP3 and the server OS is Windows 2003 SP2.  I notice a delay logging into Windows 7 as well, but I'm much more comfortable troubleshooting this in XP, so as not to confuse matters.  We have a parent domain and 5 child domains.  The workstations point to their child domain DNS servers for DNS.

This issue seems to point into a couple directions, if you are sure that your network core is solid, I would start looking at your dns servers followed by your GC's.  If policy processing takes a long time it may point to either one of these.  You will need to provide additional info to troubleshoot.

You may also take a look at your GPO settings to make sure you're not putting out Computer Setting only GPO without having the user side disabled or vice/versa...this could also be a cause.  I would also look at whether you are distributing applications via GPO as well.

I just tired issueing a static IP address, with the same result.  Then, I reversed the DNS server addresses and login took 5 seconds!  In the userenv.log file, the glaring difference I see is after it performs the ping to determine if it's processing over a fast or slow link, the next line is "network name is".  Where this occurs after a long pause, it shows the fully qualified domain name, (such as, child.parent.com).  In the instance where the login was quick, the network name is the IP address of the local network (such as 172.16.0.0). 

Our DNS servers are our domain controllers.  DNS is AD integrated and replicates with eachother.  So, where would I find where this is pulling the network name?  It should be identicle on both DNS servers, but apparently not.

Ok, that isn't the indicator.  It all depends on which DC is applies the GPO from.  If it goes to our PDC, it takes a long time.  If it applies from our backup, it's speedy. 

Joe,

As a quick test, if you get a slow logon after booting, see what information the following steps yield:

1. Open a command prompt,
2. Run dfsutil /pktinfo,
3. Verify that for each of the DFS namespaces - particularly the domain DFS replica (contains the word SYSVOL in it).

The values (servers) marked as being active should all be the local, or designated values for that site. If they aren't, then you may well be suffering subnet association issues, or even incorrect DC selection on account of the site replication costs all being the same (though there's other issues to troubleshoot if this is the case).

By way of cross-referrencing the information from above, run a "gpresult /r /scope computer" and make sure that "Site Name" has a value next to it.

Cheers,
Lain

From what I can tell, DNS looks ok.  All of our DC's are GC's.  Is there something specific to GC I should be looking at? 

Most of our workstations are still in the Computers container, so policy is applied at the domain level.  There aren't a whole lot of settings/tweaks in there and both computer and user policies are enabled.  Also, we do not deploy software via group policy. 

dfsutil /pktinfo displays all the DC's to the domain, as well as their sysvol folder.  The active DC is in the same site as the workstation. 

gpresult displays the same site.  Is there a problem with having the site name the same as the domain name?  In our case, our domain names are the location of our offices and the site name therefore is the same.  Is it normal to show the Domain Type as 2000?  Our AD forest is 2003.

Joel

No, there's not problem with the site name having the same name (I'm assuming you're talking about the NETBIOS name). For example, having a site named CONTOSO and a domain with the NETBIOS name of CONTOSO is not a problem.

So when you checked these results, it was after a slow logon with the failed application of computer policy?

Cheers,
Lain

Yes, I ran the two commands after a slow login.  This morning, login took 112 seconds.  I ran the two commands again this morning and the sysvol is in my site and gpresult shows the correct site. 

From the dfsutil results, I see the 3 DC's in my domain and this morning, the first shows "(  active targetset  )", the second just shows "(  )" and the third shows "(  targetset  )" - the third one is not in the same site. 

This mornings slow boot up shows .047 seconds to determine it's a "fast link.  Exiting.", then 91.730 seconds to "network name is 172.16.0.0" and then 112.775 seconds to "user name is:".  Yesterday, the time between network name is and user name is was milliseconds difference. 

Thanks,
Joel

Ok, disabling the Background Intelligent Transfer Service speeds login up to what I would consider normal.  I know it isn't recommended to disable this service, but why would this all but stop the processing of computer policy?  Anyone know of a way to correct this?

Note from Windows Server Moderator:

If you are having this issue on Windows Server 2008, but not 2008 R2, please go to the following KB for a hot fix and/or workaround:

KB 2379016 provides a hotfix to resolve this issue on a computer that is running Windows Vista and Windows Server 2008. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

KB 2379016  A computer that is running Windows Vista or Windows Server 2008 stops responding at the "Applying User Settings" stage of the logon process

Hi, Joe.

If you're absolutely certain this is the consistent cause of your issue, then it's a good start. There are three commands that may be of interest to you in determining what state BITS is in:

Viewing the BITS job queue:
bitsadmin /list /allusers /verbose

Cancelling all of the jobs in the queue:
bitsadmin /reset /allusers

and finally, an option that exists on the Windows 7 version that I don't recall from my XP days, but I'll list it anyway in case it came in with a service update;
Repairing the BITS service:
bitsadmin /util /repairservice /force

Bitsadmin is included natively on Windows 7 (I can't remember for Vista) but not so for Windows XP - at least not XP RTM, from what I remember. It's been so long since I ran XP, I can't remember if it came with a service pack, as I'm moderately sure I got it from either the Support Tools or Resource Kit.

Getting back on topic, BITS also has group policy settings that you may want to inspect, at least in terms of possibly setting transfer rate threshholds. You can find these settings under Computer Configuration > Administrative Templates > Network > Background Intelligent Transfer Service.

Cheers,
Lain

• Marked as answer by Wilson Jia Wednesday, February 17, 2010 2:06 AM
• Edited by Kevin Beares - MSFTMicrosoft employee, Owner Monday, January 31, 2011 10:39 PM New Information pertaining to error string
• Edited by Tod EdwardsModerator Monday, February 14, 2011 11:21 PM Updating KB link

Thanks for the tip on BITS.  I ran the command and it said "success - the bits service is functioning normally".  There aren't any jobs queued. 

Still a slow boot.  When comparing the machine policy log with the even log, I can see that around the same time, GP has determined a fast link.  A few moments later, the event being logged in the system log is a W32Time event.  Then, over a minute later, the next item in the policy logging is "network name is" and at around the same time in the event log, is event 7035 "The BITS service was successfully sent a start control".  What is going on during the boot process between the time NTP gets the time and BITS starts?  We are considering disabling the BITS service, then using a script, enabling the service and starting it after the desktop loads.  Once the desktop loads, starting the BITS service shows no sign of slowdown, but it is definitely slowing down login process if it's allowed to start.  I would much rather get this fixed than writing some workaround script to make it speedy.

Joel

To be honest, if BITS is struggling, it sounds a little more like it's struggling as a result of something else, not actually being the cause itself. Certainly, disabling it is a workaround, but I get the feeling it's not the root cause of the computer's performance troubles, and I wonder what other issues may manifest over time as a result.

Cheers,
Lain

Hello
I have a similiar problem with Windows 7 Enterprise and a windows 2003 R2.
After join the Windows 7 to my domain, the startup until Press CTRL+ALT+Del and after that to the desktop it goes about 10 minutes...
Here's an example:
server1: Server name: name1 Domain controller: thisis.example.com DNS controller IP addresses: 10.0.0.3      10.0.3.3      10.0.10.3                      10.0.9.3                      192.168.100.3                      192.168.101.3 Server2: server name: name2 Domain Controller: Thisis.example.com DNS controller IP addresses: 10.0.0.11        10.0.3.11                      10.0.9.11                      10.0.10.11                      192.168.100.11                      192.168.101.11                      192.168.102.11
Can you give a help with thos slow login process issue?
Thanks in advanced

I wish I could give you the magical answer.  I still haven't gotten resolution to this.  We tried running a shutdown script to disable the BITS service, then a startup script to enable and start it.  I'm hearing mixed results.

This is what's in the shutdown script:
sc config bits start= disabled

This is what's in the startup script:
sc config bits start= auto
sc start bits

BITS is necessary.  Without it, you won't be able to go to Windows Updates, though Automatic Updates still pull down updates and apply them.

Joel

Hello
I have a similiar problem with Windows 7 Enterprise and a windows 2003 R2.
After join the Windows 7 to my domain, the startup until Press CTRL+ALT+Del and after that to the desktop it goes about 10 minutes...
Here's an example:
server1: Server name: name1 Domain controller: thisis.example.com DNS controller IP addresses: 10.0.0.3      10.0.3.3      10.0.10.3                      10.0.9.3                      192.168.100.3                      192.168.101.3 Server2: server name: name2 Domain Controller: Thisis.example.com DNS controller IP addresses: 10.0.0.11        10.0.3.11                      10.0.9.11                      10.0.10.11                      192.168.100.11                      192.168.101.11                      192.168.102.11
Can you give a help with thos slow login process issue?
Thanks in advanced

onde mor piece of information.
With this scenario all my XP computers run very well, only the seven computers takes too long to login into domain, either domain admins or users...

I have similar or same problem as Ismail -- Win2003 SBS, one server, DC, DNS, DHCP, everything fine for 6 years with XP Pro SP3 clients.  Now two of three workstations have upgraded to Win7 Pro.  Both new workstations have identical hardware and clean Win7 x64 installations.  One PC boots from power-off to a domain-logged-in desktop in under a minute.  The other PC takes at least 2 minutes to show C-A-D logon prompt, and then a staggering 5-7 minutes (apparently doing nothing) to move past the logon prompt.
Does the DisableTaskOffload = 1 registry setting have effect in Win7 like WinXP?  I tried disabling BITS altogether just to see if it helped, and it did not.  Upon finally reaching the desktop and immediately opening Task Manager, it shows 7 minutes of idle CPU time per processor.  That's a long bootup and apparently Windows is aware of it.

All,

I have a similar problem with my SBS 2008 Domain Controller. It takes forever to "Apply Computer settings..." during the initial login (sometimes 30 minutes). I think this has something to do with GPO but after disabling it, it still takes forever.

Is this normal since AD is installed on this machine?

Thank you,

RetiredScriptingGuy

Hi,

30 minutes isn't normal for any version of Windows under a normal configuration, so something's likely amiss. The group policy client shouldn't take that long at all even over a slow link unless you're forcing the application of certain policy elements over a slow link (the settings for which you can find under Computer > Administrative Templates > System > Group Policy). That said, I doubt you would have tinkered with these settings.

What you might get more value out of is verifying your server's health and configuration with dcdiag. In particular the DNS tests (the /test:dns switch) are important for the domain controller to pass. Also on DNS, make sure you have created the reverse lookup zone and that the domain controller has registered its A record in there.

Cheers,
Lain

Better late than never.

I had a similar problem and found that

With a Windows 2003 Domain and WIndows 7 clients - the Win 7 clients attempt to make everything offline, as in user home directories and certain other directories.

Once I disabled all of this "Syncing" in Sync centre - voila login time = normal.

Hope this helps.

 

 

In a large majority of cases, the root cause is a few highly fragmented files in your hard drive. When a file is stored in many pieces, at boot time , the system takes time to find and and arrange them , so that they can be made ready for use. Here are steps to rectify the situation: Some degree of comfort level with using tools on a computer is required,- so seek help from the local geek for following instructions given below, if you wish.

0. You need to have 'administrator' privelege or log in as administrator to do below steps. Also, it is desirable that at least 25-30% of your hard drive is free space.

1. Defragment your hard drive. Control panel => all programs => accessories => system/ system tools => disk defragmenter. Please ensure that there are no other programs running when this is in progress (can be 15 min to 2 hours), not even email. If your system is windows XP or earlier, at the end of the defrag session, do a 'view report' and then save the report in a folder of your choice. Go to the saved file and observe, at the last section of the file, the names and locations of files that have many fragments. These are the culprits. Do NOT delete these fragmented files even if you think you don't need them. If you did not create those files, they are likely to be very important files that the system uses, unseen to you. The right thing to do is to make them less fragmented, - so proceed to step 2.

2. Step 1 will not solve the problem, it just prepares the ground.

You will need to download a program by the name "contig" from microsoft-approved site. It is free. Go to http://social.technet.microsoft.com and give search for 'contig'. OR, you can directly use http://technet.microsoft.com/en-us/sysinternals/bb897428.aspx, if the link is functioning. If you desire to know why and how contig works, read the information given in the same page. Download the zip file and unzip it in a folder of your choice. Do not download from sites not approved by microsoft, you may download something undesirable. The procedure you are doing is equivalent of a surgical procedure, so use only certified doctors' tools!

3. Bring up the command prompt, or the black DOS prompt shell screen. Start => all programs => accessories => command prompt {if not logged in as administrator, but having admin priveleges, right click on command prompt and choose 'run as administrator'}.

4. From windows explorer, drag the contig file from the folder you kept it, on to the command prompt and press enter. It takes a bit of practice so that the DOS prompt window does not run away, such that you can place the link of the contig file on the prompt. You will see the usage modes of the contig program displayed on the screen. Do not dismiss the command prompt shell now, just 'minimize' it.

5. Now, in explorer, go to the folder where the culprit files are kept. You will get the location from the file you saved in step 1.

5A. Bring up the command prompt shell, and by using the 'up' arrow, get the previous command. Type -v beside that, with space on either side.

5B. From explorer drag the first of the culprit files on to the command prompt shell, such that it appears as "c:\..." etc beside the -v (and space). now press enter. If you have done the dragging and dropping right, you will see contig is doing something. Please wait till the process finishes, do not use the computer for any other task in the mean time. This may take a few minutes- please be patient. [Advanced user may use contig -q for quiet mode].

6. You will know that the task is complete when the dos prompt returns. Repeat above procedure for all the culprit files.

7. This should solve the problem in a large majority of the case.

8. If the culprit list of step 1 says somewhere that pagefile has more than 5 fragments, an addtional procedure is necessary. Pagefile is something that is always in use by the system, so a different method is required. Download page defrag tool from http://social.technet.microsoft.com/Search/en-US?query=page%20defrag&ac=1. See information given in the page.

9. Unzip the pagedefrag zip file in a folder of your choice. Double click the exe to run it. When a screen comes with 3 radio button options, select to page defrag at next boot. Log off and shut down the machine and then restart. This time you will see a blue screen informing you page defrag is working. Be patient and let the process complete.

10. Once above completes and you can log in, go and run de-fragment again , as in step 1.

11. Thereafter, shut down and restart and enjoy your now faster machine.

12. If you are using windows vista you will not have access to the nice defragment report of step 1 that helped you identify the culprits in the first place. In such a case , you will have to physically find the files that are fragmented, and it is not easy. What I do is, I give a search for all files greater than 500 mb and contig them one by one. Or they can be placed in a folder and you can ask contig to defragment them all at one go. Do this only for user-owned files though. For files under c:\windows and other system / application software files, do not shift files. Just ask contig to recursively defragment files it finds in the folder in-situ.

13. Following files are the usual culprits in terms of getting fragmented : Video files, image files, large zip files, lotus notes .nsf files etc.

14. I take no liability if any loss is incurred in doing above steps. I am sharing what worked for me.

Regards

SSC

Calcutta, India.

 

 

 

 

Applying Computer Settings takes several minutes for many domain users or small domain users is normally a DNS issue. Either on the local workstation or the DNS server. One good thing to do is use the dos command "ipconfig /flushdns" on the Windows XP workstation.

Sam

Try disable a service called 'Network Location Awareness' on the client PC's then test the login times.

Very lately; but faced with the same problem, not on a client but on the server running an application with windows server 200 R2, 

You mentioned "If you are having this issue on Windows Server 2008, but not 2008 R2, please go to the following KB for a hot fix and/or workaround:"

What should be done on 2008 R2?

Many thanks in advance

Have you checked that there aren't any very large cached files in users profiles (temp/ie cache/firefox cache/etc/etc)  ?

I have seen this before with server 2003; domain level login acts funny and its due to user's profile cache being larger than it should be (in my case it was around 500MB). Removing this and relogging in as that user fixed this problem immediately for me. Hopefully it's something as simple as that ? Good luck.

Regards,

Beau

For what it's worth, I was having this same issue on ONE workstation on my SBS 2011 AD Network. I recently started working here, and was reverse engineering some work the past admin had done.

Apparently, on this machine, he was also applying a local GPO to run login scripts on a server that no longer existed.  Once I removed the local login and logoff scripts, my problem went away.

I am having a similar problem on many of my computers.  Everything was working fine then over a period of 2 weeks more and more users are reporting slow logon times.  The computers sits at 'applying computer settings' for anything between 3 and 16 minutes.  If I break the network link during this delay the PC will immediately boot to a desktop so it has to be some sort of delay in interacting with our domain.... still scratching my head !