Exactly HOW are machine start-up Group Policies processed and what is required?

Question

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!

Answer 1

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.

Answer 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