January 2017 CU for SharePoint 2013 product family is available for download

The product group released the January 2017 Cumulative Update for the SharePoint 2013 product family.

For January 2017 CU we have full server packages (also known as Uber packages). No other CU is required to fully patch SharePoint.

As this is a common question: Yes, January 2017 CU includes all fixes from January 2017 PU.


Be aware that all Updates for SharePoint 2013 require SharePoint Server 2013 SP1 to be installed first.

Please also have a look at the article that discusses how to properly patch a SharePoint 2013 farm which has Search enabled (see below).

Previous releases of the SharePoint Server 2013 cumulative update included both the executable and the .CAB file in the same self-extracting executable download. Because of the file size, the SharePoint Server 2013 package has been divided into several separate downloads. One contains the executable file, while the others contain the CAB file. All are necessary and must be placed in the same folder to successfully install the update. All are available by clicking the same Hotfix Download Available link in the KB article for the release.

This CU includes all SharePoint 2013 fixes (including all SharePoint 2013 security fixes) released since SP1. The CU does not include SP1. You need to install SP1 before installing this CU.

The KB articles for January 2017 CU should be available at the following locations in a couple of hours:

  • KB 3141479 – SharePoint Foundation 2013 January 2017 CU
  • KB 3141481 – SharePoint Server 2013 January 2017 CU
  • KB 3141480 – SharePoint Server 2013 with Project Server January 2017 CU
  • No fixes released for Office Web Apps Server 2013

The Full Server Packages for January 2017 CU are available through the following links:

Important: If your farm has been on a patch level lower than July 2015 CU: July 2015 CU and later contains a breaking change compared to earlier builds which requires running the SharePoint 2013 Products Configuration Wizard on each machine in the farm right after installing the CU.
If you don’t run PSCONFIG after installing this CU (on a farm which had a lower patch level than July 2015 CU) crawl might no longer work – so ensure to schedule a maintenance window when installing this CU which includes PSCONFIG runs.
See here for detail: https://blogs.technet.microsoft.com/stefan_gossner/2015/07/15/important-psconfig-is-mandatory-for-july-2015-cu-for-sharepoint-2013/

Be aware that the SharePoint Server 2013 CU contains the SharePoint Foundation CU. And the SharePoint Server 2013 with Project Server CU contains Project Server CU, SharePoint Server CU and SharePoint Foundation CU.

Related Info:

Comments (6)

  1. Sibylla_B says:

    Hi Stefan,
    thanks a lot for sharing all these helpful posts!

    One question – you write in this article that the July 2015 CU requires running the SharePoint 2013 Products Configuration Wizard. As I understand from your further articles the Products Configuration Wizard is always required to run, so why is this specially highlighted in this case? Or is it not always necessary to run PSCONFIG / PSCONFIGUI after updating?
    Thanks for some clarification!

    1. Hi Sibylla,
      to ensure that the whole fix is applied including changes in the database and copying all the files into the right directories PSConfig is required after installing the fix. But usually you can do this in a second maintenance window (e.g.) a couple of Weeks later.
      In July was a breaking Change. SharePoint would not work correct if running PSConfig would have been delayed.
      This breaking change affects all CU installations which install a CU from July 2015 CU and later on a System with an older CU than July 2015 CU.

      1. Sibylla_B says:

        Thanks a lot for the explanation Stefan!
        Best regards

  2. Tim B says:

    I noticed in the 2013 and 2016 update notes for SharePoint server there was a fix for “SharePoint Server 2013 becomes unresponsive and a high CPU symptom requires restarting the server. Meanwhile, you can’t access sites or get extremely slow page load times.” Is there any information about what causes the sustained CPU usage? If there are user actions that can cause the issue, it would be nice to know in order to prevent the issue from occurring until we can get the CU package applied and tested out.


    1. Hi Tim,
      the issue was related to an problem with managed metadata Navigation.
      Termset retrieval and sorting of items was which could lead to high CPU if multiple threads were accessing the same datastructures due to missing synchronization.

      1. Tim B says:

        Thanks Stefan! I always look forward to these posts every month!

Skip to main content