February 2017 CU for SharePoint Server 2016 is available for download

The product group released the February 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 February 2017 CU are available at the following location:

  • KB 3141515 – Update for SharePoint Server 2016 February 2017 (language independent)
  • KB 3141517 – Update for SharePoint Server 2016 February 2017 (language dependent fixes)
  • No fixes released for Office Online Server 2016

The download for February 2017 CU is available through the following link:

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 February 2017 CU Build Numbers:
Language Independent fix: 16.0.4498.1002
Language Dependent fix: 16.0.4498.1002
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:

9 Comments


  1. Hi,
    could you tell more about “This update deletes the Napa install option from SharePoint Server 2016”? What is Napa and should we uninstall it from existing 2016 deployments? I don’t see it in Add or remove programs on my 2016 server.

    Reply

    1. Hi Piotr,
      NAPA is Office 365 development tools in SPO. It can be optionally installed from the Store in an SPO Developer site.
      The option to install it was also available in SharePoint 2016 as SharePoint 2016 was derived from SPO but it does not work on SP2016.
      This fix removes the option to install NAPA as it caused confusion for some users.
      More details about NAPA:
      https://msdn.microsoft.com/en-us/library/office/jj220041.aspx
      Cheers,
      Stefan

      Reply

  2. Hi Stefan,
    I’m still missing the “Updates Profile Memberships and Relationships Job” in the definitions list.
    Is it hidden or is it possible ot create one with PS?

    Reply

    1. Hi Alex,
      there is a small glitch with the fix installation, the new timerjob does not automatically get created.
      To fix this do the following steps:
      – go to the central admin: you should see a health analyzer notification at the top.
      – follow the link in the health analyzer notification
      – identify the problem in the “Configuration” section from the “UserProfileService” (should mention something about a missing timerjob)
      – open the relevant problem and click “Repair automatically” in the ribbon
      That should fix the issue.
      Cheers,
      Stefan

      Reply

  3. Hi Stefan,
    I notice that the sts and wssloc were released a week apart despite both being required and that Microsoft has not listed the february release yet under the official list of SharePoint 2016 patches. Is there a reason for this? Is there some known issue that’s being fixed?

    Reply

    1. Hi Joel,
      this is not the release but the upload date.
      Both were released (made visible) on Feb 21st.
      Cheers,
      Stefan

      Reply

  4. Hi Stefan,
    I have installed feb’17 CUs and I did see the job “Updates Profile Memberships and Relationships Job” but it is not running. I kicked off manually but its not running. Any insight on this?
    I also noticed, though the Feb’17 CUs are applied successfully but my farm version is still showing as Jan’17 CU build version. Do you think the feb’17 updates are not installed properly?

    Reply

    1. Hi Mohammed,
      I have answered this question already in the comments below:
      there is a small glitch with the fix installation, the new timerjob does not automatically get created.
      To fix this do the following steps:
      – go to the central admin: you should see a health analyzer notification at the top.
      – follow the link in the health analyzer notification
      – identify the problem in the “Configuration” section from the “UserProfileService” (should mention something about a missing timerjob)
      – open the relevant problem and click “Repair automatically” in the ribbon
      That should fix the issue.
      Cheers,
      Stefan

      Reply

  5. Hi Stefan,
    I just installed the February CU. But the result was different than others CU. After patches installed on all servers, and before running PSCONFIG, all servers still in status “No Action Required”. Usually the status was “Upgrade Required” or “Upgrade Blocked”.
    I read that Microsoft added some debug since december CU about someting almost similar : “Adds more logs to diagnose the issue in which a farm server turns to the Upgrade Required status after a successful run of psconfig with the No Action Required server status.”. Maybe it will create a new bug ? so how can we know if the server was upgraded or not ?
    For information, i had this case, some servers back to status “Upgrade Required” after hours/days. and i found how to fix it :
    i’m only use PSCONFIG.EXE for upgrade. and i found that it’s mandatory to put -force switch and remove -wait switch for force TimerJob to execute the upgrade. If we put -wait switch, there is a missing action and folders _vti_pvt are not updated with last build number. I see this bug because when i’m calling get-spserviceinstance, the service ‘Microsoft SharePoint Foundation Web Application’ has the field ‘NeedsUpgrade’ to TRUE. So i think its the reason why server status back to “upgrade required”.
    I read some ULS files, and it’s seems relative to the introduction of minrole end of last years (i’m not sure, but UpgradeSequence is dependant of Server Role). I didn’t had the time to make more tests about this bug, but i had only the case on Application Servers where CA is deployed, and some times in WebFrontEnd Servers.
    Regards,
    Guillaume

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.