none
Concerns with WSUS and Automatic Updates involving server restarts and update validation

    Question

  • I've recently been asked to update all of our company's Windows servers, which haven't installed an update since August 2013. In the past, WSUS and Local GPO were used to deploy and install server updates.

    From what I've read, most admins elect to have server updates installed in the middle of the night in an effort to minimize the impact restarts will have on business. I'm having a hard time finding information on how the automated process works in regards to restarting. I understand, as long as Group Policy is configured with the defaults in regards to restarting, the systems restart automatically after installing updates. What I need to understand is how does the automated process work when a system requires multiple restarts? 

    Also, what is your process for validating that all updates have been downloaded to WSUS, the updates installed successfully and that the installed updates haven't interfered with the services, software, and performance of the servers? 

    Thanks in advance. 

    Chuck

    Tuesday, February 25, 2014 3:48 PM

Answers

  • I've recently been asked to update all of our company's Windows servers, which haven't installed an update since August 2013.

    Ouch.
    I'm having a hard time finding information on how the automated process works in regards to restarting.
    It works exactly the same on servers with WSUS as it does on desktops with Windows Update, and this process really hasn't changed in 20 years.
    What I need to understand is how does the automated process work when a system requires multiple restarts?
    This is an ugly misnomer about Windows Update, and has caused exponentially more unnecessary consternation than have existed actual systems in this condition. Generally speaking, it would be an extremely rare situation where any system required multiple reboots... even ones not patched in six months. The primary example would be a machine not patched with the latest service pack. Since service packs must be installed exclusively, they generate their own reboot, and the post-service pack updates would require a second reboot. Otherwise, almost every "multi-reboot" sceario I've seen/heard of was directly attributed to improper patch approval and patch deployment which resulted in a system installing only the partial collection of updates needed. Ergo, the multiple reboots were caused because not all updates were available for installation when they should have been, and not because it was necessary at all. 
    Also, what is your process for validating that all updates have been downloaded to WSUS, the updates installed successfully
    Review the console. Look for exceptions.
    and that the installed updates haven't interfered with the services, software, and performance of the servers?
    Does the stuff work after installing updates? (Ideally this question is answered by TESTING on a LAB machine before deploying updates to production systems.)

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Tuesday, February 25, 2014 6:09 PM
    Moderator

All replies

  • I've recently been asked to update all of our company's Windows servers, which haven't installed an update since August 2013.

    Ouch.
    I'm having a hard time finding information on how the automated process works in regards to restarting.
    It works exactly the same on servers with WSUS as it does on desktops with Windows Update, and this process really hasn't changed in 20 years.
    What I need to understand is how does the automated process work when a system requires multiple restarts?
    This is an ugly misnomer about Windows Update, and has caused exponentially more unnecessary consternation than have existed actual systems in this condition. Generally speaking, it would be an extremely rare situation where any system required multiple reboots... even ones not patched in six months. The primary example would be a machine not patched with the latest service pack. Since service packs must be installed exclusively, they generate their own reboot, and the post-service pack updates would require a second reboot. Otherwise, almost every "multi-reboot" sceario I've seen/heard of was directly attributed to improper patch approval and patch deployment which resulted in a system installing only the partial collection of updates needed. Ergo, the multiple reboots were caused because not all updates were available for installation when they should have been, and not because it was necessary at all. 
    Also, what is your process for validating that all updates have been downloaded to WSUS, the updates installed successfully
    Review the console. Look for exceptions.
    and that the installed updates haven't interfered with the services, software, and performance of the servers?
    Does the stuff work after installing updates? (Ideally this question is answered by TESTING on a LAB machine before deploying updates to production systems.)

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Tuesday, February 25, 2014 6:09 PM
    Moderator
  • Makes perfect sense.

    Thanks for your response Lawrence. 

    Tuesday, February 25, 2014 6:44 PM
  • Another quick question, Lawernce. How often do updates to Windows servers interfere with a servers performance, services, and/or software? In other words, after installing updates, what level of validation should be involved in making sure the updates are not causing issues on the server? With such a large batch of updates to install this weekend, I want to be prepared for worst case scenarios involving systems not booting up, required services not starting, software conflicts, etc. We have a 2008R2 server and a 2003 server to test on, but they're not really representative of the production servers in terms of the roles they play and services they run. Just to clarify, this is my first time updating Windows servers.

    Thanks in advance. 

    Wednesday, February 26, 2014 1:55 PM
  • How often do updates to Windows servers interfere with a servers performance, services, and/or software?

    I saw this question in the other thread, but the already-provided answers pretty much summed it up. My answer to this question would be "Almost Never". In the one-in-a-thousand scenario where this does happen, it's almost always found by larger organizations during lab testing in the first 24-48 hours after release, and the rest of the world knows about it by the next day ... thus my strong encouragement to tap into the communities that discuss patch testing and patch quality so you can get these kind of "heads up" notifications before subjecting your own systems to those rare situations.

    In other words, after installing updates, what level of validation should be involved in making sure the updates are not causing issues on the server?

    As noted in the other thread, this is the role of pre-deployment testing. If a patch is so onerous that it's going to mess with performance, services, or other application software, that will almost immediately show up on a test system, and thus the impact on a production system can be completely avoided.

    With such a large batch of updates to install this weekend, I want to be prepared for worst case scenarios involving systems not booting up, required services not starting, software conflicts, etc.

    One of the other things you can do is be judicious about which updates are deployed during your weekend maintenance event. Minimizing the list is a good objective. For starters, I strongly suggest not including .NET updates with OS updates; for that matter, personally I prefer to only install .NET or Application updates onto a system where the OS is fully patched. Consider that those .NET/Application updates were developed/tested by Microsoft on "fully-patched" systems, so there's no real knowledge of what might/could/will happen when such patches are deployed to a not-fully-patched system.

    Second, to minimize the number of updates deployed, defer the updates that do not require a system restart (another useful piece of information that can be acquired through lab testing). An update that does not require a restart can be installed at anytime (e.g. overnight a few days later).

    Third, some of those updates may just not need to be installed at all... ever. (If you don't use Internet Explorer from a server console; how important can IE updates really be on that system?)


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Thursday, February 27, 2014 5:09 AM
    Moderator