Diagnosing Logon Delays

In this column, I discuss diagnosing and solving logon delays caused by three specific problems. I use the term logon delay to include the time it takes for the logon screen to disappear after you enter valid credentials, plus the time it takes for a Windows XP or Windows 2000 system to display the desktop after the logon box disappears. Logon delays can occur in three situations: when you log on interactively at a workstation or server, when you connect to a VPN server, and when you connect to resources on a standalone server that requires local credentials, rather than domain credentials. Profile problems are also a common source of logon delays, but they’re complicated and outside the scope of this discussion—a large profile or an inaccessible or corrupt profile can appear to hang a system or result in an empty desktop after a delay of 10 minutes or more.
Incorrect or empty DNS server address. The most common cause of a logon delay in a Win2K domain is an undefined or invalid TCP/IP address for the network DNS sever. The symptom for this problem is the familiar hourglass cursor hanging over the Welcome screen. When the hourglass appears, you might see the status message preparing network connections in the lower portion of the Welcome screen. When the local machine has no TCP/IP address for a DNS server or the address is invalid, the system might be unable to locate a domain controller (DC). When the local machine has a valid DNS server address, the address might point to a DNS server on the Internet or to a server across a slow WAN link. In both of these situations, the logon delay is caused by the forwarding and routing of a name-resolution request on a less than optimal path. For example, if the DNS name-resolution request goes to an ISP’s name server, the request must find a name server that knows the address of the DNS server on the internal network. To check the TCP/IP settings for a connection that's experiencing delays, simply open a command prompt and type the command

ipconfig/all

If you use the Ipconfig command without the /all parameter, the command displays a subset of TCP/IP information for the primary network adapter but not for multiple network adapters and active VPN connections. If the local machine is on a network and has only one network adapter, Ipconfig/all displays configuration information in two sections. The first group contains the machine’s DNS host name and DNS domain name (suffix); the WINS node type, whether or not routing is enabled (it's usually not enabled on a standard workstation or server); the WINS proxy address (typically blank); and a DNS domain search list, which might also be blank. On a standard workstation, the second section contains the TCP/IP configuration data for the network adapter. If a system has multiple adapters or active VPN connections, you’ll see multiple TCP/IP configuration groups, one for each network adapter and one for each VPN connection. If the DNS address is correct, you can use the Nslookup command to verify that the DNS server is online and accepting name-resolution requests. When Nslookup starts, it contacts the DNS server defined for the primary network adapter. If you have a multihomed system, the primary adapter is the first network card in the binding order. To view the bindings, click Start, Settings, Network and Dialup Connections, then select the Advanced menu and click Advanced Options. If the DNS server is online and available, Nslookup displays the DNS name and address for the server. If Nslookup can't contact the DNS server, you’ll see the name and address of the server, followed by a timeout message that indicates the server didn't respond in a timely manner.
Images created with Sysprep. If you use Sysprep to create Win2K images, a bug in the utility forces a Win2K workstation (and potentially an XP system) to download the full Group Policy Object (GPO) each time you log on to a Win2K domain. Under ordinary circumstances, a system downloads the GPO only when the policy has been modified. A logon delay can occur when a system downloads nested GPOs—in many cases, the policy refresh can take several minutes. The registry subkey below defines the maximum number of minutes a system should wait before downloading the full GPO. Sysprep incorrectly sets this value to 1 minute, which forces the system to reload the GPO at every logon. To correct this problem, start a registry editor and navigate to the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonGPExtensions\{GUID} subkey. Locate the value entry MaxNoGPOListChangesInterval, of type REG_DWORD. (Note: On my test system, the correct globally unique identifier—GUID—was the fifth key below GPExtensions. You might have to examine several of the subkeys to locate the MaxNoGPOListChangesInterval value entry.) If the value of this entry is 1, the system is a victim of the Sysprep bug. To restore typical operation, change MaxNoGPOListChangesInterval to the default value of 960 minutes—the equivalent hexadecimal value is 0x3C0. This change should eliminate logon delays that an unnecessary GPO refresh causes.
XP system bug. If you use a complex set of GPOs to govern your organization, a bug in XP and XP Service Pack 1 (SP1) systems can cause a system to hang after you enter valid credentials. If this is the cause of the logon delay, the system appears unresponsive when the Applying your personal settings message appears in the logon screen. Microsoft has a bug fix for this problem—a new version of userenv.dll, with a file release date of November 14, 2002. The fix is available only from Microsoft Product Support Services (PSS). When you talk to the support people, cite the Microsoft article "Computer Seems to Hang When You Log On" (http://support.microsoft.com/?kbid=329457).

Diagnostic Techniques
In addition to the Ipconfig/all and Nslookup commands, you can use two diagnostic techniques to troubleshoot the source of logon delays. Both techniques require that you modify the registry.
Verbose logon and logoff messages. Start by enabling the verbose message option for startup, shutdown, logon, and logoff activities. To enable this feature, start a registry editor and navigate to the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem subkey. Add a new value entry called VerboseStatus, of type REG_DWORD, with a value of 1. Log off, then log back on and search for clues in the additional messages in the System and Application event logs. The additional messages might help you identify the source of the problem. Remember to disable verbose mode before you return the system to production (simply delete the VerboseStatus value entry).
User environment debugging. User environment logging usually produces more valuable information, especially if the delay is related to GPO application. Using a registry editor, locate the HKEY_LOCAL_MACHINESOFTWARE MicrosoftWindows NTCurrentVersionWinlogon subkey. Add a new value entry called UserEnvDebugLevel of type REG_DWORD, and give the entry a hex value of 10002 (0x00010002). This setting instructs the OS to write verbose messages for startup, shutdown, logon, and logoff activities to the log file %systemroot%debugusermodeuserenv.log file. If you want to fine-tune the debugging messages, you can set the value of UserEnvDebugLevel to any combination of these values:

NONE 0x00000000
NORMAL 0x00000001
VERBOSE 0x00000002
LOGFILE 0x00010000
DEBUGGER 0x00020000

When you set the value to 10002, you instruct the OS to write verbose messages to the log. The default value of this value entry is NORMAL|LOGFILE (0x00010001). Log off and back on and check the log file; don’t let the amount of data you see overwhelm you—it’s easy to sift through the messages and locate the source of the problem. When you’re finished, you can either reset this value to zero or delete the UserEnvDebugLevel item.