Delayed Snapin execution since 1.2.0
-
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?
- Starting FOG.SnapinClient
-
I believe snapin execution has always been delayed by 5 minutes by default. It can be changed on the client config.ini
[snapinclient]
checkintime=307Somebody correct me if this wrong information please
-
[quote=“TheGrinch, post: 35549, member: 24995”]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?[/quote]
Seeing as nothing’s changed in the FOG Client since 2011, what Edgardo states is correct.
There’s always been a sleep time set before the snapins operate.
- Starting FOG.SnapinClient
-
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.
-
I believe the reasoning, initially in the older client, is due to the way snapins operate. If you had them run at first load out, and the system was running the install of the snapin at the same time it changed the hostname or joined the host to the domain, you’d be left with broken software as the system has to reboot for the name change and ad join procedure(s).
The delay is to allow the name change and/or join to domain without interrupting the install of the snapin partway through install.
-
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.
-
I understand the frustration, believe me. Testing these things 5-8 minutes feels like years, especially when just simply trying to see if something is working, and I imagine that the same case can be said when you’re just trying to ensure all your software is installed as needed.
That being said, we’re rewriting the FOG Service currently and attempting to make things more modularized and controlled through the GUI directly. This doesn’t mean wait times won’t be any better, but we’ve already added more checks to the snapin installers to run at service boot. If there’s a task to reboot the system, and hopefully just because of a hostname change or ad join procedure, the snapins will not install, but rather the system will reboot and attempt the same steps.
Jbob’s already fixed the “expansion” of windows variable names such as %winroot% or %userprofile% which should help people as needed to interact more smoothly with their system and snapins.
Hopefully I can get the snapins, and all of the FOG related information, to be in a common directory to allow easier manipulation and control over the files in your fog server. This will take a little bit as I’m currently working to try allowing the “boot menu” customizable through the GUI.
-
Tom, I really appreciate your work and your support on here. Many thanks from Berlin.
-
There are different ways to accomplish this until the new client is ready; for example:
You can use psexec.exe to push them by hand if necessary.
You could push the snapins either before (need local administrator user and password) or after (need local administrator user and password or domain admin user and password) joining the domain.
You could also setup a startup script in your default image or use the unattended.xml to run batch files to start your snapins after setup.
You can use RunOnce Registry key…
Etc,
-
I have a similar issue with this, except for me my snapins seem to never run. I’ve had a basic .bat file which would just restart a machine sitting queued for a good 30 minutes. I’m looking at my fog.log file on the machine I’m trying to run the snapin on and it says this:
12/29/2014 9:49 AM FOG::SnapinClient Attempting to connect to fog server…
12/29/2014 9:49 AM FOG::SnapinClient Module is active…It will repeat this every few minutes. I get no notices of failures from the client or the fog server. For some reason my snapins are just not being sent.
