Print | posted on Thursday, June 30, 2011 8:01 PM
As I’m sure you are all aware, a couple of days ago Microsoft released Service Pack 1 (SP1) for SharePoint 2010. On the same day the bi-monthly Cumulative Update (CU) – the June 2011 CU - was released. Service Pack 1 of course has been hotly anticipated both by the community and customers alike. Unfortunately these releases have caused mass confusion and much contradictory advice regarding the packages and their installation.
This post is simply an attempt to reduce the amount of questions I receive about this topic, or rather have something I can point people to when they ask. Now of course, I don’t work for the SharePoint product group, so none of this is “official”. If you want that then I recommend you head on over to the Office Sustained Engineering Team blog post, which is the best official resource right now. There are of course other Microsoft places where certain recommendations and so forth are made.
In this post I will answer the most common questions from the point of view of the field. I have the luxury of being able to call it as I see it, for real based on customer deployments, not how it “should” be. I’m sure there are other questions that I don’t answer here, but these again are the most common ones over the last couple of days.
Partly due to this fiasco, the guidance from Microsoft has been fixed and made consistent. Since then this has proven to be the case. There have also been refinements made to the update packaging and application process. There are various updates throughout the rest of the post.
Q: Got any advice for me?
A: First and foremost, step away from the keyboard!
Seriously, updates are a major lifecycle event in the farm. You should be properly planning for and testing any updates. This should be part of the operational service management approach for your SharePoint deployment. Period. If you are hacking around on a single box VM of course things are different, but the more you know, the more you know! If you deploy an update and it breaks something that’s bad, but if you didn’t test it first, that’s pretty much no one’s fault but your own.
Q: If I am running SharePoint Server 2010 (SPS), do I need to install both the SharePoint Foundation (SPF) and SharePoint Server updates?
A: There are separate downloads for SPF and SPS. This is true for all the CUs and the SP. TechNet and the SharePoint Team Blog recommend you install both the SPF package and then the SPS package.
For quite a long time after the RTM of SharePoint 2010 a big fuss was made of the new style of packaging. The main thing being that you only needed to install the SPS package, which contains the SPF bits. A good attempt to make what is known as “uber packages” which streamline the installation experience for customers.
A few months ago however the guidance was changed to say “the best practice is to install both”. This is not a copy and paste error from how it used to be with SharePoint 2007. It was changed for a reason.
In principle you can get away with just installing the SPS package. This is how it should work. You may have been doing this for previous CUs with no problems at all, many have including myself on my private VM environments.
HOWEVER, there are cases where this may not work properly. There have been numerous issues with this approach. And this is why the recommendation is to install both before running PSConfig. It’s a “safest” bet. I’m not a fan of the term best practice, but the recommendation is to do both to avoid potential issues. I agree with that recommendation based upon my experience patching customer farms.
If you are comfortable simply installing the SPS package, and you don’t have any problems then great. If you hit issues, don’t moan that the SharePoint PG or the likes of me didn’t warn you!
There is of course the argument that this is a complete waste of time. Well couple points here. Firstly, that’s the how it should be. Not the how it is. Secondly, this is only valid if you can be sure it works, 100% of the time. And thirdly, the installation of the bits is the least of your time concerns when patching a large deployment. Seriously, the time it takes is minimal, it’s the time it takes to run PSConfig you should be worried about, or the time it takes to run Content DB updates in a staggered fashion for real deployments. Saving a few minutes installing binaries really is not a consideration in the real world. You’ve likely got multiple packages anyway (Language Packs, OWA). So again, this is just small fry.
Again the SPS package includes the SPF bits, that is not the issue here, the issue is the application of those bits. Have I patched farms with the uber packages successfully? Yes. But I've also been in the situation where it didn’t work…
I know some very clever and knowledgeable people disagree here, but I’ve hit problems with customer farms where it simply doesn’t work. So until I am sure the so called “uber” packages work, every time, I am standing behind the recommendation from the product group.
Could this guidance change again in the future? Sure. No one would be happier than me to see “uber” packages become the reality. [UPDATE 19/12/2011]
Now the guidance is to simply deploy the Server package. This works well now, much better than before and is what I do on all my deployments, customer and otherwise. There are additional considerations for language packs and OWA however.
Q: Does the June 2011 CU include the SP?
A: No. It does not. If you install the June 2011 CU on RTM you will have different bits than if you install SP1 and then the June CU. Any statement you see that says “the June 2011 CU includes all updates in SP1” is just wrong.
SP1 is everything up to and including the April 2011 CU plus some other bits and bobs (the new features and Windows PowerShell cmdlets).
The June 2011 CU contains updates to some SP1 bits.
The packaging of updates for SharePoint is ingenious and very smart, but with that comes some complexity.
Q: Can I deploy the June 2011 CU and not the SP?
A: Yes, but you probably shouldn’t. SP1 is effectively the new baseline build in line with Microsoft’s service pack lifecycle. It all depends upon your scenario. You can later install SP1 and it’s smart enough to know which bits to update and which not to. Bear in mind again, that the June 2011 CU contains updates to some SP1 bits.
Q: Why are the CU packages so much bigger than the SP packages?
A: Because CU packages contain all languages, whereas the SP packages are single language installers.
Q: A Microsoft blog says to install the CU at the same time or immediately after the SP, should I?
A: The answer is NO. No, no, no!
This is frankly untenable advice. You should only deploy the CU if you are affected by an issue it fixes or are instructed to by a Microsoft engineer.
Remember that CUs are a collection of hotfixes. Service Packs on the other hand are much more broadly tested. Any update is major lifecycle event in the farm and should be thoroughly tested before deployment into production (and I know you all do that right? :)).
Applying a CU just to be “up to date” is madness. Again, unless you need a fix that is in the package, don’t deploy. At least not immediately upon release. There are some of us who have to do this for certain scenarios sure, but your customers farms are not among them!
Remember the October 2010 CU? That had regressions and was pulled and re-released later. Remember the December 2010 CU? That had regressions that broke stuff and we had to wait for the February 2011 CU to fix it. I think you see my point.
[UPDATE 01/07] Hey, whaddya know? There are already regressions with the June 2011 CU. Like this one over here on Todd Carter’s excellent blog.
[UPDATE 12/07] Today the June 2011 CU was “re-released” to avoid some of the issues with the previous release. Kinda proves the point doesn’t it!
You can have much more confidence in the Service Pack as it is a Service Pack. the packaging mechanism might be the same, but CUs and SPs are very different beasts. Regardless I cannot stress enough the importance of appropriate planning and testing for updates of any kind. You should be doing this. Remember, it’s not about build envy, and having the most up to date farm!
[UPDATE 20/07] More and more details about the June CU have been shaking loose. It now is becoming clear why the Product Group were recommending it’s immediate deployment. However the advice above still stands (you need to test!) but there are numerous improvements in the June CU:
There are also numerous issues with SAML claims with just SP1 which are resolved with the June CU.
Assuming you are using the re-released June CU package, I now recommend it’s deployment. Why the Product Group couldn’t have just detailed the why initially instead of completely ignoring the question and waiting for others to discover things is beyond me! [UPDATE 19/12/2011]
The October 2011 CU is now my recommended baseline build.
Q: OK, so what order should I install the stuff?
A: Because of the way the packages are engineered the order isn’t actually important, but it makes sense to apply them in a logical order. For no other reason than it keeps things simple, especially when working with large farms. I approach the installation like this:
- SPF SP1
- SPF language packs SP1 (as needed)
- SPS SP1
- SPS language packs SP1 (as needed)
- OWA SP1 (as needed)
If it asks you to reboot, reboot once after the installs, not each time it asks. Then of course you run PSConfig on each server in the farm.
As for the June CU, you could include that if you like living dangerously. Or you can wait a while to see what shakes loose over the next few weeks! [UPDATE 19/12/2011]
As above it is no longer neccessary to deploy the Foundation packages, and you should consider the October 2011 CU as the baseline build. Why not the December? Well because it’s still December!
Q: Why is it all so damn complicated?
A: SharePoint Server is a complex beast. Suck it up. The sustained engineering folks are doing a fantastic job pulling this off. If you think you can do a better job of delivering updates for a product this size, used by so many, in a gazillion languages, you could prove it over here.