Setting a service to Automatic Delayed will delay a service for two minutes after all automatic services are run.

I thought about possible downsides of delaying the fog service, but in my situation I haven’t found any show stoppers yet.

Our images have the fog service starting as Automatic so on first startup after deployment when the machines are connected wired all is normal with no delays. They rename and join the domain as per usual. We have a GPO that changes the fog service to Automatic Delayed but of course that doesn’t get applied until after the machine has joined the domain.

This sequence seems to work fine for me so I’m sticking with it until we decide to have a look at 0.33

Thanks again to the development team for all of their fine work.

Tom,

Wow, I’ve never seen a response measured in minutes before. Thanks much.

I should try fog 0.33b but we spent a lot of time whipping 0.32 into obedience so I’m kind of reluctant to go through the pain again.

Yes I agree that your installer installs the service as “automatic”, not “automatic delayed”. This is not an option for me, I can’t see a downside to you changing the installer to “automatic delayed”. If we would have changed the service to “automatic delayed” before we created the image all would have been good but we didn’t so I don’t understand what you’re saying.

Yes we sysprep the image but all drivers are in place for the particular image we’re deploying.

When we deploy an image for a machine that has been properly registered, fog dutifully renames the machine, joins the domain properly and we must of course do this wired.

Once placed in the proper OU in active directory the device has enough info to function properly wirelessly as we have a gpo that forces wireless connection to our SSID.

Unfortunately after this when the devices are untethered the wheels fall off as far as fog is concerned.

From what I’ve interpreted from the log files it looks like the fog service checks at initial run for the available mac address’s but doesn’t find any as the wireless hasn’t yet connected due to the delay in radius authentication and a restart of the fog service when connected puts everything back in order.

If you’d like a copy of the fog logs in a working and a non working situation I would be happy to comply. You’ve done so much to improve my work situation that I can’t imagine what I could do in return.

Just a heads up on a problem I had deploying snapins over wireless. Here’s my setup.

All workstations are Windows 7 mixture of 32 and 64 bit.

Fog version 0.32

A total of 50 Ubiquiti Unifi wireless access points in 8 separate locations.
The wireless authentication is done to a radius server using device authentication against active directory.

I did know that our wireless authentication takes about 20 seconds to complete because if you try to login to windows to quick after power up it will complain about no domain server or fail to map drives and printers if you have cached credentials already on that work station.

After going to Windows 7 we noticed our snapins weren’t always deploying. No problem with XP previously and we did have the mac address of the wired interface and the wireless interface entered in the host management page in fog.

We found that snapins would only deploy via the wired interface and never the wireless. In fact when examining the fog logs I noticed that if the fog service ran when the laptops were wireless only that we’d get about 10 minutes worth of log entries and then nothing more. It seemed as though the fog service just stopped doing anything even though it was still running.

If I restarted the fog service manually the queued snapins would then deploy. As I’m no programmer I have no idea what the fog service is doing behind the scenes but I suspected the delay in network accessibility after power up so I set the fog service to “Automatic Delayed” from “Automatic” and now all works fine.

Hope this helps someone, oh and many thanks to the fog developers for a product I couldn’t live without.