• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Delayed Snapin execution since 1.2.0

Scheduled Pinned Locked Moved
Windows Problems
4
10
3.4k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T
    TheGrinch
    last edited by Aug 20, 2014, 1:08 PM

    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?

    1 Reply Last reply Reply Quote 0
    • E
      Edgardo Peluffo
      last edited by Aug 20, 2014, 6:20 PM

      I believe snapin execution has always been delayed by 5 minutes by default. It can be changed on the client config.ini

      [snapinclient]
      checkintime=307

      Somebody correct me if this wrong information please

      1 Reply Last reply Reply Quote 0
      • T
        Tom Elliott
        last edited by Aug 21, 2014, 12:28 AM

        [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.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

        Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

        Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

        1 Reply Last reply Reply Quote 0
        • T
          TheGrinch
          last edited by Aug 21, 2014, 7:01 AM

          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.

          1 Reply Last reply Reply Quote 0
          • T
            Tom Elliott
            last edited by Aug 21, 2014, 9:58 AM

            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.

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

            Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

            Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

            1 Reply Last reply Reply Quote 0
            • T
              TheGrinch
              last edited by Aug 21, 2014, 10:08 AM

              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.

              1 Reply Last reply Reply Quote 0
              • T
                Tom Elliott
                last edited by Aug 21, 2014, 10:13 AM

                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.

                Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                1 Reply Last reply Reply Quote 0
                • T
                  TheGrinch
                  last edited by Aug 21, 2014, 10:15 AM

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

                  1 Reply Last reply Reply Quote 0
                  • E
                    Edgardo Peluffo
                    last edited by Aug 27, 2014, 2:13 PM

                    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,

                    1 Reply Last reply Reply Quote 0
                    • J
                      jamesb
                      last edited by Dec 29, 2014, 3:55 PM

                      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.

                      1 Reply Last reply Reply Quote 0
                      • 1 / 1
                      • First post
                        Last post

                      157

                      Online

                      12.0k

                      Users

                      17.3k

                      Topics

                      155.2k

                      Posts
                      Copyright © 2012-2024 FOG Project