So you have a slow logon…? (Part 2)

So you have a slow logon…? (Part 2)

  • Comments 7
  • Likes

Bob Drake again and welcome back for the second part of the slow logon series. In this next part I want to dive into some simple troubleshooting techniques to assist you in isolating the cause of your slow logon.

Click here for part 1!

To dissect where it is slow is not that difficult to tackle….

  • Is it slow from when you hit the power button to the point where you get to the login screen?
  • Is it quick to get to the login screen but then hangs for a while to get to the desktop?
  • Is it all users, and not administrators?
  • All the above

Troubleshooting will be dictated by the answers to those questions. We will start off with a slow boot that occurs when the power button is hit and it takes forever to get to the logon screen (even though a slow boot is NOT a slow logon). If the slowness occurs when the machine first boots up before you get to the login splash screen, then typically there is either an issue with the core OS, the applications installed, or a combination of both. A great place to start troubleshooting is to enable verbose startup, shutdown, logon and logoff messages (providing the operating system is XP or higher) according to KB 325376. With this enabled you will receive additional information during the boot/login process:

Policy location (XP and 2003)

image

View of additional messages (XP and 2003)

image

image

image

Policy location (Windows 7, Windows 2008)

image

View of additional messages (Windows 7, Windows 2008)

image

image

image

image

image

 

 

 

 

 

 

 

 

 

image

The first thing that should be determined is if the delay happens when the machine is “clean booted (Windows XP/2003)(Vista/2008/Win7)”. With MSCONFIG you can selectively disable all third party services and applications from loading. Now before the bashing begins here about the necessity of the applications that are on the machine, this step is quite essential to know if the OS is the issue or the applications that are installed on the OS. Here is how it’s done:

1. Click Start then Run and type “MSCONFIG”

image

2.  Select the “Services” tab as displayed and check the “Hide all Microsoft Services” and click “Disable All”.

NOTE: When you “Hide all Microsoft Services” you will see the applications that are installed on the system. Often times there are applications that are crucial to the boot/logon process (like drive encryption software) which will cause the machine even more problems. You will need to review the applications and disable what you can (more the better).

Select the “Startup” tab and click “Disable All” once again. If you find disabling all the third party applications causes a bigger issue you can press F8 at startup and select “Last Known Good” or “Safe mode” to back out the changes to “msconfig”.

image

3. Once the third party services are disabled you will need to reboot (a window will appear stating you need to reboot. Once the machine comes back up another window will appear when you logon, just click “OK”).

4. Test and see if the boot time is the same or not.

When you disabled the third party services did the computer boot and logon faster or normally? If the answer is yes then you have a conflicting piece of software on the machine that is causing the delay. To find out which one can be a little more laborious but the quickest way will be to enable half the services (making sure to list which ones you are enabling) and see if the delay comes back. If not, repeat process by enabling half of the other services you haven’t tried yet until you get issue to return. Once you identify which one it is, try updating that application or components. You may also take a quicker approach if you believe that one particular application is the issue (due to a recent install) and simply disable that one only for confirmation. You will have to reboot several times during this process to be confident that you have discovered the cause. When you believe you have discovered the application causing the delay, re-enable it and see if the delay comes back just to be sure.

Once you identify the application with the issue call the vendor and explain why it has been pinpointed as the issue and seek guidance from them. Often times there are updates or hotfixes that will resolve the conflict.

NOTE: Some antivirus applications will still load filter level drivers even though their services are disabled from starting with MSCONFIG. The only way to truly rule out antivirus as a possible contributor to a slow logon is to uninstall it during the test.

So it’s still slow!?!

If the boot up is still slow check your client DNS configuration. DNS servers along with other hardware (like switches, routers) could also be the source of the problem. If you find that one section of your network is having the issue but other portions don’t, there is a good chance that you may have some network issues. A good way to determine network and DNS type issues is to take a network trace using a packet capture application like Netmon . The hard thing to do is capture a trace when the machine is starting up. This can be accomplished by monitoring the computer with another computer that is plugged in to the same hub or switch (port mirroring). You enable the network capture utility from one and filter for the other’s IP address.

Things to look for in the traces are the following:

  • Valid DNS responses (does the query response match what was queried for?)
  • Delayed or unanswered responses (both from the DNS servers to domain controllers)
  • Kerberos failures
  • SMB failures
  • Numerous TCP resets or retransmits
  • A specific Domain Controller consistently used when the issue happens (possible issue with the Domain Controller itself)

If there are any network related issues you should see them stand out without having to be a master at reading traces.

If you have disabled all the third party software using the above method and still find that you have a lengthy boot process, then the next step is to look at what policies are being applied to the machine. A great place to start troubleshooting group policies is the technical reference.

In most environments there will be numerous policies applied, so how do you rule them out as being an issue? The quickest method is to create a new “TEST” organization unit (OU) in the Active Directory Users and Computers snap-in and block policy inheritance to the OU. Once this is done, you can move the problem computer to that OU. Verify that there are no policies being “enforced” or set to “no override”. If there are polices with those settings, they will still be applied to an OU where policy inheritance is blocked.

Before you move the computer you should run the following command to find out exactly what group policy objects are linked to it:

 

image

When you open the “gp.txt” you can view the policies as shown:

image

image

You can see that the only policies that are applied to the machine are the “Default Domain Policy” and “Local Group Policy” (The above snip was shortened here to show user and computer).

Once you have the policies identified you can move forward with creating the test OU. Here is a step by step on creating the OU and blocking the inheritance:

