Part 2

The Dreaded Late Night — A Typical Patching Experience

In our blog series this week, we’re looking at the dreaded patching process for SharePoint. In my last blog, we defined the three different types of updates: Hotfixes, Cumulative Updates, and Service Packs. Today we’re going to discuss the typical process for installing and activating the updates, specifically, the Cumulative Update, as it will likely be the most common and frequent update you’ll apply to your farm.

A typical patching experience often looks like this:

• Friday night: The Windows Team installs the Cumulative Update (CU) on each of our 7 SharePoint farm servers.
• Saturday morning: We begin running PSConfig on each SharePoint server, starting with the Central Admin server.
• Saturday afternoon: The team verifies that the content database upgrades aren’t going to finish for a long time.
• Saturday evening: Late night troubleshooting the PSConfig update errors.
• Sunday morning: We verify that the content database upgrades still aren’t going to finish for a long time.
• Sunday afternoon: more troubleshooting, this time we’re tackling the content database upgrade issues.
• Sunday evening: Another wasted weekend is over.

But it doesn’t have to go like that! With some changes, my team’s patching experience can look like this instead:

• Friday night: The Windows Team installs the CU on each SharePoint server.
• Saturday morning: We begin running PSConfig on each SharePoint server, starting with the Central Admin server.
• Saturday early afternoon: The team finishes upgrading the content databases.
• Saturday mid-afternoon: We verify functionality and head to the links (golf or sausage).

So, how do we shave 12 hours off the patching time? The key is understanding the patching process in-depth. I divide the patching process into three segments:

• Before you install the patch on the production farm
• During the maintenance window
• After you finish running the update

So, BEFORE I start the patching process, I do my due diligence. I research the CU and make sure it addresses an issue. I download it into the environment. I install it on a test and/or staging farm. I verify that it doesn’t break anything or, if it does, I can live with the results of installing the CU.

Finally, during this pre-install segment, I create a folder structure on my farm servers where I put the CU files and some scripts I will use during the patch installation. Perhaps most importantly, I create a checklist of the steps I plan to take, including time estimates, so that I have a blueprint I can follow—believe me, you’ll thank yourself for it later (or sooner, actually).

Now, ok, so far you’ve heard a lot of claims of time saved, and all the steps that have been explained seem to add time and activities to the process. Where is the time savings??? We’re getting there…

A patch event can be looked at as having the following components:

• Installing the update on the servers
• Updating the SharePoint Service Applications and configuration database
• Updating the site collection content databases.

The problem is that if you don’t manage these events, you’re at the mercy of the default update process. This process is sequential. And single-threaded. With our 12-step patch installation process, we make that process parallel and multi-threaded. And THAT saves you time and frustration.

Join me on the next blog as I share this 12-step solution and dive deep into each step.