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:
- Download June 2022 Update for SharePoint Server 2019 (language independent)
This is also a security update! - Download June 2022 Update for SharePoint Server 2019 (language dependent)
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:
- Technet: Updated Product Servicing Policy for SharePoint Server 2019
- Blog: SharePoint Patching Best Practices
- Blog: SharePoint Patching demystified
- Blog: Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE
- Technet: Update Center for Microsoft Office, Office Servers, and Related Products
- Blog: SharePoint Server 2016 Zero-Downtime Patching Demystified (applies also to SharePoint Server 2019)
- Blog: SharePoint does not have a build version. Full Stop.
Permalink
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.
Permalink
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
Permalink
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
Permalink
Hi Giorgos,
the same issue will happen when going from April to June.
Cheers,
Stefan
Permalink
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?
Permalink
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
Permalink
Hi Timm,
actually yes – you would have to update this with each CU installation.
Cheers,
Stefan
Permalink
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,
Permalink
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
Permalink
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.
Permalink
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