Condividi tramite


Download, Install and Reboot operations

 

There have been numerous posts where people ask about ways to delay (or cancel) the reboot of the client machine once the update is "installed".

Let me attempt to elaborate on the relationships between download, install and reboot operations and how they should be spaced in time for the client machine to be in the most stable and secure state.

 

Summary:

(1) Download and install are two independent and distinct operations.

(2) Install and reboot are two very closely tied operations.

 

Just downloading the update on your machine has no effect in patching the machine.

A downloaded but not-installed update does not affect the security or functionality of the machine in any way.

 

 

On the other side, for an update which requires reboot; the install and reboot operations should be tied together very tightly. For an update that requires reboot, the update is NOT installed until the system reboots. A partially installed update (pending reboot) results in a non-updated and insecure state of the machine. Also since this is a ‘synthesized’ state, it can result in instability.

Ideally, install and reboot should be a quantum operation.

 

 

Let me explain this point with an example.

Let's say update U requires reboot.

You install U on your machine and have not rebooted the machine yet.

At this stage the update is NOT fully installed. Only after the machine is rebooted, the update is fully installed.

 

So as an admin, one should try to view install and reboot operations as part of a single transaction.

The admin should attempt to minimize the time for which any machine is in a reboot pending state.

 

Conclusion:

Admins are far better off to schedule the installation of reboot required updates at a time when the system can be safely rebooted vs delaying reboot to introduce stability risk in combination with the system not being updated and protected.

 

Next:

There are various settings in the group policy which the can control the reboot behavior of client machine and the user experience around this.

Most relevant ones being

· No auto-restart for scheduled Automatic Updates installation

· Delay restart for scheduled installations

· Re-prompt for restart with scheduled installations

I will blog about it next. Stay Tuned…

 

Chinmay Parekh (WSUS)

