Skip navigation

How SharePoint 2010 Changes the Update Story: When and Whether to Install Updates

Should you even install SharePoint updates?

Last week, Microsoft released the April 2011 Cumulative Update (CU) for SharePoint Foundation, SharePoint Server, and SharePoint Server with Project Server. Given thatService Pack 1 for SharePoint is right around the corner—due this summer—my guess is that this will be the last CU to be issued before SP1. The CU downloads are available, but the corresponding KB articles with descriptions of the CUs are not posted quite yet. You can find links to the downloads and (not-yet-available) links to the KB articles at Steve Chen’s blog.

I thought that the release of this CU presents a great opportunity to discuss SharePoint updates in general. There’s a lot of varied opinions out there about when and whether to install updates, so I’ll throw my opinion into the mix to provide some clarity and guidance. SharePoint 2010 also changes the update story somewhat from SharePoint 2007, so we’ll look at the differences and new features.

As with other Microsoft products, Microsoft releases an update that falls into one of a variety of categories: update, update rollup, service pack, feature pack, critical update, security update, or hotfix. Of these categories, only service packs and feature packs are fully regression tested. Other update categories are not fully regression tested, in order to deliver the update as quickly as possible to the market. The lack of full regression testing carries with it increased risk, although experience shows that in most cases, the increased risk is minimal-to-none.

The keyword there is most. Unfortunately, it only takes one update that causes unintended consequences in your environment to ruin a weekend. Updates have been known to “break” things.

Therefore, my recommendation is that you should apply service packs and feature packs (including language packs and filter packs), but that you should only apply other types of updates when the update either fixes a problem you know you have or patches a security vulnerability to which you are exposed.

I am reluctant to recommend installing updates just because they are available. Instead, wait for the fully regression tested version of the update, which is in the service pack.

My guidance is different when installing a new farm. If you’re installing a new farm, you don’t have anything in production that can break. Therefore, my preference is to begin with the most updated set of binaries. Because you must run PSCONFIG after running SharePoint setup (setup.exe) and again after installing an update, you can save yourself a step: for each server in the farm, run setup.exe to install SharePoint, then install the update, then run PSCONFIG one time.

When you do decide that you want to install an update or service pack that has just been released, I recommend that you wait a couple of weeks to listen for screams of pain from the community. Every once in awhile, an update is released that, within a few days, the community and Microsoft discover causes unintended side effects. Don’t be on the bleeding edge—at least not on your production farm.

And that leads to the single most important bit of guidance:. Always test updates of any kind in your test farm before deploying in production. People tell me, “My company doesn’t have a test farm—they don’t want to spend money for the hardware or licenses.” To that, my reply is simple: “No, your company doesn’t have a production farm.” It’s all about mitigating risk.

Without a separate farm on which to test customizations and updates, you put your SharePoint environment and therefore, likely, your entire enterprise at risk. And believe me, someone in your enterprise (you may have to go “up the ladder” to find him, her, or them) cares about risk!

When you apply an update, binaries are patched on the server. Often, you must run the SharePoint Products Configuration Wizard (psconfig.exe) to incorporate the update into the farm and to upgrade the configuration, content, and service databases in the farm. Content databases can also be updated in Windows PowerShell by using the Update-SPContentDatabase cmdlet.

There are two important changes to the update story in SharePoint 2010. First, you must only install the patch for the product you’re running. If you’re running SharePoint Server 2010, you do not need to apply the SharePoint Foundation update first, as you did with WSS v3 and MOSS 2007. Second, you can “stage” the deployment of updates—you can apply the patches to your servers and then, within a short time window (e.g. several days), update the databases. This allows you to patch critical functional and security issues—to update the binaries—and then, during your next maintenance window, perform the more lengthy process of updating the databases.

Microsoft has done a great job of documenting the update process with numerous articles on TechNet that you can access from the Updates for SharePoint 2010 page. There’s tons of detail about update strategies and processes.

Updating your farm is equivalent to upgrading your farm, e.g. from SharePoint 2007 to SharePoint 2010. It’s a big deal. The same processes and discipline you apply to a version upgrade should be applied to an update, because the same kinds of things can break an update that would break an upgrade—including and especially customizations. Do it for a reason, take time to plan to do it right, and test, test, test.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.