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.



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



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.



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 (19)

  1. Anonymous says:

    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.

  2. Mikael Rönnbäck says:

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

  3. Constantin Boulatnikoff says:

    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.

  4. WSUS Team says:

    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:)


  5. WSUS Team says:

    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?


  6. Mikael Rönnbäck says:

    Chinmay, that’s precisely my point yes, with approx 2000 servers (and some 20000+ clients) and only a 5 hour maintenance window every quarter for the servers I still feel installation in pending mode for a few hours is a much more preferrable alternative to leaving the servers unpatched for a few months.

    While I agree with you that this timewindow is way too small and seldom, the reason for this is that lots of the servers are really critical, i.e. we’re talking life and death as some of them control helicopter landings, others control pipes and valves on platforms, others again control ships or tankers or trucks.

    We’ve had LOTS of internal discussions on this topic and how to be SOX compliant, being secure and having good uptime, and the message from our application managers is that

    a) there is mostly no problem in patching (as long as they get to know it ahead of schedule and can check with each vendor), the real problem lies in the restart and subsequent downtime for their systems.

    b) since we’re still "rather" proactive in patching (at least we’re fairly up to date most of the time) we’ve yet to see any large crippling virus/worm attack, and because we still haven’t the patching is often seen as the thing causing most damage in the form of downtime. Unfortunately, but there’s little to put against that when uptime is priority one, a possibility of threat vs a real downtime, I can see their point of view.

    And again, if the servers were to be unpatched they might very well miss next time around too, and so it’d be no better by then either. Not saying WSUS or SMS are bad products, just that the +/- X minutes/hours in timing sometimes is not good enough 🙂

  7. Jason Gurtz says:

    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.

  8. pete says:

    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?

  9. Christian says:

    I HATE what Ms did with the new Windows Update.

    I even thought about disabling Automatic Updates at all. The annoying pestering restart-window sucks really.

    Even if I kill the windows update client, it just restarts.

    You are even so pestering that you destroy unsaved work to automatically reboot (this timebomb after resuming from hibernation).

    I hate Windows Update since this features was introduced.

    And of course an machine in pending state is perfectly finde IF I WANT IT!

    The company users will reboot anyway at the end of the day.

  10. lee says:

    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:  


    This is cut and paste from the the template file:

       POLICY !!NoAutoRebootWithLoggedOnUsers_Title

    KEYNAME "SoftwarePoliciesMicrosoftWindowsWindowsUpdateAU"

    #if version >= 4



    #if version >= 3

       EXPLAIN !!NoAutoRebootWithLoggedOnUsers_Help


    VALUENAME "NoAutoRebootWithLoggedOnUsers"




    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

  11. Thomas Laggner says:

    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

  12. ...1 says:

    Du musst ein Fachmann sein – wirklich guter Aufstellungsort, den du hast!

  13. Angela Merkel says:

    Du mußt eine NAZI sein! Deine facist tendancies stellen durch dar.

  14. mike says:

    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.  

  15. paul says:

    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 ;^).  


  16. sinema izle says:

    Thanks I hope that your success will go on.

  17. Rap says:

    yuru be kamil Hiphop, Rap, Ceza, sagopa, Kolera Hiphop, Rap, Gekko G Animasyon

  18. Greg Y. says:

    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.

Skip to main content