We're all familiar with patches and what they entail, but in SharePoint 2016 the model is changing significantly. In this story we will detail the changes--and examine what patches will be composed of moving forward.
SharePoint 2016 supports zero or no downtime patching. This is a major change, as I outlined in a previous post.
Currently, the process works like this:
- Download the 1.5GB
- Download the Uber files, too
- Run the binary installs on all the servers
- Run “psconfig” to get the initial upgrade of the schema, then on each server for the binary updates
One of the problems with this process is that SharePoint won't be online as you would want it to be. There's nothing worse than trying to sneakily apply a patch and having it take the entire SharePoint farm offline.
As you can imagine with Microsoft running Office 365, it's complicated to patch a large-scale tenancy infrastructure the "old-fashioned" way. So, in its wisdom, Microsoft enables us to patch live and rolling through the servers. The file size is now smaller, a lot smaller, so that beckons the question: “What did they change and what does the patch now contain?”
A patch historically contained all the fixes that had been released prior to the patch being created, along with any new features that were being rolled out. The new patching approach does not change that--it just changes what pieces are actually packaged and deployed. Instead of patching everything in the farm using updates of 3GB and more, now we get 300+ MB files that update only the components that need it. To see for yourself, you can look at the media for “SharePoint 2016 Beta 2” and then compare what the “Release Candidate” file is made up of.
Below is shows the components of the “Beta 2” installation media:
The releases candidate patch when unzipped contains the following:
As you can see, it is an “msp” file that matches the one that is stored in the main media for the full install. So what does this mystical file contain?
To see, we need to download a tool called “MSIX.”
Once downloaded, extract the zip file. You should then end up with the following folder structure:
Opening the “Release” folder shows the .exe file that we need to use to extract the files from the “MSP” file. You can then use the following command to extract the files into a new folder, which I called “STS.”
Usage: MsiX.exe
MsiX.exe "D:\SharePoint Server 2016 Release Candidate Global Patch\sts.msp" /out "D:\SharePoint_2016\SharePoint Server 2016 Release Candidate Global Patch\sts" /ext
This command then extracts the files contained within the patch file.
As you can see, the core file that will be used for the update is the “PATCH_CAB.cab” file, which, when extracted gives us the full list of pieces that are to be updated in the SharePoint environment. This list of files is quite extensive, so I am just showing the top of the list of files, ordered by applications first.
As you can see from this, the list of core application files that are being modified by the patch. The great thing about this, is in theory based on this approach for patching, you could in reality perform a comparison with the next patch that is releases, and be able to keep track on what is being modified.
This patching approach is great and will make our lives easier as we move to the SharePoint 2016 stack.
