locked
Update showing as succeeded in update history but still pending installation (KB2975719) RRS feed

  • Question

  • I just installed September patches. KB2975719 is showing as downloaded but not installed in both the WSUS console, and the Windows Update control panel of servers.

    The WindowsUpdate.log file shows the patch as successfully installed:

    2014-09-20    19:10:07:325     704    a0c    Report    REPORT EVENT: {FE320875-D2A9-44A5-8F8F-5EEA2782EE27}    2014-09-20 19:09:50:763+0100    1    190 [AU_SCHEDULED_INSTALL_SUCCESS]    101    {756F8A5D-1588-4CFA-9B00-3DC89266CEE0}    204    0    AutomaticUpdates    Success    Content Install    Installation Successful: Windows successfully installed the following update: Update for Windows Server 2012 R2 (KB2975719)

    The WindowsUpdate control panel "View update history" also shows it as succeeded

    And so does the event viewer - SYSTEM:

    Source: WindowsUpdateClient; ID 19; Message: Installation Successful: Windows successfully installed the following update: Update for Windows Server 2012 R2 (KB2975719)

    Despite these, the KB2975719 still shows as ready to install in the Windows Update control panel. "One important update is available" -> "Update for Windows Server 2012 R2 (KB2975719).

    I installed the patch manually on one server and it did install correctly. I now have two lines showing success for KB2975719 in the "view update history".

    I noticed this like in my update log and was wondering if it could be part of the problem:

    2014-09-20    19:03:32:274     708    a18    Shutdwn    user declined update at shutdown

    It's not the first time I face patches that do not install. It seems to be a recurring issue on my servers. Not sure if I did something wrong with the configuration of WSUS. Each month I have 1-2 patches that do not install while other are installing properly.

    Has anyone seen this already of have an idea of how I could troubleshoot this further?

    Monday, September 22, 2014 9:40 AM

Answers

  • There are two parts to an update installation.

    • The part that runs in the context of the WUA.
    • The part that runs at shutdown/startup.

    The part that runs in the context of the WUA can finish successfully, and the WUA will log it as successful. But if the remainder of that effort fails at shutdown/startup, then the update is not installed. The WUA does not report this type of "failure", because it knows nothing about this type of failure. The fact that this can happen is a defect in the patching mechanism, but that's what happens when the servicing stack and the agent are written and maintained by two different groups ... neither knows what the other does.

    First step here is to download and run the latest System Update Readiness Tool and see what it says about these machines.


    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.

    Monday, September 22, 2014 3:14 PM

