Every other week I receive emails, blog comments, phone calls, … from customers asking about strange behaviors they see in the SharePoint build version of their farm.
I have written a couple of articles about this topic but there is still a lot of confusion about “build numbers”, “build version”, “patch level”, …
In this article I will try to resolve this confusion.
If you are in a hurry have at least a look at the following summary table. Far more details can be found in the article below.
If you have a couple of minutes, I would suggest to continue to read.
I will start with the statement from the title of this post: “SharePoint does not have a build version.”. A more exact statement would be that SharePoint does not have a SINGLE build version – but to get started I would like my readers to forget everything they have heard about SharePoint build version/build numbers/patch level (except my previous blogs posts of course) and start with a clear and open mind to allow me to explain the facts from the beginning.
Where does the confusion come from?
The confusion comes from the fact that SharePoint exposes version numbers at verious different places:
- In KB articles for the different patches (hotfixes, security fixes, CUs, service packs, …)
- File Versions of SharePoint dlls and exe files
- On the “Manage Servers in this Farm” page in the Central admin
- On the “Manage Patch Status” page in the Central admin
- In the Versions table of the different SharePoint databases
- In Powershell using (Get-SPFarm).BuildVersion
Did I forget a place? Most likely…
The problem is that the different version numbers visible in the different places usually do not match.
And most of these numbers will not give you the info what patches have been installed on your system.
Details about the different versions shown in the different places
KB articles for the different patches
What version information is listed in the KB?
Each time SharePoint is compiled, linked and tested the build gets a new version number. The version number in the KB shows the version of the last build from which files are included in the patch.
Does this mean that all files updated in the patch will have this version number?
No. Please check the next section for more details on this question.
Will I be able to find the version number listed in the KB somewhere on my system?
Yes. You should be able to find the version number in the “Manage Patch Status” page in the Central admin
File Versions of SharePoint dlls and exe files
When is this information updated?
This version information is updated when installing the binaries on the machine by applying a fix on the machine. In some directories (e.g. _app_bin) the files will be updated when the SharePoint configuration wizard is executed later or when running the Install-SPApplicationContent Powershell command.
Why does installing the patch not update the files in _app_bin directory? Why are additional actions required for this?
The Windows installer can only update files it installed earlier. When you install a product, then the location of all installed files in stored in the installation database on the current machine. These are the locations the installer can update later. But the files in the _app_bin directory are not installed here by the Windows installers. SharePoint copied these files to this location when the web applicaton was created. To update these files after a fix was installed it is required to perform manual actions to update also the files in locations the Windows Installer is not aware of. And that is done by running the SharePoint configuration wizard or the Install-SPApplicationContent Powershell command.
If a patch updates a file – will the file version number always reflect the version in the KB of the CU it came with?
Short answer: No
Longer answer: Between two monthly releases of CUs developers integrate fixes for different issues into the source code of SharePoint. E.g. lets look at SharePoint 2013 June 2016 CU and July 2016 CU. June 2016 CU was released with version number 15.0.4833.1000. July 2016 CU was released with version number 15.0.4841.1000. You can see that at least 8 builds were created between these two CUs. Some fixes were checked in into build 15.0.4834.1000, some might be checked in into 15.0.4837.1000 and of course some into 15.0.4841.1000. If two of these fixes update the same files, then of course the relevant files will get the higher version number. But if files update with the check-in to build 15.0.4834.1000 did not get update again before the CU was released, then these files will be included in the CU with version 15.0.4834.1000 – so a version between the official version number (15.0.4841.1000) in the KB for July CU and the official version number (15.0.4833.1000) in the KB for June CU.
Here is a screen print for a typical SharePoint installation after installing July 2016 CU:
You can see that the different files have different version numbers and only a couple of them match the official version number of a CU.
Will I always find at least one file with official version number of the CU?
Not necessarily. The reason is that the last checked in fixes might not include code changes which require an update of a dll or an exe file. Some fixes require only changes in (e.g.) *.JS files. These files do not carry a version number.
Does this version number tell me if a specific CU has been installed?
Short answer: Yes and No.
Longer answer: You would have to check the KB articles for the given CU and identify all files which have a version number between the previous CU and the CU you installed and verify if these files all have the correct version. Just looking at a single file or a small number of files will not be sufficient. You would have to check at least one file per *.MSP file to be sure.
Central Admin: Manage Servers in this Farm
Where does the info come from?
This page uses the version information from Versions table in the config database.
When is this information updated?
This version information is updated through the SharePoint configuration wizard after a SharePoint patch is installed.
Do all SharePoint patches update this information?
No. Only those patches which include schema changes for the SharePoint config DB update this information.
Does this version number tell me if a specific CU has been installed?
Short answer: No.
Longer answer: First see the explanation in the “File Versions of SharePoint dlls and exe files” section above. A CU usually consists of multiple Microsoft Installer Patch files (.MSP) which are bundled in different installation files (.EXE). The same *.MSP file can be included in different *.EXE files. E.g. the Uber packages include all MSP files for SharePoint while some individual fixes released on the same day (including security fixes) can include the same *.MSP file. One single MSP (sts-x-none.msp) is responsible to update the database schema. So looking at this number it is impossible to say if all MSP of the CU or just a single MSP was installed. It is also not possible to tell which of the executables carrying this MSP was executed. So the info on this page might have been updated through (e.g.) the installation of the Uber package of a CU or through a security fix – if this security fix includes the sts-x-none.msp file.
If a patch changes this version number – will this version number always reflect the version in the KB of the CU it came with?
Short answer: No
Longer answer: See the explanation in the “File Versions of SharePoint dlls and exe files” section above. Not all CUs include database schema changes and even if they include them the version number for these schema changes might be slightly smaller than the highest build number included in the patch.
Central Admin: Manage Patch Status
Where does the info come from?
This page uses the information from the ServerVersionInformation table in config database.
When is this information updated?
This information is updated whenever a fix is installed on a server. The following article contains more information how this is performed:
Do all SharePoint patches update this information?
Yes.
Does this version number tell me if a specific CU has been installed?
Indirectly. SharePoint consists of multiple different components. This page gives you an overview over all the components that are installed on the different servers on your farm. This page tells you the version number for the different components. A CU does not update all components to the same patch level as differnet components are fixed each month. Comparing the version and KB information for the different component will give you the information about the patch level of each of these components and will allow you to determine which fixes are installed.
If a patch changes this version number – will this version number reflect the version in the KB of the CU it came with?
Yes.
Versions table of the different SharePoint databases
When is this information updated?
Whenever the database schema version of the database is updated. E.g. when running the SharePoint configuration wizard after installing a fix which updates the database schema for this specific database type. Also during database attach of an older database which gets upgraded during the DB attach or when running Upgrade-SPContentDatabase Powershell Command.
Do all SharePoint patches update this information?
No. Only those patches which include schema changes for the specific SharePoint database type update this information.
Does this version number tell me if a specific CU has been installed?
No.
If a patch changes this version number – will this version number reflect the version in the KB of the CU it came with?
Short answer: No
Longer answer: See the explanation in the “File Versions of SharePoint dlls and exe files” section above. Not all CUs include database schema changes and even if they include them the version number for these schema changes might be slightly smaller than the highest build number included in the patch.
Powershell: (Get-SPFarm).BuildVersion
Where does the info come from?
This command retrieves the information from the Objects table of the Config Database by reading the version information of the persisted Microsoft.SharePoint.Administration.SPFarm object.
When is this information updated?
This version information is updated through the SharePoint configuration wizard after a SharePoint patch is installed.
Do all SharePoint patches update this information?
No. Only those patches which include schema changes for the SharePoint config DB update this information.
Does this version number tell me if a specific CU has been installed?
Short answer: No.
Longer answer: See the explanation in the “File Versions of SharePoint dlls and exe files” and in the “Central Admin: Manage Servers in this Farm” sections above.
If a patch changes this version number – will this version number always reflect the version in the KB of the CU it came with?
Short answer: No
Longer answer: See the explanation in the “File Versions of SharePoint dlls and exe files” and in the “Central Admin: Manage Servers in this Farm” sections above.
Summary
We have seen that the only reliable source to check if a specific patch has been installed is the “Manage Patch Status” page in the Central admin. Even this page does not directly expose to you if all fixes in a specific CU have been installed. It is required to check all the components individually.
The learning is that there is no single version number in SharePoint which would reliably tell you the patch level for a server or a server farm.
If you are facing the challenge to determine if your server is has specific fixes installed you should start with the Windows Control Panel / Programs and Features which will list all the fixes installed on the box and on top the “Manage Patch Status” page in the Central admin to verify the patch status on the different servers.
I hope this article has helped to reduce the confusion about the different build/patch/version information exposed in different parts of SharePoint.
Permalink
Is installed KB information from Windows Update history reliable even if I install only with the downloadable package, not with windows update? I know it won’t tell me if I ran psconfig, but it should tell me what bits are installed and either in use or ready to be applied. It should also be useful for comparing different servers in the same farm.
What information does ROIScan show?
Permalink
Hi Piotr,
what do you mean with “reliable”?
Only installing the security fixes and not the full CUs is fully supported – if this is what you mean.
It is recommended to also run PSConfig to ensure that fixes in stored procedures in the SharePoint databases are also applied – but it is supported to postpone this.
Looking at the Patch Status Page will give you a simple way to compare patch level between different servers in the farm as it shows the fixes installed on all the servers.
Roiscan gives you the information about the patch baseline and the patch level of each MSP files applied.
Cheers,
Stefan
Permalink
What I meant is whether all patches (KB numbers) that are applied when running the CU installer are listed in Windows Update history, or whether ROIScan lists them. For use in an instance where a failed update took down the whole farm and central admin is unavailable. Also for automated “inventory scanners” that don’t know what SharePoint is, but can gather installed KB information.
Permalink
I did not double check but I think only the KB of the fix installed is listed. So if you install the Uber package only one KB will be listed. If you install all the individual KBs these should be listed.
Permalink
Microsoft does not see any reason to change this and make it easier than this. So many blog posts about patching SharePoint and then about recognizing version of the farm. Why cannot the installation of the patch do all pre-proceedures like stopping services when PSconfig does that? Just click to install and after installation server would be up and running showing right version. This cant be so hard to do since there are already powershell scripts that do just this.
Permalink
Hi Ano,
I’m not exaclty sure what you mean: installing the fixes does the pre-procedures like stopping services and restarting them. Just clicking install installs them.
And looking at the Patch Status page in SharePoint shows the right versions right after installing the fixes.
Can you explain in more detail what you mean?
Thanks,
Stefan
Permalink
To clarify what Ano said:
This is incompetent engineering change management, and indicative of the sloppiness with which SharePoint is built. I fully recognize that SharePoint is a “collection of services” and that various services can be patched independently.
But there is still a single configuration database, and Microsoft is explicit regarding the importance of maintaining the integrity of this database. One absolute constant is that when the farm is patched, it is necessary to run psconfig to upgrade the database schemas involved.
THIS IS WHEN THE FARM VERSION NUMBER SHOULD BE SET IN THE CONFIGURATION DATABASE. And it should be reflected on the patch page, the Config build number page, and in $(get-spfarm).buildversion.
Saying that I have to go the one place Microsoft says never to venture (the actual configuration database) is insane.
The worst part is that Microsoft COULD have fixed this at any time over the life of SharePoint, but they have never taken the time to bother.
I’ve seen code written by teenagers that had more engineering discipline.
(Note: I recognize that none of this is the author’s fault. I just needed to vent)
Permalink
The Config DB Schema Version is updated using PSConfig – but the config DB Schema Version does not give an info about patch Level for any other component aside the config DB Schema.
If the WCM component is patched but the Search component is not patched – what Farm Version number would you like to see?
Permalink
You asked us to put aside what we know about build numbers, patching, etc. And you carefully explained why there are dozens of different build numbers and why they don’t all match up. I ask you to put aside what you know about the build numbers and consider the following: The SharePoint community wants a simple singular build number so that we can all easily know that our servers are properly built and in sync. I don’t know if that means under the hood that an explicit recompilation all components, regardless of whether they were “fixed” since the last release, is necessary when Microsoft is going to post a new CU or SP. When I apply a fix, be it a SP or a CU, if the build number is 16.5890.1234 then I want everything in the farm to report the same number. When I go to a customer site and sit down before a farm that I have never seen, it should not take me 3 hours of comparing hundreds of versions numbers in the Patch status page to try to decipher what patches have been installed. I should be able to go to a single page and look at a single number and know exactly what patches & service packs were applied to SharePoint in less than 5 minutes.
Permalink
Hi Don,
what you want to have and what other customers want to have is not necessarily the same.
We have hundreds of customers who are concerned that installing a single fix might break things.
Customer ask for small fixes to be able to “just fix the one thing they have problem with”.
So if they need a search fix they don’t want to install WCM fixes and so on.
Also be aware that the same applies for security fixes: if you install a security fix for Word Automation services do you also want to install the feature pack from 2 months ago?
Your approach would do this – and actually this is more or less how it is now in SharePoint 2016.
We only have two packages: one for the language independent pieces (dlls) and one for the language dependent pieces (e.g. RESX files).
Which means installing a security fix is more or less the same as installing a full CU.
We have already got some complaints about this that the security fixes are no longer as granular as in SP2013.
This blog is not the right forum to get things changed anyway. If you think what you need is what most customers want, then raise your suggestion on Uservoice. This is where the product group listens for ideas and other people can vote for the different ideas and rate them up or down:
https://blogs.technet.microsoft.com/stefan_gossner/2015/12/16/you-have-an-idea-how-to-improve-sharepoint-we-are-listening-to-you/
Cheers,
Stefan
Permalink
Great blog post and very informative, thank you.
Additionally, looking at /service.cnf and /buildversion.cnf Web endpoints sometimes available in Sharepoint, where do these obtain their version from and would that be a reliable way to check for patch status?
Permalink
Hi Luis,
these are text files stored in the relevant directories.
You can open them with notepad to double check.
Cheers,
Stefan
Permalink
Hi Stefen,
Recently, I have installed the December 2021 CU in our SharePoint Server and while checking the version from Manage servers in the farm is showing little bit lesser than the Exact version.
Also, While i am checking in “Manage Patch Status” page it is showing the exact version mentioned in BLOG.
Is My upgrade id good or we need to check further as version is different in Manage Servers in farm page.
Permalink
Hi Nidamanuri,
this is expected. The field you are looking at does not allow to identify if a patch has been applied correctly as outlined here:
https://blog.stefan-gossner.com/2014/10/23/common-question-why-does-the-version-number-on-the-servers-in-farm-page-not-change-after-installing-october-cu/
For more details please have a look at this article:
https://blog.stefan-gossner.com/2016/08/23/sharepoint-does-not-have-a-build-version-full-stop/
Cheers,
Stefan