Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We have Server 2008 R2 and Windows 7 Enterprise.

I'm asking this because we have several hundred laptops and netbooks at our organization. We do'nt have a NAC or a RADIUS server so all the wireless configs are done on the local computer. Please don't suggest a NAC or RADIUS as we don't have the ability to implement that at this time.

We have a GP machine start-up script that resets the wireless settings on the laptops/netbooks upon start up. This is because our users typically will take their devices home, travel, etc and when they join other networks our network info will often get lost or disabled. Our script leaves any connections the user added but resets our settings and makes it the primary item on the list.

It works fairly well but occasionally fails for some unknown reason.

I have yet to find any sort of documentation on exactly how Windows processes and applies Machine Start-Up GPs and what is required. For instance, because the network is not always present, yet the GP still runs when offline, I assume that the GP is cached somewhere on the local machine. Where does it cache this? For some reason when we put the script in the GP itself it does not run. But when we put the script into a file in the file store of the GP and call it from the GP it runs fine. Are Machine Start-Up scripts applied before or after the local wireless is enabled?

All these questions could be answered if I could find some definitive documentation on exactly how this entire process works.

Any help would be appreciated.

Thanks!

This seems to be a lot more stable but no one has yet to answer the actual question, which is where is a reference doc on exactly how GPOs are applied. What are the steps, what are the conditions and restrictions, etc.

Thanks!

share|improve this question
    
I have never seen this kind of screwy network problem. I am a consultant, use Win 7, and have probably connected to 100 wifi networks in the last year. I suspect your wifi deployment is the issue, and you are spending a lot of time trying to find a workaround. –  tomjedrz Aug 30 '11 at 19:30
    
"Are Machine Start-Up scripts applied before or after the local wireless is enabled?" Every Network Card manufacturer is different as to how the are configured or can be configured, mainly as to whether you use the Utility that comes with the card or do you use Windows Built in Wireless Utility. some can be set to pre-logon (Authenticate) and some do not have the ability. It will cost more work on your part, alot actually, but, you may want to add the script to the local security policy of the laptops and netbooks instead of putting it in the GP and hoping it will work that day –  Tom Sep 1 '11 at 5:36
1  
Also, of course it's quite difficul for any GPO to get applied before the computer can establish a working connection to the domain... so this is never going to work reliably if a computer actually uses a wireless connection to reach your network. –  Massimo Sep 14 '11 at 20:15

2 Answers 2

Windows will allow you to log in to the workstation even before any network connections are ready.

Most people are not aware that Windows uses Fast Logon Optimization on startup. In this configuration, if the network is not available in time, existing users are logged on using cached credentials. Group Policy is applied in the background after the network becomes available. This also has the side effect that if any computer policies require a non-logon state, they require two logons to apply. This could possibly explain your failure.

You could try to turn off Fast Logon Optimization via Group Policy by setting this to Enabled:

Computer Configuration\Policies\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon
share|improve this answer
    
Totally +1, in my opinion that is the most annoying feature ever introduced in a Windows system (yes, I find it even more annoying than UAC). –  Massimo Sep 14 '11 at 20:01
1  
@Massimo: While I agree with you and what newmanth says I don't think this really applies to the OP's question. Having said that, I always deploy a domain-level GPO that turns off this stupid "feature". –  Evan Anderson Sep 14 '11 at 20:09
    
We have this turned off and have had that for years so this isn't the issue. –  Matt Penner Sep 16 '11 at 19:45

It's unclear to me what you're trying to do and I think you're taking the wrong path to get there.

The contents of Startup Scripts aren't cached by clients. The client does cache the path to the script, but not the content of the script itself (any executable could be used as the script and there might be dependencies on files besides the "script" itself).

It sounds like you've figured out that you can't distributed a pre-shared key to clients using Wireless Network Policy Group Policy Client Side Extension (CSE). To "work around" this fact you've deployed a startup script that probably uses netsh to import an XML file with the PSK. It's unclear to me, though, why you'd want to do this on every boot. You need only import it once and the client will retain the settings.

What you're trying to do is never going to work well. I know you don't want to hear this, but you'd have a much better time just using Group Policy to distribute your network information. Of course, to do that you'll have to move to a non-PSK-based encryption / authentication strategy.

Unless you've got utterly backwards access points you'd be better off taking the 2 to 3 hours to install a Windows RADIUS server, configure a policy, connect a couple of APs to it as RADIUS clients, and deploy a test GPO with the new WPA-RADIUS or WPA2-RADIUS SSID configured in it. Then you won't have to muck about with the dodgy hack that you're doing.

If you have to do what you're doing your best bet would be to put your Startup Script in a Local Group Policy. When your clients boot and have "lost" your wireless network settings the script will execute and restore them but boot Domain Group Policy processing will be done by that point and any changes to Domain GPOs won't be applied until the first periodic policy refresh (and, then, only settings that can be applied during periodic refresh will be applied). The client would have to be booted again in order for all the Domain Group Policy settings to apply.

Save yourself the hassle and just do this the conventional way. You'll be happier in the end and the net amount of time you throw at it will be significantly less than years of care-and-feeding for your dodgy hack.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.