Patch Management for SharePoint On-Premises

Like me, you have probably patched a SharePoint Server at some point, if not then you are a not a true SharePoint Administrator J Just kidding, I envy you if you have not had to do it yet.

Unfortunately this is one of those tasks that everyone dislikes but they are necessity to keep SharePoint running and up to date. Patching any system can be a complex process and keeping tabs on the current versions and what is needed often only make it worse. In order for you to know how to patch effectively you first need to know how patching works and what it is all about.

SharePoint 2013

When a patch is release for SharePoint 2013, you will find the core executable and then the famous “Uber” file. You may wonder what the “Uber” files are, as they increase the update patching to 3GB plus in size.

When Microsoft create the patches, they roll the fixes into the main file for that specific month then anything previously released gets added to the Uber files. So an example would be the following, where on Month 1 a fix was issued, then in month 2, 3 fixes were issued, month 3, there was only 1 fix issued and then month 4, 2 fixes were issued.

Now if we took month 4 as a standalone update you would miss out on the previous patches, possibly causing issues or not even installing at all. So to resolve this, the other patches that were missed get wrapped into the “Uber” patches that are delivered with the cumulative update.

This means that in fact each update that you apply is indeed cumulative, and the previous fixes are bought into the update via the “Uber” patch. This means that your SharePoint Farm will be very happy as it gets everything it needs in order for the new cumulative update. There are times though where Microsoft requires a specific update to be applied before moving forward.

There are different types of updates and understanding these is just as important. These are core Service Packs, Cumulative Updates, things called Public Updates and then Critical on Demand fixes that make this a little more complicated sometimes. You can learn more about the different types here: https://blogs.technet.microsoft.com/stefan_gossner/2013/03/21/common-question-what-is-the-difference-between-a-pu-a-cu-and-a-cod/

SharePoint 2016

I recently posted about this previously so feel free to read it here: http://sharepointpromag.com/sharepoint/sharepoint-2016-what-you-need-know-about-zero-downtime-patching

So how does knowing this help as we patch servers?

Well in reality the plan for patching is really simple, allow Security Updates to be installed, and then determine when and if you need the Cumulative Update or Service Pack. For quite a few years now I have always stayed two patches behind the current version, unless a newer version resolves issues that I am seeing in the environment. This is my own personal view based on many years of hitting issues that often cannot be rectified once the patch is installed.

As an example of the personal approach would be this:

As you can see by the time I would reach Month 4, I would have installed 6 security updates and then only installed Month 1 and 4 Cumulative Updates, all because of the benefit of the “Uber” packages. I can skip levels, unless otherwise documented and required before moving forward.

This means that at any point we can see what version of a component is running giving us the ability to know where each piece is within the patch rotation.

Knowing and understanding where you’re SharePoint Servers are, patch wise is important to a healthy farm. Too often people skip patches and updates, try to apply new updates without previously required updates often leading to support tickets.

If in doubt of versions and you are worried about the patch versions of all your SharePoint components then you can use the “Robust Office Inventory Scan Tool (ROISCAN)” to check before you do anything.

https://gallery.technet.microsoft.com/scriptcenter/68b80aba-130d-4ad4-aa45-832b1ee49602/

To use the script you need to copy it all out of the page and create the “VBS” file and then run it from a command line.

Patching does not have to be some dark art that takes amazing ninja type skills, it is simple and logical. A part of the patching process is also coming to know what version everything is running. Microsoft have a done a decent job of giving you a display that shows the patches that were installed, and their version numbers. 

Once it had completed it outputs a text file with the details you need.

This script is a great place to start, checking for actual versions that are being used. Of course if you want to know the actual SharePoint versions or see a table of what they should be then you can use the search engine of your choice and search for it.

http://www.bing.com/search?q=SharePoint+Version+Numbers+List&go=Submit&qs=n&form=QBLH&pq=sharepoint+version+numbers+list&sc=1-31&sp=-1&sk=&ghc=1&cvid=58B6AECE20A54A9F9710B8FD5C69F220

https://www.google.com/#q=SharePoint+Version+Numbers+List

The real key to successfully patching SharePoint is ensuring that you know where the current environment is, patch levels and then what you are about to move to. Remember also that you may not need to move to a specific cumulative update, you could wait till the next one, as long as the “Uber” patch is part of it. Happy Patching.