Windows 7 VERY SLOW Windows 7 Wireless Domain Login

teejay

New Member
Hey Guys,

I'm an IT Tech. for a school and we have currently tested and pushed out a new Windows 7 image to a couple of hundred HP Laptops. We are noticing increased login times over our wireless network (802.11N) which is very inconsistent with our initial testing results. Students are taking sometimes up to 5minutes (even more) just to login after entering their username and password into the machine. Our wireless network is more than capable of handling 3 times the number of active connections we have, as we have more than enough base stations throughout the areas students are trying to login. When they are logged in everything is fine, no troubles at all. Signal strength couldn't go any higher.


EDIT: We are using a Default Local Profile, so users shouldn't be downloading roaming profiles across the network.


Our Problem:
Slow login times over the Wireless-N Network

Possible Solution:
Wireless Driver Update?
Windows Hack?

Thanks for any help!
Tim
 
Last edited:
Hey.

Are you sure it is the login that is slow? It could be that the students are placing software on the machine(s) that start with Windows and adversely affects Windows operation for some reason or another. Perhaps a VMWare service slowing down the boot to desktop or similar circumstance. It happens all the time.

Maybe it's not a specific login problem as it seems?
 
Hey.

Are you sure it is the login that is slow? It could be that the students are placing software on the machine(s) that start with Windows and adversely affects Windows operation for some reason or another. Perhaps a VMWare service slowing down the boot to desktop or similar circumstance. It happens all the time.

Maybe it's not a specific login problem as it seems?


As VMWare isn't installed on the image, I doubt this is the problem.

We had been thinking that services/programs running in the background whilst the user was logging on could be affecting the login time. As this is a new image, students wouldn't have installed any software themselves and as it is there access to do so is very restricted.

Other than that we are puzzled.


Thanks for the reply.
 
Last edited:
teejay:
Hello and welcome to the forums.
Whew, where to start;
Did you sysprep the install that you created the image from?
Can an admin logon with his domain credentials with better results as far as the time it takes to complete the logon?
GPOs, to many? Or peculiar for students, doing something special with the desktop, excessive resource mapping, especially some printers. Making sure that the Students OU has a minimum amount of GPs associated with it and that there aren't several cascading and conflicting, as well as making sure they are as clean and uncluttered as possible. Also try experimenting with the "Wait for connection before logon" group policy, sometimes turning it on helps, but more often especially with wireless clients, turning it off helps more. Use the event viewer and see if anything hits you in the face also try running gpresult /R and see if anything there really stands out, like slow connection threshold.
Wireless security overhead? WPA Enterprise? Radius Server?
Third party wireless software from HP, possibly at odds with Windows7?
Startup programs especially antivirus software attempting to update at logon, which may or may not be possible depending on students priviledges?
Which Server product Win2k3(r2) or 2k8(r2), which mode, mixed or native. Is that you DNS server as well as your DHCP server, is that DNS server defined within the DHCP scope for your wireless clients.
I suspect either a GPO or some third party software at startup/logon attempting to accomplish something that is ultimately timing out or failing because of the students lack of privledges on the local machine.
It would really help to know if admins experience the same issue when they log onto the problem machines.
 
teejay:
Hello and welcome to the forums.
Whew, where to start;
Did you sysprep the install that you created the image from?
Can an admin logon with his domain credentials with better results as far as the time it takes to complete the logon?
GPOs, to many? Or peculiar for students, doing something special with the desktop, excessive resource mapping, especially some printers. Making sure that the Students OU has a minimum amount of GPs associated with it and that there aren't several cascading and conflicting, as well as making sure they are as clean and uncluttered as possible. Also try experimenting with the "Wait for connection before logon" group policy, sometimes turning it on helps, but more often especially with wireless clients, turning it off helps more. Use the event viewer and see if anything hits you in the face also try running gpresult /R and see if anything there really stands out, like slow connection threshold.
Wireless security overhead? WPA Enterprise? Radius Server?
Third party wireless software from HP, possibly at odds with Windows7?
Startup programs especially antivirus software attempting to update at logon, which may or may not be possible depending on students priviledges?
Which Server product Win2k3(r2) or 2k8(r2), which mode, mixed or native. Is that you DNS server as well as your DHCP server, is that DNS server defined within the DHCP scope for your wireless clients.
I suspect either a GPO or some third party software at startup/logon attempting to accomplish something that is ultimately timing out or failing because of the students lack of privledges on the local machine.
It would really help to know if admins experience the same issue when they log onto the problem machines.


