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.

Article from:

Error, Your backup is from a different version of Microsoft SharePoint Foundation and cannot be restored

When I tried to restore a site collection backup using SharePoint Management Shell,I got the following error:
restoreAnother error which I’ve seen is this one:

What is causing this error :- Restore-SPSite : <nativehr>0x80070003</nativehr><nativestack></nativestack>

I tried to take a site collection back up from a SharePoint farm that it’s build number version is not identical to the target SharePoint farm that i need to restore a site collection back up to it.  The source Farm had a build number of 4701 but the destination Farm had a build number of 4569. The security hotfix was not installed on destination

Note: Ensure that the destination farm is not at lower build version than the source.
If so, you will need to patch your environment as same as your source.

First I checked the patch level of source and destination farm by following:

  • Open SharePoint 2010 Management Shell as administrator and type
  • The output of the source farm is 14.0.7121.5000.

Another Method 

  • Open Central Administration -> System Settings -> Manage Server In this Farm


  • Below farm Info check the Configuration database version.


  • Apply the previous command to the destination farm.

As you can note the patch number for target farm is different and lower than the source farm! therefore, you need to patch the target farm as same as the source farm with all hot-fix and Service Pack and CU.
Check this build number table to discover the missed CU.SP and try to install it in your destination farm.
After I installed the required update to the target farm and now both farms are identical.
Now I should Check Database Schema Versions before trying to restore a site collection by following the mentioned steps below:

  • Open Central Administration
  • Navigate to Upgrade and migration section.


  • Review Database Status.


  • Check the content database of your web application that you want to restore a backup to it.
  • contentDBListCheck the status column for each content database and if you found “database is in compatibility range and upgrade is recommended” so you will need to upgrade your database.
  • Click on WSS_Content and check the version to show details.


  • If the Current Schema Version is less than the Maximum Schema Version, then the database should be upgraded as soon as possible.
  • To Upgrade content database, run the below command in SharePoint Management Shell.
    “Upgrade-SPContentDatabase <Content_db_name>”


  • After executing the command,the Current Schema Version is should be equal to the Maximum Schema Version.


  • Now try to restore site collection backup that should be restored without any issues.

nowbackup working

Note: If the site collection size exceed 1GB.The restore operation will take a long time.
So I advise to use SQL Server Backup/Restore operation that mentioned in this article  if the site collection size is more than 1GB.

You can also check the following Article to restore SharePoint backup without checking the farm build number.

Article from:

List of all hot-fix and Service Pack for SharePoint 2013

This post provides a rough guide to information on SharePoint version numbers for the following SharePoint products:

Microsoft SharePoint Server 2013 and Microsoft SharePoint Foundation 2013

Using SharePoint Central Administration Web site, under Upgrade and Migration, click Check product and patch installation status
You can also use the Windows PowerShell command, (get-spfarm).BuildVersion, however that can show a different version number from the web page.

Article from: