The product group released the January 2017 Cumulative Update for SharePoint Server 2016 product family.
This CU also includes Feature Pack 1 which was released with November 2016 CU.
The KB articles for January 2017 CU are available at the following location:
- KB 3141486 – Update for SharePoint Server 2016 January 2017 (language independent) – this is also a security update!
- KB 3141487 – Update for SharePoint Server 2016 January 2017 (language dependent fixes)
- No fixes released for Office Online Server 2016
The download for January 2017 CU is available through the following link:
- Download Update for SharePoint Server 2016 January 2017 (language independent) – this is also a security update!
- Download SharePoint Server 2016 January 2017 (language dependent fixes)
- No fixes released for Office Online Server 2016
Be aware that as well the language independent and the language dependent fix is required to fully patch a SharePoint server as each SharePoint installation comes with a language independent component and a language dependent component. If additional language pack are added later (only) the language dependent fix has to be applied again.
It is irrelevant which language you pick on the drop down in download center. Even the language dependent fixes are all in the same package for all languages.
After installing the fixes you need to run the SharePoint 2016 Products Configuration Wizard on each machine in the farm. If you prefer to run the command line version psconfig.exe ensure to have a look here for the correct options.
SharePoint 2016 January 2017 CU Build Numbers:
Language Independent fix: 16.0.4483.1001
Language Dependent fix: 16.0.4483.1001
To understand the different version numbers please have a look at my article which explains the different SharePoint build numbers.
You can use the SharePoint Server 2016 Patch Build Numbers Powershell Module to identify the patch level of all SharePoint components.
Related Links:
- Blog: Common Question: What is the difference between a PU, a CU and a COD?
- Blog: SharePoint Patching demystified
- Blog: Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE
- Blog: January 2017 Office Update Release
- Technet: Update Center for Microsoft Office, Office Servers, and Related Products
- Blog: SharePoint Server 2016 Patch Build Numbers Powershell Module
- Blog: SharePoint Server 2016 Zero-Downtime Patching Demystified
- Blog: SharePoint does not have a build version. Full Stop.
Permalink
Dumb question but do we need to install both patches on each server?
Permalink
yes.
Permalink
Ok thanks, just to be clear, even if I don’t use language packs I need the language-dependent fixes too?
Permalink
Hi Anon,
you always have a language pack – you might just not see it separately.
If you have an english SharePoint installation you have the language independent core components and the language specific components for english.
Both have to be patched so you need to install the language independent fix and the language dependent.
Cheers,
Stefan
Permalink
Thanks for the help, I installed the patches but come to psconfigui (config wizard), the wizard says:
Missing on
Missing on
For both patches. I tried get-spproduct local and a reboot on each server as well as clearing the config cache.
i fixed this by skipping the update check in psconfig, but no comfortable with the mysterious error.
Permalink
Hi Gurdip,
I would not be comfortable either.
My recommendation is to open a support case to get your environment analyzed.
Cheers,
Stefan
Permalink
Ok thanks! Hmm I’ve installed both exes on all of the servers but when I run the config wizard I get the error that both patches are missing, but the guilty server is not mentioned. So I see:
Missing On
Missing On
For both CUs.
I see that there’s a way to skip the check via psconfig but there should be a reason for this error?
Permalink
Hi Stefan, in SP2010 / SP2013 days cumulative updates were not as fully regression tested as other updates so they could be released more rapidly thus often they were only implemented in Prod to fix a specific live issue otherwise the potential for unexpected regressions meant it was best to wait until the service pack. Is this still the case with SP2016 “public” updates (which you continue to call “cumulative”)?
Permalink
Hi John,
I’m not sure what you mean with “other updates” as we only have cumulative updates in SharePoint.
With SharePoint 2016 we only have two packages. So the smallest patch available is the one of these two packages. So a security fix will mostly be the same as a cumulative update.
All fixes in SharePoint 2016 are tested the same way. So there is no difference in the quality of different patches.
The same applies in SharePoint 2013. The only exception are service packs which have undergone several months of testing.
Cheers,
Stefan
Permalink
Thanks for your reply, it is useful to know that security patches and public/cumulative updates undergo the same level of testing. What about feature packs, same level of testing as updates vs service pack, more/less?
For Prod I _always_ install service packs and security updates (after testing) but _only_ install public/cumulative updates if the later fix a critical issue that I am currently experiencing in Prod. Is that a common approach with your customers? Or do people tend to install public/cumulative updates in Prod regardless?
Thanks
Permalink
Hi John,
a feature pack is nothing but a fancy name for a CU. The difference is that in a feature pack we not only provide fixes but also new functionality.
As they are CUs you will find the feature pack functionality also in all later CUs. So December CU contains the feature pack as the feature pack was released in November.
Cheers,
Stefan
Permalink
Thanks again. Any thoughts on my other question: For Prod I _always_ install service packs and security updates (after testing) but _only_ install public/cumulative updates if the later fix a critical issue that I am currently experiencing in Prod.
Is that a common approach with your customers? Or do people tend to install public/cumulative updates in Prod regardless?
Permalink
Hi John,
this was the recommended approach.
But as you can see with SP2013 – there has not been a service pack since years. So continous patching is more and more common.
Which means that the need to have a test environment where fixes can be evaluated in context the application is very important.
Cheers,
Stefan
Permalink
I think that the confusion with what exactly is “Feature Pack” comes from the fact that SQL Server also has Feature Packs, but those are sets of additional, optional components, which are installed and updated separately from the main product. It’s a good example of how naming conventions can cause issues.
Permalink
Hi Our farm is still running the oldest version 16.0.4327.1000. Do we need to install the KB articles for all the past release (It has updates for each month), or only this two? The accumulative will include all updates from day one?
Permalink
Hi Mike,
it is named cumulative because it contains all previous fixes.
So just the latest is enough.
Cheers,
Stefan