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 Subscription Edition.
Monthly SharePoint Server Subscription edition updates are released as a single unified “uber” package containing both the language independent and language dependent fixes. Language independent and language dependent fixes will no longer be released separately. This is similar to the full server packages released for SharePoint 2013.
The KB article for June 2026 CU will be available at the following location in a couple of hours:
- KB 5002873 – June 2026 Update for SharePoint Server Subscription Edition
This is also a security update!
The download for June 2026 CU is available through the following link:
It is irrelevant which language you pick on the drop down in download center. It will always download the same package.
After installing the fix you need to run the SharePoint 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 Server Subscription Edition June 2026 CU Build Number: 16.0.19725.20384
Important: To minimize the installation time for SharePoint Server Subscription Edition Fixes, please follow the guidance in the following article: Solving the extended install time for SPSE CUs
Related Links:
- Learn: Updated Product Servicing Policy for SharePoint Server Subscription Edition
- Learn: FAQs for SharePoint Server Subscription Edition product servicing policy
- Blog: SharePoint Patching Best Practices
- Blog: SharePoint Patching demystified
- Blog: Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE
- Learn: SharePoint Updates
- Blog: SharePoint Server 2016 Zero-Downtime Patching Demystified (applies also to SharePoint Server 2019)
- Blog: SharePoint does not have a build version. Full Stop.
- Blog: Solving the extended install time for SPSE CUs
Permalink
Hi Stefan,
The file hash I’m seeing on uber-subscription-kb5002873-fullfile-x64-glb.exe’s download does not match the KBAs file hash.
From https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-sharepoint-server-subscription-edition-june-9-2026-kb5002873-748a1c50-e53b-48ce-b71a-44c39a02922e
File name: uber-subscription-kb5002873-fullfile-x64-glb.exe
SHA256 hash: A5F6804D6A11B00145893D3B87C16237A7B3F2FD4E3B6508D186138CE49AF4C7
But my download is showing (Get-FileHash)
Algorithm : SHA256
Hash : 0AA1FF99C920665968D07FD9CFECA6B1A0D0C60EFE0E458774997DFCF27CCE8C
File: C:...\Downloads\uber-subscription-kb5002873-fullfile-x64-glb.exe
Anyone have the same result? Was the update .exe changed last minute or is something else going on??
Permalink
Hi Brian,
yes – I can confirm your findings.
The version number in the KB is also much lower than the binaries.
I pinged the KB author to update the details.
Cheers,
Stefan
Permalink
Thanks! Verified it’s been updated.
Permalink
Hello Stefan, thanks for this post.
I noticed in the KB that “If you’re currently running the Classic version of Workflow Manager, you have to enable the debug flag in order to continue using it”, is that referring to Workflow Manager 2010?
Permalink
Hi Daniel,
there is no Workflow Manager 2010. SharePoint 2010 style workflows do not use an external workflow manager.
It refers to SharePoint 2013 workflows which are currently supported using classic Microsoft Worfklow Manager and its successor SharePoint Workflow Manager.
Cheers,
Stefan
Permalink
Ah ok, thank you.
Permalink
Hello Stefan,
I just installed KB5002873 on our test server, but it looks like the CU Build Number is higher than yours:
$farm = Get-SPFarm
$farm.BuildVersion.ToString()
16.0.19725.20384
Permalink
Hi Daniel,
indeed – I trusted the details in the KB article but indeed the file has a higher version number.
Cheers,
Stefan
Permalink
I meant to say I just installed KB5002873
Permalink
Hi, Stefan
We have a working Sharepoint2019 and I have to make fresh install of SE for attach-upgrade to it.
Downloaded RTM of Sharepoint SE, downloaded 2026-05 CU , made a “test” blank install, without DB attaching – after applying 26-05 CU the Sharepoint stopped working – management console won’t open , so I decided to start from scratch… and today found your site. After reading about problems introduced with these CU patches, I wonder what is the correct way to install fresh Sharepoint SE ?!
is it
1. RTM+ language pack, then go to latest CU (2026-06)
or
2. RTM -> 2025-09 -> 2026-06
or something else!?
Idea of reading years of patches and fixing these by hand looks … bad.
Thanks :/
Permalink
Hi Chavdar,
you should skip September 2025 CU – it introduced a large number of problems.
The recommended method is method 1:
RTM+required language packs -> 2026-06 CU.
Cheers,
Stefan
Permalink
Stefan,
We normally use the Learn page – https://learn.microsoft.com/en-us/OfficeUpdates/sharepoint-updates for seeing/downloading SharePoint updates. The page has not been updated for June patches. Is this page no longer supported or is there a better location to see all the updates?
Thanks,
Daniel W
Permalink
Hi Daniel,
it is not only this page which is stale right now – the 26H1 feature page is also not yet online.
The learn.microsoft.com site is currently undergoing a bigger maintenance which causes publishing of new content and updates for pages to be delayed.
Cheers,
Stefan
Permalink
Hi Stefan,
We are noticing that months Subscription Edition patch is breaking workflow. Has anyone else reported this issue? We tried two separate farms and got same results. We plan to collect logs next and open a ticket. When a workflow is initiated we get a status of “Failed to Start.”
Permalink
Hi Stefan, are there any reports of classic workflow having issues. We confirm workflow problem on two farms. We get “Failed to start” message. Thanks, Will
Permalink
Hi Stefan, has anyone reported issues with classic workflow in Subscription Edition? We patched 2 farms with same result error “failed to start.”
Permalink
Hi Stefan, does this June patch cause problems with classic workflow? We confirmed issue on two farms that show “failed to start.” Thanks, -Will
Permalink
Hi,
we are testing the CU on our QA environment. It seems there is something not working prperly with the Approval workflows. Did anyone else notice the same?
RunWorkflow: System.InvalidOperationException: This feature has been temporarily disabled.
at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.CompileBytes(Byte[] xomlBytes, Byte[] rulesBytes, Boolean doTestCompilation, String assemblyName, SPWeb web, Boolean forceNewAppDomain)
at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association, Boolean fallback)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow)
at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(SPWorkflowHostService host, SPWorkflow workflow, Collection
1 events, TimeSpan timeOut)1 events, SPWorkflowRunOptionsInternal runOptions)at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection
spNoCodeXomlCompiler.IsGoodWorkflow: Potentially malicious WorkflowCodeTypeReferenceExpression:
Workflow Compilation XPath killswitch resulted in an exception: System.InvalidOperationException: This feature has been temporarily disabled. at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.CompileBytes(Byte[] xomlBytes, Byte[] rulesBytes, Boolean doTestCompilation, String assemblyName, SPWeb web, Boolean forceNewAppDomain)
Permalink
Hi Zoltan,
please try the suggestion provided by another user:
https://pastebin.com/Fzqg1P3u
Let me know if it helps.
Cheers,
Stefan
Permalink
After installing June 2026 CU for SharePoint Server SE, Nintex Workflow stopped working.
When publishing a workflow, the following error is displayed: soap:ServerServer was unable to process request. —> Failed to publish workflow: This feature has been temporarily disabled.
When firing a workflow: Workflow failed to start
Temporarily resolved by running this script:
$farm=Get-SPFarm
$farm.EnablePreParseSecurityCheckForWorkflow = $false
$farm.update()
iisreset
Update: solved by adding this line
to the web.config
<System.Workflow.ComponentModel.WorkflowCompiler>
and also to owstimer.exe.config (same place)
Permalink
In case someone is using Nintex for SharePoint SE (6.0.13.0). We had to register additional safe types in the Web.config file in order to publish new workflows:
<System.Workflow.ComponentModel.WorkflowCompiler>
…
…
Permalink
Hi Marc,
we are using Nintex withe SPSE (have not updated to June CU yet). Can you please describe in more detail what you had to add to your web.configs – maybe we already have those lines. In 2025 we had this issue as well, where we had to add some new safe types. However nobody else on this blog seemed to had this issue.
BR Alex
Permalink
A am unable to pass throught Akismet antisam filter on this page. This system is unusable and communication is desperate.
Permalink
Hi Michal,
its not aksimet – first time commenters need to be manually approved by me to avoid SPAM.
Cheers,
Stefan
Permalink
Permalink
Hi Alex,
I uploaded them here: pastebin.com/Fzqg1P3u because the lines are being blocked by the blog.
Kind Regards
Marc
Permalink
Thanks Marc, will look into this.
BR Alex
Permalink
Hi Marc,
just wanted to let you know that I found the seven authorized types from your upload in our web configs. The only difference between yours and mine is the type name. Yours for example are listed as CodeMethodInvokeExpression.Method or CodeMethodInvokeExpression.Parameters while my web configs only have one entry with just CodeMethodInvokeExpression (everything else is the same).
BR Alex
Permalink
Hi Alex,
yes we had “CodeMethodInvokeExpression” also already listed but the “sub types” were also needed for our Nintex Workflow.
Kind Regards,
Marc
Permalink
Hi Stefan,
We ran into some issues with SharePoint 2010 workflows after applying this patch. The workflows started failing, and one of the more interesting entries I found in the ULS logs was:
“Potentially malicious xoml node”
What’s confusing is that the functionality doesn’t appear to be completely broken. I created a new empty workflow in SharePoint Designer and was able to publish it successfully. The workflow also ran without issues. I then added a simple action (sending an email to a user), republished it, and that worked as well.
However, as soon as I added a condition, SharePoint Designer refused to publish the workflow, these conditions existed in previously published workflows. I tested conditions such as:
If Current Item: Promoted State equals …
If Current Item: Created By equals …
In both cases, publishing failed with the following error:
“Errors were found when compiling the workflow. The workflow files were saved but cannot be run.
Unexpected error on server associating the workflow.”
Have you come across anything similar, or do you have any insight into what might be causing this behavior?
Permalink
Hi Tobias,
can you try the solution suggested by one affected user:
https://pastebin.com/Fzqg1P3u
Please let me know if it works for you.
Cheers,
Stefan
Permalink
Hi again,
After adding the authorizedTypes entries to web.config, the original “Potentially malicious xoml node” error seems to have disappeared. However, workflow publishing and execution still fail. The ULS log now reports:
SPNoCodeXomlCompiler.IsGoodWorkflow:
Potentially malicious WorkflowCodeTypeReferenceExpression:
Microsoft.SharePoint.WorkflowActions.Helper
Noticed that we had the same or similar issue to Zoltan and others refering to workflows “failed to start”
The issue appears to occur specifically when workflow conditions are added, while action-only workflows publish and run successfully.
Permalink
Hi Tobias,
yes, you are correct. I can confirm that classic sharepoint workflows still fail.
“spNoCodeXomlCompiler.IsGoodWorkflow: Potentially malicious WorkflowCodeTypeReferenceExpression: ns2:WorkflowCodeTypeReferenceExpression QualifiedName=”Microsoft.SharePoint.WorkflowActions.Helper” Type=”Microsoft.SharePoint.WorkflowActions.Helper”
I tried adding it also as a safetype in Web.config file , but it is not working for me.
Permalink
Hi!
When i applied the June patch on my SPSE farms i got problem with Search Service.
A inc-crawl goes on forever and when in CA Search Admin in CA i get an error
“Unable to retrieve topology component health states.
This may be because the admin component is not up and running.”
I had to rebuild the topology and got it working again.
I got this on all of my farms.
I also got a new row in web.config.
With true set i got a cookieerrormessage when starting a 2010wf
Changed to false and i got rid of message.
Is this a known issues?
Permalink
I also found search was broken, search results said “Search has encountered a problem that prevents search results being returned.”, and Search Administration said “Unable to retrieve topology component health states. This may be because the admin component is not up and running.”
Rebuilding the search topology seemed to have fixed this.
Permalink
Hi,
We had the same issue on two of our farms:
* search results were not returned
* Search Administration said “Unable to retrieve topology component health states. This may be because the admin component is not up and running.”
* ULS contained the following error: Failed to synchronize legacy admin: System.InvalidOperationException: Failed to connect to system manager. SystemManagerLocations: net.tcp://xxx/8492CD/AdminComponent1/Management —> System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.
On one farm it was enough to restart Admin and Search-related services. On the second farm multiple restarts did not work, but restarting the whole server worked.
Stefan, are those search issues a trending issue?
Best Regards,
Maciej
Permalink
Hi Maiej,
it is not completely clear here as we get different symptoms from different customers and different solutions work for different users.
Obviously something is going on here but its not possible to get reliable repro steps, symptoms, workarounds and others.
Cheers,
Stefan
Permalink
I see these errors in event viewer also. (Gatherer\CSS connector failed to connect to CSS net.tcp://servername/55EF82/ContentProcessingComponent1/ContentSubmissionServices/content)
An iisreset seems to fix this one.
(Additionally, I restarted OSearch16,SPSearchHostController but not sure if that had any effect, was still failing.)
Permalink
Something similar has happened to us. Since installing the June 2026 SPSE CU, we have been experiencing recurring HTTP Throttling and 503 Server Busy errors.
Most of the queued requests are long-running calls to User Profile Service endpoints such as FeedCacheService.svc and ProfileDBCacheService.svc. These processes come along with Search and involve our Search servers.
We have tried different troubleshooting, we know that by resetting the IIS pool, the issue is contained but nothing has worked to actually resolve the issue
Permalink
Anyone experience this as well?
Immediately after applying the June 2026 Cumulative Update (CU), users began losing their Federated Authentication (FedAuth) cookies. This issue is specifically observed when users are routed to one or two servers within the pool. The dropped cookies cause unexpected session terminations, forcing users to re-authenticate. (We have 6 Front End web servers and Web servers are sitting behind the F5.)
Permalink
Hi Stefan,
We have recently migrated from SharePoint 2019 to subcription edition.
We have installed the SharePoint subscription edition across the farm and put the latest cu patch on of it run the config wizard.
Recently after moving content db’s in UAT farm observed that while running Test Db’s command
Language pack is missing in the servers
My question is still can we install language patch on the game and run configuration wizard again if yes what is the language patch need to install please confirm
Thanks
Permalink
Hi Adithya,
based on the message a “Language PACK” is missing – not a “Language PATCH”.
The content database you are trying to attach contains site collections for a different language than the SharePoint installation.
In the original farm you either had a different language of SharePoint installed – or additional language packs were installed.
You need to install the language pack for the missing language and afterwards reapply the most recent SharePoint CU.
You can find the different language packs here:
https://www.microsoft.com/en-us/download/details.aspx?id=103600&msockid=0d888a8c09b26bfc3e339ea208d96a96
Cheers,
Stefan
Permalink
Hello,
Since installing the June 2026 SPSE CU, we have been experiencing recurring HTTP Throttling and 503 Server Busy errors. Request queues continue to grow even after increasing the ASP.NET threshold from 500 to 800.
Most of the queued requests are long-running calls to User Profile Service endpoints such as FeedCacheService.svc and ProfileDBCacheService.svc
The issue started immediately after patching. We are temporarily mitigating it by removing affected WFEs from the load balancer and recycling IIS application pools, but the problem eventually returns.
From the comments, I have seen that some are experiencing the same; jobs taking forever, the constant need for resetting IIS pools. We have engaged Microsoft, but nothing has worked.
Permalink
Hi Belen,
ensure to open a support ticket with Microsoft to get this investigated.
Cheers,
Stefan
Permalink
We are also experiencing severe performance degradation after installing this update to the point that SharePoint is unresponsive and unusable.
Restarting the web services resolves the issue but only for a few minutes.
A ticket has been raised with MS Support.
Permalink
I noticed the following behavior with a SharePoint list and was wondering whether anyone else has observed the same issue. I have been able to reproduce it in multiple environments after installing this CU.
Calculated fields that return a “Yes/No” value are no longer recognized as Boolean (Yes/No) fields by our solutions when querying the list.
In contrast, manually populated “Yes/No” (Boolean) fields continue to be recognized correctly by the same solutions.
However, I have not been able to find any documentation or release notes describing such a change. Has anyone seen similar behavior or is aware of an intentional change in this area?