SharePoint patching demystified

After release of SharePoint 2013 August CU I received many emails and blog comments which showed that there is lots of uncertainty related to SharePoint patching. Especially the difference between the terms Cumulative Update and Server Packages (also known as "Uber" package) seems to be unclear.

Using this post I'm trying to shed some lights on the following aspects:

  • Cumulative updates (CUs)
  • server packages (also known as "Uber" packages)
  • patch baselines
  • public updates (PUs)
  • farm patch version information

 

SharePoint cumulative updates (CUs)

After release of August 2014 CU I read several statements that August CU is not cumulative – but that is not correct! SharePoint fixes are always cumulative! So if SharePoint fixes are cumulative – why is it required to install July 2014 CU as well to have a fully patched SharePoint server?

The reason is that SharePoint is not a monolithic product. It consists of various different and mostly independent components (e.g. Search, Excel Services, Web Content Management, Document Lifecycle components, …). Each of these independent components is packaged separately. You can get an overview over the different components and their patch level on the "Patch Status" page in the central administration of your SharePoint server:

As these components are independent from each other they can be patched independently. In each CU we ship fixes for various different components. E.g. it might happen that in a specific CU we need to ship a fix for Search but not for Excel Services, then this CU will only contain updates for Search but not for the Excel Services. Each of the shipped update packages is cumulative. That means if we ship fixes for one of the components in a CU, then the CU will contain all previous released fixes for this components as well.

Most of these components consist of a language independent piece (global) and a language dependent piece for the UI. The global and the language specific pieces are packaged separately to support separate installation for different languages (language packs). So we have e.g. a package for the language independent search component piece and a package for the language dependent search component piece. Same for Web Content Management and so on…

Let me give you an example:

In the example above we shipped Search Fixes in January CU and March CU. Excel Services Fixes in February CU and March CU. And WCM Fixes in February and April CU.

As SharePoint fixes are always cumulative the WCM fixes shipped in April CU also included the WCM fixes released in February CU. Same for the Search Fixes shipped in March CU which included the fixes from January CU and for the Excel Services Fixes released in March which included the fixes released in February CU.

The problematic piece here is that in the above example in April CU we don't ship fixes for Search and Excel Services. So if someone installs April CU only he will receive all WCM fixes ever released – but none of the Search of Excel Services fixes. The fix packages are cumulative – but you need more than the fixes from April CU to patch all your components to the latest version.

So if SharePoint fixes work this way – why was it sufficient in the past to install only the latest CU? The answer are the "Uber" packages:

 

Server Packages (also known as "Uber" Packages)

The "Uber" packages which are usually released with each CU not only include patches for the components updated in the current CU but also all patches released for other components of the product. So they are very similar to a mini service pack.

E.g. for the example above the "Uber" package would look like this:

In the past we always shipped an "Uber" package with every CU so in my blog posts I only listed the "Uber" packages for SharePoint Foundation, SharePoint Server and Project Server. August 2014 CU was the first CU where no "Uber" package was released – so I linked the individual hotfix packages for the patched components from my blog post which include the updates for the packages that have changed in August CU. To ensure that all other components are also on the latest patch level the "Uber" packages of July CU should be installed as well.

Why is there no "Uber" package for August CU?

The reason is a side effect of the new monthly update cadence. In the past we released cumulative updates every second month. Starting in June we began shipping cumulative updates every month. That reduces the timeframe a CU can slip if a problem is found in a CU near the release time. In the past a CU has often slipped 1,2 or even 3 weeks. Now with the monthly update cadence that is no longer possible as it would reduce the timeframe required to build and test the next CU. And that is what happend with August 2014 CU for SharePoint 2013. A problem was identified in one of the fixes included in August CU after all the packages have been built and the fixes were finalized. Rather than skipping the complete CU it was decided to just remove the affected fix package from the CU – and that also means that no "Uber" package was released as this "Uber" package would also contain the affected package.

What happened in August CU can happen again which means that we might see CUs without "Uber" packages more often.

 

