1 Reply Latest reply on Oct 16, 2014 3:49 PM by Steven English

    Why is a Job Sent before UniUpdater?

    Richard Smith Jr Scout

      We have recently completed a major overhaul of our printing infrastructure:  2008 VMWare to 2012 R2 HyperV, UniPrint 8.3 - 9 and a brand change of each printer we use that communicate with Pharos.

       

      One of our bigger hurdles was that while the updater would pick up these changes and update accordingly, the users job was still sent and would charge/print an error page.  Is there a spooler or other Windows service/issue leading to the way this currently works or can it be changed?  To be more specific:

       

      Current: Popup client information entered -> users job is sent -> uniupdater is launched, etc.

      Proposed: Popup client information entered -> uniupdater is launched -> users job is sent once the 'No Updates' or 'Finished updates' process is complete

       

      Forgive me if this has been addressed in the past,

       

      Richard

        • Re: Why is a Job Sent before UniUpdater?
          Steven English Guide

          Good Afternoon Richard,

           

          If I remember correctly, the automatic updater runs completely independently of the popups.  What I mean by that is the printing mechanism checks the registry every time you send a print job to determine whether or not it should trigger the uniupdater (presuming it exists/is installed).  If installed, the uniupdater gets fired up as a completely separate process, and the popup print job continues on its merry little way.  I expect you could simply schedule the uniupdater to run at night when the machines are unprotected (if DeepFreeze or other security software is installed).  That should result in the machines always being 100% up to date each day.  If you are making changes during the middle of the day, there is not much that can be done short of triggering the updater remotely.

           

          In response to the proposal you made above, because the spool file has already been generated (or at least started generating) before the popup client ever appears, any updates made to the packages by the uniupdater would fail to provide any benefit to the job just submitted  - even with the rearranged workflow - because at this point in the process it has been already been rendered to the spool file.

           

          Regards,

          Steven