The product group released the June 2019 Cumulative Update for the SharePoint 2013 product family.
For June 2019 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, June 2019 CU includes all fixes from June 2019 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 June 2019 CU should be available at the following locations in a couple of hours:
- KB 4464598 – SharePoint Foundation 2013 June 2019 CU
- KB 4464601 – SharePoint Server 2013 June 2019 CU
- KB 4464600 – Project Server 2013 June 2019 CU
- There was no fix released for Office Web Apps Server 2013 this month
The Full Server Packages for June 2019 CU are available through the following links:
- Download SharePoint Foundation 2013 June 2019 CU
- Download SharePoint Server 2013 June 2019 CU
- Download Project Server 2013 June 2019 CU
- There was no fix released for Office Web Apps Server 2013 this month
After installing the fixes you need to run the SharePoint 2013 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.
Be aware that the SharePoint Server 2013 CU contains the SharePoint Foundation 2013 CU. And the Project Server 2013 CU also contains the SharePoint Server 2013 CU and SharePoint Foundation 2013 CU.
- Technet: Updated Product Servicing Policy for SharePoint 2013
- 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: Support for SharePoint 2013 RTM has ended
- Blog: SP1 for SharePoint 2013
- Technet: CHANGE: SharePoint 2013 Rollup Update for the December 2013 Cumulative Update Packaging
- Technet: Install a software update for SharePoint 2013
- Blog: How to: install update packages on a SharePoint 2013 farm where search component and high availability search topologies are enabled
- Technet: Update Center for Microsoft Office, Office Servers, and Related Products
- Blog: SQL Server 2014 and SharePoint Server 2013
Hi Stefen, great blog… we appreciate the effort you do. I have a question about the discrepancy in time between monthly CUs to run psconfigui on the first SharePoint server following the install of the binaries. We have nearly 200 content dbs and typically it can take about 4 hours to run the psconfigui on the first app server. But some months, it is much shorter. For example, the June 2019 CU took only about 5 minutes to complete successfully. The logs show success, so I am not worried whether the update completed successfully. It’s just that I have not been able to explain it. Is this expected behavior?
this is expected. It depends on how many objects have to be upgraded.
Most objects in SharePoint include an upgrader which is called by PSConfig. If nothing has to be done the upgrader returns very quick. If upgrade work has to be done it will take longer.
So depending on the fixes (some affect only objects in the configuration database or objects in service application databases while others affect objects in the content database) the time required to perform the upgrade is different.
It also means if you are patching on a monthly basis the upgrade time will usually be shorter as the amount of changes is smaller as if the upgrade has to perform upgrades for changes included in multiple CUs.
btw: you can reduce the upgrade time by running the content database upgrades before running PSConfig using Upgrade-SPContentDatabase in several PowerShell windows which allows you to run content database upgrades in parallel.
In PSConfig all upgrades are performed in a serial manner one after the other. Running PSConfig afterwards will only have to run the upgrades for objects in the service applications and in the configuration database.
Another side note: upgrading objects is just one thing PSConfig does. So even if there would not be any objects in the CU that would have to be upgraded you still have to run PSConfig to perform the other operations like file copy and (re-)registering new or upgraded services.
Thanks for your detailed answer and explaination. In 10 years I’ve never come to the idea, to do database upgrades first. I did it the other way around. I detached most of my big databases so psconfig would run faster and attach/upgrade the databases afterwards.
Thanks for your insight, I’ll do it this way from now on.
in this case I would recommend to read the following blog post:
It compares methods to speed up patching in SP2013 with SP2016 and gives more insights on Upgrade-SPContentDatabase
one question. After installation June 2019 CU to my SharePoint 2013 I’m getting 15.0.5131.1000 as my Farm BuildVersion. I know I shouldn’t care too much about it, but up until now (at least I would say so) the BuildVersion of the farm somehow correlated to the version numbers Todd is posting on his side.
Can you tell me if this is expected? Cheers, Andreas
please use the information in this article to verify a correct Installation of the CU:
After deploying the Project Server 2013 June 2019 CU to my SharePoint 2013 farm, the “Health Analysis Job (Daily, Microsoft SharePoint Foundation Timer, Any Server)” timer job brings down one of the two PWA site collections in the farm. This behavior did not occur in the staging environment.
The thread has an Unexpected error:
07/18/2019 00:00:00.86 OWSTIMER.EXE (0x3AF0) 0x4BF0 SharePoint Foundation Health 8fs4 Unexpected Heavily fragmented indexes can decrease query performance and cause SharePoint to respond slowly.. Automatic repair is being attempted. e460f19e-981a-7035-2712-f0d0c3aac298
Have you heard of anything like this?
If you need assistance for this I would recommend to open a support case with Microsoft.
The issue was a coincidence. The site collection’s database was heavily fragmented. There is a health rule that checks this and attempts to defragment the database resulting in failure. The timer job is hung and the database is locked. Restarting the timer service on the executing service is a band-aid but defragmenting the database (Reorganize Index) task – in SQL Server 2014 – will eliminate the issue.
The job is: Health Analysis Job (Daily, Microsoft SharePoint Foundation Timer, Any Server)
i regularly follow your blog and use the information to maintain and manage my Farms.
Thank you very much.
After i installed the June 2019 CU, and updating my Farms, of all sites list, where we have a look up column, when ever user right on the item and try to open in a new tab it gives 404.
This has impacted, all of SharePoint 2013 enterprise farms. i tried to look for the issue but found no such.
However exact same behavior is reported for SharePoint online/SharePoint 2019 which is primarily because of Modern experience. But this has not been reported for On premise farms.
Can you please help or point me to the right direction.
this is not a known issue. I would recommend to open a ticket with Microsoft Support to get this analyzed.
Hi Stefan, we have the same issue in our farms running with June 2019 CU. Is this problem fixed in July 2019 CU?
Thanks and KR
this issue has been reported through a support case to Microsoft first on July 8th. A hotfix is currently in the works but a release date is not yet available.
We would like to upgrade our farm with the latest SharePoint 2013 CU. Currently it is Feb 2019 CU. I have read few known issues in June and July 2019 CU’s. Which CU do you suggest to upgrade?
it is recommended to evaluate all fixes in a test environment which is similar to your production environment to see if there are any unwanted side effects.