June 2019 CU for SharePoint 2013 product family is available for download

16 Comments

1. 

   Tom Crawford
   On 29. June 2019 Permalink

   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?

   Reply
   1. 

      Stefan Goßner
      On 1. July 2019 Permalink

      Hi Tom,
      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.

      Cheers,
      Stefan

      Reply
      1. 

         Andreas Blüher
         On 2. July 2019 Permalink

         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.

         Reply
         1. 

            Stefan Goßner
            On 2. July 2019 Permalink

            Hi Andreas,
            in this case I would recommend to read the following blog post:
            https://blog.stefan-gossner.com/2016/04/29/sharepoint-2016-zero-downtime-patching-demystified/
            It compares methods to speed up patching in SP2013 with SP2016 and gives more insights on Upgrade-SPContentDatabase
            Cheers,
            Stefan

            Reply
2. 

   Andreas Blüher
   On 2. July 2019 Permalink

   Hello Stefan,

   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

   Reply
   1. 

      Stefan Goßner
      On 2. July 2019 Permalink

      Hi Andreas,
      please use the information in this article to verify a correct Installation of the CU:
      https://blog.stefan-gossner.com/2016/08/23/sharepoint-does-not-have-a-build-version-full-stop/
      Cheers,
      Stefan

      Reply
3. SharePoint Updates: Patchday Juni 2019 - busitec Blog
   5 years ago Permalink
4. 

   GMO
   On 18. July 2019 Permalink

   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?

   Reply
   1. 

      Stefan Goßner
      On 18. July 2019 Permalink

      If you need assistance for this I would recommend to open a support case with Microsoft.

      Reply
      1. 

         GMO
         On 18. July 2019 Permalink

         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)

         Reply
5. 

   sam.mitkayal
   On 24. July 2019 Permalink

   Hello,

   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.

   Reply
   1. 

      Stefan Goßner
      On 24. July 2019 Permalink

      Hi Sam,
      this is not a known issue. I would recommend to open a ticket with Microsoft Support to get this analyzed.
      Cheers,
      Stefan

      Reply
      1. 

         JD
         On 30. July 2019 Permalink

         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

         Reply
         1. 

            Stefan Goßner
            On 30. July 2019 Permalink

            Hi JD,
            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.
            Cheers,
            Stefan

            Reply
6. 

   Arul
   On 12. August 2019 Permalink

   Hi Stefan,

   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?

   Reply
   1. 

      Stefan Goßner
      On 12. August 2019 Permalink

      Hi Arul,
      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.
      Cheers,
      Stefan

      Reply