What are Slow Logons and Where Do They Come From?
Considering the importance of fast logons for a good user experience there is surprisingly little information on the subject. Windows does not even record the total logon time, let alone where it is spent. Administrators wishing to analyze their users’ logons are left in the dark. But that can be changed.
What is in a Logon?
A logon is the act of preparing a session for a user. It consists of several phases, each of which can take between mere milliseconds and several minutes:
- Authentication
- User profile loading
- Group policy processing
- Logon script processing
- Shell startup
Common Problems
Authentication
A session can only be initiated after the user’s credentials have been verified. This typically happens by talking to an Active Directory domain controller over the network. Delays during this phase can typically be traced back to DNS issues, as can most AD problems.
User Profile Loading
Once the user is authenticated the operating system can start to build his session. First, a user profile is needed. All of the following phases require the user profile to be set up and the user’s registry hive to be loaded.
If the user does not already have a profile a new one is created. This slows down the initial logon quite a bit compared to subsequent logons. The main reason is that Active Setup runs the IE/Mail/Theme initialization routines.
Problems with the loading of user profiles are legendary; however, if this takes very long then probably a huge roaming profile needs to be copied over the network.
Group Policy Processing
Many corporations use Group Policy to manage their Windows PCs. Built on top of Active Directory, policies rely on the directory service’s infrastructure for their operation. As a consequence, DNS and AD issues may affect Group Policies severely. One could say that if an AD issue does not interfere with authentication at the very least it will hamper group policy processing.
Logon Script Processing
Although considered a legacy technology by some logon scripts are still used extensively so set up the user environment. Many logon scripts are ancient, dating back to the days of NT4. Administrators often are reluctant to change anything for fear of breaking the age-old construct, so they just add something new to the end. Always adding, never deleting – that cannot be good for performance, and consequently bloated logon scripts are a common cause for slow logons.
Shell Startup
During the last logon phase the user shell, typically Explorer.exe, is initialized. Loading Explorer itself is typically fast, but a large number of autoruns can make this phase seem to stretch forever.
Measuring Logon Performance
As mentioned earlier Windows does not have any counters for measuring logon performance. Administrators wishing to analyze slow logons need to bring in additional tools. Among the most helpful for troubleshooting individual logons are Sysinternals Process Monitor and the Windows Performance Toolkit (WPT, containing the xperf tools). Both work in a similar way: the administrator starts a tracing session, tries to reproduce the problem by logging on, stops the trace, and then goes to work sifting through the trace looking for cues – a very time-consuming process that requires skilled personnel and is only performed when the pressure is already high.
Would it not be great to have the total duration of every single logon, optionally broken down into phases? That way it would be a snap to spot trends and see the effects of GPO changes. Today’s slow logons could be traced to yesterday’s failed domain controller or last week’s logon script change.
uberAgent gives you all that. It has averages:
It shows trends, giving you the big picture:
And it displays as much detail as you could possibly want:
