msandhorst
asked on
Slow Windows 7 logon using cached credentials
Mobile users that are using domain joined Windows 7 laptops have slow logon times when their not connected to the domain and relying on the cached credentials. Login can take 2-3 minutes.
When the computers are connected to the domain, logons are fast. I'm sure the computers are searching for the DC and eventually give up allowing the logon to proceed and presenting the desktop which is causing this. I searched extensively for an answer on experts exchange and google but no articles I read nail it down.
I'm not using a solid background color which Microsoft reported as a bug that caused slow logons. The machines basically process a login script when connected to domain to map network drives. I tried disconnecting all network drives and logging off and back on again but still same wait time when not connected to doamin. Group Policy for logons are Microsoft's default and have not been altered.
There has to be a GPO setting for the computer account that if it can't find a DC in 5 seconds or whatever set to the logon process moves on and gives the user their desktop.
When the computers are connected to the domain, logons are fast. I'm sure the computers are searching for the DC and eventually give up allowing the logon to proceed and presenting the desktop which is causing this. I searched extensively for an answer on experts exchange and google but no articles I read nail it down.
I'm not using a solid background color which Microsoft reported as a bug that caused slow logons. The machines basically process a login script when connected to domain to map network drives. I tried disconnecting all network drives and logging off and back on again but still same wait time when not connected to doamin. Group Policy for logons are Microsoft's default and have not been altered.
There has to be a GPO setting for the computer account that if it can't find a DC in 5 seconds or whatever set to the logon process moves on and gives the user their desktop.
Rob Williams
IS it still slow if there is no network connection? If it is faster with no network connection, might the alternate network, when using cached credentials, be using the same subnet?
This is a common problem on Windows 7. Make sure you uncheck IPv6 in network connections (control panel) that should increase logon speeds dramatically..
Control Panel\All Control Panel Items\Network and Sharing Center\local area connection\properties
Control Panel\All Control Panel Items\Network and Sharing Center\local area connection\properties
I would disagree. IPv6 a proven technology and becoming necessary in Server 2008 and newer domains. In some cases disabling IPV6 on servers (I appreciate this is a PC) causes major problems.. I have yet to see issues actually caused by IPv6 since the release of XP SP3. However, if you do feel it will help it is important to disable it in the registry, not in the NIC configuration. The following Microsoft article outlines how to do so, in the registry, or using their "fixit".
http://support.microsoft.com/kb/929852
http://support.microsoft.com/kb/929852
ASKER
I've turned off wireless and had no connection to LAN port and it's still slow using cached logon. Has also been connected to a wireless network outside of domain with same slow response. I will try disabling IPV6 this morning.
ASKER
Disabled IPV6 and there was no difference when using cached credentials. If it's a common problem with Windows 7 I would hope there is a resolution for it since M$ must know about it, very frustrating not being able to find a fix for this.
It is not a common problem. One reason for slow logins can be searching for a domain controller, since still slow with network disconnected, that should rule that out as the source of the problem.
Perhaps try using msconfig to disable all services and start up applications, and see if still slow.
Perhaps try using msconfig to disable all services and start up applications, and see if still slow.
I agree that IPv6 is BECOMING more used but as of now is not in wide spread use and that means that all DNS tasks have to check both IPv4 and v6 requests. Unfortunately this isn't just that it takes 2 as long, its worse than that because v6 in not in widespread use. It is getting better and promises to be so in the future but I see this EVERY TIME I add a new system to my networks--granted I deal with small networks (50 of fewer systems--that's my client base)--but when I logon with IPv6 enabled it is clearly slower and when I disable it it is much faster. Regardless, this is not addressing the issue that msandhorst has.
What is in the logon script and do you have logon scripts set to hidden and synchronously? Are logon scripts controlled via GPO and where are these located? I assume you have checked both system and application logs and there is nothing helpful in either?
What is in the logon script and do you have logon scripts set to hidden and synchronously? Are logon scripts controlled via GPO and where are these located? I assume you have checked both system and application logs and there is nothing helpful in either?
ASKER
Logon scripts are in the netlogon share on server. The scripts are set to run using Microsoft's default setting for the GPO which is apply scripts and group policy processing after logon.
ASKER
Ok... today i 've timed the logon with no network connectivity using cached credentials and it takes 30 seconds exactly to get logged on. If I'm connected to a wireless or wired network outside of the domain it takes 60 seconds. If I'm connected to domain network the logon takes 5 seconds.
There has to be a GPO setting for this, not to look for 60 seconds if it can't find the DC.
There has to be a GPO setting for this, not to look for 60 seconds if it can't find the DC.
Please show us what these logon scripts are doing--thanks. Can you test what happens if don't run the scripts? Systems will try to re-establish connection to the domain and the fact that wireless add 30 seconds to logon time tells me quite a lot is happening at logon, no?
ASKER
I looked at the GPO at domain level and local machine level. The client side processing for the Windows 7 computer is set to "Not Configured" which will process policies asynchronously, not waiting for network connections which is considered fast logon optimization and is correct setting for using cached logon.
Login script is net use z:\\server\share. Removing the script doesn't speed up the login.
When the user is outside the network connected to a wireless LAN or wired LAN is when the login takes so long cause the computer can't find the DC. Policies and login scripts wouldn't matter at that point cause they won't run anyway. It has to do with the computer trying to find a DC for 60 seconds when it's connected to a network that the DC is not in.
Login script is net use z:\\server\share. Removing the script doesn't speed up the login.
When the user is outside the network connected to a wireless LAN or wired LAN is when the login takes so long cause the computer can't find the DC. Policies and login scripts wouldn't matter at that point cause they won't run anyway. It has to do with the computer trying to find a DC for 60 seconds when it's connected to a network that the DC is not in.
ASKER
1 ) Here's what I found after further testing with VPN client. If the user is outside of domain, boots up machine and connects to a network for instance "at home" it takes 45 seconds for the desktop to be presented after logging in.
2) If the user never connects to the VPN after logging in and logs off, the login time takes 45 seconds just like step 1.
3) If the user logs in, connects to VPN and logs off while VPN is connected, it takes exactly 5 minutes to log back in before getting a desktop.
4) If the user disconnects from the VPN before logging off the login takes 45 seconds.
Conclusion:
The extreme (5 minute) logon is cause by logging off from Windows while still connected to VPN. Even though the logoff disconnects the VPN it's like Windows thinks it's still connnected when its not causeing the 5 minute logon. As long as the user disconnects from VPN first the logon only takes 45 seconds which we can live with. It would be nice if it only took 5 seconds outside of network (this was the goal for this post) but using cached logon info in Windows 7 must take 45 seconds when outside of network. I still believe there is a setting for local policy side extensions for this but can't find it. The 5 minute login if not disconnnecting from VPN first is weird but at least we know disconnecting first knocks the logon time down to 45 seconds.
2) If the user never connects to the VPN after logging in and logs off, the login time takes 45 seconds just like step 1.
3) If the user logs in, connects to VPN and logs off while VPN is connected, it takes exactly 5 minutes to log back in before getting a desktop.
4) If the user disconnects from the VPN before logging off the login takes 45 seconds.
Conclusion:
The extreme (5 minute) logon is cause by logging off from Windows while still connected to VPN. Even though the logoff disconnects the VPN it's like Windows thinks it's still connnected when its not causeing the 5 minute logon. As long as the user disconnects from VPN first the logon only takes 45 seconds which we can live with. It would be nice if it only took 5 seconds outside of network (this was the goal for this post) but using cached logon info in Windows 7 must take 45 seconds when outside of network. I still believe there is a setting for local policy side extensions for this but can't find it. The 5 minute login if not disconnnecting from VPN first is weird but at least we know disconnecting first knocks the logon time down to 45 seconds.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the help, the VPN connection requires Sonicwall VPN client, I'm not using Windows VPN.
The group policies you mentioned above are all set to "not configured". I'm closing this case with points awarded cause the machine was put into the field. User will just have to disconnect from VPN before logging off.
I didn't disable services and starups with MSConfig cause it was a brand new install and not much was running out of the box.
Thanks Robwill for all your help.
The group policies you mentioned above are all set to "not configured". I'm closing this case with points awarded cause the machine was put into the field. User will just have to disconnect from VPN before logging off.
I didn't disable services and starups with MSConfig cause it was a brand new install and not much was running out of the box.
Thanks Robwill for all your help.
We had the same issue - 7/10 minutes to get to the login prompt with a domain bound laptop that is off domain (working remote). We narrowed it down to windows searching for DC and GPOs - hard to reproduce at work without an outside DSL so we used our phone's hotspots ;-) In fact if you plug in one such slow laptop to the domain, and gpupdate + reboot, it will boot and login normally... Take it home, it will keep logging in quickly until it does a GPO update, then next reboot it's back to being slow to get to a login prompt.
none of the GP setting above made a bit of difference, sadly. I really expected "Computer Configuration | Administrative Templates | System | Logon | Always wait for the network at computer startup and login " to work, but nope...
Our solution until we figure this out is as follows: Small package that drops 2 scheduled tasks. One at boot time, turns off all network devices... One at login time, turns them back on. Both scheduled tasks were edited to work when laptops are not powered on AC (otherwise it may not run) and wrapped into a little exe that we push with remote tools (bigfix). But you can do the same just sending scheduled tasks... Logins went from 10 min to 2 minutes - windows detects no valid networking and immediately quits trying to phone home... Then at login, it gets networking back. Only caveat is the user must have cached creds before this happens, and a backdoor admin password is a good idea in case something goes wrong and you need to get in and remove the scheduled tasks.
I'd still prefer a cleaner solution based on GPs or a patch, but our MS support budget is limited this year ;-(
Example for win7 and win10: create onebatch file with
netsh interface set interface name="wireless network connection" admin=disabled
netsh interface set interface name="local area connection" admin=disabled
netsh interface set interface name="wi-fi" admin=disabled
netsh interface set interface name="ethernet" admin=disabled
and another, reversed for enabled... I ran it, then modified the task options to also work without AC power (optional - did not know the dos command to do that above, so I did it by hand and exported it via XML, which keeps track of when the tasks run, what's in it etc...)
and I push the resulting xml files to the target pc and run them to create my tasks like so: schtasks.exe /Create /TN "DisableNetwork" /XML "%MYPATH%\DisableNetwork2.
none of the GP setting above made a bit of difference, sadly. I really expected "Computer Configuration | Administrative Templates | System | Logon | Always wait for the network at computer startup and login " to work, but nope...
Our solution until we figure this out is as follows: Small package that drops 2 scheduled tasks. One at boot time, turns off all network devices... One at login time, turns them back on. Both scheduled tasks were edited to work when laptops are not powered on AC (otherwise it may not run) and wrapped into a little exe that we push with remote tools (bigfix). But you can do the same just sending scheduled tasks... Logins went from 10 min to 2 minutes - windows detects no valid networking and immediately quits trying to phone home... Then at login, it gets networking back. Only caveat is the user must have cached creds before this happens, and a backdoor admin password is a good idea in case something goes wrong and you need to get in and remove the scheduled tasks.
I'd still prefer a cleaner solution based on GPs or a patch, but our MS support budget is limited this year ;-(
Example for win7 and win10: create onebatch file with
netsh interface set interface name="wireless network connection" admin=disabled
netsh interface set interface name="local area connection" admin=disabled
netsh interface set interface name="wi-fi" admin=disabled
netsh interface set interface name="ethernet" admin=disabled
and another, reversed for enabled... I ran it, then modified the task options to also work without AC power (optional - did not know the dos command to do that above, so I did it by hand and exported it via XML, which keeps track of when the tasks run, what's in it etc...)
and I push the resulting xml files to the target pc and run them to create my tasks like so: schtasks.exe /Create /TN "DisableNetwork" /XML "%MYPATH%\DisableNetwork2.
Greg, should be a new question/topic as this is closed, but sounds overly complicated. This shouldn't be a problem. Any chance the subnet is the same at both sites? I have often seen it search indefinitely if home uses the same subnet as the office, especially if the PC is not shut down, but rather in sleep mode. I suspect some of the network information for the domain network is retained in the registry.
Well it sounds complicated because I went into too much details. If I just said we turn off network adapters at boot and turn them on at login, it's simpler ;-) To your point, it's possible some stuff is retained in the registry. The minute the PC GP updates from VPN at home it breaks again. Something is coming down that sticks... Odd thing is most of our remote people are OK, just 15 or so out of several hundreds experience this, hnce the kludgy solution !
Is the office using a common subnet like 192.168.0.x, or 192.168.1.x?
No ;-) Looked at that first....