The challenge
Patching SharePoint is a process not to be undertaken without planning and preparation, and given the frequency of errors and failed upgrades, is not for the faint of heart.
One of the challenges is that the patch process causes an outage regardless of any High-Availability configuration you may have in-place: it's just the way patching happens in SharePoint. Without a way to patch on-line, meeting Service Level Agreements for uptime can be challenging or require the judicious use of "Scheduled Maintenance Windows". This does allow us to meet the SLA for uptime, but in the eyes of the end-user SharePoint is down "again" - not our ideal scenario.
This recent article by Sam Betts, Smoother SharePoint Patching, discusses approaches that can minimize the time it takes to have SharePoint back on-line in a patched state. I've often used and prefer the third approach from the article: "Disconnecting Content Databases Pre-Upgrade".
The approach
The general approach is to run PowerShell scripts that:
- loop through the attached content databases (
Get-SPContentDatabase) and pipe the names to a text file
- dismount all content databases from the farm (
Dismount-SPContentDatabase) - apply the desired patch to the farm, using Russ Max's script that speeds things up [^n]
- run
psconfigto upgrade the farm - using the text file as input, attach each of the databases to the farm without performing the build-to-build upgrade (
Mount-SPContentDatabase -NoB2BSiteUpgrade) - selectively upgrade content databases based on priority (
Upgrade-SPContentDatabase)
If your farm has more than a single web application or SQL Server instance hosting SharePoint content databases, you will need to specify additional parameters when running the PowerShell commandlets and target the specific web app or SQL instance.
One additional step that I like to take is to bring online the databases that are of highest-priority first, and then start the upgrade on those content databases prior to attaching those of lower-priority. In order to make this happen I will generally use more than a single input file for the Upgrade-SPContentDatabase or add a column in the file that indicates the priority.
Summary
Applying SharePoint patches is an often lengthy process, and one that requires downtime; by using some of the techniques described above you can reduce the time required significantly. In today's 24/7 environments with SLAs to meet, every minute we gain counts - both operationally and in the eyes of our clients.