Understanding SharePoint Farm Build Numbers
In SharePoint Products and Technologies, the farm build number varies in proportion to the number and variety of updates that have been installed in the farm. Not every IT department installs the exact same kind of updates at the same time; for this reason, figuring out the build number of a SharePoint farm can be more of an art than a science.
Before deploying any update, it is important to be aware of the current build number of the SharePoint Products and Technologies deployment. It is also important to ensure that all servers within a SharePoint farm consistently share the same build number. Having the same build number is defined as “specific SharePoint Products and Technologies installed from an MSI file that is at the same update level.” For example, if you have an Office SharePoint Server farm with five servers, you could have Windows SharePoint Services Service Pack 2 (SP2) plus the June Cumulative Update (June CU) and Office SharePoint Server SP2 without any cumulative update installed on top of it. This is acceptable as long as all five servers are configured in the same way. If three of the servers have Windows SharePoint Services SP2 plus the June CU, and two of the servers only have Windows SharePoint Services SP2 without the June CU, you have not achieved consistency. The June CU should be applied to the two servers that are out of sync from a build number perspective.
To clarify this point: We are discussing the build number on a per-product basis. The build numbers in the content databases, site settings, and Central Administration site are based on the Windows SharePoint Services build level; they are not necessarily the same for other products such as Office SharePoint Server, Project Server, and so on. You can update the different products to different build numbers, but we recommend that you keep them in sync to maximize the benefit of applying fixes that cross product boundaries. For example, it will not harm your environment if you do not keep Windows SharePoint Services and Office SharePoint Server in sync, but if Microsoft releases a hotfix that requires both Windows SharePoint Services and Office SharePoint Server builds to be past a certain build number, you will not gain the benefit of that fix, and your environment will remain “broken” in the same way it was before the partial fix was applied.
Build Number Format
The format of a SharePoint Products and Technologies build number is shown in the following illustration.
The build number is composed of the following four numbers:
- Major This indicates the major version of the product. For Windows SharePoint Services 3.0 or Office SharePoint Server 2007, this is always 12.
- Minor This indicates the minor version of the product. For any version of Windows SharePoint Services 3.0 or Office SharePoint Server 2007, this is always 0 for our binaries when our major version is 12, and will not be incremented when we install service packs. (In some contexts, this number will change; for example, in the upgrade log, you may find references to 12.1, where the .1 represents Service Pack 1).
- Build This is what we can use to indicate the version number. This is the number that is incremented when we apply a service pack or any other update. Some examples of build numbers and their corresponding versions are given below:
- 4518 is the RTM build
- 6219 is SP1
- 6320 (Windows SharePoint Services) and 6322 (Office SharePoint Server) are the Infrastructure Updates
- 6421 is SP2
- 6520 is the October 2009 CU
- Revision The revision number indicates the type of update that has most recently been applied. Some examples are given below:
- 5000 is a fully supported, COD hotfix suitable for a production environment
- 1000 is a service pack
- 300x is private release build for a customer who has been working with Microsoft Premier Support. This type of update should not be deployed in a production environment, because it has not been properly integration-tested. However, if this type of update is applied to a production environment, the final hotfix or later hotfixes will replace it as a final release and will have a higher revision number in the format of 500x.
Caution Using a private release in production can cause irreversible data loss. In many cases, Customer Service and Support can work through non-data loss scenarios, but the risk of data loss is so high with private release builds that Microsoft has taken the stance that these types of builds should never be put into production.
In SharePoint Products and Technologies, the farm build number varies in proportion to the number and variety of updates that have been installed in the farm. Not every IT department installs the exact same kind of updates at the same time; for this reason, figuring out the build number of a SharePoint farm can be more of an art than a science.
Before deploying any update, it is important to be aware of the current build number of the SharePoint Products and Technologies deployment. It is also important to ensure that all servers within a SharePoint farm consistently share the same build number. Having the same build number is defined as “specific SharePoint Products and Technologies installed from an MSI file that is at the same update level.” For example, if you have an Office SharePoint Server farm with five servers, you could have Windows SharePoint Services Service Pack 2 (SP2) plus the June Cumulative Update (June CU) and Office SharePoint Server SP2 without any cumulative update installed on top of it. This is acceptable as long as all five servers are configured in the same way. If three of the servers have Windows SharePoint Services SP2 plus the June CU, and two of the servers only have Windows SharePoint Services SP2 without the June CU, you have not achieved consistency. The June CU should be applied to the two servers that are out of sync from a build number perspective.
To clarify this point: We are discussing the build number on a per-product basis. The build numbers in the content databases, site settings, and Central Administration site are based on the Windows SharePoint Services build level; they are not necessarily the same for other products such as Office SharePoint Server, Project Server, and so on. You can update the different products to different build numbers, but we recommend that you keep them in sync to maximize the benefit of applying fixes that cross product boundaries. For example, it will not harm your environment if you do not keep Windows SharePoint Services and Office SharePoint Server in sync, but if Microsoft releases a hotfix that requires both Windows SharePoint Services and Office SharePoint Server builds to be past a certain build number, you will not gain the benefit of that fix, and your environment will remain “broken” in the same way it was before the partial fix was applied.
Build Number Format
The format of a SharePoint Products and Technologies build number is shown in the following illustration.
The build number is composed of the following four numbers:
- Major This indicates the major version of the product. For Windows SharePoint Services 3.0 or Office SharePoint Server 2007, this is always 12.
- Minor This indicates the minor version of the product. For any version of Windows SharePoint Services 3.0 or Office SharePoint Server 2007, this is always 0 for our binaries when our major version is 12, and will not be incremented when we install service packs. (In some contexts, this number will change; for example, in the upgrade log, you may find references to 12.1, where the .1 represents Service Pack 1).
- Build This is what we can use to indicate the version number. This is the number that is incremented when we apply a service pack or any other update. Some examples of build numbers and their corresponding versions are given below:
- 4518 is the RTM build
- 6219 is SP1
- 6320 (Windows SharePoint Services) and 6322 (Office SharePoint Server) are the Infrastructure Updates
- 6421 is SP2
- 6520 is the October 2009 CU
- Revision The revision number indicates the type of update that has most recently been applied. Some examples are given below:
- 5000 is a fully supported, COD hotfix suitable for a production environment
- 1000 is a service pack
- 300x is private release build for a customer who has been working with Microsoft Premier Support. This type of update should not be deployed in a production environment, because it has not been properly integration-tested. However, if this type of update is applied to a production environment, the final hotfix or later hotfixes will replace it as a final release and will have a higher revision number in the format of 500x.
Caution Using a private release in production can cause irreversible data loss. In many cases, Customer Service and Support can work through non-data loss scenarios, but the risk of data loss is so high with private release builds that Microsoft has taken the stance that these types of builds should never be put into production.
