Can't deploy snapins via wireless
-
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.
-
If it’s of any help, FOG 0.33b is not stringent on which MAC is being sent, so long as any of the mac’s sent are attached to the host whether by the main MAC or the additional macs.
The service, to my knowledge, is always installed as Automatic, not Automatic delayed. My suspicion with you’re issue is whomever created the image told the Service to be delayed. Maybe because you are sysprepping the image and using a Driver installation system after the system is imaged? Just my thoughts, and you’re more than welcome.
-
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.
-
I originally misread your original dialogue and thought you changed from “Automatic Delayed” to “Automatic” which in your case is reversed. For that I’m sorry.
The only downside I can see with having it in “Automatic Delayed” is how long is the delay? I ask because on the first bootup, the service runs and changes the Hostname and joins the system to the domain. If this is delayed, how would this operate for these important options?
The Service runs many different things, especially depending on how things got installed. There’s something along the lines of 3 checks and balances for each service.
There are a total of 12 services, that I’m aware of.
The Hostmanager/Hostname Changer, and Hostregister scripts run at the initial startup of the service. Hostname Changer changes the hostname and joins the system to the domain. Hostregister, registers all available MAC’s on the system to the host within FOG as “Pending” macs. Pending MACs are not available to link to a host, but additional and, the primary, MACs are one way to tell how the host get’s recognized by the service. Only issue is, 0.32 only cared about the primary MAC, so none of the Service checks would actually operate if the Primary MAC was not changed to that of the Wireless adapter.
I hope this helps clarify some things.
If you’re ever willing to attempt 0.33, I don’t think it’s quite as painful as 0.32 was to get things running. 0.32 is kind of old and doesn’t install as nicely on more modern linux’s. If you need any help just post or convo and I’ll, or any of the other developers and community managers, will be more than willing to help.
-
As someone who came into FOG when .32 was all there was and had never messed with PXE servers before, 33 is a walk in the park. Do a fresh install and you’ll have no issues. And if you do have issues we will be here to get you up and going.
Remember to backup your hosts and images if you want to add them back in, once added to 33b you will need to set an image to the hosts or you will see errors popping up in the web UI(it will still work, just show errors).
Here are the steps for upgrading if you don’t do a fresh install(highly recommend fresh install)
[url]http://fogproject.org/wiki/index.php/Upgrade_to_0.33[/url]IF you do a fresh install make sure you set your images to partImage instead of partClone.
For that you need to check this option under fog settings->general settings:
FOG_LEGACY_FLAG_IN_GUI
then change the drop down found at the bottom of the image definition. -
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.