All replies

  • There are two parts to an update installation.

    • The part that runs in the context of the WUA.
    • The part that runs at shutdown/startup.

    The part that runs in the context of the WUA can finish successfully, and the WUA will log it as successful. But if the remainder of that effort fails at shutdown/startup, then the update is not installed. The WUA does not report this type of "failure", because it knows nothing about this type of failure. The fact that this can happen is a defect in the patching mechanism, but that's what happens when the servicing stack and the agent are written and maintained by two different groups ... neither knows what the other does.

    First step here is to download and run the latest System Update Readiness Tool and see what it says about these machines.


    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.

    Monday, September 22, 2014 3:14 PM
  • The issue is caused by KB2993651. This is a pre-requisite of KB2975719, but WSUS doesn't know.

    Well, strictly speaking, WSUS doesn't know crap; it only knows what it's been told by a Windows Update Agent. Pedantically speaking, what you mean here is that the detection logic for KB2975719 appears to fail to properly evaluate the prior existence of KB2993651. KB2993651 (MS14-041, August 2014) is a Security Update. KB2975719 is the August 2014 Update Rollup. To my knowledge, there is NO dependency relationship between these two updates, BUT if you're having issues installing them concurrently, the simple solution is to not do that.

    My workaround is to manually install KB2993651 and reboot before installing KB2975719.

    There ya go. And herein lies the fundamental dysfunctionality of using MDT to deploy a year's worth (or more) of updates in one pass.

    The *better* solution here is to apply those patches to the IMAGE being used to deploy WS2012R2, rather than trying to install them in one pass after the IMAGE has been deployed.


    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.

    Saturday, October 4, 2014 1:15 AM
  • Please read the KB article for 2975719. It clearly lists update 2993651 as a pre-requisite.

    Okay, so why are we having this conversation? It's a documented prerequisite. Having access to that information, it's then incumbent upon you to install the August KB2993651 Security Update, before the September KB2975719 Update Rollup as indicated by the documentation for the update.

    That's pretty much the way 99% of people are going to patch their systems anyway. (FWIW, I never encountered this issue on any of my systems because I always install Security Updates first and I installed the Update Rollup last.)

    Yes, the Update Rollup does not detect that prerequisite. Fact is, there are a LOT of updates that do not have logic to detect for prerequisites, so in that this is not really unusual at all., albeit somewhat inconvenient if you're trying to throw months of updates at a machine in a single pass.

    What I'd say is more disconcerting, is not that the detection logic fails to detect the prereq, but that the "Update Rollup" didn't include the prerequisite update in the first place.

    In any event, you're right, this is something for the Windows SE team to fix. That would be something to discuss with them in the Windows OS forum.

    We use MDT to "build and capture" the fully-patched image that we then deploy with SCCM.

    But that's not what I said. What I said was to patch the IMAGE (not patch a reference machine and recapture a patched image), so that the IMAGE is always up to date.

    But even if you patch a reference machine, and recapture the image, and keep the reference machine up-to-date on a monthly basis, or only patch one-month-at-a-time of updates, you would have never encountered this issue. Fundamentally you hit this issue because you're deploying multiple months of update simultaneously.

    Patching the IMAGE as the update are released would completely avoid this issue (as well as eliminate the need to regularly recapture the image) as the August Security Updates would have almost certainly been applied prior to a September Update Rollup.


    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.

    Sunday, October 5, 2014 9:31 PM
  • I'm sorry, I just want to find the right place to get this fixed. We are not looking to change our OSD process. It was recommended to us directly by Microsoft. If there's a better place for this conversation to take place, I'm happy to have it there. Thanks very much for your thoughtful responses.

    Well.. the only possible way to consider the possibility of getting something fixed is to talk to the Windows OS SE team who authored the update package.

    But to be frank, your odds are quite slim, as my guess would be their argument would be that there is no defect in the package, as the prerequisite is clearly documented in the update documentation.

    But my .02... you should look at changing your OSD processes -- for exactly this reason. This is not the first time this scenario has occurred, nor will it be the last. The best protection is to install updates in chronological order of Release Date.


    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, October 7, 2014 1:01 AM
  • The official place to get this fixed is through Microsoft Support. Microsoft has full support for MDT 2013, so you can call up Microsoft Support, and if it's a blocking issue, they can provide you with a fix.

    I am going to have to disagree with Lawrence here ( my .02 :^). Offline patching may be common, but so is updating images through online tools like MDT and SCCM/OSD. Creating images with MDT LiteTouch is an officially recommend best practice from Microsoft: http://technet.microsoft.com/en-us/library/dn818437.aspx

    On a personal note, I generally dislike offline patching mainly due to the ordering instructions like those described in the thread. Security patches first? Patches installed in order by release date? Can someone point me to some officially prescribed guidance, best practices and/or reference designs from Microsoft that outline installation of offline patches for windows images? For example a list of patches and the correct order to install in Windows 7 and above. I've taken a look at WSUSOffline.net, but wow, that's one ugly baby.

    Specific fix

    In this case, ZTIWindowsUpdate.wsf is getting confused by the Windows Update Agent. First, the Update Agent finds this update:

    INSTALL - 9fed22fc-cdd2-4724-8463-c08f21de6196 - Update for Windows 8.1 for x64-based Systems (KB2975719) - 13 MB

    Then, after a reboot, the update agent finds another update:

      FOUND - 9fed22fc-cdd2-4724-8463-c08f21de6196 - Update for Windows 8.1 for x64-based Systems (KB2975719) - 183 MB

    Although these updates both have the same Update ID, note that they have different install sizes? Are they really the same package? Historically, MDT has, skipped over Updates that were previously installed, due to poor detection logic in some Updates (Get's into an infinite loop, installing patches that were already installed). The change is to allow MDT to install an Update even if the update was installed previously.

    I have made some changes to ZTIWindowsUpdate.wsf to fix this problem, and posted here:

    https://onedrive.live.com/redir?resid=5407B03614346A99%2113517


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Wednesday, October 22, 2014 11:02 PM
  • I am going to have to disagree with Lawrence here ( my .02 :^). Offline patching may be common, but so is updating images through online tools like MDT and SCCM/OSD. Creating images with MDT LiteTouch is an officially recommend best practice from Microsoft: http://technet.microsoft.com/en-us/library/dn818437.aspx

    I think perhaps you've misunderstood my point and thus are unnecessarily disagreeing.

    I have no issue with using SCCM or MDT to deploy patches after a bare-metal OSD.

    I do think it's a risky maneuver to deploy the *RTM* instance of the OS, and then expect to add 5-9 years of updates in one pass. It's also just as risky to deploy a Win7SP1 ISO and then expect to deploy three years of updates in a single pass.

    Security patches first? Patches installed in order by release date? Can someone point me to some officially prescribed guidance, best practicesand/or reference designs from Microsoft that outline installation of offline patches for windows images?

    Other than my ten years of experience in this discipline? Nope. I'm just pointing out what works successfully -- and what doesn't. This forum, and conversation, isn't just about what's "officially documented"; it's about how to actually USE the product and processes successfully. Ninety percent of what we discuss in this forum isn't in the documentation (and the 10% that is probably doesn't matter since nobody reads it anyway, it seems).


    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, October 23, 2014 2:37 AM
  • Thanks for the reply Lawrence,

    I must admit that I'm new to the "offline patching" thing, having spent most of my time working with the "Online" Windows Update Agent. :^)

    With the upcoming release of Windows 10, and the changes in release cadence, I felt it was important to revisit offline patching as a complement to the overall deployment process. Still trying to find the sweet spot for offline patching; Manifest/Ordering/Exceptions.

    If you or anyone else has specific guidance, please let me know. Additionally, Patching/Updating and Release Management will be my #1 investigation topic at the MVP summit in Nov. :^)


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Thursday, October 23, 2014 3:51 AM