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 May 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 May 2026 CU will be available at the following Location in a couple of hours:
- KB 5002870 – May 2026 Update for SharePoint Server 2019 (language independent)
This is also a security update! - KB 5002872 – May 2026 Update for SharePoint Server 2019 (language dependent)
This is also a security update!
The downloads for May 2026 CU are available through the following links:
- Download May 2026 Update for SharePoint Server 2019 (language independent)
This is also a security update! - Download May 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 May 2026 CU Build Number:
Language independent fix: 16.0.10417.20128
Language dependent fix: 16.0.10417.20128
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
Did the May 2026 CU break Search for anyone else in SharePoint 2019 (Admin component/SystemManager net.tcp failures, “All Errors”)? Rebuilding and activating a new Search topology resolved the issue on my side.
Permalink
I installed this latest update right now, just a few days after it was released (which I don’t normally do, in order to avoid issues that might arise over time), and it seems I’m having the same issue with the Search Service Application (SSA).
Before installing the update, I pause the SSA, but after installing both updates, restarting, and going through the configuration wizard, I can’t resume the SSA.
Fortunately, I installed it on a test environment where it doesn’t bother me, so I’ll wait until it’s resolved. I don’t have time to open a ticket with MS (I apologize).
Permalink
I had to revert to april CU as more problems were discovered. At least SPS2016 and SPSE looks fine after May CU.
Permalink
I have the same issue with the Search applications. On one of the SSA, the Admin component is showing the red mark, and on the other SSA, it’s the Analytics Processing component. Restarting the search services did not fix that.
Permalink
Could you please let us know what other issues you’ve encountered? … so I can see if I’m having them too.
Permalink
A topology rebuild restored access to the Admin component and slightly improved the GUI, but I still distrusted the green checkmarks because the ULS logs showed communication-related errors. After a server restart the Query component failed to come online and I didn’t have time to investigate why. This time the GUI correctly showed the failed component.
Permalink
Yep, broke here as well, unable to retrieve topology. Was not able to activate a new topology, had to rebuild the SSA then it worked. Fortunately was test environment, not planning to install in prod quite yet 🙂 and will delay also SPSE updates for a bit.
Permalink
HI!, it is safe to installa may updates without the February update mentioned in Trending Issue: SPSE – Configuration Wizard will fail for upgrades from January 2026 CU to March 2026 CU?
Permalink
Yes, it is safe. Only March CU was affected.
Permalink
We are encountering the same SSA topology issue after installing the May 2026 update, as described above.
“Unable to retrieve topology component health states. This may be because the admin component is not up and running.”
Permalink
Hi Andres,
please open a support case with Microsoft to ensure this is investigated.
Cheers,
Stefan
Permalink
We experienced the exact same issue in both our SharePoint 2019 and SharePoint Subscription Edition environments.
After working with Microsoft Support, we were able to resolve the issue in both environments by restarting the following services via services.msc:
SharePoint Search Host Controller
SharePoint Server Search 16
Permalink
Unfortunately, restarting those services didn’t resolve the issue in my case. This is one of the first steps Microsoft Support typically recommends, and I had already tried it. What’s still unclear to me is why the component was missing after a full server restart in the first place.
That said, I haven’t experienced similar issues with SharePoint Subscription Edition across multiple environments – this seems to be an isolated case.
Permalink
Same here. Restart the services several times. No go.
Also tried refreshing the search components by running the RefreshComponent(). Same result.
Permalink
The conclusion from yesterday that the issue was resolved after restarting the search services is incorrect. The same issue occurs again after a reboot (in both SPSE and SP2019), as several others have mentioned. Looks like it will be another round with Microsoft support today!
Permalink
I was in a call with Microsoft Support again yesterday. The following findings were identified:
•The issue was observed due to the SharePoint Search services not initializing correctly after a system restart.
•Specifically, the Search Host Controller service did not start cleanly, resulting in unavailability of the Search topology.
•This behavior was further affected by the service startup sequence, where dependencies (such as SQL connectivity and related services) were not fully available during the initial startup phase.
To prevent recurrence of this issue after reboots, the following measures have been implemented:
The Search services startup type has been configured to “Automatic (Delayed Start)”, ensuring they start only after all dependencies are fully available.
This approach helps avoid partial initialization and ensures consistent availability of the Search topology.
The following commands were applied:
sc.exe config SPSearchHostController start= delayed-auto
sc.exe config OSearch16 start= delayed-auto
Following these changes, the servers have been rebooted multiple times, and the Search functionality has remained operational after each restart.
I will continue to monitor the environment and perform additional testing, including further reboots, over the weekend.
That said, the root cause of this issue has not yet been fully explained.
Permalink
Hi AndersK,
Did you run the sc.exe commands on all the servers?
Thanks,
Permalink
Confirmed: this affects SPSE as well. In SP2019 the problem is nearly instantaneous, while in SPSE it develops more slowly. Benjamin’s fix (restart services and run PSConfig repair) is somewhat effective, at least for SPSE.
Permalink
Hello Stefan!
We have reproduced issue with search mentioned by Benjamin Freitag (https://blog.stefan-gossner.com/2026/05/12/may-2026-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-63503) in our SP2019 test environment.
After installing the May CU, search appeared to be functioning correctly. However, after a server reboot, an issue occurred with the Search Application Topology – “Search Application Topology: Unable to retrieve topology component health states”. Restarting the SharePoint Search Host Controller resolved the issue, but after the next server reboot, the problem occurred again.
Regards,
Zaneta
Permalink
Hello Stefan,
I have also experienced the exact same issue in SP2019 with the error: “Unable to retrieve topology component health states. This may be because the admin component is not up and running.” Since this issue has been encountered by many customers under this post, I would suggest that you publish a blog post about it and the recommended remedy.
Thank you
Permalink
Hi all,
I hope you all open support tickets for this – so far I have not seen one.
Cheers,
Stefan
Permalink
Hello to all.
Sorry for the “stupid” question, but who is even authorized to file a case with MS support? What type of contract does the company have to have to authorize it to open a support case? And what is the proper way? Is there some web page, web form or application?
Thanks in advance for your answers.
With best wishes.
Permalink
We are also seeing this issue with 2019 where search topology does not load and search is broken. I have rasied a support ticket TrackingID#2605270030007347 and spent an hour with an engineer who attemted to recreate search searvive but we are presented with
“Set-SPEnterpriseSearchTopology : Topology activation job died prematurely, the topology already is in Activating state.”
Permalink
Hi Stefan,
Do you have any suggestions for how to avoid these problems with Search? Any tips on what might help?
Permalink
Hi Bruce,
I have not seen a large number of cases on this topic and as my main focus is not on search I do not have all the required insights.
From a brief review of cases I see that this method helped at least two customers:
sc.exe config SPSearchHostController start=delayed-auto
sc.exe config OSearch16 start=delayed-auto
Cheers,
Stefan
Permalink
Hi Stefan, hi Bruce,
From my testing, I’m not convinced this approach is reliable. Setting both services to delayed automatic startup feels somewhat counter-intuitive—especially since the Search Host Controller should be responsible for orchestrating the Search service startup in the correct order, rather than relying on delayed timing.
I did an additional round of tests, and after server restarts, Search actually ends up in a non-functional state more often than not. What consistently helps in my case is:
stopping the Search service, and
restarting the Search Host Controller service
After that, Search gradually recovers until all components show healthy in the Search Administration page.
Also, I suspect the low number of support cases might not fully reflect the scope of the issue. Given that this version is effectively at end-of-life (with support ending next month), there’s limited incentive for customers to open new cases, especially for environments that ideally shouldn’t remain in production.
So at least from what I’m seeing, the delayed-auto configuration doesn’t appear to address the underlying problem, but rather masks it inconsistently.
Cheers,
Atis
Permalink
Hi Atis,
did you open a ticket with Microsoft Support for this yourself?
Cheers,
Stefan
Permalink
No, not at this stage – mainly because this isn’t affecting a production environment. For SPSE, I’d be more inclined to open a support case.
Cheers,
Atis
Permalink
Since applying the following changes to the search service during a call with Microsoft Support, a week ago:
sc.exe config SPSearchHostController start= delayed-auto
sc.exe config OSearch16 start= delayed-auto
I have not experienced any issues with the search topology failing to provision after server reboots in the SPSE environment.
However, in the SP2019 environment, the issue still occurs. After approximately 50% of server reboots, I encounter the same error related to the search topology.
I agree with Atis that this “fix” does not address the underlying root cause.
Permalink
Because of this, we are currently holding off on upgrading the QA and production environments with this CU.
This is critical, as this CU appears to address serious vulnerabilities related to remote code execution (e.g., https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-47294).
As a result, we are in a difficult situation:
On one hand, we cannot install the May CU in production due to the issues observed with the Search Topology in our dev and test environments.
On the other hand, our production environment remains vulnerable to remote code execution.
Permalink
Hi AndersK
I understand the concern, but reading your description it sounds like this has been observed in dev/test only, and I’m wondering whether you’ve already validated the service restart workaround end-to-end before deciding to block the CU rollout entirely.
In my testing, the issue with the Search topology is reproducible, but also recoverable. After restarting the affected services, the Search service returns to a stable working state and continues operating as expected.
It would be interesting to know whether the restart/recovery approach failed in your case, or if it simply hasn’t been validated yet.
Permalink
Hello everyone,
I have noticed similar issues on our Sharepoint 2019 after the May CU: The crawlers were running endlessly and
$ssa = Get-SPEnterpriseSearchServiceApplication
Get-SPEnterpriseSearchStatus -SearchApplication $ssa
returns
Get-SPEnterpriseSearchStatus : Failed to connect to system manager. SystemManagerLocations: net.tcp://myserver/C3BC4A/AdminComponent1/Management
At line:2 char:1
+ Get-SPEnterpriseSearchStatus -SearchApplication $ssa
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (Microsoft.Offic…GetSearchStatus:GetSearchStatus) [Get-SPEnterpriseSearchStatus], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.Office.Server.Search.Cmdlet.GetSearchStatus
The workaround with sc.exe (delayed auto) does not help in my case.
Maybe I will find a few minutes in the next days to open a support case.
Permalink
Hi Phil,
Just a quick note based on my recent interaction with Microsoft support and what I’ve observed so far.
From what I understand, for SPS2019 the support scope may be limited to break/fix assistance rather than a full RCA. In similar situations, the focus may be on mitigation rather than a deeper root cause investigation.
In my case, the workaround I am currently using (stopping the Search Service and restarting the Search Host Controller service) has been working reliably so far.
Of course, it may still be worth opening a support case, but I just wanted to share this context so expectations can be aligned.
Cheers,
Atis