SharePoint 2010 Service Pack 1 and June 2011 CU

Last week, Microsoft released Service Pack 1 for SharePoint 2010 and—to many people's surprise and dismay—the June 2011 Cumulative Update (CU) for SharePoint 2010. What ensued was a tragic comedy in many ways. It serves to emphasize just what kind of "disruption" (and wake-up call) SharePoint serves, the level of discipline that enterprises must build around their SharePoint service, and some of the weak spots in Microsoft’s communication about the updates.

I'd like to summarize the steps for deploying and the issues related to SP1 and the June CU, in hopes of clarifying and simplifying the noise and guidance that’s arisen over the last week.

About SP 1

Service Pack 1 includes a regression-tested set of all fixes released through April 2011, as well as important new features, functionality, and PowerShell cmdlets, much of which is described on the SharePoint team’s blog, and which Caroline Marwitz detailed last week. Service Pack 1 is a new baseline, as defined in Microsoft’s support policies, so the reality is that you should aim to install this service pack at some point—perhaps sooner rather than later. You can install SP1 on the RTM version of SharePoint 2010, or on a system with any cumulative update through April 2011.

About the June Cumulative Update

The June CU includes updates released after April 2011, including some updates to the SP1 bits. Technically, you can install the June 2011 CU without SP1, but please don’t. Assume that you will install the June 2011 CU after installing SP1.

Now the question becomes, “Should you install the June CU?” Typically, my answer would be, “only if it solves a problem you actually have.” Updates are not regression tested, so they do have the potential and the track record of breaking things.  In fact, the June 2011 CU is no exception—there are already issues reported with—you guessed it—the User Profile Synchronization Service, aka the bain of my existence. See Todd Carter’s blog entry, "User Profile Heats up with June CU regression" for details and the fix for this issue.

However, in the case of the June 2011 CU, my guidance is a bit more nuanced, and I think you should consider installing it. First, my read of the update set is that it’s likely you will want to install this CU. But, more importantly, my experience is that the biggest bottleneck in update deployment is getting an update through whatever change management process you have in your organization, and testing the update and your deployment strategy. 

That considered, you will be putting yourself into test-and-deploy mode for SP1, so why not also consider continuing the test and deployment with the June 2011 CU. Get it over with while you’re in the zone.

For all of the details about my guidance about updates, see "How SharePoint 2010 Changes the Update Story: When and Whether to Install Updates."

How to Install SP1 and the June CU

So let’s assume that you are going to install SP1 and the June CU. Here’s the process, and some color commentary. The most important and (in some cases) undocumented steps in the entire process are steps 1-3 and 8-9.

STEP #1: Ensure Your Test Farm Is the Same as Your Production Farm

You must—and I mean must—test the deployment of an update or service pack before deploying it in production. See the previously mentioned article to set the stage, but here’s the key takeaway: If your test farm isn’t the same as your production farm, you cannot conduct an adequate test. Many of you know that Dan Holme’s QA Rule #1 is:

No Test Farm = No Production Farm

If someone comes to me and says, “we don’t have a test farm,” my answer is,  “no, you don’t have a production farm.”  The corollary to Rule #1 is:

A Test Farm That’s Different Than The Production Farm = No Test Farm

And so, transitively:

A Test Farm That’s Different Than The Production Farm = No Test Farm = No Production Farm

Right? Now “equal to” must be taken in context. In the case of an update deployment, I recommend you consider a test farm that has exactly the same data and SharePoint configuration as your production farm. 

But duplicating the underlying hardware of the production farm is, in many cases, not as important and, realistically, probably not available to you.  I don’t expect many enterprises to have test farms that are exactly identical—the cost of Tier 1 storage and hardware is generally prohibitive. There’s a cost-benefit decision that must be made, and a level of risk assumed.

But if you haven’t tested an update against exactly the configuration, content, custom code, and additional “bits” installed on the farm, you haven’t done your job. And if something breaks in production because of one of those things, please do not blame Microsoft.  I know people who use a single virtual machine (VM) as their test farm for these kinds of tests, and simply restore a backup of the production databases to run the test against.  You may not be able to get a good feeling for performance of the update without the same hardware, of course.

How do you ensure your test farm is the same as your production farm?  Well Step #2 might be the answer…

STEP #2: Back up the Farm and Test the Restore

I can’t believe I still have to say this, but based on what I saw happen when the community went update-crazy last week, there are still a few people who need to be reminded .  Remember, a backup is useless unless you know it can be restored.  This is the time to test your farm-level disaster recovery process!

STEP #3: Read the Installation Notes (the “README” file)

Read the README! Really, people, READ the notes! The installation notes--the all-important README file--can be found at the Microsoft website.