Public Updates (PUs)

Public Updates are also cumulative updates – but only include those packages which include updates which should be distributed to all customers. Public update are either security fixes or other fixes which are recommended to be installed by all customers as they address issues which affect many users. A public update is always a subset of a CU. For more details about PUs and CUs see here:

PUs can be downloaded from Microsoft Download Center and are also published using Windows Update.

They are released on a monthly cadence if required. Be aware that you cannot expect that the latest public update includes all previous public updates for the reasons outlined in the Cumulative Updates section above. The following Graph highlights this:

In the example above you can see that a PU addressing issues in the Search component have been released in January. And two PUs addressing issues in the Excel Service Component have been released in February and March. In the example above no PU is released in April.

SharePoint PUs are cumulative – so installing the Excel Services PU from March will apply also the changes to Excel Services included in February PU and also all other fixes which were added to the same package in previous CUs. But as March PU does not ship any changes for the Search component it will be required to also install January PU to ensure that your system is properly patched with all public updates.

I'm usually not blogging about public updates on my blog as the CUs are a superset of the PU. Means the CUs contain all changes of the PU plus potentially fixes in other components. And "Uber" packages are a superset of the CUs installing the "Uber" packages of the CU will also include the changes from the PUs.

What might be confusing is that even that you installed the CU windows update might present you with additional patches. I'm not a windows update expert so I don't know all the details but it seems that windows update does not recognize that the fixes addressed in the PU have been already applied using a CU as the CU and the PU have different KB article numbers.

 

Patch baselines

While I'm writing this article about SharePoint patching let me also explain why it is required to install service packs although the CUs often include all fixes from an earlier released service pack. The reason is the patch base line.

Each service pack sets a new patch baseline while CUs don't set such a baseline. The patch baseline is the starting point for patching. Looking at the second picture above (the one explaining the "Uber" packages) you can see that the CU only included fixes for Search but not for any other component. The reason is that no fixes have been released for other components since the patch baseline was defined. When a service pack is installed on the server the patch baseline is set to this service pack.

That allows to speed up the patching process in the future as only those packages have to be updated which have changed since the patch baseline was defined.

For our CUs on the other hand it makes things a little bit more complicated: as we support the previous service pack for 12 more month after releasing a service pack we need to support two patch baselines with our cumulative updates. E.g. at the moment for SharePoint 2013 we support RTM and SP1 as patch baseline – that means our cumulative updates can be installed as well on RTM and on SP1.

That done by packaging the fixes for both patch baselines in the same package. This increases the size of the patches but allows our patches to be installed on both patch baselines: if SP1 is found the CU packages with SP1 as baseline are applied. If RTM is found, then the CU packages with RTM as baseline are applied. 12 months after release of the service pack things get more interesting – and that is also the time when we get more support cases.

Here is what will happen:

1) The CUs will be significantly smaller

As only the CU packages for the latest patch baseline are included in the CU the download size of the CU will be smaller. That often causes concerns with our customers as they are not sure if all fixes from the previous (much bigger CU) are really included in the new CU.

2) Fixes will no longer install on a system which is on a lower patch baseline

If the patch baseline on the SharePoint server is lower than the patch baseline defined in the CU package the CU fails to install. That often causes support cases if a customers forgot to apply the latest service pack for one of his language packs. For the next 12 months CUs can still be applied on such a system as we support the lower patch baseline but suddenly – around 12 months after release of the service pack – the older patch baseline is no longer supported and customers are no longer able to apply the CU.

A very good method to isolate such problems is the Roiscan script which lists the patch baseline and the patch level for all installed products and product components of the Office product family including SharePoint.

 

Farm Patch Information

One question I really have problems with is: what patch level will I see in central admin when I have applied that CU. The reason is: that information is not really very helpful to understand if the server is properly patched – at least when looking at the version number in "Manage Servers in this farm" page – which is usually referred to.

Why? The version number here is controlled only by one SharePoint component: SharePoint foundation. And here also only by a single DLL which writes the version information to the configuration database during patching. This version number does not give any indication if any of the real SharePoint server components like Excel Services, WCM or Search are properly patched.