1. Create a “Test” OU and move the computer account to it.

 

 

image

2. Open the Group Policy Management Console and block inheritance to the TEST OU.

image

Note: You will know that you are blocking inheritance when the OU icon has a blue exclamation as seen:

image

3. Once you have inheritance blocked and the computer moved to the OU, reboot the computer at least two times to clear the previously set policies.

There are times where you cannot remove all policies if they are enforced. At least you will have a short subset of policies at this time. Time to test again…

If the computer boots fast now then you have a group policy (or combination of policies) that ARE causing the delay. To find which policy is causing the issue you will need to link them one at a time rebooting in between and monitor when the delay occurs again. This is done by selecting the “Link an Existing GPO” as seen in above picture. Once you have the policy identified a thorough audit should be done to determine which setting in the policy is causing the delay.

So it’s still slow…!?!

If you have gone through the above steps and were not able to find why the boot up is slow and you were not able to disable all software or policies then the next step to do is enable debug logging. There are a few ways to enable logging depending on which operating system you are using.

For 2000, XP, 2003 you can enable logging by following the article: “How to enable user environment debug logging in retail builds of Windows “http://support.microsoft.com/default.aspx/kb/221833. Lucky for me one of my co-workers has already written a blog on how to interpret the output (find more in his two part section: Section 1 Section 2). For Vista, 2008 and Windows 7 Microsoft has changed the debug logging format to what is called “Event Tracing”. Basically the data output is the same as the output from the above KB article once it is converted from the binary output. You will need Microsoft’s assistance with converting these files since they contain source code (to view the policy portion without the profile use gpsvcdebug logging).

Another great tool to use is “Autoruns”. This utility will show you programs that are configured to run during system start or during login. One of the best features of this tool is the “Hide Microsoft Entries”:

image

It also allows you to select the autoruns per user as seen:

image

Autoruns may also find items not normally seen with other applications.

To wrap it up, most of the time a slow boot or slow logon happens there is a conflict with an application, restrictive group policy or configuration issue. With the above troubleshooting and a little homework you will be able to identify where and why you have a slow logon and be able to resolve it in minimal time.

More reading here!

- Bob ‘Quasi-Manager’ Drake

  • Bob,

    First off, thank you for this excellent outline in your Part 1 and 2 articles.

    I have been assigned to troubleshoot slow logon in our domain, mostly with our laptop users but I am first attempting to take it to the next level and insure we are approaching the issue from a baseline standpoint.

    95% of our workstation OS client base is XP SP3 and while we do deploy using imaging, I am currently at a point of testing with a fresh manually built XP SP3 installation, no user or computer group policy, no computer or user group memberships, no logon scripts, no drive encryption software, and no additional applications loaded in the OS.

    Currently, I am at the point where I am attempting to determine why enabling a Home Folder for a user account increases the logon time by 30 seconds.  If I remove the Home Folder mapping in AD, the logon process completes anywherer from 2 to 5 seconds.  Once I enable the Home Folder for the user account I am testing with, the logon to a usable desktop takes approx. 30-35 seconds.  I have tried NetMon from another workstation, ProcMon boot logging, and all the windows debug logging but I have yet to determine exactly why the additional 30 second delay occurs.  I havent been able to find any documentation outlining why the delay occurs.

    Once I can determine whether or not this is "normal" I can continue with trying to determine our baseline by enabling our standard group policies, drive encryption software, standard group memberships and our standard enterprise applications.

    Thank you in advance for any assistance you can provide.  I have attempted to post this question in several other forums but I don't ever geta a solid response.  I have been working on this too long to give up now but I am nearing the breaking point.

    Thank you,

    Moe

  • Hey Geemail....

    If you were to bust open that network trace and dig a little deeper do you see "DLL's" being referenced accross the network?  If so, then the section from part 1 will apply:

    " If home folders are needed with roaming profiles there is a registry key tweak (SafeDllSearchMode) that can be added that will change the behavior. If you’re not sure that this is an issue in your environment, take a network trace at logon and see if DLL’s are being queried across the network to the home folder. There is also another tweak on the same page (StartRunNoHOMEPATH) that will assist with applications doing this behavior."

    Hope that helps..

    Bob Drake

  • Bob,

    Thank you for the reply.  

    In my testing environment, I do not have roaming profiles enabled.  We do however have some production scenarios in which we do have home folders with romaing profiles and this information will be beneficial for those cases.

    Am I understanding your point correctly or can enabling a home folder for a user account without a roaming profile also fall subject to the above mentioned behavior?

    Thanks,

    Moe

  • Hey Moe,

    I was out of town but now Im back....your correct.  If you are using home folders there is a chance that you are experiencing searches to those directories by the applications.

    To be sure, check those network traces for DLL's being searched on the home folder path.

    Bob Drake

  • Thanks Bob....i understand your point, but the only gotcha was that I did not have any additional applications or policies enabled for user or computer account.  Literally an XP workstation joined to the domain and logging in with a home folder enabled.  That was why I was so confused...I would not have expected such a delay.

  • Thanks for the informative blog.  I have found that Superfetch/Readyboot could be your best friend, or your worst enemy.  Disable it and it takes 45 seconds to login.  Turn it on and it takes 2 minutes to login.  But after 6 logins/reboots the login goes down to 20 seconds.  But how do you automate that?  Plus, in education you usually have the environment of Deepfreeze and Pgina, where every login is a 'new user', and on logout the machine is rebooted and the whole computer configuration is reset.