locked
Allowing a service to auto-update during scheduled update window RRS feed

  • Question

  • We're using SteadyState (currently 2.0, soon 2.5) with Windows XP Pro SP2 (soon SP3) to create "Print Release Station" kiosks; i.e., a machine running the print management software who only purpose is to let users authenticate and release their queued jobs for printing.  In this case, the print management software is GoPrint, which installs as a service and so is always running.  The computer is also set to AutoAdminLogon with a restricted user account so that users can interact with the GoPrint user interface.

    Here's the problem: The Schedule Software Update feature in SteadyState expects to run updating programs or scripts that pull updates down to the client computer on demand.  However, this print management service expects to receive and apply updates pushed to it every time it starts.  I would not have thought this would be a problem: During our update period (4:00am), while WSUS is getting updates and SCTMcAfeeVirusUpdate.vbs is getting updates, I thought the GoPrint service would be running as usual, and so detect and receive its pushed updates at that same time, and everything would be retained. 

    However, it appears that either the print management service updates are not being received (is the service even running?), or they are selectively not being retained.  Now, I can write a script that applies the updates if they have been received, but I don't know how to force them to be received, since I cannot "pull" them--they are pushed by the server service when the local service starts.  This problem is not specific to GoPrint or even to print management software; it would happen with any installed service that expects to update itself.

    So how do I make this work?  Should I write a script to start the service and wait for it to update itself?  Should I instead create a Windows scheduled task to start the service and thus the update, and schedule it for 4:00am knowing that's the update window?  (Or 4:05am--what time?)

    There is a brief description in this forum of how the SteadyState Schedule Software Updates works with Windows Disk Protection, but it doesn't go into enough detail for my purposes.  For example, it doesn't say whether other installed services are allowed to run or not.  It also doesn't specify what order the Windows Updates and other scripts are run, or how long they run for.

    Anyone who has worked with any self-updating service like this, I'd love to hear your solution.                                  Sande
    • Changed type Sean Zhu - Thursday, April 9, 2009 2:54 AM
    • Changed type Sean Zhu - Wednesday, April 15, 2009 3:37 AM
    Monday, April 6, 2009 11:11 PM

Answers

  • Hi,

    SteadyState does not disable other services when it runs its update cycle.  However, it does disable all user accounts.  If your service logs on using an account other than the built-in service accounts (local system, local service, etc.), there's a strong chance this is the reason it fails to run.

    The update scripts run in this order:
    1. Windows Updates
    2. Custom Script
    3. A/V Update Scripts
    The scripts are run sequentially, and the update process ends when the last script returns.  Thus, update scripts must not simply start an asynchronous update handled by another process, then return while that asynchronous update runs in the background. 

    Scripts are limited to 30 minutes by default.  If they run longer than that, SteadyState will give up and begin running the next script.  This time limit can be changed by a reg key in case 30 minutes is too short.
    Thanks,
    Rob Elmer
    Development Lead
    Windows SteadyState
    • Marked as answer by Sean Zhu - Wednesday, April 15, 2009 3:37 AM
    Saturday, April 11, 2009 4:30 AM

All replies

  • Hi,

    SteadyState does not disable other services when it runs its update cycle.  However, it does disable all user accounts.  If your service logs on using an account other than the built-in service accounts (local system, local service, etc.), there's a strong chance this is the reason it fails to run.

    The update scripts run in this order:
    1. Windows Updates
    2. Custom Script
    3. A/V Update Scripts
    The scripts are run sequentially, and the update process ends when the last script returns.  Thus, update scripts must not simply start an asynchronous update handled by another process, then return while that asynchronous update runs in the background. 

    Scripts are limited to 30 minutes by default.  If they run longer than that, SteadyState will give up and begin running the next script.  This time limit can be changed by a reg key in case 30 minutes is too short.
    Thanks,
    Rob Elmer
    Development Lead
    Windows SteadyState
    • Marked as answer by Sean Zhu - Wednesday, April 15, 2009 3:37 AM
    Saturday, April 11, 2009 4:30 AM
  • Thanks, Rob, that's exactly the information I was looking for.

    So, for the record, the following is how the SteadyState Schedule Software Updates works with Windows Disk Protection:
    • 10 minutes before the hour, displaying warning that updates will run on the hour.
    • Logging off any active user (actually starting 1 minute before the hour).
    • Restarting the computer so that Windows Disk Protection can clear disk changes.
    • Disabling shared user accounts to prevent unapproved disk changes from being introduced while updates are in progress.  (Services running under service or system accounts are not disabled.)
    • Turning on Retain all changes permanently in Windows Disk Protection to ensure that the updates are not removed the next time the computer restarts.
    • Downloading and installing updates (until last script returns):
      1. Windows Updates
      2. Custom Script (if any)
      3. A/V Update Script (if any)
    • Restarting the computer.
    • Turning Windows Disk Protection back to Remove all changes at restart for increased security on your shared computer once updates have been installed.
    Monday, April 13, 2009 5:34 PM
  • Yes, that's correct.
    Thanks,
    Rob Elmer
    Development Lead
    Windows SteadyState
    Wednesday, April 15, 2009 3:42 AM