To get a more reliable picture you really have to look at the Patch Status page ("Check product and patch installation status"). It contains the patch level for each installed component.

Another question I often hear is: "Why is the patch level in the central admin slightly different from the one in the KB article?"

One reason might be that you looked at the KB article for SharePoint server and not the one for SharePoint foundation. These two components might have slightly different version number – e.g. the SharePoint server package might have been created a couple of days later than the SharePoint foundation package. As the version number on the "Manager Servers in this farm" page in the Central Admin only shows details for the SharePoint foundation component you cannot expect to see the version number listed in the SharePoint server KB article.

But even when looking at the SharePoint foundation KB article there are rare cases that the patch level listed in the central administration is lower than the version number in the KB article. The reason for this is that different fixes are added to the CU at different times. Some fixes modify dlls of the components other just CSS files or JavaScript files. Most of the fixes affect the Microsoft.SharePoint.dll as this is the core component of the SharePoint Foundation component – so its version number usually has the highest version number in the package. But not always! It might be that the last fix being added to the package is a different file. If this is the case, then the version number in the KB article might reflect the version of this other file. If this file is a dll you can verify this in explorer. But if this file is just a CSS file or a Javascript file or any other file which does not carry version information then you might not be able to identify the file which defines the version number in the KB article.

The reason that I don't like questions around the version number in Server in Farm is that you will see the same version number in all the following scenarios:

  • SP2013 Server RTM plus SharePoint foundation August 2014 CU
  • SP2013 Server RTM plus some fixes for SharePoint Server August 2014 CU plus SharePoint foundation August 2014 CU
  • SP2013 Server RTM plus Service Pack 1 plus July 2014 CU plus all fixes for SharePoint Server August 2014 plus SharePoint foundation August 2014 CU

Just looking at this version number will not tell you if a CU installed correctly! It only tells you if the package for the SharePoint Foundation component has been applied but nothing about the other components.

 

I hope this article clears up some of the mysteries of SharePoint patching.