Comments

  • Anonymous
    January 01, 2003
    Thank you for the post Chinmay. We have a large number of laptop users. The Laptops are not plugged into the network at night when updates are pushed out, so they get the updates when the users get here the next morning. Our desire is for the laptop to stay in that installed/non-rebooted state until the end of the day when the user will shutdown on their own to go home.  I believe this is one situation where separating the install/reboot process by a few hours is important to making the install seamless for the users. Currently, we're configured so that 30-minutes after they log in, the updates are installed and they receive the prompt to "restart now". The "restart later" option is grayed out. Two questions, then: 1) If I set the "delay restart for scheduled installations" option in the GPO, that seems like it will fix our problem, but will that force the restart instead of prompting the user at the end of that delay? 2) Is there a way to enable the "restart later" option without allowing the user to approve/disapprove updates? Looking forward to your next post.

  • Anonymous
    September 21, 2006
    I tend to disagree somewhat with this philosophy.

    Ideally it would of course be optimal to install and restart at the same time, however in a large corporate environment I would argue that sometime it is better to make sure patches are installed even if only in "pending" mode, rather than not installed at all.

    For example, if you only can do patch maintenance 4 times per year, then I see it as perfectly reasonable to make sure the patches are installed early on in the evening when your maintenance window occurs, to maximize the chances of patches being installed at all (for example since SMS is not a realtime system and may sometimes miss its target time by minutes or hours).

    This will result in the possibility of an instability during several hours until restart, but may be a better option than the servers not being restarted at the time you have specified to your users. (Additionally you may want to install other pieces of software at the same time and reduce the number of reboots).

    But the risks of instability can be minimized with good testing procedures, sending the same patches to a few test servers without restart some weeks before production date and let them run and see whether any problem occurs to them. (Naturally these would be for testing only and not have any real data on them).

  • Anonymous
    September 22, 2006
    I have two machines (servers), based on the Intel server platforms, one in office and one on remote co-location. Both servers has one problem. On reboot, they do not start, they stops on BIOS until USB keyboard plugged and Esc key pressed. I does not have solution fo this problem.
    So, while automatic reboot enabled, I periodically finding both machines with BIOS screen, waiting for the Esc.

  • Anonymous
    September 26, 2006
    Mikael . I see your point. You are basically comparing if you should keep your machine in pending-reboot state for 6 hours or unpatched state for 3 months.

    As a side note, 3 months patch management cycle looks a little long to me.

    Coming back to the point, I personally, would think that to keep machine completely unpatched for a month or two is better than keeping it in pending-reboot state.  However, I am not an admin, I'll ask experts around me and will post what they have to say on this:)

    chinmay

  • Anonymous
    September 26, 2006
    Constantin, I see that it can get very annoying. From our side, we are trying to make as few update to require reboot as possible.

    However, why does your machines ask for Esc key ? Does it boot in bios by default? why?

    chinmay

  • Anonymous
    October 02, 2006
    The comment has been removed

  • Anonymous
    October 27, 2006
    Most PC BIOS, by default, will display an error at POST if there is no keyboard attached.  Typically, the user must press some key <F1> or I guess <ESC> to get past the warning.  These types of errors also occur if there is a floppy drive configured in the BIOS and the physical drive stops working or is removed. Motherboards that are ment to be used headless in a server role, would typically have a bios option to continue on these warnings instead of asking for user input. The obvious workaround for a suboptimal bios would be to leave a keyboard attached.  I would hope most IT departments validate these types of things before rolling out hardware but I can understand some situations that could cause this hardware validation to not happen. In short, I really don't see how this is a WSUS problem.

  • Anonymous
    November 13, 2006
    What about the ability to delay the restart for non-admin users.  I'm want to force the install but the only option for non-admin users after the patch is installed is to Restart now.  I'd like my users to have the ability to delay the reboot for say 60 minutes or so.  This alows them to save their work and I can pester them every hour (or sooner)that they need to reboot.  I'm told this is a limitation with the current Update client, will there be any change soon?

  • Anonymous
    November 15, 2006
    The comment has been removed

  • Anonymous
    November 29, 2006
    I am attempting to use a group policy to institute automatic updates. So far I have the GPO set up except there is one thing I want to change but I can't find it even though I imported the latest wuau.adm template file.   the setting I am interested in setting via GPO is:   NoAutoRebootWithLoggedOnUsers This is cut and paste from the the template file:    POLICY !!NoAutoRebootWithLoggedOnUsers_Title KEYNAME "SoftwarePoliciesMicrosoftWindowsWindowsUpdateAU" #if version >= 4    SUPPORTED !!SUPPORTED_WindowXPSP1 #endif #if version >= 3    EXPLAIN !!NoAutoRebootWithLoggedOnUsers_Help #endif VALUENAME "NoAutoRebootWithLoggedOnUsers"    VALUEON  NUMERIC 1    VALUEOFF NUMERIC 0    END POLICY Why can't I see this as a setting in MY GPO?  I want to reboot if a user left their machine logged off, but not if it is logged on. Does this make sense.  I am using the latest production version of WSUS. Lee Duynslager

  • Anonymous
    December 05, 2006
    Hi Lee, exactly the same problem I have. We have 96% non Admin User. So non of them will be able to delay the reboot. Our current solution. Option 4 with a Install time and no reboot. The End User see following scenario: When they are shutting down there PC they have the Option "Shut Down and Install". The Scheduled time is somewhere at Midnight. So on the next day they will install the Update in the background and at the evening they shut down. So the maximum 8 hours are the PC in State Reboot Pending. To your trouble with the ADM. Have you tried the filter Option. In GPMC click on "Administrative Template" and then you can use in the Menu -> View -> Filter -> and remove the last Flag (something show full configured only) then you will see much more option in the GPMC. B.r. Thomas Laggner

  • Anonymous
    March 14, 2007
    Du musst ein Fachmann sein - wirklich guter Aufstellungsort, den du hast!

  • Anonymous
    August 18, 2007
    The comment has been removed

  • Anonymous
    December 14, 2007
    I'd have to agree that the ability to patch, and wait for a reboot is something that is sorely needed.  If patches come out Tuesday at 3 PM, I'm technically in an insecure state until I apply and reboot the servers.  What difference is it I install the updates and then wait to reboot?  Both are still leaving the computer unsecure.  When you have hundreds of servers that need patched and rebooted, it is unwise to merely have them all download, and all reboot at that same time as some don't always come backup.  you then are looking at an extended outage for servers.  For example, if I have 500 servers, and I patch them at 10 PM, then they all reboot, and 10 of them don't come back up, who knows how long until server #10 will be back up.  On the flip side, if I patch them all at 10 PM, then I can slowly reboot them all to minimize the associated downtime.  

  • Anonymous
    October 09, 2008
    Mikael Rönnbäck, you mention some of your server have life or death related criticality levels, I'm surprised you would rather have your servers in a pending reboot state vs. skip a patch maintenance window.  Frankly I would consider it fairly irresponsible to make a blanket statement on such an important decision.  Having the server in a synthesized state means the server is inherantly unstable.  I would not want to be the helicopter pilot with you as my sys admin ;^).   Paul

  • Anonymous
    December 11, 2008
    http://www.battery-export.com/dell/dell-inspiron-2200.html  Dell Inspiron 2200 http://www.battery-export.com/dell/dell-inspiron-2600-series.html  Dell Inspiron 2600 Series

  • Anonymous
    February 06, 2009
    Thanks I hope that your success will go on.

  • Anonymous
    July 31, 2009
    yuru be kamil http://www.kodes.com Hiphop, Rap, Ceza, sagopa, Kolera http://www.gekkog.com Hiphop, Rap, Gekko G http://www.maskanimasyon.com Animasyon

  • Anonymous
    April 13, 2010
    The problem I have with this feature is that I am the one who patches the 700 servers prior to the maint window, and local IT is responsible for doing the reboots.  The reboots need to be done in a certain order and having an auto shutdown is not acceptable.  We can not use WSUS to patch our servers anymore and have moved to HFNeChk because of this feature.  I'm sure you will find other larger companies doing the same.