On July 13, 2010 we released a patch for Microsoft SharePoint Foundation 2010 running on Windows 7 and Windows Vista. The guidance in the KB article directs you to run PSCONFIG after the patch to complete the installation. If your workstation is set to allow Windows Update  to automatically install updates you might already have this update and not even know about it!

Look in your Windows Update history:

If you haven’t run PSCONFIG yet – this gives you a good opportunity to see what the new SharePoint 2010 patching process feels before the release of the first SharePoint 2010 CU. Open Central Administration on your developer workstation and select Upgrade and Migration. Click Check Product and Patch Installation Status. If you scroll down the list you should see an update listed under Microsoft SharePoint Foundation 2010 Core for KB 2032588. Clicking the link takes you to the KB article for the update – nice.

Now go back to the Upgrade and Migration page and choose Review Database Status. This page lists all the SharePoint databases, for services and content, and their respective patch status. On my workstation I had two Content Databases – one from a site and one from CA that have a status of:
”Database is in compatibility range and upgrade is recommended.” My Configuration database and the WSS Logging database also have the same status. This status means the content database isn’t at the same level as the bits of the farm – in this case the files that were updated in SharePoint Foundation 2010 Core. However the Farm and this content are available to end users.

If I open the SharePoint Management Shell I can use the Get-SPDatabase cmdlet to find the same information:

Get-SPDatabase | ?{$_.NeedsUpgrade –eq $true} | Select Name

Now to upgrade the Content Databases I need to run Upgrade-SPContentDatabase against the Content Database:

Get-SPContentDatabase | ?{$_.NeedsUpgrade –eq $true} | Upgrade-SPContentDatabase

Note: this command line  would run the Upgrade for every Content Database in the Farm that needs Upgrade, however this will do this one at a time through the PowerShell pipeline and not in parallel. Also the Central Admin Content Database will get updated by PSCONFIG. You don’t (and can’t) touch it with Upgrade-SPContentDatabase.

Get-SPContentDatabase –Identity WSS_Content | Upgrade-SPContentDatabase

Since this could be quite a long-running operation for a Content Database with lots of Site Collections – you are prompted to confirm proceeding with the process:

After you are finished with all your content databases – run PSCONFIG to finish updating the farm. When this completes, if you run this line again:

Get-SPDatabase | ?{$_.NeedsUpgrade –eq $true}

it will return no results since all databases have been upgraded.  Services in on a Server in Central Administration will now show the farm is at 2010 build 14.0.5050.5001. If you didn’t get all the Content Databases with the Upgrade-SPContentDatabase cmdlet – the PSCONFIG run will upgrade them during it’s run.

This new patching process definitely adds some much needed flexibility to the SharePoint patching story. The process allows administrators to patch pieces of the Farm’s services and content with out having in incur all of the downtime in the same maintenance window. You could potentially install the update bits on the box during the week in a short maintenance window (AFTER you’ve tested it first!) and then schedule a weekend outage to upgrade the content.