Table of Contents
- Using Central Administration
- Using SPFarm Object
- Using HTTP Header (Not Reliable)
- Using Registry (Not Reliable)
- Using Windows Installer (Not Reliable)
- Using SQL Queries
- Using File Version
The purpose of this article is to detail the multiple ways to retrieve the build version of a SharePoint deployment. The main challenge is the fact that version information is stored in multiple places which are not always (perfectly) equal.
Unless explicitly stated, the methods documented in this article are applicable to all SharePoint versions from WSS3/MOSS2007 to SharePoint 2013.
On WSS3/SharePoint 2007
Open the Central Administration then go to Operations, Under Topology and Services > servers in farm
On SharePoint 2010 and SharePoint 2013
Open the Central Administration then go to System Settings > Manage servers in your farm
While pre-SharePoint 2010 version do not report objects needing upgrade, most recent will do through the admin pages /_admin/PatchStatus.aspx and /_admin/DatabaseStatus.aspx
The SPFarm object simply returns the Version from fetched the configuration database.
On WSS3/SharePoint 2007
Start a PowerShell session with elevated privileges or with UAC disabled then enter the commands hereunder
$SPFarm = [Microsoft.SharePoint.Administration.SPfarm]::Local
On SharePoint 2010 and SharePoint 2013
Start a SharePoint Management Shell session with elevated privileges or with UAC disabled then enter the command hereunder
Once Installed, SharePoint adds a customer HTTP header to the web applications/IIS sites where is operates.
The version reported by the header MicrosoftSharePointTeamServices reflects the one from contained in the files Microsoft.SharePoint.dll and Microsoft.SharePoint.AdministrationOperation.dll
It can be observed with network analyzers such as WireShark, Netmon/MessageAnalyzer or HTTP Inspector such as Fiddler. The PowerShell snippet hereunder reports it as well. Note when running against authenticated sites, it will exclusively work with classic mode.
$SiteUrl = “http://intranet.massivedynamic.net/”
$WebReq = [System.Net.WebRequest]::Create($SiteUrl)
$WebReq.UseDefaultCredentials = $true # Necessary if the site requires authentication (classic mode only!)
$WebResp = $WebReq.GetResponse()
This way to retrieve SharePoint version must be considered as inaccurate because it does not reflect the exact build number from the Configuration Database. Refer to this comprehensive post by Wictor Wilén for the details SharePoint Mythbusting: The response header contains the current SharePoint version.
This header, like other HTTP headers disclosing technical information’s such as Windows/IIS version is sometimes obfuscated for security reasons, particularly on Internet-facing sites. Be aware that if it is the case, some client-side features or crawl might cease working as well. Therefore you might want to achieve this on a gateway (UAG 2010) or reverse-proxy to keep your SharePoint, at least partially, safe from harm.
On each server where SharePoint is installed, a section of the Windows Registry stores configuration elements. The exact location depends upon the major version of the product:
- WSS3/SharePoint 2007: HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions12.0
- SharePoint 2010: HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0
- SharePoint 2013: HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions15.0. Note: SharePoint 2013 comes with additional and somewhat misleading sections since HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0 also exists as well as HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions 15.0
Underneath lies the key “Version”. While this could have been way to easily get the version on all servers in a farm, this method must be considered as inacurate, see in the section below why.
The version seems to always reflect the version of the installation sources SharePoint has been originally installed with. Or at least, it will not reflect the same version, as the one from the configuration database if Cumulative Updates have been applied
Depending upon the way SharePoint has been installed, this registry entry may be empty. Third party relying on it mays fails to install/operate. See Symantec KB for details: Symantec Protection for SharePoint Servers 5.1.x does not install correctly when SharePoint was installed using the Windows PowerShell.
Like any piece of software properly installed on a Windows System, SharePoint registers itself in the Windows Installer database. Therefore it is possible to query it to retrieve the version of the installed product. So does the PowerShell one-liner hereunder:
Get-WmiObject -Class Win32_Product -Filter “Name LIKE ‘%SharePoint%'”|Select Version
Unfortunately, it will only reflect the version SharePoint has been originally installed with without Service Pack or CY subsequently applied. Therefore it should also be considered as inaccurate.
On recent Windows operating systems, querying the Win32_Product leads to all installed applications to be reconfiguregdby the Windows Installer Engine, refer to the MS KB Event log message indicates that the Windows Installer reconfigured all installed applications and to the Scripting Guy’s post Use PowerShell to Quickly Find Installed Software for details.
Not to mention that WMI, Win32_Product and the side-effect above make this method dead slow
Directly querying SharePoint’s SQL database give the ability to retrieve the version on a per database-basis. Executing the query hereunder will give the same result as the CentralAdmin or SPFarm object methods. Executing against content databases will help identifying those needing an upgrade.
FROM Versions WITH (NOLOCK)
WHERE VersionId = ‘00000000-0000-0000-0000-000000000000’
From the same table, the field UserName will contain the login of the user who performed the installation and subsequent upgrade when application and the field TimeStamp when it happened
Not all databases will contain the appropriate table: it will work with config, content and most of service application database but it will fail on State and Session State services DB’s. Will post a comprehensive list in the next revision of this article
Content databases upgraded from a previous SharePoint version are likely to report multiple rows, in this case, replace SELECT with SELECT TOP 1 and add ORDER BY Version DESC to the end of the query
Not supported, like any direct access to SharePoint database, unless working under supervision from an MS Support Engineer
You’re in the starting blocks to join a new SharePoint to an existing farm and you suddenly doubt about the version of the binaries used to install it. There is no perfectly reliable method to identify the current build version, therefore you should use the one stated hereunder cautiously.
Depending upon the product major version, locate the file Microsoft.SharePoint.dll under one of the folder hereunder then edit its properties in a Windows Explorer then go to the tab Details or Version (Depending upon the Windows version)
- WSS3/SharePoint 2007: C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12ISAPI
- SharePoint 2010: C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14ISAPI
- SharePoint 2013: C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15ISAPI
The PowerShell snippet below does the same:
While Microsoft.SharePoint.dll is usually modified with each Service Pack or Cumulative Update, it is not guaranteed to always happen.