[Update: People asked why the official guidance on SharePoint Team Blog and CAPES Blog are different from my post – The official guidance is to keep the consistency with the patching methods in the past. At the meantime we are also working hard internally to provide crisp clear official guidance in the future, so stay tuned. ]
There’re always lots of questions around SharePoint patching. How to patch SharePoint? Which patch should I use to get a certain build number? In which order should I apply those patches? What is CU? What is SP? What is the difference between them?… All these questions are hard to answer – because to understand the answers, you have to understand the patching process of SharePoint.
Let’s go through different scenarios of SharePoint patching. Hopefully this can explain the mystery. I will start with the easy one and then the complex one.
Apply a security/feature fix on SharePoint Server Farm
This is the most simple scenario in SharePoint patching. Download the patch, apply it to every SharePoint Server in the farm and run PSConfig on all of them. That’s it.
Wait, is this really that simple?
The answer is no. Because there will be quite a few questions here:
- Will my database be updated?
Maybe. Depending on which DB version you have right now, a DB schema may or may not be triggered.
- When will the database be updated?
If a database schema update is necessary, then the first time you run PSConfig those databases will be updated. Alternatively you can detach all content databases, apply the patch, run PSconfig, and then reattach content databases. In this way you can choose when to update individual content databases.
- How can I tell if this patch can be applied to my farm?
Take a look at the build number. SharePoint patch will check the version number to decide if a file should be replaced or not. If you already have a component with a higher version number, then it will not be touched since all the fixes are already included.
- How can I know what is included in the patch?
Aha! Now you get the point. I’m going to share my secret here, you may have never seen this before on any official documents.
Look at the KB article of the fix. There is a file information table which contains all MSI/MSP/CAB filename, size and date. The following quick table may help you to understand the names:
Directory Name File Name Component SharePoint Server 2010 ACCSRV acsrvwfe Access Services DLC dlc Document Lifecycle Component IFS ifswfe Infopath Forms Services LHPSRV lhpwfe Slide Library OSRV osrv Shared Components MEWA mewa Excel Mobile Viewer Component PPL pplwfe User Profile PPSMA ppsmawfe PerformancePoint Services SEARCH oschwfe Search Server 2010 Core SPS spswfe SharePoint Portal VISIOSERVER/VisioSrv vsrvwfe Viso Services WASRV wasrvwfe Web Analytics WDSRV wdsrv Word Server (Word Automation) WSS sts (wss) SharePoint Foundation 2010 Core XLSERVER xlsrvwfe Excel Services SharePoint Foundation 2010 WSS sts (wss) SharePoint Foundation 2010 Core Office Web Apps 2010 WACMEWA wacmewa Office Web Apps Excel Mobile Viewer WACWFE wacwfe Office Web Apps Web Front End WOSRV wosrv Office Web Apps Shared Components XLSERVERWAC xlwacwfe Excel Web App Components Project Server PRJSRV prjsrvwfe/pswfe Project Server Web Front End
Table 1. All Components in SharePoint 2010 Related Products
File names ending with “MUI” means MUI/Language Pack for that component. For example dlc and dlcmui, sts and wssmui, etc. Ending with -x-none means it is not language related.
It is very important to understand the above table – if you really want to get clear on patching, you may want to recite it . Anyway, sometimes the description provided on KB pages are not correct. For example http://support.microsoft.com/kb/2516497 says it is a Office Web Apps hotfix package in April. And here’s the file table:
Use my table above to look up the component, you will find WDSRV does not belong to Office Web Apps, but SharePoint Server 2010. It is the Word Server (Word Automation) component. Someone mistakenly labeled it Office Web Apps hotfix. So, if you tries to apply this update to a SharePoint Foundation + Office Web Apps installation, it will never work – because this WDSRV component does not exist. If you applied any SharePoint Server update that has a higher version number than this patch, it will not be able to be applied either since the fix is already included.
Is this helpful? Let’s go on to the second scenario: Cumulative updates.
Apply Cumulative Updates/Service Packs on SharePoint Server Farm
CU packages are released in a bi-monthly manner. We want to make it more predictable so customer can plan their patching window, and save time by package everything together. CU does not have the same testing quality with Service Packs in theory, and the release schedule is always a little bit funny. Most of the CUs are scheduled to be released at the end of that month (subject to change), for example Apr CU was released on Apr 26th. If a last minute regression comes in at that time, then the release will be delayed, and you may already noticed Feb CU was released in March 3rd, to ensure the quality.
I used to post CU release information on SharePoint Team Blog. Now Stefan Goßner’s blog is my favorite to catch up with all the information. For example his Apr CU post is quite clear on the packages: http://blogs.technet.com/b/stefan_gossner/archive/2011/04/27/april-2011-cu-for-sharepoint-2007-and-2010-has-been-released-today.aspx
You can see he listed all the full server packages. Please remember, unless necessary, please only use these server packages to apply CU update. Internally we call them “Uber” updates, which includes all language packs and all components. If you are not using these packages, you may be missing some component updates. How to tell that? Using the table above to compare with the file information tables in KB article, and you will find all of the components are covered, with all MUI packages. Individual fixes do not have all of them.
Service Packs are different. Traditionally the service pack downloads does not give you an all-in-one package like the Uber updates do. Language packs are not there in the main package, you need to download and apply them separately.
Now here are the questions:
- Do I need to install SharePoint Foundation CU first to update a SharePoint Server farm? 【Please follow SharePoint Team Blog/TechNet guidance to apply the patches at this moment】
No. SharePoint Foundation CU are included in SharePoint Server CU packages. Look at the table I showed you above, STS.CAB is all what Foundation has, and that is already included as part of SharePoint Server 2010 and its CU/SPs. Apply Foundation CU before a SharePoint Server CU won’t break your farm, just a waste of time since the setup program has to go through those files twice.
- Should I use slipstreamed SharePoint server installation files to deploy SharePoint and its CUs?
Maybe – depending on if you want to use language packs or not. If language packs are not installed when you install SharePoint Server, and you install those LPs after the server has been installed, you may need to reapply SharePoint CU packages to get all those LPs up to date.
Best way to install a up-to-date multi-language SharePoint Server 2010 farm now is
- Install SharePoint Server 2010 with SP1 Slipstreamed
- Install SharePoint Server 2010 Language Packs with SP1 Slipstreamed
- Install Office Web Apps 2010 and Project Server 2010 with SP1 Slipstreamed if necessary
- Install SharePoint Server 2010 (with Project Server 2010) latest CU Full Server Package
- Install Office Web Apps 2010 latest CU (if exists)
- Run PSConfig
All the above is just to identify which update should be installed. The best “how to patch” article is still the one on TechNet: http://technet.microsoft.com/en-us/library/ff806338.aspx and it covered how to monitor patching, how to reduce downtime, etc.