G
Guest
I am having an issue with many XP SP2 Dell Lattitude D6xx laptops.
All affected laptops are memebers of a domain.
When these affected users boot their laptops while disconnected from the
Domain (at home, on the road, etc) they get to the CTRL>ALT>DEL screen,
login, and then wait. Some report that they will sit there for a "ridiculas"
amount of time ~5min before they poweroff and try again. During this 'hang'
time they see their dekstop background, but that is it. No icons, no task
bar, windows (ie Preparing Network Connections).
Of course when they are on the network and there is a domain controller
available, they log right in. No delays.
EventID 5719 NETLOGON (No Domain Controller is available for domain) appears
in the event log. No surprise.
One thought that I had that might be causing this is login/logoff scripts.
All laptop users have both a login and logoff script (assigned via GPO to the
user) that maps drives on the login and then un-maps them on the loggoff.
My thought on the logoff script was to eliminate these types of delays by XP
looking for a drive/server that can not be found when not connected to the
network. I hope that this is not doing the opposite.
A "home folder" is also mapped via their profile.
I found a 'potential' solution having to do with the asyncronous loading of
networking during the boot up process. I see that this can be disabled via a
GPO. However seems to me that this solution would be for domain computers
that have slow logins regardless of their connection to the domain.
Of course logging in as a local user bypasses these issues. Therefore it
appearst that the issue has to do with cached credential logins outside the
network.
Any thoughts? Could it really be that a domain profile will look for a
authentication server for that long? I decided to paste my simple login &
logoff scripts below for you to see.
-KC
**Login Script**
REM Disconnect existing network mappings - do not prompt the user
NET USE J: /D /Y
NET USE K: /D /Y
NET USE L: /D /Y
NET USE P: /D /Y
NET USE Q: /D /Y
NET USE R: /D /Y
NET USE S: /D /Y
NET USE V: /D /Y
REM Connect SI standard drive mappings
NET USE p: \\sidfs01\projects
NET USE w: \\sidfs01\workgroup
NET USE S: \\sidfs01\shared
NET USE Z: \\sidfs01\SID_DFSROOT
REM Connect each user's home directory
NET USE U: \\sidfs01\USERS\%USERNAME%
**Logoff Script**
REM Disconnect existing network mappings - do not prompt the user
NET USE I: /D /Y
NET USE J: /D /Y
NET USE K: /D /Y
NET USE L: /D /Y
NET USE P: /D /Y
NET USE Q: /D /Y
NET USE R: /D /Y
NET USE S: /D /Y
NET USE V: /D /Y
NET USE W: /D /Y
NET USE Y: /D /Y
All affected laptops are memebers of a domain.
When these affected users boot their laptops while disconnected from the
Domain (at home, on the road, etc) they get to the CTRL>ALT>DEL screen,
login, and then wait. Some report that they will sit there for a "ridiculas"
amount of time ~5min before they poweroff and try again. During this 'hang'
time they see their dekstop background, but that is it. No icons, no task
bar, windows (ie Preparing Network Connections).
Of course when they are on the network and there is a domain controller
available, they log right in. No delays.
EventID 5719 NETLOGON (No Domain Controller is available for domain) appears
in the event log. No surprise.
One thought that I had that might be causing this is login/logoff scripts.
All laptop users have both a login and logoff script (assigned via GPO to the
user) that maps drives on the login and then un-maps them on the loggoff.
My thought on the logoff script was to eliminate these types of delays by XP
looking for a drive/server that can not be found when not connected to the
network. I hope that this is not doing the opposite.
A "home folder" is also mapped via their profile.
I found a 'potential' solution having to do with the asyncronous loading of
networking during the boot up process. I see that this can be disabled via a
GPO. However seems to me that this solution would be for domain computers
that have slow logins regardless of their connection to the domain.
Of course logging in as a local user bypasses these issues. Therefore it
appearst that the issue has to do with cached credential logins outside the
network.
Any thoughts? Could it really be that a domain profile will look for a
authentication server for that long? I decided to paste my simple login &
logoff scripts below for you to see.
-KC
**Login Script**
REM Disconnect existing network mappings - do not prompt the user
NET USE J: /D /Y
NET USE K: /D /Y
NET USE L: /D /Y
NET USE P: /D /Y
NET USE Q: /D /Y
NET USE R: /D /Y
NET USE S: /D /Y
NET USE V: /D /Y
REM Connect SI standard drive mappings
NET USE p: \\sidfs01\projects
NET USE w: \\sidfs01\workgroup
NET USE S: \\sidfs01\shared
NET USE Z: \\sidfs01\SID_DFSROOT
REM Connect each user's home directory
NET USE U: \\sidfs01\USERS\%USERNAME%
**Logoff Script**
REM Disconnect existing network mappings - do not prompt the user
NET USE I: /D /Y
NET USE J: /D /Y
NET USE K: /D /Y
NET USE L: /D /Y
NET USE P: /D /Y
NET USE Q: /D /Y
NET USE R: /D /Y
NET USE S: /D /Y
NET USE V: /D /Y
NET USE W: /D /Y
NET USE Y: /D /Y