114 Comments


  1. My colleague Stefan Gossner wrote a great article, we reviewed internally today and posted it few minutes

    Reply

  2. After release of SharePoint 2013 August CU I received many emails and blog comments which showed that

    Reply

  3. Following my tradition in presenting a summarized "Build Numbers Cube Sheet" as I did so before

    Reply

  4. Very informative and nicely explained Helped me answer lot of SP updates questions.

    Reply

  5. We have large SP farm with WFE and App servers . do we need to run psconfig.exe on farm after installing Public updates ? Does install procedure for PU insame as that for CU i.e to start with central admin server then do others etc..

    Thanks

    Reply

  6. Hi MP,
    there I no difference regarding psconfig between CU and PU.
    Both follow the same procedure.

    Reply

  7. Seems like you would just put an ad to sign up for Office 365 SharePoint Online at the end of this (great) post. 🙂

    Reply

  8. Awesome! This explains a lot. I wish there was more verbosity when it comes to patches in the product itself. Now we have to keep up with blog posts to know what's happening. If you were to change the naming of your packages to be less cryptic and include
    a clear indication about them in SharePoint, then it would be much easier. For example, just like you pointed out the different components, the patch installer and psconfig could show us an information "I will update these components to these version numbers".
    On the Patch Status page we would see the different components with their version numbers. On your "official" page listing available updates (reached with a url on the Patch Status page preferrably – a "Find Updates" button), we would find information on what
    is the latest version of each component, so we know if we should patch it. That would make patching SharePoint less of a lottery and hoping that we get everything we need. Having an ubersrv@$@@djhsy12345.cab package that contains the Wdsrv-x-none.msp, Coreserver-x-none.msp,
    Xlsrvwfe-x-none.msp and Oserver-x-none.msp individual packages doesn't tell us anything, so we just apply those blindly hoping for the best (i.e. not breaking the whole farm). That's exactly why patching this product is criticized so much.

    Thank you for your work for the community. I hope more areas of this product become demystified.

    Reply

  9. Thank you, really good and appreciated you took the time to explain this. Now if you only could take the time (or maybe link to a "go-to"-reference) of how to re-initialize the upgrade process if the GUI config wizard fails when applying a CU.. I usually
    just execute "psconfig -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures", is that correct procedure?

    Reply

  10. Hi Kristoffer,

    we usually recommend this command: "psconfig –cmd upgrade –inplace b2b -wait"

    Cheers,
    Stefan

    Reply

  11. Hi Stefan,
    This just came to my attention. How does one verify at the moment if any of these packages are missing and which one is it? What if a client installed all except one and that happened on just one server. For example WFE1 has all packages installed, but WFE2
    is missing one. From your post, I understand that I will successfully run psconfig after installing just one of the above packages.

    Reply

  12. Hi Piotr,
    the easiest way to verify this is to run the above listed Roiscan script on both machines and compare the output.
    Cheers,
    Stefan

    Reply

  13. Hi Stefan,
    Just want to make sure I understand it correctly. For CU that is not "Uber", you have to install both Foundation and Server patches. For CU that is "Uber", you just need to install the Server patch. Is that correct?
    Thanks

    Reply

  14. Hi Eric,
    that’s correct.
    Cheers, Stefan

    Reply

  15. Summary: Patching Sharepoint is difficult.

    Dont do it unless you have to, or it is a service pack.

    Reply

  16. Great information … one question There are 5 Updates/downloads for August SharePoint Server 2013. Do you have to run psconfig after installing each patch or can you do it once after all 5 have been installed

    Thanks

    Reply

  17. @Christian: and remember to test, test and test before deploying to production.

    Reply

  18. Hi Andrew,
    PSCONFIG only has to be run once at the very end.
    Cheers,
    Stefan

    Reply

  19. Thank you for this information! We have some catching up to do on our patching. We are on SP1 + June 2011 CU. I read in one of your previous posts that we should install the June 2013 CU before SP2. Given that SP2 was released > 12 months ago will we still
    be able to do that?

    Reply

  20. Hi Monica,
    that was just if you wanted to install June 2013 CU. Any later CU can be installed on top of SP2. No need to install June 2013 CU if you would like to go to the latest CU.

    Reply

  21. This link has been making the rounds lately and I wanted to share it.

    SharePoint patching demystified

    Reply

  22. This link has been making the rounds lately and I wanted to share it.

    SharePoint patching demystified

    Reply

  23. The SP process has been a total cluster-F for too long. Why is it so hard for MSFT to make something that is simple.

    Reply

  24. As CUs are Cumulative (thus the name), August’s patches really aren’t a CU. While I realize the difference between Uber and non-Uber, clarity is lost when you call BOTH of these items Cumulative. What happens if I install August’s patch for a supported
    functionality, then add functionality which requires July’s patch? In the past, we’ve never been allowed to patch backwards.

    All in all, this is quite confusing. Please select a convention and stick with it. If CU != Cumulative (and installing two of them would indicate this), please say so and be clear about it. You run the risk of confusing a lot of SharePoint admins whose job
    depends on this clarity from Microsoft.

    Reply

  25. Hi Troy,

    seems you did not understand the article correctly. There is no backward patching. Installing July on top of August does not revert anything. It just patches those packages which did not get updated with August CU.
    August CU is – as all previous CUs a cumulative update.
    With all previous CUs we released as well the cumulative updates for each patched component and the Uber packages.
    There is nothing new in August CU except that the Uber packages were not shipped.
    All previous CUs from the beginning of MOSS 2007 were packaged in the same way.

    The Uber is also nothing new as some mentioned earlier. It was shipped as courtecy for our customers to simplify patching.

    E.g. lets look at July 2014 CU.
    These packages are mentioned on my blog:

    •KB 2882999 – SharePoint Foundation 2013 July 2014 CU
    •KB 2882989 – SharePoint Server 2013 July 2014 CU

    These are the Uber packages for July CU.
    But the real CU are the following KBs:

    KB 2883000
    KB 2882987
    KB 2881088

    The Uber packges INCLUDE the current CU and all other packages which were patched in earlier CUs.

    Cheers,
    Stefan

    Reply

  26. Great article Stefan – just what I needed. The Redmond article on the August CU was really very confusing. Your article is clear.

    Reply

  27. Our SharePoint product group released the next monthly cumulative updates. This month we will have the

    Reply

  28. Hi Stefan,

    Great article and blog in general, using it a lot.

    On patch-sizing as you mention briefly.
    What is the main reason for CU-uberpackages being so much larger than a servicepack?

    E.g. The CUs before SP1 were much smaller.
    If the same fixes are contained, it should be similar.
    Of course CUs are globally languaged, but still.

    Thanks!

    Reply

  29. Hi Mikkel,
    two reasons: two different patch baselines (as discussed above) and the fact that a CU contains fixes for ALL language packs while you have separate service packs for each language pack.
    Cheers,
    Stefan

    Reply

  30. If using ROIScan.vbs is the easy way to determine which one of the patches might have been missed on one server in the farm then I would really hate to see the hard way.

    Reply

  31. @Mike: ROIScan looks cool. I'm corrently playing around with it to see if I can determine which files were changed by a PU. Looks like a good tool to use when "stuff don't work" and the client claims they didn't install any updates since last time you
    visited them or when they claim that psconfig ran without errors.
    The hard way would probably be contacting MS Support.

    One question though. All product codes are hard-coded there. I wonder if they will update roiscan when a new product comes in the future, For instance if Office Graph comes to on-prem. Where to look for updates on that?

    Reply

  32. Hi Piotr,
    The developer of roiscan sits in an office near me and I know that he is constantly updating the script. I’m pretty sure he will update the public version when new products are released. Just drop me a note in case you see son discrepancies and I will forward
    it to him.
    Cheers,
    Stefan

    Reply

  33. I understand your team's frustration, but the current method of patching at the moment is unacceptable. I hope your team starts to consider releasing individual patches, but via a simplified download and apply process like WSUS or windows updates.

    Reply

  34. Our next cumulative update packages are available. The general information you can find in the Office

    Reply

  35. Our SharePoint product group released the next monthly cumulative updates. This month we will have the

    Reply

  36. Hi Stefan,
    Thank you so much for your great post. Could you please clarify my question:

    We installed September 9, 2014 Cumulative Update for Project Server 2013 package. The link says the build must be 15.0.4649.1001 but after I ran psconfig the build in Configuration database version is 15.0.4649.1000 and everything works as expected.

    Does it mean something is wrong with our patching?

    Thanks

    Reply

  37. Hi Hassan,

    the configuration database version is unrelated from the build version in the KB. Please read the section "Farm Patch Information" above for more details.

    Cheers,
    Stefan

    Reply

  38. Our next cumulative update packages are available. The general information you can find in the Office

    Reply

  39. Our SharePoint product group released the next monthly cumulative updates. How patching works for SharePoint

    Reply

  40. Note! Since July 2014, the release cycle is now every month! Any CU’s published later than June 2013

    Reply

  41. Since July 2014 CU, the release cycle is now every month rather than the Bi-monthly cycle. NOTE! All

    Reply

  42. Our SharePoint product group released the next monthly cumulative updates. How patching works for SharePoint

    Reply

  43. Our next cumulative update packages are available. For SharePoint we are still suggesting to install

    Reply

  44. I understand the desire for Microsoft to create smaller packages but it seems that you are overlooking what your customers obviously want and need. Most SharePoint Admins I meet at user groups, want a simple single package that they can install and then
    look at a single farm build/version number and know that they are current. Most of us don't want to track down blogs to determine what magical combination of downloads is required to update our server this month. We want to install base product (hopefully
    with latest service pack slipstreamed), install the latest CU (1 package) and be DONE! I dare say the average SharePoint Admin expects a CU to have updates for any and all possible components of SharePoint in a singular package(i.e. your "Uber" packages).
    We think of cumulative updates in terms of "SharePoint Server 2010" not WCM, Excel Services, Search, etc.

    Reply

  45. Our next cumulative update packages are available. For SharePoint we are still suggesting to install

    Reply

  46. Our SharePoint product group released the next monthly cumulative updates. How patching works for SharePoint

    Reply

  47. Hi Stefan

    our SharePoint 2013 enterprise server based line is SP1. we are trying to catch up with all the SharePoint patch update and need some guidance badly.
    Would you provide a summary list of what we need to patch on the servers to be up to date with patching?

    Thanks so much

    Reply

  48. Hi Stefan
    That is absolutely a great news for us.

    Thanks

    Reply

  49. For the past several months I have worked on an issue with the Excel Interactive Preview throwing the

    Reply

  50. Our SharePoint product group released the next monthly cumulative updates. How patching works for SharePoint

    Reply

  51. Our next cumulative update packages are available. For SharePoint we are still suggesting to install

    Reply

  52. SharePoint 2010 Build Numbers Cube Sheet
    As many times used in our daily business, we’re used

    Reply

  53. Note! Since July 2014, the release cycle is now every month! Any CU’s published later than June 2013

    Reply

  54. This Month CU has been released with a full server packages, a.k.a. "Uber Packages" – so this

    Reply

  55. SharePoint 2010 Build Numbers Cube Sheet
    As many times used in our daily business, we’re used

    Reply

  56. Our next cumulative update packages are available. For SharePoint we are still suggesting to install

    Reply

  57. Our SharePoint product group released the next monthly cumulative updates. How patching works for SharePoint

    Reply

  58. Our next cumulative update packages are available. For SharePoint we are still suggesting to install

    Reply

  59. Our SharePoint product group released the next monthly cumulative updates. How patching works for SharePoint

    Reply

  60. I’m presenting a summarized "Build Numbers Cube Sheet" as I did so before, so please find

    Reply

  61. The product group released the July 2015 Cumulative Update for the SharePoint 2013 product family.

    Reply

  62. Our next cumulative update packages are available. For SharePoint we are still suggesting to install

    Reply

  63. Our SharePoint product group released the next monthly cumulative updates. How patching works for SharePoint

    Reply

  64. I’m presenting a summarized "Build Numbers Cube Sheet" as I did so before, so please find

    Reply

  65. SharePoint 2010 Build Numbers Cube Sheet
    As many times used in our daily business, we’re used

    Reply

  66. Our next cumulative update packages are available. For SharePoint we are still suggesting to install

    Reply

  67. Our SharePoint product group released the next monthly cumulative updates. How patching works for SharePoint

    Reply

  68. How can we check, which public update version my environment is on?

    Reply

  69. Hi Prashant,
    there is no such public update version. When it comes to security fixes each component in SharePoint is patched individually. So the different components can and will have different patch levels if only security fixes are applied and not the uber package of
    the cumulative updates.
    Cheers,
    Stefan

    Reply

  70. The product group released the August 2015 Cumulative Update for the SharePoint 2013 product family.

    Reply

  71. Ya tenemos disponibles las actualizaciones acumuladas tanto de SharePoint 2010 como de SharePoint 2013

    Reply

  72. Our next cumulative update packages are available. For SharePoint we are still suggesting to install

    Reply

  73. How can I install service pack 1 and latest CU for existing SharePoint 2013 at the same time?

    Reply

  74. Hi Me,
    you have to install the SP1 binaries first and then the latest CU binaries.
    At the end run the config wizard.
    Cheers,
    Stefan

    Reply

  75. So you mean that we can't slipstream the SP and CU ?

    Reply

  76. Hi Me,
    slipstream allows to integrated upgrades into the installer that performs a complete installation of SharePoint. So if you have a new box you can use SharePoint 2013 with SP1 and slipstream it with the latest CU.
    But you cannot slipstream the installation of a service pack and a CU into an existing installation.
    Cheers,
    Stefan

    Reply

  77. I’m presenting a summarized "Build Numbers Cube Sheet" as I did so before, so please find

    Reply

  78. SharePoint 2010 Build Numbers Cube Sheet
    As many times used in our daily business, we’re used

    Reply

  79. I’m presenting a summarized "Build Numbers Cube Sheet" as I did so before, so please find

    Reply

  80. I can never get psconfig to run smoothly, it is always a pain.

    Reply

  81. Stefan,
    Can you please help me clarify some things? I am taking over patching of our SP environments (both monthly and CU). My approach is to only review CUs twice year or as needed if it fixes something that breaks. My confusion is, if there are monthly SharePoint security patches via Windows Updates (as in Jan 2016), are they typically dependent on a certain CU (like the one that broke SP in Jan 2016)? Since Jan 2016 CU is also problematic (breaks Excel services), I am going to apply the June 2015 CU to a new farm. Does that decision have any impact on subsequent monthly SharePoint security patches that were or will be released? Finally, should I run psconfig after applying the monthly SharePoint security patches (I typically only do it for CUs when applied).

    Reply

    1. Security fixes have SP1 as baseline. Means they will install on SP1 and all Post-SP1 CUs.
      With other words: Security Fixes are not dependent on a CU – just on a Service Pack.

      Reply

      1. Finally, should I run psconfig after applying the monthly SharePoint security patches (I typically only do it for CUs when applied)?

        Reply

  82. Thanks for the info Stefan. It’s a great piece.
    I deployed SharePoint 2010 SP2 and the August 2015 CU to my production farm at the weekend but an issue in Project Server 2010 hasn’t been resolved.
    Is it still the case that installing the Project Server version of a CU or an Uber package also contains all of the SharePoint patches or do both files need to be installed?
    Thanks in advance.
    N03L.

    Reply

    1. Hi N03L,
      yes August 2015 CU for Project Server contains the CU for SharePoint server and foundation.
      Cheers,
      Stefan

      Reply

  83. Hi Stefan,
    We applied CU for April 2015 a while back. We run monthly Windows and Microsoft Updates, after which I always run the SharePoint Configuration Wizard because we were seeing some ‘Needs Update’ messages.
    Imagine my surprise when we recently ran PowerShell (Get-SPFarm).BuildVersion and got back 15.0.4797.1000, which is February 2016 CU.
    I have not applied this CU and have not noticed that the CU was downloaded or applied. I also do not see it in the Control Panel\Programs\Programs and Features. Why am I seeing this result?
    Thank you

    Reply

    1. I DO see various Security Updates related to ‘Microsoft SharePoint Server 2013’ when I click ‘View Installed Updates’, but no CUs.

      Reply

      1. Hi Marcel,
        in the article above I tried to explain that something like a farm patch level does not exist.
        The same applies for the build version returnd from the SPFarm object.
        The result of this property is the database schema version of the configuration database. And this database schema version can also be updated by a security fix – and that happend in February 2016.
        If you check this article https://technet.microsoft.com/en-us/library/security/ms16-015 you will notice a security fix for Microsoft SharePoint Foundation 2013 Service Pack 1 (3114733).
        This security fix updates the database schema version.
        To reemphasize what I said in my article: it is impossible to determine if a specific CU has been installed by just looking at a single version number.
        Cheers,
        Stefan

        Reply

  84. Hi Stefan,
    Great post! Helped me a lot.
    I am defining a patching evaluation process for SharePoint at my firm and one of the things I am struggling with is how to determine what SharePoint service is impacted by a given patch. Whilst there is lots of useful information in the respective KB page, I feel it can be difficult to determine what services or features are effected so that appropriate testing can be carried out; no one want to regression test every time.
    It would be great if Microsoft included some addition information that would help with this. Do you have any tips on how one can determine what services/features have been changed?
    Paul

    Reply

    1. Hi Paul,
      unfortunately there is no simple way to do this.
      In addition you would also have to look at all the CUs between your current patch level and the patch you are installing as the latest CU also includes all changes from earlier CUs.
      Cheers,
      Stefan

      Reply

      1. I thought as much, but was worth the ask. Thanks for confirming!

        Reply

  85. Hello Stefan,
    We have patch our SharePoint farm with June 2017 CU. It installed successfully and Config wizard run successfully. But when we go to patch status page in CA, for old patch we see the status as “superseded” can you please let us know what does it mean and how to get rid of it. Does it mean that our June CU has created and issue and not installed properly.

    Reply

    1. Hi RN,
      SharePoint fixes are cumulative. That means that newer fixes include older fixes. In this case it means that June 2017 CU has superseded an older fix as the older fix is included in the newer one.
      So that is not a problem at all. It just shows you the history of what has been installed and which fix replaced/includes which older fix.
      Cheers,
      Stefan

      Reply

  86. Is a Public Update just one patch/package? Or is is very SP patch that month other than the CU
    For January 2018 I see
    4011599
    1011579
    4011653

    Reply

    1. Hi Dominick,
      each month we release dozends of fixes. They are bundled as Uber packages including all cumulative updates.
      If you would like to install only the package which include security fixes you might have to install multiple packages each month.
      Cheers,
      Stefan

      Reply

      1. Does that mean a PU is not just one fix but a series of them, is it recommended just to install the CU?

        Reply

        1. Hi Dominick,
          it depends on your business needs.
          Installing the CU is simpler if you are not relying on Microsoft Update to push the fixes on your machine.
          Cheers,
          Stefan

          Reply

    1. Yes. Main difference is that the number of patch able components has been significantly reduced in SP2016. That’s why there are no Uber packages in SP2016 and SP2019.

      Reply

  87. Hello Stefan, thanks for this page, it is quite helpful. If there is a security update for SharePoint 2013 Foundation SP1 and we are running Enterprise, it is needed? On one hand enterprise is foundation plus more, but then on the other hand Enterprise might not ‘need’ the update otherwise, they would release the security update for SharePoint 2013 Enterprise SP1, right?

    Reply

    1. Hi Jon,
      SharePoint Foundation security patches always apply to SharePoint server as well.
      SharePoint Foundation is one of many components of SharePoint server.
      Cheers,
      Stefan

      Reply

  88. Hi,

    You have put very well together everything about Sharepoint patching, but I still don’t know what updates I need for my situation.

    So I’m building a new SP2016 Single-Server farm for testing and I want to patch it to the latest CU.

    Can I just install the RTM version without running config wizard and then install the latest CU (October 2020)?
    After patching it to the latest CU I will start config wizard and proceed with the farm.

    In the CU description it says it includes Service Pack 1 and Service Pack 2 so I don’t need to install them separately?

    Eventually I’m going to build a production farm with 4 servers and I’m going to use those shared roles which came in Service Pack 1 so I believe the correct way is to again install the RTM version without running config wizard and then patch it to the latest CU and then run the config wizard.

    Reply

    1. Hi Kalvero,
      yes, you can install RTM version and afterwards install the latest CU and then run the config wizard.
      There are no service packs for SharePoint Server 2016. What is included are Feature Packs. No you don’t have to install anything else. The latest CU includes them.
      Cheers,
      Stefan

      Reply

      1. Ahh…that makes sense. Thanks for quick reply!

        Reply

        1. And yes, in the CU description it says “Feature” pack and not “Service” pack. Just thought that they mean the same thing. 🙂

          Reply

  89. Hi Stefan, Great article, I am still a little confused on patching content databases. If I choose to run upgrade-spcontentdatabases against all content DBs before running PSConfig are the DBs locked while the upgrade is running against them or are they still available for R/W operations?

    Reply

    1. Hi Stephen,
      for SharePoint Server 2016, 2019 and Subscription Edition the databases are available for R/W operations.
      For SharePoint 2013 the databases cannot be accessed during the upgrade.
      Cheers,
      Stefan

      Reply

Leave a Reply to MP Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.