One important note is that the .NET Framework version 4 can cause problems for you. Read "Description of the SharePoint Server 2010 cumulative update package (SharePoint server-package): June 28, 2011", and Todd Carter’s blog entry mentioned earlier.

STEP #4: Download the Updates

My favorite easy-to-use resource for the links to the downloads is Bill Baer’s blog entry. You can also start at the SharePoint 2010 Products Updates Resource Center, but as of today, this site still hasn’t been updated to link to the June 2011 cumulative update.

The Office and SharePoint Update Center has links to the following products:

It would be really nice to include these update links on the SharePoint update site, wouldn’t it?  Microsoft, are you listening?

I also just discovered this very nice TechNet list of updates.  I’m not sure why this has not become the most publicized download page for this set of updates. 

You will perform each remaining step in your test environment first, then in production, as emphasized in Step #1.

STEP #5: Install SP1 on Each Server in the Farm

OK, now you have graduated to the level at which you can begin to install the updates. This is “Step #1” in most other articles, so if you’ve read everyone else’s guidance about SP1 and June 2011 CU deployment, you’re good-to-go, already. Note that you can skip reboots until all updates have been installed.

STEP #6: Reboot and Run PSCONFIG

Now, reboot each server in the farm. Then run PSCONFIG on each server, to update the binaries on the server: 

psconfig -cmd upgrade -inplace b2b -wait

The first time you run PSCONFIG in the farm, the databases will be updated.

STEP #7: Verify Success

After installing SP1, the version of the content databases will be 14.0.6029.1000. And your farm should be functioning correctly. For details about how to verify an update, see "Verify upgrade and review upgraded sites (SharePoint Server 2010)."

STEP #8: Back up the Farm and Test the Restore

You’ve got a new baseline. Capture it!

STEP #9: Read the Documentation

Read " Description of the SharePoint Foundation 2010 hotfix package (sts-x-none.msp, wssmui-xx-xx.msp): June 28, 2011."  

STEP #10: Install June 2011 CU on Each Server in the Farm

While several resources from Microsoft suggest installing SP1 and the June 2011 CU together, this is terrible advice. SP1 is a regression-tested baseline. The June 2011 CU is a non-regression tested update. You’ll notice that CU installation files are much bigger than service packs, because they include multiple languages.

STEP #11: Reboot and Run PSCONFIG

As in Step #6, run the following on each server in the farm:

psconfig -cmd upgrade -inplace b2b -wait

STEP #12: Verify Success

 After installing the June 2011 CU, the version of the content databases will be 14.0.6106.5000. And your farm should be functioning correctly.  For details about how to verify an update, see "Verify upgrade and review upgraded sites (SharePoint Server 2010)."

STEP #13: Back up the Farm and Test the Restore

There’s no time like the present.

Remember, you will repeat Steps 5-12 first in your test environment, and only after verifying success, in your production environment.

ADDITIONAL NOTES

In SharePoint 2010, Microsoft enhanced support for a richer set of update deployment options. For example, you can install the binaries of an update, service pack, or upgrade, then update farm databases as a second step. The process is very similar to a database attach upgrade—you detach your databases, install the updates, run PSCONFIG, then attach databases. Be sure that you’ve read "Prepare to deploy software updates (SharePoint Server 2010)." 

RESOURCES

Be sure to read Spence Harbar’s excellent blog entry, "So What's the Fuss? SharePoint 2010 SP1 and June CU."

And for detailed steps about updating, read Microsoft’s "Install a software update (SharePoint Server 2010)."  Want even more detail? See Microsoft’s SP1 whitepaper.

Finally, in addition to the other links in this article, here are some great resources:

·         Office 2010 Cumulative Update for June 2011

·         Description of the SharePoint Foundation 2010 cumulative update package (SharePoint Foundation server-package): June 28, 2011

·         Description of the SharePoint Server 2010 cumulative update package (SharePoint server-package): June 28, 2011

·         Description of the Office Web Apps hotfix package (wacproof-sv-se.msp): June 28, 2011

·         Description of the Project Server 2010 cumulative update package (Project server-package): June 28, 2011

·         The Mystery Behind SharePoint 2010 Patching

·         Joel Oleson’s blog post: "10 Best Practices and Recommendations for SharePoint 2010 SP1 and June 2011 CU"

Microsoft does an incredible job releasing updates for a gigantic suite of products across numerous languages. It can’t test every scenario, because each of us is doing our own strange and bizarre things with the product.

The SharePoint team has done great work, overall, with these updates, and it’s our turn as customers to build discipline around our update deployments. It’s critical that you test, test, test, and back up (and test the restore). 

That said, any update to an enterprise-critical service is a big deal, so I wish you all the best with it!