Fix-SeptemberCU-Permission-Problem.ps1
Alternatively you can also remove the NT Authority\system account from WSS_WPG and IIS_IUSRS local security groups of the SharePoint machines.
For more details check this article: Trending Issue: SharePoint fixes fail to install after installation of September 2025 CU
The product group released the June 2026 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 2026 CU will be available at the following Location in a couple of hours:
- KB 5002874 – June 2026 Update for SharePoint Server 2019 (language independent)
This is also a security update! - KB 5002876 – June 2026 Update for SharePoint Server 2019 (language dependent)
This is also a security update!
The downloads for June 2026 CU are available through the following links:
- Download June 2026 Update for SharePoint Server 2019 (language independent)
This is also a security update! - Download June 2026 Update for SharePoint Server 2019 (language dependent)
This is also a security update!
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 2026 CU Build Number:
Language independent fix: 16.0.10417.20153
Language dependent fix: 16.0.10417.20153
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
Does this patch solve the issues from the may patch with the search etc.?
Permalink
Hi Admin EK,
there is no specific fix for this issue included as we do not know what is causing it.
Cheers,
Stefan
Permalink
Hi,
This version has not yet appeared in the SharePoint updates article. Has it been officially released to users?
https://learn.microsoft.com/en-us/OfficeUpdates/sharepoint-updates
Permalink
Hi Maduranga,
it is meanwhile listed.
There was a delay due to maintenance on the Learn.microsoft.com website.
Cheers,
Stefan
Permalink
It seems this CU cleared out the fix for the Nintex issue in sept 2024. I find the “C42Q0” in my ULS logs and some of my Nintex workflows work and some don’t. Probably because it affects some actions and not others.
Permalink
Hi Bob,
you are running into this issue:
https://blog.stefan-gossner.com/2026/06/12/trending-issue-sharepoint-2010-workflows-fail-after-june-2026-cu/
Cheers,
Stefan
Permalink
After installing the updates in our test (single‑server farm) and pre‑production (multi‑tier) environments, we observed that during IIS resets or automatic recycling triggered by SharePoint daily timer jobs, all custom API calls become stuck in the worker process application pool.
In these cases, the expected event is missing from the Event Viewer (Applications):
SharePoint booted. Process Name: [w3wp] App Pool: [TestAPI], Process ID: [0x29C4], App Domain Name and ID [/LM/W3SVC/3/ROOT-1-134272950808646276],[2], Command Line [c:\windows\system32\inetsrv\w3wp.exe -ap “TestAPI” -v “v4.0” -l “webengine4.dll” -a \.\pipe\iisipm69fb76ab-789b-4b6d-9aef-61a5d120d3b8 -h “C:\inetpub\temp\apppools\TestAPI\TestAPI.config” -w “” -m 0 -t 20 -ta 0]
In working scenarios (randomly after IIS reset), this event appears normally.
Need your support to investigate why the event is not consistently logged and why API calls remain stuck post‑update, as this impacts both UAT and pre‑production environments and blocks preparation for production remediation.
Permalink
Hi Mohamed,
if you need assistance to get this investigated, please open a ticket with Microsoft Support.
Cheers,
Stefan
Permalink
Dear Stefan,
Thank you for your comment.
I have already opened a case with Microsoft, but I am seeking your support if you have any insights regarding this symptom.
Permalink
Hi Mohamed,
I have not heard about these symptoms but it sounds more like a problem with IIS than with SharePoint as the SharePoint related dlls do not get loaded into the process (otherwise event 8356 would be logged).
Cheers,
Stefan
Permalink
After installing the updates in our test (single‑server farm) and pre‑production (multi‑tier) environments, we observed that during IIS resets or automatic recycling triggered by SharePoint daily timer jobs, all custom API calls become stuck in the worker process application pool.
In these cases, the expected event is missing from the Event Viewer (Applications – ID 8356):
Code
SharePoint booted. Process Name: [w3wp]
App Pool: [TestAPI]
Process ID: [0x29C4]
App Domain Name and ID [/LM/W3SVC/3/ROOT-1-134272950808646276],[2]
Command Line [c:\windows\system32\inetsrv\w3wp.exe -ap “TestAPI” -v “v4.0” -l “webengine4.dll” -a \.\pipe\iisipm69fb76ab-789b-4b6d-9aef-61a5d120d3b8 -h “C:\inetpub\temp\apppools\TestAPI\TestAPI.config” -w “” -m 0 -t 20 -ta 0]
In working scenarios (randomly after IIS reset), this event appears normally.
Need your support why the event is not consistently logged and why API calls remain stuck post‑update