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 July 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 July 2026 CU will be available at the following Location in a couple of hours:
- KB 5002883 – July 2026 Update for SharePoint Server 2019 (language independent)
This is also a security update! - KB 5002885 – July 2026 Update for SharePoint Server 2019 (language dependent)
This is also a security update!
The downloads for July 2026 CU are available through the following links:
- Download July 2026 Update for SharePoint Server 2019 (language independent)
This is also a security update! - Download July 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 July 2026 CU Build Number:
Language independent fix: 16.0.10417.20175
Language dependent fix: 16.0.10417.20175
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
After SP2019 July Patches am getting Search Topology error. did anyone face similar issues?
“Unable to retrieve topology component health states. This may be because the admin component is not up and running.”
Permalink
Hi Srini,
this was already reported by some users after June 2026 CU.
I assume you skipped it?
For some users these commands have helped:
sc.exe config SPSearchHostController start=delayed-auto
sc.exe config OSearch16 start=delayed-auto
Cheers,
Stefan
Permalink
Hello, so the search issue that appeared with the may CU didnt get resolved?
Permalink
For SPSE the workaround above resolves the issue per our current knowledge.
For SP2016 and SP2019 the workaround works for some users but not for others.
Due to time contrains it was not possible investigate, request and create a fix for SP2016 and SP2019 before end of support – which is today.
Cheers,
Stefan
Permalink
I can confirm this is an issue for us as well with Sharepoint 2019 and the CU July 2026.
We also tried the workaround Stefan mentioned:
sc.exe config SPSearchHostController start=delayed-auto
sc.exe config OSearch16 start=delayed-auto
It did not fix that issue for us.
Permalink
Hello Christian did you try these:
Restart-Service SPSearchHostController
Restart-Service OSearch16
Stop-Service OSearch16
Restart-Service SPSearchHostController
Start-Service OSearch16
$ssa = Get-SPEnterpriseSearchServiceApplication
Get-SPEnterpriseSearchStatus -SearchApplication $ssa
Since I will install the CU in the coming weeks it would be appreciated to find a working fix for this issue on sharepoint 2019. Maybe someone can report if any of these work.
Permalink
I restarted the windows seach services and server itself (test farm) a couple of times. Didn’t help.
I cloned/rebuilt the Search Topology (all 6 components) via Powershell, waited a for a while until it had activated and restarted the server again and now it works again.
https://milindpoint.wordpress.com/2018/03/27/recreate-any-sharepoint-search-components-in-existing-topology/
Permalink
Never mind. This issue comes back when the Windows Server or Sharepoint Search Services are restarted. Reading through the comments this issue seems to have been introduced in the Mai 2026 CU and i guess it won’t be fixed since Sharepoint 2019 is eol
Permalink
Do I understand it correctly that even after rebuilding the search topology the issue still occurs? Unfortunately this update was the last since sharepoint 2019 is now eol. I dont know if they will release another update because of that.
Permalink
After installing the SU on 2019 (while preparing to finalise migration to SE), we now get an error Host ” not in allowlist ‘SPAllowedOutboundHosts’ for property ‘WcfEndpointAddress’ in WCF based BCS flow. Add ” to farm based generic allowlist: ‘SPAllowedOutboundHosts’ to allow usage of this host. As well as Host ” is being blocked in WCF based BCS flow as it is not in the allowlist. To disable enforcement add server debug flag ‘DisableWcfBdcHostAllowlistEnforcement’ (115) to the farm. I have not yet installed the update on the SE farm but suspect will face the same issue. I’d rather set the allowlist instead of disabling the enforcement, how to set this up? I understand the support has ended but would like at least a confirmation before potentially facing the same issue in SE farm.
Permalink
— removed this misleading text to avoid confusing others —
Permalink
Ok thanks, the message is a bit misleading then 🙂 I opened a ticket just to be sure but at least we have a way around it using the flag. The allowlist would have been a welcome addition especially on the SE farm for a longer term security improvement.
Permalink
i have to come back to this because this security change doesn’t seem to make any sense to me without the allow list. For any WCF connection the only option is to then disable the check which is pretty much equivalent to not having the security improvement/fix at all?
Permalink
Hi Johan,
you are right – and sorry I was not clear enough.
There IS an allow list – but in the scenario above it seems to look for an empty string as hostname: Host ” not in allowlist.
And this would need to be investigated.
If the message would contain a hostname, you could enable it by adding it to SPFarm.SPAllowedOutboundHosts collection.
Hope it is more clear now.
Cheers,
Stefan
Permalink
It’s clear 🙂 the hostname is there, was just removed for the post. Now i just have to figure out format for multiple entries in the allowlist.
Permalink
Ah! You tricked me on this! 🙂
Try this:
PS C:> $farm = Get-SPFarm
PS C:> $farm.AddGenericAllowedListValue(“SPAllowedOutboundHosts”, “host1”)
PS C:> $farm.AddGenericAllowedListValue(“SPAllowedOutboundHosts”, “host2”)
PS C:> $farm.AddGenericAllowedListValue(“SPAllowedOutboundHosts”, “host3”)
PS C:> $farm.Update()
Permalink
Perfection! and yes i did remember to remove the flag 115, removed it first – confirmed issue present, added allowed hosts – confirmed issue resolved. Happy with this security improvement 🙂
Permalink
Hi Stefan,
we have SHP 2019 farms, right, and last month we had an issue with the workflows after patching the farms with the June 2019 CU, and we followed your post and workaround about it
https://blog.stefan-gossner.com/2026/07/14/resolved-trending-issue-sharepoint-2010-workflows-fail-after-june-2026-cu/
Now, my question is, are we going to get the workflow issue fixed with July 2026 CU, or are we going to face the issue of this user Srini, where the search topology schema isnt recognised anymore?
Permalink
Hi,
July 2026 CU fixes the issue introduced in June 2026 CU.
Please revert the workaround after installing the CU.
Cheers,
Stefan
Permalink
Good morning Stefan,
quick update, yesterday evening i patched our QA SHP 2019, and indeed i ran into the search error message, as the user before me, stating that : Unable to retrieve topology component health states. This may be because the admin component is not up and running.
i have checked and on one of the front ends (we have 2) the free space on the C drive was running low – we added more space, i ran IIS reset on all servers (6 total), that didnt solve the issue.
i then, ran into this article, where the user was suggesting to restart the search servers, in my case we have 2, so i did, and under the topology schema section, on the Search Admin Page, the error message was no more.
I will monitor if the crawl is properly crawling on its scheduled time and let you know of the outcome.
Have a great day.
Permalink
Dear all,
we have a SHP 2019 farm and after installing the July 2026 CU our search center (running on “intranet” web app) does not display the preview of all office documents (being rendered by the OOS) which are not coming from “intranet” web app itself but e.g. from “collaboration” web app and any other.
The error message seems to be related to new cross-site access issue as it says “collaboration… has refused the connection”
What could be the root cause and how can we fix that?
Thanks and best regards
Alex
Permalink
Hello ,
I see that Microsoft Support ended for SP2019 as of JULY 14, 2026.
Are they going to release additional patches , if we see any issues after installing JULY CU.
Permalink
Hi Nandu,
most likely not.
Cheers,
Stefan
Permalink
Because of recent patch issues, the last SP 2019 CU I had installed was APR 2026. Due to zero-day exploit requiring JUL 2026 CU for remediation, I installed it yesterday.
Nintex workflows that have a pause appear to run properly. Nintex workflows that run immediately without pausing are throwing a “failed to start”.
Seeing things like this in ULS log:
Potentially malicious xoml node: <ns0:CodeBinaryOperatorExpression.Right xmlns:ns0=”clr-namespace:System.CodeDom;Assembly=System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″> <ns0:CodePrimitiveExpression.Value> true </ns0:CodePrimitiveExpression.Value> </ns0:CodeBinaryOperatorExpression.Right>. If this type is considered legitimate, add TypeName=’CodeBinaryOperatorExpression.Right’ to the authorizedTypes section in server config. Ask your farm administrator to add the corresponding assembly to farm property WorkflowTrustedAssemblies. a6db27a2-45da-20b8-bddb-ac784e7ac901
Permalink
Hi James,
please check the required additional settings for the web.config in this blog post:
https://blog.stefan-gossner.com/2026/07/14/resolved-trending-issue-sharepoint-2010-workflows-fail-after-june-2026-cu/
Cheers,
Stefan
Permalink
Hi Stefen,
thanks for reply. currently SP2019 is single farm include SQL DB for migration purpose. unfortunately, July 2026 CU patch updated direct for the first time and am end up with Search server issue. we tried remove 6 components and activate again but time job struck 10 min (Search Topology Activation Timer Job – Search Service Application/31A501 )
Log error: Crawler:Content Plugin cd11 Critical Content Plugin can not be initialized – list of CSS addresses is not set.
07/16/2026 15:59:06.91 mssearch.exe (VMSPDEV:0x0898) 0x28C0 SharePoint Server Search Crawler:Content Plugin du0c High Failed to extract required parameter FastConnector:ContentDistributor, hr=0x80070002 [pluginconfig.cpp:82] \search\native\gather\plugins\contentpi\pluginconfig.cpp
Multiple times delete and reconfigured. cleared timer cache, restart search host controllers, node runner memorybytes increased. but still no luck. strange part is inactive has 6 components all are good state but I cannot activate them.
Thanks.
Permalink
Hi Stefan!
Since July update, we are facing a problem in our SharePoint 2019 farms. We are seeing an intermittent issue with modern document libraries after updating SharePoint Server 2019 to build 16.0.10417.20175, that leads to a blank page.
Are you aware of such a problem? Please find below our current observations.
During the affected state, the browser requests: /_layouts/15/next/odspnext/office-ui-fabric-react/lib/KeytipData.js
The request returns 404, followed by a MIME-type error and:
RequireJS: Script error for “office-ui-fabric-react/lib/KeytipData”
Recycling the SharePoint web application pool, or running iisreset, temporarily resolves the issue. The problem then returns after an unknown amount of time. We observed the same behavior in two different environments:
– A farm with multiple WFEs;
– A test farm with only one WFE and one application server.
This makes a load balancer issue or a mismatch between WFEs unlikely.
All WFEs have been checked and are consistent:
– Same SharePoint build
– Same installed products
– No missing products
– Same DLL versions
– Identical ODSP JavaScript files and SHA-256 hashes.
During a working page load, RequireJS used the following base URL: /_layouts/15/16.0.10387.20008/next/odspnext/
No request for KeytipData.js was generated.
During the affected state, RequireJS used: /_layouts/15/next/odspnext/
We inspected the RequireJS registry and found that the following standard Office UI Fabric modules depend on office-ui-fabric-react/lib/KeytipData:
office-ui-fabric-react/lib/components/Button/BaseButton
office-ui-fabric-react/lib/components/Link/Link.base
office-ui-fabric-react/lib/components/ContextualMenu/ContextualMenuItemWrapper/ContextualMenuAnchor
office-ui-fabric-react/lib/components/ContextualMenu/ContextualMenuItemWrapper/ContextualMenuButton
office-ui-fabric-react/lib/components/ContextualMenu/ContextualMenuItemWrapper/ContextualMenuSplitButton
BaseButton is defined in: splistreactcontrolsbeforeplt.js and Link.base is defined in: splist.js
We compared these resource folders:
TEMPLATE\LAYOUTS\next\odspnext
TEMPLATE\LAYOUTS\16.0.10387.20008\next\odspnext
TEMPLATE\LAYOUTS\16.0.10417.20175\next\odspnext
The non-versioned next\odspnext files are byte-for-byte identical to the 16.0.10417.20175 files. The older 16.0.10387.20008 versions are different and do not contain any references to KeytipData.
An important detail is that KeytipData is not actually missing from the current package. It is defined inside splist.js:
define(
“office-ui-fabric-react/lib/KeytipData”,
[
“require”,
“exports”,
“tslib”,
“./components/KeytipData/index”
],
…
);
The related KeytipData components and keytip utility modules are also present in the bundle. Therefore, the issue appears to be that RequireJS does not resolve KeytipData from the splist.js bundle and instead tries to fetch it as a standalone file.
Recycling the application pool resets the w3wp process and AppDomain and temporarily restores a working state, which suggests that an in-memory SharePoint or ASP.NET cache may be involved.
Permalink
Hi Mátyás,
if you see requests going to /_layouts/15/16.0.10387.20008/next/odspnext/ it means that the side-by-side token configured in your farm is configured for June 2022 CU – which is unsupported since a very long time.
Alternatively it might be that you have custom SPFx web parts where this path is hard coded.
Please verify the side-by-side token your farm using these steps:
PS> $webApp = get-spwebapplication https://yourserver
PS> $webApp.WebService.SideBySideToken
My assumption is that this will retun 16.0.10387.20008
If side-by-side patching is enabled (which seems to be the case in our farm) you need to ensure that the side-by-side token is updated after installing all SharePoint fixes.
See here for details:
https://blog.stefan-gossner.com/2017/01/10/sharepoint-server-2016-patching-using-side-by-side-functionality-explained/
To set the side-by-side token to July 2026 CU you need to use these steps:
PS> $webApp = get-spwebapplication https://yourserver
PS> $webApp.WebService.SideBySideToken = “16.0.10417.20175”
PS> $webApp.WebService.update()
Cheers,
Stefan
Permalink
Many thanks! It solved our problem!
Permalink
Great! Thanks for the confirmation! 😊
Permalink
Hi All,
The search issue for us is fixed by following the below steps:
Try running below two commands:
$ssa = Get-SPEnterpriseSearchServiceApplication
$ssa.ForceResume($ssa.IsPaused())
If you get error like:
Exception calling “ForceResume” with “1” argument(s): “Failed to connect to system manager. SystemManagerLocations: net.tcp:// ‘….
Try below commands:
Stop-Service SPSearchHostController
Wait for 3-4 minutes
Start-Service SPSearchHostController
Then try running below command again:
$ssa.ForceResume($ssa.IsPaused())
The output should be “True”
If yes, just refresh the search admin page and all should be fine.
Permalink
Didn’t work for us.
Permalink
Hi Chris,
For us, this worked in prod as well.
Permalink
Hello everyone.
This didn’t work for us either.
I’m curious if this issue will be solved by an update at all.
Because of it, we are stuck on April 2026 CU level, both for SharePoint 2016 and 2019 farm.
Has anyone tried playing with the memory limit settings for noderunner, or with the firewall settings as AI suggests for the remedy of problem with error “Failed to connect to system manager. SystemManagerLocations: net.tcp://servername/some-id/AdminComponent1/Management”?
Permalink
After patching, our custom claimprovider gets stuck in a login loop (authenticates, but kicks it back to the idp/sso provider). We had to revert using a snapshot to pre-patch.
I couldn’t find a specific error message via ULS, etc. that looked to be the issue. Was any of the logic or security requirements around custom claim providers updated?
If not, any suggestions as to how I can investigate? Is opening a MS case productive with end of support?
Thanks
Permalink
Will there be another update or are you working on a workaround for the search topology issue? Or is this the last?
Permalink
I am trying to install this CU to my dev servers. I install the CUs on all servers, restart all servers, stop services, then trying to run the “SharePoint 2019 Products Configuration Wizard” .
When running the “SharePoint 2019 Products Configuration Wizard”, it is super slow. I found the C drive has no free spaces although it used to have over 100GB before install the patch.
Any suggestion?
Permalink
I would suggest to check what used up the disk space.
Permalink
I give up on the Cumulative Update July, June and Mai 2026. Those updates just break Search, a couple of Workflows and Infopath forms for us. I doubt this issues will be fixed in future updates since Sharepoint 2019 is end-of-life.
We will update to CU April 2026 and use that as a baseline for our Sharepoint Subscription migration. At least there is hope that Microsoft will (eventually) fix those known issues there.
Permalink
June and July include several security fixes classified as critical. Delaying the installation leaves the environment unprotected against threats that are already documented and weaponized. The longer the delay, the higher the likelihood of a breach.
Permalink
Could someone please recommend the latest stable CU for my SharePoint 2019 farm?
Based on the comments in this thread, I understand that the May–July 2026 CUs may cause issues with Search and other components. Does this mean that the April 2026 CU is currently the most reliable and stable version to install?
I would appreciate your recommendations.
Permalink
See my previous comment
Permalink
June and July include several security fixes classified as critical. Delaying the installation leaves the environment unprotected against threats that are already documented and weaponized. The longer the delay, the higher the likelihood of a breach.
Permalink
Yes that might be true, but it’s not really a solution if the security fixes come with the search issue and render the SharePoint environment unusable.