June 2022 CU for SharePoint Server 2019 is available for download

The product group released the June 2022 Cumulative Update for SharePoint Server 2019 product family. SharePoint Server 2019 is patched with a language dependent and a language independent fix.

The KB article for June 2022 CU will be available at the following Location in a couple of hours:

  • KB 5002212 – June 2022 Update for SharePoint Server 2019 (language independent)
    This is also a security update!
  • KB 5002211 – June 2022 Update for SharePoint Server 2019 (language dependent)

The downloads for June 2022 CU are available through the following links:

Important: It is required to install both fixes (language dependent and independent) to fully patch a SharePoint server. This applies also to servers which do not have language packs installed. The reason is that each SharePoint installation includes a language dependent component together with a language independent component. If additional language packs 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 2019 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.

Please ensure to have a look at the SharePoint Patching Best Practices before applying new fixes.

 
SharePoint 2019 June 2022 CU Build Number:

Language independent fix: 16.0.10387.20008
Language dependent fix: 16.0.10387.20008

 
Related Links:

11 Comments


  1. Hello Stefan,

    Does the June 2022 CU for SharePoint Server 2019 is taking care of the “Trending Issue: left navigation missing after applying May 2022 CU for SharePoint Server 2019”, based on your update only we are planning to update SP2019 Jun2 2022 CU to our environment. Please confirm.

    Reply

    1. Hi Prabhu,
      not automatically. You need to apply the same workaround as with May CU.
      Either clearing the browser cache or using a side by side token.

      Cheers,
      Stefan

      Reply

      1. Hi Stefan
        Just to be clear on this: the issues is caused by a mix of old & new of JS libraries from April CU to May CU, correct? Or is it a perpetual issue?
        So, if we are going from April to June it will still exist.
        But, what about going from May (where it has already surfaced and libraries are removed from users’ cache) to June? Still there?

        Thanks for your patience
        Giorgos

        Reply

        1. Hi Giorgos,
          the same issue will happen when going from April to June.
          Cheers,
          Stefan

          Reply

      2. At present our SP2019 PROD have 1 WFE & 1 SQL Server setup does it required to do the side-by-side-functionality in the WFE server?
        Whether the side-by-side-functionality workaround will be addressed in the SP2019 July 2022 CU patch or still in the July patch also we need to do the same workaround side-by-side-functionality?

        Reply

  2. Hi Stefan, does the “Trending Issue: left navigation missing after applying May 2022 CU for SharePoint Server 2019” have to be fixed everymonth with activating SideBySide or is this a one time fix?

    I´m asking because in the SBS Script we´ll have to assign the build number, which changes with every CU. So we are unsure if the we have to redo this now every month?

    best regards
    Timm

    Reply

    1. Hi Timm,
      actually yes – you would have to update this with each CU installation.
      Cheers,
      Stefan

      Reply

  3. Hi Stefan,

    Read your instructions on setting up side by side so we wouldn’t need to clear the browser cache. But had a few questions:

    On Front-End WebApplication:

    If you have more than 1 Web Application, can we just pick one, or need to be enabled for both webapps?

    $webapp = get-spwebapplication http://mywebapp
    $webapp.WebService.EnableSideBySide = $true;
    $webapp.WebService.update()

    Do the command below on all servers in the Farm but only needs to be done the first time, unless you recently did some customizing of directories, then run again?

    Copy-SPSideBySideFiles

    Now set SideBySideToken to match current version (just this initial first time)

    $webapp = get-spwebapplication http://mywebapp
    $webapp.WebService.SideBySideToken = “The Current Version Number”
    $webapp.WebService.update()

    Now install the new June Cumulative Updates on all servers, run my PSConfig command on all servers in the Farm and then from any server:

    Find the new version number in the LAYOUTS directory, then:

    $webapp = get-spwebapplication http://mywebapp
    $webapp.WebService.SideBySideToken = “New Version Number”
    $webapp.WebService.update()

    Also, if we’re not using custom directories that we made, we shouldn’t need to worry about PSConfig removing the old version
    directory once we run PSConfig? PSConfig will remove the old version folder after it creates the new?

    Thanks,

    Reply

    1. Hi Jess,

      you only have to EnableSideBySide is set on the SPWebService level. We just use a random web application to get to this SPWebService.
      There is only one of these – so the command does not have to be issued multiple times.

      Copy-SPSideBySideFiles has to be run on all machines if the directory was not created automatically or if manual changes were done.

      PSConfig file clean up unused side-by-side directories. No need to manually clean up.

      Cheers,
      Stefan

      Reply

  4. Has anyone noticed a spike in RAM usage since the patch? I can’t be certain if it is the June patches or not, but the worker pools seem to hoard memory and continue until the server crashes. It has been happening to our 3 WFEs. Not all at once, but after reboot, it takes 3-5 days where 1 site is taking as much as 8GB of RAM and just slowly continue to climb. Previously, I had never noticed worker pool going past 1 or 2GB of RAM.

    Reply

    1. Hi Samir,

      the application pool settings should be that the worker process recycles once a day. Thats how SharePoint configures it. The fact that the memory climbs in your scenarios for several days indicates that the automatic workerprocess recycling is disabled.
      You should verify this setting in IIS manager.

      Cheers,
      Stefan

      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.