Tom, I really appreciate your work and your support on here. Many thanks from Berlin.

I see were the idea comes from. Maybe it would be good idea if the fog client knows about the state of its task list (reneming, domain join) so that snapins could run immediately after first reboot or second reboot if there are appropriate joining/renaming tasks.

Use Case: We are deploying computers for events. So they will get imaged, shutdown and packed. It is great that the image process just needs 4 minutes for around 30 computers, but it seems like a waste of time that we have to wait another 6 to 7 Minutes just for the snapins.

Ok, maybe I was too impatient and realized it the first time. Thank you for the fast answer to an impatient guy.

So why is the client not contacting the server the first time it is invoked?
Why is there a difference between 409 seconds sleeping in the log and 307 seconds sleeping in the config?

EDIT: Changing the config chekintime has no effect on the first run time of the snapins.

Hi all,

I updated from TheFog 0.32 to 1.2.0. I have noticed that the execution of snapins is not done on startup of TheFog service, but arorund 6 minutes later. The fog.log says something like this:

[CODE]…
ClientUpdater Checking Status : SnapinClient.dll
…

• Starting FOG.SnapinClient
  …
• Starting FOG.SnapinClient (yes this comes twice!!)
  …
  FOG::SnapinClient Starting snapin client process…
  FOG::SnapinClient Sleeping for 409 seconds[/CODE]

I do know that the snapins were executed instantly after image deployment with 0.32. So is there a configuration for this?

Hi community,

I am running TheFog 1.2.0 on Ubuntu 12.04.4.

I noticed that the FogMulticastManager service does not start properly. I checked that with:

[CODE]ps aux | grep FOGMulticastManager[/CODE]

As the startup skript still produces a PID file, I assume that it got invoked but crashed on it’s way up. So just restarting the service does not work without deleting the PID file before. But in any case I want it to start up automatically. I could not find any hints in any log for it, so I started trial and erroring.

I assume a dependency to another service (I could not find out wich one yet).

WORKAROUND:
When lowering the priority of the startup links it works like a charme:

[CODE]update-rc -f FOGMulticastManager remove[/CODE]
[CODE]update-rc -f FOGMulticastManager defaults 99[/CODE]

Can anyone confirm that behaviour? Is it a bug in the installation skripts?

[quote=“Matt Harding, post: 11827, member: 1207”]I’ve had this problem before in the early days of me trying to deploy snapins and get my head around it… easy enough to fix if it’s the same problem I had with my snapins…

When you install the FOG service it installs itself and runs as a local system account… for some reason this doesnt work for me for everything… I just changed the user to local administrator on the service before I imaged… see the posted pic. Try that and see if it starts working.

Incidentally, is this the only snapin you’ve made that you’re struggling with or do they all do this?

Hope this helps anyhow.[/quote]

I came across the same problem when joining the client to a domain after imaging. It might be an individual security-dependency of the domain but your solution helped. Thanks for posting…

@Junkhacker

Ok using a CSV seems to be a good idea. Unfortunately you generate another place of information with this.

It would be great if the snapin link would be configurable for every host. So I could give every host different arguments for runnning a netsh script.

Thanks for your reply. This means that I need one batch file for each machine. With over 400 machines this produces much snapins.

I remember a data field in the fog web gui below host name for it. Maybe the guy just coded a snapin that connected to the fog database to get the individual IP for each machine…? I also read a comment in another forum that the FogService should be also able to change the IP.

@mod: Please feel free to move this thread to general.

Hi guys,

I already have seen someone who used FOG for changing the static IP of Windows XP clients after imaging several years ago. Now that I want to try this on my own, I can not find any information about it. Is this feature gone in the new versions?