Jump to content

[Question] - Diagnose: eXtreme delays when (Win XP) log on to a domain


shamshasan

Recommended Posts

I have a problem addressed by MS whitepaper: 832161 - "You experience a delay when you use your Windows XP computer to log on to a domain or to connect to a network resource" [Note: OS: XP Pro SP2]

Wanted to thoroughly understand the details before i venture into exhaustive dianostics to the problem (intention being i don't have to diagnose *all* the possible causes mentioned). Appreciate everyone's help.

These questions are in the context of the problem & symptoms mentioned in the paper and i'd appreciate answers within that realm too.

"If the destination server does not support HTTP on TCP port 80, or if the destination server is offline, the proxy server may not send the expected HTTP error code back to the WebClient."
I understand that this can be a 'cause' of delay? However, an 'error' message isn't received. What would happen here then?
"The Network Provider Order lists Web Client Network before it lists Microsoft Windows Network."
So that would be an misplacement. Why do we have to place them in that particular order? Ok so this causes a delay, why? What *actually* happens (so the technical part) when you order them improperly?
"The domain controller that is used for authentication runs a service that listens on TCP port 80. For example, the domain controller is also an Exchange server with Outlook Web Access (OWA)."
Why/How is this a problem? What are the technicalities involved that make this a problem?
"The PATH statement variable contains a reference to a DFS link, such as the following:

PATH=\\corp.domain.com\dfsroot\DFSLink;C:\WINDOWS\system32; "

What would happen if you set things up like this? Why is this a problem? How should it be set?

Also, User Profiles can provide a detailed log to aid troubleshooting. To create a detailed log file for user profiles:

1. Start regedit and locate the following path:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

2. Create a new value called UserEnvDebugLevel as a REG_DWORD, and set the value to 30002 in hexadecimal format.

The log file can be found at: %windir%\debug\usermode\userenv.log

True? I hope to use this to be able to gather data on what is causing the delays at bootup. Any advice?

Thanks

Title Edited - Please follow new forum rules from now on

-- Martin L

Link to comment
Share on other sites


However, an 'error' message isn't received. What would happen here then?
Make sure you're looking at a netmon trace for the error, for that's where it would be seen (not on the machine's GUI).
Why do we have to place them in that particular order? Ok so this causes a delay, why? What *actually* happens (so the technical part) when you order them improperly?

Since most people are running Windows domains on their networks for their Windows machines to connect to, using the "Microsoft Windows Network" provider first will provide the fastest login times (due to the fact that the "Web Client" provider will not be able to be used to log onto a Windows domain). Also, if you're using the Web Client provider, you have to wait for the provider to time out (5 seconds is the default, IIRC), the redirector to be closed and reopened, and then the Microsoft Windows Network provider to be called and initiated. This can add 7 or 8 seconds to login or boot times.

Why/How is this a problem? What are the technicalities involved that make this a problem?
\

This one deals with the "connection to resources" issue, and particularly in IE - although the port matters little. Most web services use the IIS server to provide authentication, which causes AD lookups if NTLM or Kerberos are the authentication methods used by IIS. Thus, a domain controller running a web service that requires authentication will also be doing NTLM and/or Kerberos authentication lookups for web client requests, on top of authentication for domain logins via a winlogon process. This means the DC is doing double-duty, logon-wise. This can (and often does) cause login slowdown issues if the web service is used heavily.

What would happen if you set things up like this? Why is this a problem? How should it be set?

If you use a UNC path in a system's environment variables, and there is a problem with the client accessing the UNC path during login, your boot process will be held up waiting for the UNC path lookup (and authentication handshake, if one needs to be done). This can take upwards of 5 - 7 seconds or more, depending on the network speed and congestion, the load on the server hosting the share, and even antivirus software on the client. This obviously will slow down the logon process by a few seconds or more at times.

Edited by cluberti
Link to comment
Share on other sites

What about using the UserEnvDebugLevel key in registry to log details of a user logging in (Steps recreated below, at end)?

First of all am i correct in believing that this setting would capture processes AFTER logging in only?

(If above true) Is there anyway of catching the delays (via a log) when the process boots up till before it gets to the login prompt... for example when it sit's stuck on stages such as: "Applying Computer Settings", or others...

Intention being that if i could get these logs and times i can just sift through it and figure out excactly what is taking too long (rather than do guess work, turn this off turn that on, etc).

Any ideas out there?

STEPS:

1. Start regedit and locate the following path:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

2. Create a new value called UserEnvDebugLevel as a REG_DWORD, and set the value to 30002 in hexadecimal format.

3: The log file can be found at: %windir%\debug\usermode\userenv.log

.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...