UPDATED NEWS: 8-7-13: I mentioned that SP2 didn't include the June cumulative update (CU), and that CU’s aren't regression-tested to the level of service packs. Well, true to form, two updates that went through two different “channels” don’t play well together. If you have SharePoint 2010 SP2, you shouldn’t deploy the June CU (instead, wait for the August CU). If you have the June CU, don’t deploy SharePoint 2010 SP2 until you have the August CU (then, deploy in any order). You can find details on the Office Sustained Engineering Blog. Thanks so much to Andy Talbot for pointing this out to me!
Microsoft released Service Pack 2 for SharePoint 2010 and the rest of the Office suite, which simplifies deployment of SharePoint 2010—offering a fully regression-tested and supported set of fixes through May 2013—and, importantly, sets the stage for support of SharePoint 2010 running on Windows Server 2012.
This week, I’ll point you to what you need to know about this important release.
SharePoint 2010 SP2 was published on July 21, and announced yesterday—July 23—through numerous channels including the SharePoint Team Blog. The most important thing you need to know is that you can download Service Pack 2 for SharePoint Server 2010.
Start the download NOW… it’s gigantic (437 MB). Let it start downloading while you read the rest of this article.
If you’re new to SharePoint updates, be sure to bookmark and explore the Updates for SharePoint 2010 Products page, which is the updates “resource center”—your first stop for all things update. Learn about the types of updates Microsoft releases, how to prepare for an update, and multiple ways to deploy updates.
Where to Get SharePoint 2010 SP2
Well I’ve already linked to the download for SharePoint Server 2010 SP2.
If you’re interested in SP2 for SharePoint Foundation, Project, Office Web Apps, or other Office server products—or for language packs—go to the List of Available SharePoint 2010 and Office Server 2010 SP2 Packages. There’s a great list on Steve Chen’s Blog.
And if you want to look at service packs and updates for ALL Office products—clients and servers—across all versions, check out the Update Center for Office, Office Servers, and Related Products.
What’s in SharePoint 2010 SP2?
That’s a good question! There are at least three answers.
Service Pack 2 includes all public updates through May 2013 and cumulative updates through the April 2013 CU. Keep that date in mind—because there was a June CU that is not part of SP2.
A list of the updates that were included can be found at this Microsoft Office blog post, but it’s pretty academic. It’s just “everything through May 2013.”
The more interesting, but very geeky answer to “What’s in SP2?” can be found in the Technical Details About the SharePoint 2010 and Office Server 2010 SP2 Releases article, which lists all of the patches (.msp files) included in SP2.
The most “human” answer to the question is found in the Description of SharePoint Server 2010 SP2. The article hints at something that isn’t made explicit elsewhere—that SP2 includes “previously unreleased fixes.”
So there are net-new items in SP2. From this article, there’s a link to a great little download: the Microsoft Office and SharePoint 2010 Service Pack 2 Changes package. This Excel-based file lists many of the changes and fixes in super-readable form.
I strongly recommend reading the file. At a minimum, search for each instance of the word “SharePoint” in the worksheet. There were a couple of interesting surprises for me—some things that had been broken that I hadn’t known before, and some improvements that make great sense.
When Should You Update?
I believe—but I haven’t had time to confirm—that Microsoft has already applied SP2 to its Office 365 v14 tenancies. That’s pretty significant “testing” from a user-impact perspective.
So my guess is that the update is safe for consumption. However, given the SharePoint team’s record with updates, it wouldn’t hurt to give it a week or two to listen for screams of pain from the community.
In the meantime, you can prepare for your first database-attach update, described below. Time well spent.
How Will You Update?
A notable link from the Updates site is the Install a Software Update article, which describes in great detail the actual procedures used to update a SharePoint farm.
This article is becoming increasingly important for IT Pros to understand, because it lists three different approaches to updating an existing farm.
Broadly speaking, you will install the binaries on servers, then upgrade specific services as required (sometimes a service requires you to update it using a Windows PowerShell cmdlet). Then you’ll update content databases, then run the SharePoint Products Configuration Wizard (psconfig.exe) on each server.
Unfortunately, at various points in the process, one or more or all servers in the farm are offline.
Most organizations are hosting more and more mission-critical data and workloads on their SharePoint farms, which puts pressure on the IT organization to minimize downtime and eliminate mistakes. It’s no longer viable for many of us to do an old-school in-place update, where the entire farm is offline while we update it.
The TechNet article provides two approaches that use rolling updates of web front-end (WFE) servers to reduce downtime. But the best approach—the most technically “pure” approach—is to do a rolling migration of the farm itself, using a database-attach update.
In short, you build a new farm that is updated, then migrate settings, services, and databases to the new farm. As you attach service and content databases to the new, updated farm, the databases are updated.
This is, in fact, how you must upgrade the farm from SharePoint 2010 to SharePoint 2013, but it is also a phenomenal way to reduce downtime and mistakes for updates.
It takes time to build an inventory of settings, scripts to manage the deployment, and procedures to ensure it runs smoothly. But if you establish the process now, with the upgrade to SP2, it will make your migration to SharePoint 2013 significantly—significantly—easier.
This rolling-farm, content database attach upgrade process is, in fact, how Microsoft updates Office 365 farms. It becomes easier as you use virtualization for your farm, rather than relying on physical hardware.
And it does not necessarily mean double the number of virtual machines during the migration. There is a temporary increase in the number of VMs, so your virtualization infrastructure needs some headroom, but it doesn’t have to be double.
For details, jump to the heading Use the Database Attach Method for High Availability of Existing Content.
Words of Warning
RTFM, y’all: Known Issues When You Install Office 2010 SP2 and SharePoint 2010 SP2. Luckily the list is short and may affect only one or two of you.
Windows Server 2012
At this point, you can’t yet install SharePoint 2010 on Windows Server 2012. To do that, you will need an integrated installation of SharePoint 2010 SP2, which includes SharePoint Server 2010 bits and SP2 bits, all-in-one.
That installation media is not yet released. My guess is within a week, you’ll see that appear—so watch Microsoft Downloads or the aforementioned update sites.
After the slipstreamed installation is released, you will be able to install SharePoint 2010 SP2 on Windows Server 2012, and the TechNet article about support for Windows Server 2012 will be updated to reflect newfound support for that scenario.
In the meantime, in theory, you should be able to install SharePoint 2010 SP2 on Windows Server 2008 R2 then upgrade the OS to Windows Server 2012. But you need an additional update, which is part of the June 2013 CU for SharePoint 2010.
See the Known Issues article, linked above, for details. I’ve not tested this scenario yet.
June 2013 Cumulative Update
Service Pack 2 does not include the June 2013 Cumulative Update (CU). So that CU should be considered a Post-SP2 release.
In other words, to be fully updated, you’ll need both SP2 and the June 2013 CU. You can download the June 2013 CU from TechNet.
As we all know—some of us painfully well—CUs are not regression tested to the same level as Service Packs.
Test, Test, Test
So, whether a CU or an SP, or any other kind of update, you should always TEST TEST TEST. Don’t assume that a change to bits is going to be flawless, and result in just the level of service you need for your internal or external customers.
You should always test. Another great reason to master the new-farm, content-database-attach method: It allows you to build out a test lab easily. Happy updating, everyone!