SharePoint CUs and Windows Update

Be aware that starting with February 2015 CU SharePoint Product Updates including non-security product updates will be made available via Windows Update.

E.g. for February CU the following fixes are offered through windows update for SharePoint 2013:


The fixes shipped using windows update are the individual package release in a given CU. The fixes I link to in my blog posts are the server or "Uber" packages. See my article on SharePoint patching demystified for details.

What does this mean:

  • If you have windows update enabled or WSUS configured to push SharePoint fixes automatically to your SharePoint farms it will guarantee that your SharePoint servers will always be up-to-date. The only thing you need to plan is to run PSConfig from time to time to ensure that not only the binaries or your box but also the SharePoint databases get updated.
    A caveat is that evaluating the fix in a test environment before applying it on the production farm will be more complicated.
  • If you have windows update disabled nothing changes. You can plan the installation of the CU to be installed and evaluate it. In this case I would encourage you to install the "Uber" packages I list in my blog posts as it ensures that all components are at the same patch level.
  • As always you should ensure to install the security related fixes as soon as possible.
Comments (49)

  1. anonymouscommenter says:

    What are the implications of running an upgraded server without running psconfig? Is there a mechanism to automatically notify that SharePoint needs psconfig?

  2. anonymouscommenter says:

    Hey Stefan!

    Does that mean that when a CU has been released the Windows Updates will include these Updates on the same day or are they going to be better tested? I'm asking because the last CUs always included many regressions.

  3. anonymouscommenter says:

    With the quality track record of CUs, I fail to see any sense in this. I believe it's quite common scenario WU patches are installed by mistake, and now it may mean a corporate wide service goes down due to that or starts misbehaving. #badidea

  4. Hi Piotr,

    in this case the farm is running in backward compatibility mode till PSCONFIG is run. See here for details:


  5. Thank you, interesting bloB post. 😉
    You, Jörg Sinemus AND Todd Klindt are doing a good job regarding background information on patching and updates.

  6. Hi Chris,

    with the number of fixes included in the CUs and the number of different configurations possible with SharePoint it is impossible to guarantee that no regressions can occur.
    Thats why it is important to evaluate a CU in a test environment before applying it to a production farm.

    Production farms should have a defined patch management which ensures that patches are only applied after being evaluated in a test environment (and that includes all type of patches – e.g. windows patches, .NET framework patches, and also SharePoint patches).


  7. Thanks Arjan for your feedback! 🙂

  8. Hi Jussi,

    a server responsible to host a corporate wide service should never have automatic installation of updates enabled. Patch management for such a server requires evaluation of all fixes in a test environment as I explained to Chris above and afterwards installation
    of the fixes in a planned patch time window.


  9. anonymouscommenter says:

    Hi Stefan,
    Your example mentions SP2013 and this is tagged with 2010 so will the windows updates cover both?



  10. Hi Tony,
    an example is an example and not a complete list.
    This applies to 2010 and 2013.

  11. anonymouscommenter says:

    As chris posted, this is a pretty silly move. It ensures that administrators will be even less likely to keep their servers patched against common windows vulnerabilities, while ensuring that those who do are more likely to break their SharePoint farms.

    Factor in the dismal track record of these CUs, and the future gets pretty dark.

    It seems unlikely to me that testing Windows Updates includes testing SharePoint Cumulative Updates. Everything about how SharePoint works (complexity, multiple tiers, variations in configuration, custom code) screams that auto updating is a terrible idea.

    Seems you have a fairly rosy view of how patch management works in most companies. This is unfortunate.

  12. anonymouscommenter says:

    If I remember right this is how it used to work on SPS2003, with the result that SP environments got broken when Windows Update pushed the SP updates to those environments with no change of testing (unless you disable automatic Windows Updates, which many
    admins were not willing to do, because good or bad they have automatic updates going on due to budget constraints, as doing automatic updates is cheaper than doing them manually). This is probably not a very good move. So I agree with Jussi here.

  13. anonymouscommenter says:

    Como el título del post indica, a partir de este mes las todas las actualizaciones para SharePoint incluyendo

  14. anonymouscommenter says:

    Quite risky move. I'm worried that most of small environment will met problems connected with this change.

  15. Chen V says:

    Not a good move. If things go green SP admins will be happy. It’s impossible to isolate the issue after any custom solution deployments.

  16. anonymouscommenter says:

    This post shouldn't be a surprise to anyone. Microsoft is just accelerating the downfall of on-prem SharePoint to try and drive everyone to o365. Sad that its come to this. Once again there is zero consideration given to enterprises as the team works in
    a world of unicorns and rainbows.

  17. anonymouscommenter says:

    Has Microsoft officially announced this change?

  18. anonymouscommenter says:

    I had this issue last week, and noticed these patches being pushed down to one of my SP2013 farms. One of the updates removed the "SpDataAcces" role to the Profile database for most of my web app pool accounts, which caused the Newsfeed web part to stop
    working. This meant that anywhere that this webpart existed, the page wouldn't render. Keep an eye out in your ULS logs for this type of messages if you get the same type of issue: "SqlError: 'The EXECUTE permission was denied on the object 'Admin_GetPartitionProperties',
    database 'ServiceApp_Profile_DEV', schema 'dbo'".

    I'm VERY disappointed about this change; as you can see above, some farms still get problems from SP updates, and pushing them out via Windows update is just asking for trouble. Now that CU's are released monthly, if Admins are forced to receive these updates,
    then they're going to be kept very busy with the fun task of testing, and service disruption when PSCONFIG has to be run (let alone the fear of seeing the dreaded 'Configuration Failed' message). More of my thoughts on CU's here:

    Andy Talbot

  19. anonymouscommenter says:

    Hi Stefan, very interesting post! Thank you

  20. anonymouscommenter says:

    When you look at, it shows 2 updates for each update, one a standard update and one a "farm-deployment" update. I manage our SCCM infrastructure which handles the OS patching of our servers in our environment. I don't see these
    "farm-deployment" updates in our catalog (I see the standard "non-farm-deployment" patches as I always have. Does anyone know if these updates are being released to the SCCM Software Updates Catalog?


  21. Any idea if workflow manager and WAC servers will be updated the same way going forward?

  22. Hi JScott, for WAC server it is a clear YES.
    For Workflow manager I don’t have information, sorry. Thats a different team involved.

  23. "I list in my blob posts" – Stefan, are you planning to RBS your "blob" posts as well 🙂

  24. Thanks Hilton!
    I fixed the spelling problem.

  25. anonymouscommenter says:

    I think I've seen SharePoint updates that had 'Security' in their title come through via Windows Update – will there be some sort of identifier to in WU to note if a SharePoint update is security-related, versus a CU?

  26. anonymouscommenter says:

    Similar to the post from my colleague Stefan (SharePoint Server 2013 screenshots) I can talk a bit about

  27. anonymouscommenter says:

    My understanding is that even with previous SharePoint updates via WSUS, they only could deploy on and install where you chose a "Standalone" 2010 Installation. If you chose "Server Farm" the WSUS updates would not auto install. Has this changed too?!?!
    Forcing changes in a "Server Farm" installation where you may a larger environment (i.e. 4-8 servers) that would be devastating. Running PSConfig on 8 servers can take almost 2 hours to complete (mostly because you ultimately still have to run psconfig on
    one box at a time). And that is when everything works perfectly/! Please tell me that Microsoft hasn't flipped their lid completely and set us up to have our farms blow up. It is already hard enough to vet out when a regular patch like somthign on IIS or .Net
    is causing problems in my SharePoint farm without throwing unwanted cumulative updates as well.

  28. Hi Don,

    that has changed long ago as 2010 and 2013 do not require to run PSCONFIG immediatelly and SharePoint works even with different patch levels in the farm for a short while till you have time to execute PSCONFIG.


  29. anonymouscommenter says:

    You say that SharePoint works with different patch levels but the instant that the binaries are applied this is breaking our ability to move content back and forth between the Development, QA, and Production environments. We can copy sites from a lower
    farm version to a higher farm version but when we need to troubleshoot a production issue, we are no longer able to restore the site into QA or DEV because the restore process throws the following error: "Restore-SPSite : Your backup is from a different version
    of Microsoft SharePoint Foundation and cannot be restored to a server running the current version." The SharePoint community is strongly divided on whether a CU should be applied if you are NOT experiencing a problem. We have held a strong stance that we do
    not apply a CU unless we are having a specifically cited problem. Rolling out these CUs were planned well a month in advance and scheduled around developers' commitments and go-live dates. CUs were never applied until the next CU had been released due to the
    horrible track record of Microsoft having to retract CUs. Furthermore, extensive preparations went into making sure that the entire farm had a complete and verified backup prior to applying any SharePoint patch. We have to contend not only with the base SharePoint
    product but several third-party bolt-ons as well. I was able to maintain the same version of SP build throughout the enterprise landscape. Since this change I have a huge mess of disjointed and mismatched versions all over the place. It is naïve to think that
    in large enterprises with hundreds of servers that everyone flawlessly ensures that all Dev boxes are patched before QA and they in turn are before patched production through an entirely automated process. This decision from Microsoft has created a notable
    hardship with no clear warning and left many scrambling to not only clean up an unwanted mess. Additionally we now have to devise a way to prevent these problems form occurring potentially every month. This decision does more harm than good in my opinion and
    does not serve to help Enterprise customers to provide a stable environment for our users.

  30. anonymouscommenter says:

    What's weird to me is that it's been like this since .. august or september for me! Since then we've gotten Sharepoint updates through our on premise WSUS server wether I wanted it or not. My first reaction was "wtf, how can they do this without telling
    anyone". Well now they do. And most people agree with what I thought back then which was "why? Why would you do this!?". Our company, even though we have ~2000 users, shouldn't really need a dedicated engineer for just Sharepoint maintenance since all we do
    is use it for document libraries basically (although mission critical since it's every document we've ever made in the past 10 years stored there), but stuff like this means I (whos Sharepoint skill was a mere bonus when I was hired) have to sit with Sharepoint
    almost all the time and deal with stuff like this! I can't tell you how annoying it is when I think everything is peachy and I have a small issue I need Microsoft tech support, they start a remote session and say right away "sorry man, we can't help you until
    you've applied the patches you've installed" and I'm going "huh? why does it say "upgrade required, I didn't do anything". But if MS think that a small company that has a Sharepoint farm for document repository has the time and resources to have an automated
    or even manual routine for patchining through DEV, TEST and then PROD while constantly testing functionality without also suffering downtime (which psconfig always does) and doing this once a month, then that is unfortunately incorrect.
    (and we're a pretty IT intense company and have monthly "patch thursdays" when we spend all night patching all servers and not even that is enough to get these patches installed, let alone applied. That's assuming I even work those patch nights which isn't
    something I should need to do)

    Fortunately for everyone it was easy to filter out and decline the updates in our on-prem WSUS server so I'm good…

  31. Hi Don,

    the fixes you have seen in the past were just the SharePoint security fixes. This was introduced a couple of month ago to ensure that SharePoint security fixes are deployed using the same channels as security fixes of other Microsoft products.

    And security fixes should always be tested and applied as soon as possible.

    In February you have seen non-security related fixes on Windows Update as well.
    That is the important difference.


  32. anonymouscommenter says:

    Be aware that on SBS 2011, unless you psconfig after installing a SharePoint update you just broke backup on the server. On that platform psconfig does have to be done immediately.

  33. anonymouscommenter says:

    "a server responsible to host a corporate wide service should never have automatic installation of updates enabled. Patch management for such a server requires evaluation of all fixes in a test environment as I explained to Chris above and afterwards installation
    of the fixes in a planned patch time window." << In a perfect world, yes. In a big corporate with dedicated personnel for Windows Updates and SharePoint, yes. For all the others (majority? such as SMB), no.

  34. anonymouscommenter says:

    Buenas, Hemos considerado relevante escribir este post, donde comentemos los nuevos criterios usados

  35. anonymouscommenter says:

    I am concerned about this new process. We had an incident back in July 2014 where Office Server updates got applied to a couple of our production SharePoint servers and it "broke" Excel Services. We had to scramble to apply the July 2014 CU to the farm to get
    Excel Services back working. Add to this, we later discovered that the July 2014 CU broke the People Picker on lists (had to elevate users to manage lists for People Picker to work). This was fixed with September 2014 CU. How can we ensure this process won't
    break services? How can we make sure the Windows Update service doesn't automatically include these updates? This whole process is very time consuming to regression test our sites. Applying a CU to a farm takes it down, from our experience, up to four hours.
    Once the September 2014 CU was applied to all the servers, the farm was off-line until we could apply the PSConfig to the Central Admin and at least one WFE.

  36. anonymouscommenter says:

    Hello Stefan,
    Hope you are doing well. We had a strange issue in our preprod sharpoint 2010 farm with project server 2010. The farm has totally 3 servers where in one server the windows automatic update installed some sharepoint patches. (KB2687415, KB2899589, KB2910904
    etc..) . Now the farm is not accessable. It says installation required for other two servers for the missing patches and run upgrade. This is really strange thing happened because of microsofts recent changes.

    Now we need to recover the farm back to the previous state as we have not tested these patches. Is there any way that i can uninstall the patches in the server where it got installed automatically? I have not executed PSconfig till.

    Or i need to install the missing patches in other two servers and run psconfig? If this is the case the version might be different from other farms (dev/Prod etc)

    Please advise.


    1. Michael Baron says:

      Hello Vinoth and Stefan,

      I am in a similar catch-22 situation. I have one SharePoint server that has a CU (kb2760265 April 8 2014 HF) and 4 that don’t. They all 5 have the SharePoint 2013 Service Pack 1 re-release (KB2880552) installed. I’m running the Configuration Wizard and it’s reporting that “Hotfix for Microsoft SharePoint Enterprise Server 2013 (KB2760265) 64-Bit Edition (15.0.4605.1000) is Mission on….” and it lists the 4 servers that didn’t get that Hotfix before the Service Pack update.

      Any way to fix this without rolling back to previous environment backup?



      1. Hi Michael,
        I would recommend to run “Get-SPProduct -local” on each machine and then run the configuration wizard. That should update the patch information for the specific machine.
        If this does not help I would recommend to open a support case with Microsoft to get the issue analyzed in more detail.

  37. Hi Vinoth,

    SharePoint fixes cannot be uninstalled.
    If PSConfig hasn’t been run, you should be able to restore a backup of the server from before or reinstall the affected node to the desired patch level.


  38. anonymouscommenter says:

    Hello Stefan, Thanks for your prompt answer. One more clarification. When you say reinstall the affected node, reinstalling Just sharepoint is enough or including OS?


  39. Hi Vinoth,

    just SharePoint would be enough.


  40. ngctechnet01 says:

    Hello, we had great process for installing the monthly SharePoint Security updates. We would download them Robocop copy them to all of our servers stop our SharePoint services and then command line execute them and restart and then PS config now if they were
    required. So what is the best recommended approach for installing these in a large enterprise environment?

    The last thing we want to do is log on each server and execute the windows updates from Control Panel. I was able to find the patches I think in C:WindowsSoftwareDistributionDownload but there isn’t any tie to a KB article in the file or the xml file. So
    how can we command line install these and know what each KB is we are installing.
    The only thing better I see about this process is the patches are already on the server but if they are in a format where we can install easily them a process that were once comfortable with no became difficult again and have to develop a way to automate the
    installation of the patches. I would prefer to be able to opt out of the SharePoint patches being pushed to our server like this.

    I see this method causing an outage at some point.



  41. Hi Chris,
    usually customer use WSUS to automatically install the security patches in a controlled manner on their farm servers – or even install them manually.

  42. anonymouscommenter says:

    Here is a summary of some news, Announcements and other interesting stuff. send out "randomly"

  43. Coentjo says:

    How can I install the SharePoint security farm deployment updates automatically through WSUS and/or SCCM? Because the updates state the migth require user input (which they don’t 8-( ) the only way we can install them nog is manually by logging into the server and starting windows update there. Since our developers have setup the SharePoint environments as farms and not as standalone we end up patching 100 servers manually every month 8(

Skip to main content