Thanks heaps for the reply/help mate.

Information I have so far:
- Yes the image was sysprep'd.
- Administrators have the same extended login time.
- Wireless Security using RADIUS Authentication. (No third party wireless software)
- Running Microsoft Server 2k8

Just slowly going through the list you made and seeing what fixes it if it does.We have tested several different users and different login scenarios;

Cold Boot > Login User1 = Longest time, >1min ( Copying local profile? Preloading Services? Applications? )
Logoff > Login User1 again = Almost instant, <6secs ( Due to Profile already copied, Windows Services already running? )
Restart > Login User1 again = Not to bad, <1min ( Because profile is already copied? but windows services loading, etc? )
Logoff > Login User2 = Not bad, >20secs ( needs to copy profile, etc )

We rolled out a new trolley of laptops just the other day with a fresh, up to date image. Most students took more than 5mins to login :S
It's quite frustrating really haha ohhwell. I'll reply again when i know more!

Cheers,
Tim
 
Last edited:
I suspect that TorrentG may be on the right track and overburdened radius server could be having an issue with multiple simultaneous logins.
I seem to recall (and I must admit, it has been a while) that in most instances a radius server authenticates the machine as well as the user and as you pointed out in your second example the logoff and logon of a user was quick and just guessing but I suspect that that's because no addition authentication of the machine was taking place, more so then the profile loading. The radius server may have some information in its' log files that may shed some additional light on the problem.
 
We're seeing very similar issues. The best result so far is to have users disable the wireless card on the laptop before logging in, then after logon re-enable. Most have physical switch on unit, so it's not that intrusive.

The same goes for the users if they are on a remote network say a coffee shop, etc.

We are thinking this is an issue with wireless not fully active prior to or during logon time. We utilize WPA2Enterprise, so the local credentials are passed for auth. We see shorter times if the network is immediate... like an open or pre-setup WEP based, but still a delay.

Our guess it's a compound issue... delay for processes to auth., delay for processes waiting on network and delay due to those that account for both and lastly, partial network... connect to WAP is successful, but no IP is issued until auth. is validated by WAP... so some process detects a network and a time out starts.

It would be great if you could create network profiles... i.e. designate IP ranges in which a domain account is forced to auth. to the DC and/or processes like GPO/startup items that access network based intrinsic commands (persistant mapped resources, etc) are ignored or immediately time out. If not on that IP, cached credentials and GPO are applied without even trying for the DC.

Even a place to control the timeout values would be nice, but I can't seem to decern them. Or a place to control the order of items launch... i.e. make the first action after credentials entered to windows be to launch WiFi, execute profiles and pass credentials through if required... THEN start processing core items like domain auth, GPO, etc.

Another issue this brings up is pre-creating profiles on multi-user systems with WiFi enabled only after logon... chicken and the egg effect.

With XP, CISCO VPN (IPSEC varient) and certain wireless card (more driver specific than the card), you could set the CISCO to launch prior to logon which forced the wireless card to activate and prompt for auth credentials. Still doesn't help users who've never logged onto the system before or if WiFi profile is set to pass through auth.

Thus it's technically possible to control at least some of this, but a custom GINA and some slick resource integration programming would be required to get it to work.

BTW... our wireless auth. is pushed by RADIUS with integration of our AD. We have had issues with Back-to-School preventing wireless connections as well, but even when the problems aren't occuring with RADIUS (low use times) we are still seeing' these extreme slowness issues with wireless clients.
 
Last edited:
I just figured out the problem on XP sp3 after setting up an 802.11 WPA2 \ AES \ PEAP wireless profile. The system is auto checking the box to Authenticate as the computer on the Authentication tab. The network system is not built to permit the computer account to authenticate and the timeout takes forever.
 
Back
Top