I’ve installed and updated a ridiculously high number of SharePoint farms over my career already. Patches, service packs, and cumulative updates are an essential part of keeping operations running smoothly and preventing incidents from causing downtime. But for many of us, we have to rapidly assess and maintain a large number of SharePoint servers.
Microsoft rolls up off the patches into a consolidated update every two months (February, April, June, August, October, and December). Major functional changes are usually only made as part of a Service Pack. SharePoint 2007 has issued a few Service Packs – the current one is SP3. For SharePoint 2010, so far, there’s been only one – SP1. And no Service Packs yet for SharePoint 2013.
Usually cumulative updates are just that – cumulative. But Microsoft did a funny thing with SharePoint 2013. They issued a “Public Update” in March 2013. This became the new ‘baseline” for all subsequent updates. In other words, you need to apply the 1.7GB March 2013 before you could apply the 1.9GB April 2013, June 2013 etc. patches.
So, to understand your patching requirements, you need to know two things:
Microsoft aggregates some of the latest patches and versions on TechNet. (True story – these pages started because of an audience question to Steve Ballmer at the SharePoint Conference keynote in 2009!)
And since I don’t remember internal versions and build numbers well, I tabulate all of them on my personal blog at http://www.chrismcnulty.net/blog/Lists/Categories/Category.aspx?CategoryId=5&Name=Version-Build%20Numbers
That’s great. But how do we find the patch level for each server in the farm? You can visit each server to run a command. That’s tough in a big enterprise. In part, we added the infrastructure management features in SIteAdmin5 for me. If you need to assess a new SharePoint system quickly, you need to grab information about numbers of servers, RAM, free disk space, roles and versions. Take a look at a screenshot from SiteAdmin:
See that 15.0.4420.1017? That’s the build number, and it tells me that this server is running the October 2012 original RTM build of SharePoint 2013. So this server needs the Public Update before it can be patched.
Its simple for a single server – but Site Admin can aggregate all the servers across all the farms at all version of SharePoint in your enterprise. No more scripted queries on each server or sequential logins to separate Central Admin consoles. Supa-cool!
OK, so you’ve found a patch you want to install. Obviously, first you need to download them. Service Packs are usually directly available for download. For Cumulative Updates, you have to supply an email address, and you’ll be sent a link to a password encrypted download file. Once you’ve extracted the files, you’re ready to begin.
For SharePoint 2010 and 2013, patches are usually specific to a target platform:
Prior to August 2011, patches were sequential – meaning you need to download and apply the patch for Foundation first, then the patch for Server. This should no longer be needed on contemporary SharePoint systems.
At a high level, patching involves both installing the patch on relevant servers followed by deploying the patches on all servers. The deployment is usually run from the SharePoint Products and Technologies Configuration Wizard, and updates databases, system settings and deployed code. Deployment also goes in sequence:
Here’s the process:
When the update completes, SharePoint Central Administration should launch, indicating that the system was successfully updated. You can check on the health of the update in Central Admin > Upgrade and Migration > Check Product and Patch Installation Status.