SharePoint 2010 Patching/Upgrade (Part 2) – Which Patch-Level/Build-Level is installed & what’s their history?

Hello @all,

after publishing the first Patch level of SharePoint 2010 (JuneCU 2010) i get some question regarding a new view in SharePoint 2010 Central Administration. There we can see the current Patch level  of each SharePoint server and of the whole farm.

As little introduction into SharePoint patches lets define some basics:

1. After installing binary on a server, we need to execute the psconfig / configuration wizard to upgrade all related databases into new schema level.

2.In the SharePoint world we need to make a difference between a single patch/Hotfix and an ueber package:

A single Hotfix was created for a single product issue and modifies only one single component in SharePoint. Each component has a unique patch level included into the file properties.

Like descript on my previous post we get every 2 month a new build level of SharePoint. In the first step we get a single Patch for each single component which get updated. Like in SP2010 JuneCU 2010, here we have 7 single Patches for a complete Server/Farm patching into the next complete build level. One Patch for WSS/MSF and 6 patches for the Office Server components.

An ueber package is package of all Hotfixes related per product (MSF or OfficeServer). This include all components of the new build level. This makes it easier in patching SharePoint server, because you only need to install two patches: (one WSS/MSF ueber package and one Office Server ueber package to enter the next build level)

For every System Administrator it’s important to know, which build level is currently installed on the machine. Therefore we have in the central administration a new User Interface:

In the central administration/ Upgrade and Migration / Check product and patch installation status:

First Question:

Why we have this UI in the section “Upgrade and Migration”?

Because every patch installation in SharePoint can include a database schema level update like: stored procedures were modified, database tables were modified, etc.
That’s the same function which is used for a SharePoint Upgrade. The only difference we have is the upgrade mode.

SharePoint Upgrade mode:

- build to build –> is used for Patching, we jump from one build level into the next build level of the same product.

- version to version –> is used for an Upgrade, we jump from one product version into the next product version, e.g. 2007 to 2010.

On the view: “Check product and patch installation status” here we can see the patch level of each component in our SharePoint server installation. SharePoint 2010 was published in RTM with build level: 14.0.4763.1000. If you install the JuneCU 2010 then some component will be patched into a new build level.

Build Level of JuneCU 2010 =  14.0.5114.1003

So a SharePoint Farm with installed JuneCU2010 looks like:

 

As you can see, some component run on RTM build level and some on JuneCU2010.

It’s also a nice feature to drill down the component for each server:

Note: My host machine has the name: SP4763

With this UI we are able to see Farm-Level and Server Patch Level of any SharePoint server.

With PowerShell we can get this information with:

get-spproduct

with using the object model we can drill down into the server and their components:

get-spproduct |get-member

$sp2010 = get-spproduct

$sp2010.servers

In a bad case of bad patching steps it can help to run through the object model and focus on properties like:

$sp2010.InstallStatus
$sp2010.RequiredButMissingPatchableUnits
$sp2010.RequiredButMissingPatches
$sp2010.RequiredButMissingProducts

All components we get with:

$product = get-spproduct
$product.PatchableUnitDisplayNames

 

With a look into the database it’s also possible to see the patching history of each database. In each SharePoint database we will see a table named Versions which include an entry of the schema level.

E.g.

In my demo farm i installed SharePoint in RTM on 26.04.2010 with my system account (demo\administrator). On the 18.08.2010 i installed JuneCU 2010 with the same account.

In case you will some like this:

 

Then you know:

- this contentdb was upgrade from sharepoint 2007, because any version beginning with 12.0.0.xxxx is from SharePoint 2007.
- in case you see something like 6.0.x.xxxx then we know, this database was migrated from SharePoint 2003 to SharePoint 2007

on this screenshot you see build level 6.0.2.6568 which is SP2003 SP3 and 12.0.0.6318 which is SharePoint 2007.

So in a production environment were SharePoint runs since a long time you may will see a structure like this:

version table:
6.0.2.6568                  -> sps2003
…
12.0.0.4518                -> MOSS 2007 RTM
12.0.0.6219
12.0.0.6318
12.0.0.6341
12.0.0.6421
12.0.0.6510
…
14.0.4762.1000           -> SP2010 RTM
14.0.5114.5000           -> SP2010 JuneCU 2010
…
-> this means your data structure has a long patching history

In a really bad and worst case you may be see something like this:

version table:
6.0.2.6568                  -> sps2003
…
12.0.0.4518                -> MOSS 2007 RTM
…
14.0.4514.1009          -> SP2010 Beta   -> UNSUPPORTED Upgrade
14.0.4762.1000           -> SP2010 RTM

-> This means the data structure is not supported because in the past was an unsupported upgrade method has been used.

Now the next question: why is the version table important?

For any SharePoint Upgrade Project and planning the SharePoint patching history can be used for a risk calculation.
In case our data structure is very old, then we need to be aware of old relicts can be inside of the data structure and can be an upgrade blocker. In the last example the upgrade blocker would be: “14.0.4514.1009 -> SP2010 Beta -> UNSUPPORTED Upgrade” if you start the upgrade planning be aware of the patch history.

Regards

Patrick

Comments

• Anonymous
  October 04, 2011
  Excellent article...exactly what i was looking for....and i was having trouble finding the right combination of words for the search query. Update SharePoint recently to August CU and SP1...suddenly there are two "ghost" servers reporting missing update files. This is funny at 1st...until solution stop deploying as they wait for a nonexisistant timer job. Upgrades reporting services is not happy.....and could not find any info or anothers experience with the same situation. hopefull this info will help me find a solution.