News

October SharePoint Cumulative Update Released

• By Kurt Mackie
• 10/15/2014

Microsoft this week released updates for both SharePoint 2010 and SharePoint 2013.

The October CUs are arriving this time without an "uber package," which is Microsoft's term for a "mini-service pack." The absence of an uber package means that IT pros have to ensure that SharePoint farms are already updated with the September CU fixes before applying the October ones.

Microsoft has previously explained this uber package concept, which can be confusing. Despite the use of the word, "cumulative," in SharePoint cumulative updates, SharePoint CUs only contain updates for a particular SharePoint component that got updated for a particular month. It's the uber package that contains the updates for all SharePoint components.

Microsoft's Advice
For organizations updating SharePoint 2013, Microsoft recommends installing "SP1 and September 2014 CU before installing October 2014 CU," according to an announcement by Stefan Gossner, a Microsoft senior escalation engineer for SharePoint.

For organizations updating SharePoint 2010, Microsoft recommends installing "SP2 and September CU before installing October 2014 CU," according to a second announcement by Gossner.

Gossner added that organizations running SharePoint Server or Project Server need to install the fixes for SharePoint Foundation as well.

After installing the October CUs, Microsoft recommends running the Products Configuration Wizard -- at least for SharePoint 2013.

For help in figuring out what's already installed on a SharePoint farm, Microsoft MVP Todd Klindt has compiled lists of the build numbers associated with Microsoft's SharePoint update distributions. SharePoint 2013 build numbers are shown at this page, while SharePoint 2010 build numbers can be found here. He also posts alerts via his SharePoint 2010 and SharePoint 2013 Twitter streams.

SharePoint Patch Q&A
I asked Klindt via e-mail to clarify a few things about SharePoint updates that may be obscure. Here's a Q&A that's been edited for brevity.

Redmond: In checking updates on a SharePoint farm, IT pros should go by the SharePoint Foundation patch number, according to Stefan Gossner. What's the rationale behind that?
Klindt: Prior to SharePoint 2010, SharePoint had a single version number. In SharePoint 2010 and continuing in SharePoint 2013 it's not quite that simple. In SharePoint 2010 there's a "BuildVersion" property of SPFarm object that is pretty close to the SharePoint 2007 and early farm build version, but like Stefan [Gossner] says, it is controlled by the Foundation patch, specifically to the build version of a single file, Microsoft.SharePoint.DLL. In the past when SharePoint was patched as a whole, that was fine. Starting with SharePoint 2010 it became possible to patch individual components (like Search and User Profiles for instance), so the version of that single DLL became mostly meaningless. To be absolutely certain an admin has to go to the Patch Status page in Central Admin and look at the build number of each component.

If an organization is using SharePoint Server, but not SharePoint Foundation, they still have to install the CUs for SharePoint Foundation, right? Why?
Klindt: A SharePoint Server admin has to install the Foundation CU if the Server CU is not an Uber patch. The Server Uber patch includes Foundation. The Project Uber patch includes Server and Foundation. So a SharePoint Server Admin would have to install the October 2013 Foundation patch because the October 2013 patches are not Uber. The September 2014 CUs were Uber patches, so that same SharePoint Server admin would not have to install the Foundation patch. Now, if they do install the Foundation Uber, [and] then the Server Uber, it's okay. Nothing breaks.

What does running the Products Configuration Wizard do after installing the updates and why does Gossner recommend doing that?
You have to run the Config Wizard after the installation of any SharePoint. If you have a SharePoint farm with more than [one] server (which is 99.999% of them), you can install the patches at different times and have servers at different states of patchedness. There are a lot of shared resources, namely databases that cannot be upgraded until all the servers are at the new patch level. One of the many things the Config Wizard does is upgrade those common components after every server has been patched.

More SharePoint administration insights can be found at Todd Klindt's blog.