Identifying SharePoint Build Numbers
There are various methods you can use to identify build numbers, including:
- Check SharePoint Products and Technologies special directories and storage locations.
- Check the Windows SharePoint Services content databases version in SQL Server®.
- Check the Knowledge Base (KB) updates that have been applied on each server that is running SharePoint Products and Technologies .
- Check the upgrade log.
Check Special Directories and Storage Locations
You can check the version attribute value of certain key files contained in the Office SharePoint Server 2007 installation directory (%COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12) to determine the build number of the SharePoint Products and Technologies environment. Note that when these build numbers are identified for corresponding components, they only relate to global updates that have been applied. It can be difficult to identify localized updates that have been applied, because the files that are updated by localized updates are not usually files that have a version number. To check these files manually, you can do one of the following:
- Validate the contents of the files against the same files in a non-modified environment that has had the update applied.
- Generate an MD5 hash of the current file and compare it against what is stored in the MSP file by opening the MSP file in Orca.exe. For more information about using ORCA, see “Dismantling Updates,” later in this white paper.
Files that are typically updated by the localized updates are resource files, JavaScript files, and so on. For more information about identifying specific localized updates that have been applied, see “Check the KBs that have been applied on each server running SharePoint Products and Technologies.”
The following TechNet article describes the special directories and storage locations: http://technet.microsoft.com/en-us/library/cc721635.aspx.
The following table lists the files that correspond to components of SharePoint Products and Technologies.
| Component | Filename |
| Windows SharePoint Services | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\OWSSVR.DLL |
| Office SharePoint Server (core server) | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\ Microsoft.SharePoint.Portal.DLL |
| OSRV | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\ Microsoft.Office.Server.DLL |
| DLC (Document Lifecycle Conversions) | Highest version of:
Microsoft.Office.Policy.DLL, Mirosoft.Office.Workflow.Pages.DLL located in: %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\ |
| PJSRV (Project Server) | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.Office.Project.Server.dll |
| IFS (InfoPath® Forms Server) | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.Office.InfoPath.Server.dll |
| XLSRV (Excel® Services) | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\Xlsrvint.dll |
Looking at these file versions is very helpful, but does not always give you an exact picture. Consider the Windows SharePoint Services Infrastructure Update. This update was released with a build number of 6320. However, the build number of OWSSVR.DLL is actually 6318 after the Windows SharePoint Services Infrastructure Update has been successfully applied. This can cause a certain amount of confusion, because the perceived build number in this case is 6318, but the actual build number is 6320.
Important Using the OWSSVR.DLL and other key files to identify our build number is typically a reliable approach to take, but it is important to be aware that it is not an exact science.
The most accurate method for identifying the build number is to look at the KBs that have been installed. The KB numbers should correspond to the actual build number. For more information, see “Check the KBs That Have Been Applied on Each Server Running SharePoint Products and Technologies,” later in this white paper.
Check Windows SharePoint Services Content Databases Version in SQL Server
Another way to identify the build number of Windows SharePoint Services is to look up the build number from the version table in a content database. It is in fact OWSSVR.DLL that defines this value.
For a particular content database, locate the table named dbo.versions. In this table, find the records that have a VersionID attribute equal to all zeroes. If multiple updates have been applied, there will be multiple records showing the different intermediate builds. The record that has the highest Id value shows the latest build number in the Version field.
A preferred way to retrieve this information is to issue a read query on this table by using the NOLOCK option. This option ensures that no shared locks are issued, which prevents other transactions from modifying data being read by the current transaction. Use a query such as the following:
SELECT * from Versions with (nolock)
This is a great way to identify all the updates that have been applied. For example, if you check OWSSVR.DLL and see that the environment has a build number of 12.0.0.6335 (the build corresponding to the December 2008 CU) , but you do not know whether SP1 has ever been applied, you can use this table to identify any record that has a value in the version field that corresponds to SP1 (12.0.0.6219).
Check the KBs That Have Been Applied on Each Server Running SharePoint Products and Technologies
Another way to identify the build number is to identify the KBs that have been installed on the server. In Control Panel, open Add/Remove Programs, and then click View installed updates. To identify the build number that corresponds to a KB number, do one of the following:
- Look up the KB on the Knowledge Base site (use the format http://support.microsoft.com/kb/<kbnumber> for the URL), and look for the build number in the KB description.
- Raise a Customer Service and Support case, provide the KB number, and request the build number.
As previously described, any localized updates that have been applied do not have build numbers. The only way to determine which localized updates have been applied is to identify which KBs have been installed.
You can use this method of checking for installed KBs is as an alternative way to see the set of updates that have been applied to a server and to identify any servers that do not have all the updates that the rest of the servers have.
Check the Upgrade Log
You can use the upgrade log to identify what components have been updated, and — more importantly — to what build level.
There are two stages of upgrade:
- Binary installation
- Build-to-build (B2B) upgrade
It is possible for upgrade to reach a successful first stage and a partially successful second stage without the entire environment being in an unavailable state. For example, in the scenario where we have 100 site collections, four might have failed to be upgraded. For every subsequent update applied in the future, the upgrade will continue to fail on those sites because it can’t move forward to the new TargetSchemaVersion until it completes upgrading the site it is currently on. In fact, it has to upgrade each site in order. This reinforces a point mentioned earlier that there is no such thing as a “farm build number.” There’s not a single number. You could come close to a single number if you have updated all of the MSI files installed relating to separate components of SharePoint Products and Technologies to the exact same build number. We come close to this with the new server-package cumulative updates (described in “Cumulative Updates Model,” later in this white paper), but even there we can have different builds inside those packages.
In summary, we should view our farm update level from a component (MSI)–specific standpoint, but also understand that individual components may actually be older if they failed to be upgraded when an update was applied.
There are various methods you can use to identify build numbers, including:
- Check SharePoint Products and Technologies special directories and storage locations.
- Check the Windows SharePoint Services content databases version in SQL Server®.
- Check the Knowledge Base (KB) updates that have been applied on each server that is running SharePoint Products and Technologies .
- Check the upgrade log.
Check Special Directories and Storage Locations
You can check the version attribute value of certain key files contained in the Office SharePoint Server 2007 installation directory (%COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12) to determine the build number of the SharePoint Products and Technologies environment. Note that when these build numbers are identified for corresponding components, they only relate to global updates that have been applied. It can be difficult to identify localized updates that have been applied, because the files that are updated by localized updates are not usually files that have a version number. To check these files manually, you can do one of the following:
- Validate the contents of the files against the same files in a non-modified environment that has had the update applied.
- Generate an MD5 hash of the current file and compare it against what is stored in the MSP file by opening the MSP file in Orca.exe. For more information about using ORCA, see “Dismantling Updates,” later in this white paper.
Files that are typically updated by the localized updates are resource files, JavaScript files, and so on. For more information about identifying specific localized updates that have been applied, see “Check the KBs that have been applied on each server running SharePoint Products and Technologies.”
The following TechNet article describes the special directories and storage locations: http://technet.microsoft.com/en-us/library/cc721635.aspx.
The following table lists the files that correspond to components of SharePoint Products and Technologies.
| Component | Filename |
| Windows SharePoint Services | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\OWSSVR.DLL |
| Office SharePoint Server (core server) | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\ Microsoft.SharePoint.Portal.DLL |
| OSRV | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\ Microsoft.Office.Server.DLL |
| DLC (Document Lifecycle Conversions) | Highest version of:
Microsoft.Office.Policy.DLL, Mirosoft.Office.Workflow.Pages.DLL located in: %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\ |
| PJSRV (Project Server) | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.Office.Project.Server.dll |
| IFS (InfoPath® Forms Server) | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.Office.InfoPath.Server.dll |
| XLSRV (Excel® Services) | %COMMONPROGRAM FILES%\Microsoft Shared\Web Server Extensions\12\ISAPI\Xlsrvint.dll |
Looking at these file versions is very helpful, but does not always give you an exact picture. Consider the Windows SharePoint Services Infrastructure Update. This update was released with a build number of 6320. However, the build number of OWSSVR.DLL is actually 6318 after the Windows SharePoint Services Infrastructure Update has been successfully applied. This can cause a certain amount of confusion, because the perceived build number in this case is 6318, but the actual build number is 6320.
Important Using the OWSSVR.DLL and other key files to identify our build number is typically a reliable approach to take, but it is important to be aware that it is not an exact science.
The most accurate method for identifying the build number is to look at the KBs that have been installed. The KB numbers should correspond to the actual build number. For more information, see “Check the KBs That Have Been Applied on Each Server Running SharePoint Products and Technologies,” later in this white paper.
Check Windows SharePoint Services Content Databases Version in SQL Server
Another way to identify the build number of Windows SharePoint Services is to look up the build number from the version table in a content database. It is in fact OWSSVR.DLL that defines this value.
For a particular content database, locate the table named dbo.versions. In this table, find the records that have a VersionID attribute equal to all zeroes. If multiple updates have been applied, there will be multiple records showing the different intermediate builds. The record that has the highest Id value shows the latest build number in the Version field.
A preferred way to retrieve this information is to issue a read query on this table by using the NOLOCK option. This option ensures that no shared locks are issued, which prevents other transactions from modifying data being read by the current transaction. Use a query such as the following:
SELECT * from Versions with (nolock)
This is a great way to identify all the updates that have been applied. For example, if you check OWSSVR.DLL and see that the environment has a build number of 12.0.0.6335 (the build corresponding to the December 2008 CU) , but you do not know whether SP1 has ever been applied, you can use this table to identify any record that has a value in the version field that corresponds to SP1 (12.0.0.6219).
Check the KBs That Have Been Applied on Each Server Running SharePoint Products and Technologies
Another way to identify the build number is to identify the KBs that have been installed on the server. In Control Panel, open Add/Remove Programs, and then click View installed updates. To identify the build number that corresponds to a KB number, do one of the following:
- Look up the KB on the Knowledge Base site (use the format http://support.microsoft.com/kb/<kbnumber> for the URL), and look for the build number in the KB description.
- Raise a Customer Service and Support case, provide the KB number, and request the build number.
As previously described, any localized updates that have been applied do not have build numbers. The only way to determine which localized updates have been applied is to identify which KBs have been installed.
You can use this method of checking for installed KBs is as an alternative way to see the set of updates that have been applied to a server and to identify any servers that do not have all the updates that the rest of the servers have.
Check the Upgrade Log
You can use the upgrade log to identify what components have been updated, and — more importantly — to what build level.
There are two stages of upgrade:
- Binary installation
- Build-to-build (B2B) upgrade
It is possible for upgrade to reach a successful first stage and a partially successful second stage without the entire environment being in an unavailable state. For example, in the scenario where we have 100 site collections, four might have failed to be upgraded. For every subsequent update applied in the future, the upgrade will continue to fail on those sites because it can’t move forward to the new TargetSchemaVersion until it completes upgrading the site it is currently on. In fact, it has to upgrade each site in order. This reinforces a point mentioned earlier that there is no such thing as a “farm build number.” There’s not a single number. You could come close to a single number if you have updated all of the MSI files installed relating to separate components of SharePoint Products and Technologies to the exact same build number. We come close to this with the new server-package cumulative updates (described in “Cumulative Updates Model,” later in this white paper), but even there we can have different builds inside those packages.
In summary, we should view our farm update level from a component (MSI)–specific standpoint, but also understand that individual components may actually be older if they failed to be upgraded when an update was applied.
