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 August 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 August 2026 CU will be available at the following location in a couple of hours:
- KB 5002893 – August 2026 Update for SharePoint Server Subscription Edition
This is also a security update!
The download for August 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 August 2026 CU Build Number: 16.0.19725.20522
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,
I’m not sure about the follwoing statement:
Notifies that the SharePoint 2010 Workflow feature will be disabled starting with the September 2026 Public Update. Use the Enable-SPLegacyWorkflow cmdlet to enable the feature for a site collection.
Maybe you can clarify that for me.
Does it mean that with the September 2026 CU the Feature for 2010 Workflows will be disabled on every Site Collection and we just need to activate it on SiteCollection level if we want to keep using them?
BR,
Chris
Permalink
Your understanding is correct.
You can already run the command today if August CU is installed. This will prevent September CU from disabling the workflows for the configured site collections.
Cheers,
Stefan
Permalink
is there any timeline on how long the Enable-SPLegacyWorkflow command will be available?
Permalink
Hi Ben,
sorry, I did not receive a timeline for this.
SP2010 workflows are already unsupported since July 14th.
All efforts should focus on migrating away from this unsupported feature to an alternative solution.
Cheers,
Stefan
Permalink
Hi Stefan,
I haven’t installed the new CU update yet and therefore I wanted to know how does one use this new cmdlet “Enable-SPLegacyWorkflow”. Is there a KB article for this or some sort of documentation? Right now I would assume to just open the SP management shell and run the command Enable-SPLegacyWorkflow + URL of the site collection. Maybe you or someone else here could clear things up for me.
BR Alex
Permalink
Hi Stefan,
Do you have any updates on the ‘defence-in-depth feature currently under development that may cause a regression’, mentioned in the KB article for the July 2026 CU (https://support.microsoft.com/en-us/servicing/office/update/2026/5002882)? Having reviewed the list under ‘Improvements and fixes’, I didn’t find any entries relating to that defence-in-depth feature. I ask because I’m wondering whether we may still have to disable this feature. Based on a few tests after installing the August 2026 CU, it looks like this is the case. However, I would prefer an official statement.
Cheers,
Paul
Permalink
I’d also prefer an official statement.
Permalink
In the meantime, I applied the update to a test farm and was informed that there had been a misunderstanding. The property no longer exists after the August 2026 CU was applied, so my question has become obsolete.
Thanks,
Paul
Permalink
Hi Stefan,
There seems to be a bug introduced in this CU of SPSE.
The “?contents=1” parameter used to check webparts on pages is not working anymore (it was OK on July CU).
PS : Thank you for the quality of your posts and the follow-up provided.
Cheers,
Rémi
Permalink
Hi Stefan,
We just applied the Aug 2026 Patch for SPSE and it looks like it broke our existing External Content Types which were working before the Patch. When we launch them now they produce the following error(s):
“An error occurred while retrieving data from {Target Application Name}. Administrators, see the server log for more information.”
“Business Data Connectivity is configured incorrectly. Administrators, see the server log for more information.”
Any suggestions on a fix?
Thank you so much for your help!
Permalink
Additional info. We’re seeing this in the logs now:
Business Connectivity Services Business Data 36px4 Unexpected BCS type ‘SecureStoreProvider’ from assembly ‘Microsoft.Office.SecureStoreService, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ is being blocked. 3b9c30a2-1094-5019-cfb2-0f505895651b
Permalink
Does this August CU fix the issues from June and July’s CU?
Permalink
From July CU – yes. Which June CU issue do you mean?
Permalink
From reading the June SharePoint SE CU several people have reported on your blog:
Search Administration in CA throwing “Unable to retrieve topology component health states. This may be because the admin component is not up and running,” incremental crawls hanging indefinitely, and search results failing with “Search has encountered a problem that prevents search results being returned”
ULS showing Failed to synchronize legacy admin: System.InvalidOperationException: Failed to connect to system manager against the AdminComponent management endpoint
Gatherer/CSS connector failures to the ContentProcessingComponent endpoint in Event Viewer
Permalink
Hi Robert, this has been reported already starting with April CU.
No this was not fixed.
Permalink
Hi Stefan!
Do know if someone has come up with a workaround, when search is failing after patch
Unable to retrieve topology component health states. This may be because the admin component is not up and running,”
I have to rebuild Search totally and loosing 2,5 days until a full crawl har run.
Is there someway i can just rebuild the admincomponent?
Regards,
/ML
Permalink
Hi Micke,
please try these steps and afterwards restart the machine:
sc.exe config SPSearchHostController start=delayed-auto
sc.exe config OSearch16 start=delayed-auto
Cheers,
Stefan
Permalink
Hello Stefan,
we had the same problem with search not working after installation of Sharepoint July Update and Windows Update from August.
The two delayed start commands for the search services fixed the search problem for our farms, thanks very much!
Can we keep this setting permanently (delayed start)?
Regards,
Martina
Permalink
Hi Robert!
One of my farms has the same problem, every patch kills Search.
I get the same error as you and i have to rebuild Search, removing app and proxy, deleting databases and create searchcomponents and im up and running again. Have you found a quicker way to fix the admincomponent?
Regards,
/ML
Permalink
We purposely have stayed on Aprils CU because of these issues. So I haven’t tried any of the fixes yet-I was hoping August CU would fix these issues before I patched to current.
Permalink
Hi Robert,
I did a test in my failing test farm. I added searchserviceaccount to local administrators, restarted search host controller and osearch16 and Search was up and running. I removed searchaccount from admininstrators, restarted service again and i get the admincomponenterror.
I then rebuilt the Searchapp and service, topology ans Search is up and running. I checked if my searchserviceaccount was in administrators and it wasnt.
So this has to do with permissions in some way. In certain farms the patches since April makes some kind of permissionchange. i have farms where search survives patches to
Regards,
/ML
Permalink
Hi Stefan,
We have applied the August patch which appears to complete successfully, but when we attempt run: Add-SPDistributedCacheServiceInstance to add a distributed cache it returns an error stating no hosts present in the cluster. This has been part of our standard patching process for some time (we remove using Remove-SPDistributedCacheServiceInstance, run psconfig, then add), but since the August 2026 CU it has failed on multiple environments. We’ve attempted to follow some of the suggested processes for re-instating the distributed cache but with no luck. Has anyone else encountered this? Have you got any other ideas?
Thanks,
Matt
Permalink
Yes – this was identified as a known issue in August CU. You can solve it by removing the server f r Om the farm and join it back with dcache role.
Planned to be fixed in September CU for SPSE
Permalink
Thanks for the quick response, we’ve just attempted removing the server from the farm and re-adding it with distributed cache. Unfortunately we are still getting similar errors, we tried in three environments. Two farms gave the error – “CacheHostInfo is null” while the other farm gave a NullReferenceException error. Can you provide any more guidance around this issue? Are their any additional step we need to do to make this work?
Thanks,
Matt
Permalink
Hi Matt
When I experience this issue, I usually run the following commands. Perhaps this might resolve your problem as well:
Unregister-CacheHost -HostName SERVERNAME-ProviderType SPDistributedCacheClusterProvider -ConnectionString „\SERVERNAME“
I hope this helps!
Permalink
Hi Matt,
When I had this exact issue, after trying all the other solutions, as a last resort, I ran the following command and it solved my error:
Unregister-CacheHost -HostName YOUR_SERVER_NAME -ProviderType SPDistributedCacheClusterProvider -ConnectionString „\YOUR_SERVER_NAME“
Hope this helps!
Permalink
What exact steps did you use to remove the dcache from the server before patching and what exact steps did you use to remove and ready the server with dcache role?
Permalink
The dcache was not removed before patching.
Our process is:
1) Apply patches
2) Remove-SPDistributedCacheServiceInstance
3) Run PSCONFIG.exe
4) Add-SPDistributedCacheServiceInstance (this errored this time after the August 2026 CU) Previous we have had no issues with this process.
To remove and ready server with dcache role:
1) Ran SharePoint Configuration Wizard
2) Remove server from farm
3) Add Server to existing farm with dcache role.
In addition, when that didn’t work we repeated the process and included rebooting and repairing SP prior to re-adding to the farm with no success.
Thanks,
Matt
Permalink
Hi Matt how many dcache servers do you have in farm? Have all been removed or are some still joined and working?
Permalink
Thanks. Will send the details to engineering
Permalink
We only have 1 dcache server in each of these farms. For these lower environments we only have 2 servers per farm total.
Permalink
That is so silly; this is a known issue, and they didn’t communicate it in the patch notes. My team and I lost the entire day trying to investigate this…
We are also having this issue, even on single-server farms. Are we supposed to remove and re-add the server even on single-server farms?
Permalink
I’ve attempted to remove/re-add our single server to the farm, and now I get Failed to register SharePoint services.
This is a critical task. You have to fix the failures before you can continue.
An exception of type System.InvalidOperationException was thrown. Additional exception information: cacheHostInfo is null
Permalink
Hi Andre,
please try this workaround:
$farm = Get-SPFarm
$farm.ServerDebugFlags.Add(59052)
$farm.update()
Cheers,
Stefan
Permalink
It was identified after the fix was released.
Permalink
Hi Matt,
please try this workaround:
$farm = Get-SPFarm
$farm.ServerDebugFlags.Add(59052)
$farm.update()
Cheers,
Stefan
Permalink
Thank you Stefan, the ServerDebugFlags witchcraft worked for us (again). thank you! MS itself hasn’t updated the CU official notes to include this known issue yet, what would be of us if we didn’t had your blog… Thank you for all the help
Permalink
Hi Stefan,
Thankyou for your help, this appears to have resolved the issue for us. We’ve been able to use it in a number of environments and are now able to bring the DCaches back up.
Are you able to advise what this magic does?
Will this be the official MS work around for this issue?
Going forward will we need to revert this setting when we apply the next round of patching?
Thanks,
Matt
Permalink
Hi Matt,
please revert the flag after the server is joined back to the farm.
It is only required to temporarily disable the affected code path that caused the problem to join new DCACHE servers to the farm.
A permanent fix is currently planned for September 2026 CU.
Cheers,
Stefan
Permalink
Hi Stefan,
I have two Distributed Cache Servers and after August Patch
I disconnected First FE and Rejoined it with FE with DCache Role , it worked fine
i disconnected Second FE and Rejoined it with FE with DCache Role it is now FEwithDcache role but distributed Cache Server is still not working ,
Compliant ( no ) fix in Central Admin
run your $farm script
First Server is showing , DCache online but Second Server PsConfig is also failing with CacheHostisNull
Permalink
Hi Raheal, did you try the workaround with the Serverdebugflag above?
Permalink
Hi Stefan,
Yes, I rejoined the second server and Run your PowerShell
$farm = Get-SPFarm
$farm.ServerDebugFlags.Add(59052)
$farm.update()
But Second server while joining ( running psconfig ) give exception of CacheHost is null, First server is working fine and Distributed Cache is also working fine.
I tried Remove and Add-SPDistributedCacheInstance but it throws exception of “No host present in the cluster”
Please suggest.
Permalink
Hi Raheel,
if the flag doesn’t help, my suggestion would be to open a ticket with Microsoft support to analyze this in more detail.
Cheers,
Stefan
Permalink
Hi Stefan,
I had the same problem in a customers SP SE farm. I tried the following fix in my own test environment. It worked several times without the need to re-join the server.
The DC size must be modified depending on the farm/server.
$cacheSizeInGB = 12
$instanceName = “SPDistributedCacheService Name=SPCache”
$instance = Get-SPServiceInstance | Where-Object { “$($_.Service)” -eq $instanceName }
if( $instance ) {
Export-SPCacheClusterConfig “temp.xml”
$instance.Delete()
Start-Sleep -s 10
Import-SPCacheClusterConfig “temp.xml”
try {
Add-SPDistributedCacheServiceInstance -CacheSizeInMB ($cacheSizeInGB * 1024)
} catch {
#Error can be ignored
}
$instance = Get-SPServiceInstance | Where-Object { “$($_.Service)” -eq $instanceName }
$instance.Provision($true)
Start-Sleep -s 10
Get-Service “SPCache”
}
Regards
Ingo (MCM: SharePoint 2010)
Permalink
Hi Chris, yes – just the site collection url as parameter
Permalink
Hi Stefan, has the “DisableActorTokenAudienceValidation” feature actually been fully implemented?
The reason for my question is that the “DisableActorTokenAudienceValidation” flag is no longer accessible.
Thx Geo
Permalink
After installing the August 2026 CU (16.0.19725.20522), we observed a regression related to the Document ID Service.
Symptoms:
– Existing Document Sets no longer return a value for the „Document ID“ field.
– Custom solutions that read the Document ID now fail with exceptions.
– The issue is reproducible without custom code by opening:
/_layouts/15/DocIdSettings.aspx
– The page throws an InvalidDocumentIdProviderException.
The issue appeared immediately after applying the August 2026 CU and was not present before the update.
Can anyone else confirm this behaviour on SharePoint Subscription Edition farms patched to the August 2026 CU? Has Microsoft acknowledged this as a known issue or provided a workaround/fix?
Permalink
Hi Seu,
if this is a problem for you my recommendation would be to open a ticket with Microsoft support.
Cheers,
Stefan
Permalink
Hi Seu,
we have the behavior. Works on our prod farm but not on test with the latest update for August. In the ULS Logs there is this error:
Microsoft.Office.DocumentManagement.InvalidDocumentIdProviderException: Invalid document ID provider: Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, Microsoft.Office.DocumentManagement.Internal.OobProvider
at Microsoft.Office.DocumentManagement.DocumentId.GetProvider(Hashtable rootWebProperties)
at Microsoft.Office.DocumentManagement.Pages.DocIdSettings.UpdateControlStates()
at Microsoft.Office.DocumentManagement.Pages.DocIdSettings.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Permalink
I opened a Microsoft case to this issue!
Permalink
Hello In,
The Document ID issue following the August SharePoint CU has now been identified and resolved.
The CU introduced/enforced a new security restriction for Document ID provider assemblies through the farm-level AllowedDLCAssemblies allowlist.
Our Document ID provider uses:
Microsoft.Office.DocumentManagement, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
After installing the CU, this assembly was blocked because it was not present in AllowedDLCAssemblies.
The ULS logs confirmed the root cause:
Assembly ‘Microsoft.Office.DocumentManagement, Version=14.0.0.0…’ is not in the farm allowlist ‘AllowedDLCAssemblies’. Blocked.
This caused:
• The standard SharePoint DocIdSettings.aspx page to fail with InvalidDocumentIdProviderException.
• Document Sets to return a null Document ID.
• Our custom solution to subsequently fail with a NullReferenceException.
The issue was resolved by adding the Microsoft Document Management assembly to the farm allowlist:
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(
“AllowedDLCAssemblies”,
“Microsoft.Office.DocumentManagement, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
)
$farm.Update()
IISRESET
After applying this configuration, the Document ID service and our custom solution are working correctly again.
Best regards,
Hicham
Permalink
Hello Ziani,
We are seeing the same behavior in our environments. Does the PublicKeyToken stay the same in the script or do i have to find my own PublicKeyToken in my farm?
Permalink
Hi In/Alex,
this command work for us,
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(
“AllowedDLCAssemblies”,
“Microsoft.Office.DocumentManagement, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
)
$farm.Update()
IISRESET
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(
“AllowedDLCAssemblies”,
“Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
)
$farm.Update()
IISRESET
“”””””””””””””
After installing the CU, this assembly was blocked because it was not present in AllowedDLCAssemblies.
The ULS logs confirmed the root cause:
Assembly ‘Microsoft.Office.DocumentManagement, Version=14.0.0.0…’ is not in the farm allowlist ‘AllowedDLCAssemblies’. Blocked.
Permalink
Hi Ziani,
thanks for the confirmation and also Microsoft wrote me the same in the case I opened. It is exactly as you mentioned it, an entry is missing in the AllowedDLCAssemblies. I added the Version=15.0.0.0 (it is also fine to add both Version=15.0.0.0 und Version=14.0.0.0) and the Document-ID service working fine now.
BR Alex
Permalink
Hi! Probably it’s a migrated Site Collection? I had the same problem and updated the DocID provider assembly and class name:
Get-SPSite -limit all | ForEach-Object {
$site= $_
if( $site.ReadLocked -or $site.IsReadLocked -or $site.WriteLocked -or $site.ReadOnly ) {
write-host "Site ($($site.Url) is locked. Skip."
} else {
$rootWeb = $site.RootWeb
if( $rootWeb.AllProperties["docid_customProvider_assembly"] ) {
if( $rootWeb.AllProperties["docid_customProvider_assembly"] -like "Microsoft.Office.DocumentManagement*" -and
$rootWeb.AllProperties["docid_customProvider_assembly"] -notlike "*Version=16*" ) {
$rootWeb.AllProperties["docid_customProvider_assembly"] = "Microsoft.Office.DocumentManagement, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
$rootWeb.AllProperties["docid_customProvider_class"] = "Microsoft.Office.DocumentManagement.Internal.OobProvider"
$rootWeb.Update()
write-host "Site $($site.Url) patched."
} else {
write-host "Site $($site.Url) is already fine."
}
} else {
write-host "Site $($site.Url) has no DocID provider registered."
}
}
}
It’s only for SharePoint SE!
Regards
Ingo (MCM: SharePoint 2010)
Permalink
Hi Stefan,
Has the „DisableActorTokenAudienceValidation“ feature actually been fully implemented? The reason for my question is that the „DisableActorTokenAudienceValidation“ flag is no longer accessible.
Regards Georg
Permalink
Yes. This was removed in August CU.
Permalink
Hi Stefan,
Is it triggered by removing cache instance only?
I patched one SPSE farm with separate, single distributed cache server role without using script method and $true parameter.
Cache Host is up and running.
Kind Regards,
Kamil
Permalink
With August CU it is not possible to add a dcache server through server role conversion. Other functionality should not be affected.
Permalink
That’s an effect.
But what is triggering an issue in fact?
It is because of removing distributed cache instance? Or it’s an effect of August CU installation, no matter if you’ll decide to remove distributed cache instance or not at some point?
Kind Regards,
Kamil
Permalink
It is triggerd by changing the role of a server in the farm to include the dcache role.
Permalink
Hi Stefan,
Just to be sure, when applying a CU, before installing binaries and running psconfigui, we only stop (gracefully for ZDP) the DC service and not remove the DCache instance.
So in that scenario we shouldn’t run into this issue, correct?
Best Regards,
Richard
Permalink
Correct
Permalink
All right, thank you for the confirmation.
Matt’s comment may be somewhat confusing because it implies that the issue was triggered by removing the Distributed Cache service instance rather than by changing the server role.
That said, this doesn’t align with what I’ve seen after applying the August patches across several farms. Nevertheless, I trust your expertise and appreciate the clarification.
Thanks!
Permalink
Hi Kamil,
Just to clarify, this issue was first triggered for us when we removed the Distributed Cache and then tried to re add it (this is repeatable). We also saw the problem when trying to change server roles which we were attempting as a work around for the first issue. Neither are successful.
Kind Regards,
Matt
Permalink
Hi Stefan,
has the “DisableActorTokenAudienceValidation” parameter been removed from the current August CU update? Tried to set it to $false on our SPSE test farm, to test if its still needed to be disabled but the paramter isn’t there anymore. What I noticed is that the ServerDebugFlag 53534 isn’t needed anymore for the picture import.
BR Alex
Permalink
Correct. This issue was fixed and the flag should be reverted
Permalink
Hello Stefan,
Considering the issue reported by users about the Add-SPDistributedCacheServiceInstance command, would a manual CU installation (without removing the service instances and without using the script) still trigger the same problem?
Thanks for your great help !
Permalink
No. If the role is not changed this will not happen.
Permalink
Hello Stefan,
Thank you for your response.
Just to confirm: if we run your script with -ShouldGracefulStopDCache $true, we should not experience the issue, correct?
That is my understanding, but I would appreciate your confirmation.
Permalink
we see that securitytokenservice application have issues after the August CU applied:
An exception occurred when trying to issue security token: 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..
Permalink
Although there are already posts in the 2019 article, but for the sake of completeness I would like to ask about ‘SE’ here.
We also have critical applications that run with BCS and which are no longer usable after the August patch.
BCS type 'Nullable`1' in namespace 'System' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not in the 'BCSAllowedTypeNames' generic list. To permit this type, add entry 'Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|Namespace=System|TypeName=Nullable`1' to the 'BCSAllowedTypeNames' generic list.
The cmdlet
Enable-BdcmFileImport -Identity “{SiteCollectionUrl}” -Verbose
VERBOSE: Leaving BeginProcessing Method of Enable-BdcmFileImport.
VERBOSE: Leaving ProcessRecord Method of Enable-BdcmFileImport.
VERBOSE: Leaving EndProcessing Method of Enable-BdcmFileImport.
was unsuccessful. Therefore, the question. Is the only fix the following cmdlet?
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue('BCSAllowedTypeNames', 'Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|Namespace=System|TypeName=Nullable`1')
$farm.Update()
iisreset
kind regards
Sebastian
Permalink
Hi Sebastian,
yes – this is the correct way.
Cheers,
Stefan
Permalink
Thank you so much Sebastian for the workaround. It really helped us resolving the issue, otherwise it would be nightmare for our entire team. I dont see this workaround anywhere yet.. You saved our day !!!
We followed the below workaround.
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(‘BCSAllowedTypeNames’, ‘Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|Namespace=System|TypeName=Nullable`1’)
$farm.Update()
iisreset
Permalink
Hi Vishwa,
the behavior is the result of improved security. So what you applied is a solution and not a workaround.
For your reference:
https://blog.stefan-gossner.com/2026/08/14/trending-issue-bcs-type-is-not-in-the-bcsallowedtypenames-generic-list-after-august-2026-cu/
Cheers,
Stefan
Permalink
We patched, all good, no issues. Thank you! 🙂 People only mention bad situations but for us it worked fine.
Permalink
Hello Stefan,
Just to confirm: if we run your script with -ShouldGracefulStopDCache $true, we should not experience the issue about the Add-SPDistributedCacheServiceInstance command, correct?
That is my understanding, but I would appreciate your confirmation.
Best regards !
Ciro
Permalink
Yes, this is correct.
Permalink
Hi Stefan,
starting with the August CU we see the following Health Analyzer flagging one of our content DBs: “Remote event receivers without application identity are detected on one or more site collections.”
This is also listed under the improvements and fixes section of the KB500289: “Notifies that orphaned Remote Event Receivers (RERs) that do not have an app identifier will be blocked starting with the November 2026 Public Update. Use the Get-SPOrphanedRemoteEventReceiver cmdlet to identify affected RERs.”.
What we have not found yet is any information how to fix this / re-register the event receivers and link them with an application identity.
Can you give us some hint how we can prepare in advance of the November CU?
Thanks,
Timo
Permalink
Following up on this registering new event receivers is failing with an access denied error message already ahead of the November CU. So we are not solely in the ‘Notification’ phase.
Permalink
This is interesting to read. My issue with PnP that I wrote about below also concerns registering event receivers, using the Invoke-PnPQuery PowerShell command. What method are you using to register them? And do you also see the “the request is not from a browser” message in your ULS logs? Note that I had to increase the ULS log level to VerboseEx for “SharePoint Foundation” to get this log entry to appear.
Permalink
Hi Maurice,
we are using C# CSOM to register our event receivers but we also tried registering Add-PnPEventReceiver, but both fail with an Access Denied error. From the ULS we can see
“Adding a Remote Event Receiver Definition without an AppIdentifier is blocked”
So the Error Message is pretty clear.
Maybe i don’t get the KB-Article right and/or my research sklills are lacking, but i am not able to find out what we’re supposed to do in order to register event receivers successfully. Our already registered Event Receivers are working for now, but will eventually going to fail by November.
Looks like Microsoft is kindly asking us to migrate to something else as they broke the search recently, abondoned Office Online Server and now taking away event receivers and workflow. So maybe we can go ahead and use a fileshare as ultimately using SharePoint is (exaggerating) going to end up with feature-parity as everything is going away due to security risks / zero-days 🙂
Permalink
Hi Timo,
to allow me to dig into this, can you share the exact C# CSOM method you are using to register the remote event receiver where you get this error?
Cheers,
Stefan
Permalink
Hi Stefan,
thank you for following up on this – appreciate
Below is our code
<<<
foreach (var eventReceiverDefinition in eventReceiverDefinitions)
{
var newRER = new EventReceiverDefinitionCreationInformation();
newRER.EventType = eventReceiverDefinition.EventType;
newRER.ReceiverName = eventReceiverDefinition.ReceiverName;
newRER.Synchronization = eventReceiverDefinition.Synchronization;
newRER.ReceiverUrl = receiverHostName + eventReceiverDefinition.ReceiverUrl;
newRER.SequenceNumber = eventReceiverDefinition.SequenceNumber;
list.EventReceivers.Add(newRER);
}
list.Update();
ctx.ExecuteQuery();
We are connecting to the SharePoint Site using below code
<<<
clientContext = new ClientContext(sharePointSite.AbsoluteURL);
Would it be enough to register an App with AppRegNew.aspx and use this registration for the connection to allow to register the Receivers successfully?
Permalink
Hi Timo,
I have analyzed the issue and discussed my findings and your experience with the product group.
Here is the official answer to your question:
This behavior is by design as of the recent security update. Remote event receivers (RERs) registered without an add-in/app context are now blocked, because that registration path could allow a receiver to bypass item-level permission checks when it fires. As a result, registering a remote event receiver from a plain interactive user CSOM/PowerShell session is no longer supported — this is why your current code returns “Adding a Remote Event Receiver Definition without an AppIdentifier is blocked.”
The fix is to register the receiver so the call carries a valid app identity (AppIdentifier), by registering it through a SharePoint Add-in:
Register the receiver through a SharePoint Add-in:
Let the add-in provision the receiver at install time. It’s automatically stamped with the add-in’s app principal, so AppIdentifier is always set.
Example — declaring the receiver in elements.xml :
<?xml version=”1.0″ encoding=”utf-8″?>
<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>
<Receivers ListTemplateId=”101″>
<Receiver>
<Name>ItemUpdatingReceiver</Name>
<Type>ItemUpdating</Type>
<SequenceNumber>10000</SequenceNumber>
<Url>~remoteAppUrl/MyReceiverService.svc</Url>
<Synchronization>Synchronous</Synchronization>
</Receiver>
</Receivers>
</Elements>
Here ~remoteAppUrl is the token SharePoint automatically resolves to your provider-hosted add-in’s endpoint, and ListTemplateId=”101″ targets the document library (adjust the type/URL to match your scenario). When the add-in is installed, SharePoint provisions this receiver under the add-in’s identity — so AppIdentifier is populated and the registration is allowed.
Please note: the add-in that registers the receiver becomes its owner, so subsequent updates or deletion of that receiver must also be performed from the same app identity. This is expected and is part of the same protection.
Regarding PnP PowerShell — this is not a supported registration path, we recommend the add-in approach above.
Cheers,
Stefan
Permalink
I’d be very interested in learning how we can successfully register a new RER using an AppIdentifer in CSOM as well. I hope Stefan can point us to some developer documentation from Microsoft.
Permalink
Hi Maurice,
please have a look at the answer given here:
https://blog.stefan-gossner.com/2026/08/11/august-2026-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-85846
Cheers,
Stefan
Permalink
Me also.
Because we have a huge farm with a many many many custom implemented apps but also K2 Workflow Engine and third party apps which is registering Remote Event Receivers on new sites.
It is not documented by microsoft how to setup an remote event receiver with AppIdentifier.
Permalink
Hi Oliver,
please check the answer here:
https://blog.stefan-gossner.com/2026/08/11/august-2026-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-85846
Cheers,
Stefan
Permalink
Stefan,
I read the answer you received from the product group and I have to say I am honestly flabbergasted.
I know that it was announced that existing RERs created without an AppIdentifier would stop working starting with the November CU, but it was never communicated that registering new RERs would already be blocked starting with the August CU.
This change breaks many custom solutions as you can read from the reactions above.
I really wish MS would have introduced this blocking of new RERs in the November CU as well and not as soon as has happened now.
Permalink
@Stefan, i have a solution. I will explain later how we solved this problem. I have to buy some goods or my wife became angry.
Permalink
Hi Stefan,
After installing the August CU on our test SP SE farm, we noticed that some scripts that use the PnP 3.29 framework (specifically the Invoke-PnPQuery PowerShell command) no longer work and SharePoint returns a 401 Unauthorized response. In the ULS logs we see these entries:
Claims Windows Sign-In: Sending 401 for request ‘/_vti_bin/client.svc/ProcessQuery’ because the request is not from a browser.
Do you know of any new security measures in the August CU that prevent these requests from being processed?
Permalink
Hi Maurice,
PNP is not supported by Microsoft and not included in any test suite for CUs.
I’m not aware of a breaking change but if there is one the PNP community would have to look into this.
Cheers,
Stefan
Permalink
Hello Stefan,
First of all, the answer you gave to Timo is correct, in theory.
In practice, Remote Event Receivers were used in many situations. Especially in air-gapped environments with an Active Directory domain and accounts, Remote Event Receivers were installed by Administrators with Full Control permissions or by Service Accounts that have Full Control permissions on the web application or site collection level. Normal users do not have Full Control permissions in any way, except for their own MySite.
From a general app perspective:
I know there are a lot of SharePoint farms with custom web applications and implemented Remote Event Receivers connected to SharePoint. The authentication and authorization work in the context of an account that is used as an identity for Scheduled Tasks, Windows Services, or Application Pools in IIS. So these accounts are permitted by an administrator just like normal user accounts. But—and this is the point—these applications do not have an App Solution or a registered SharePoint App User on the Tenant, Site Collection, or Site level. The registration process is implemented via custom PowerShell scripts.
The decision of the SharePoint Product Group forces the implementation of the Provider-Hosted App (PHA) model in each custom app. But what they actually need is only the App Solution part of a PHA solution.
What does this mean?
To get or build an App Solution, you have to implement a PHA solution in Visual Studio using the SharePoint Add-in template.
You have to register a SharePoint App User in the farm with a unique ClientID (also known as AppID) and a unique name. You can also configure a secret, but I don’t know when to use it.
Well, the PHA uses OAuth authentication against SharePoint. In an air-gapped environment, there is no Azure Entra or ACS. Only an S2S (Server-to-Server) Trust is an option to create access tokens used for OAuth authentication.
To create an S2S Trust, it is strongly recommended to configure a Trusted Security Token Issuer in the SharePoint farm. For that, you need an X.509 PKI certificate with a private key.
In every environment, you have to create a certificate, a Trusted Issuer in the SharePoint farm, and a registered SharePoint App User.
The PKI certificate must be installed on each server hosting the custom application.
All this effort just to register a Remote Event Receiver in the context of a SharePoint App User instead of using accounts with Full Control permissions, just to assign an AppIdentifier to the Remote Event Receiver.
Ironically, to register a Remote Event Receiver in the context of the app, the SharePoint App User needs Full Control permissions on the Tenant, Site Collection, or Web level. To install the app, you need Full Control permissions on the Tenant or Site Collection level.
Now, to the interesting part of how we solved the problem in our environment:
We have a very large SharePoint environment with 12 Content Farms and 60k Site Collections. No user account has Full Control permissions on the Site level. Therefore, the installation of apps only works with a custom implementation of an App Store. The App Store has a background service implemented as a Windows Service, running in the context of a Service Account as the identity of that Windows Service. This Service Account has Full Control permissions on the web application level.
The App Store knows where to install the app.
The app installation involves two steps:
The first step is to upload the App Solution to the farm’s app catalog and install it on the site collection.
The second step is to execute custom PowerShell scripts containing installation and configuration details.
Since August 12th, we have been getting error messages like “UnauthorizedAccessException” when a Remote Event Receiver tries to connect to a list in SharePoint.
What we have done is create an Access Token for the Service Account running the background service.
You cannot configure the HTTP Request Header in CSOM or PnP connections.
So, we tried to implement the Remote Event Receiver registration directly against the REST API.
We implemented the body for the EventReceiverDefinition and converted it into a JSON string:
$body = @{
“__metadata” = @{
“type” = “SP.EventReceiverDefinition”
}
“ReceiverAssembly” = “”
“ReceiverClass” = “”
“ReceiverName” = “MyRemoteEventReceiverWithBearerToken”
“EventType” = 10003
“SequenceNumber” = 10004
“ReceiverUrl” = “https://myreceiverapp.contoso.com/Services/EventReceiver.svc”
“Synchronization” = 2
}
$jsonData = $body | ConvertTo-Json
Request the form digest for the executing account (Service Account) by using the Invoke-WebRequest function with the -UseDefaultCredentials parameter:
$contextInfoResponse = Invoke-WebRequest -Method Post -Uri $contexInfoUrl -Headers @{ “Accept” = “application/json;odata=verbose” } -UseBasicParsing -UseDefaultCredentials
$contextInfo = $contextInfoResponse.Content | ConvertFrom-Json
$formDigestValue = $contextInfo.d.GetContextWebInformation.FormDigestValue
Prepare List URI:
$listUri = “$siteUrl/_api/web/lists(guid’$listId’)/EventReceivers”
Prepare Request Header with the Access Token as an Authorization Bearer token:
$header = @{ “Accept” = “application/json;odata=verbose”
“Content-Type” = “application/json; odata=verbose”
“X-RequestDigest” = $formDigestValue
“Authorization” = “Bearer $accesstoken”
}
Execute the web request by using the Invoke-WebRequest function without the -UseDefaultCredentials parameter:
Invoke-WebRequest -Uri $listUri -Method Post -Headers $header -Body $jsonData -UseBasicParsing
Response:
StatusCode : 201
StatusDescription : Created
To tell the truth / To be honest:
Does the Remote Event Receiver have an AppIdentifier?
How can I detect if an AppIdentifier exists on the Remote Event Receiver?
Is the Remote Event Receiver still orphaned?
Technically, the access token for the Service Account was created by the SharePoint App User registered for our App Store application.
The Remote Event Receiver belongs to the custom app, which does not have an app solution or a SharePoint App User.
Once we finalize this solution, we will have solved a problem for thousands of app installations in our SharePoint environment.
However, this solution only solves the problems in our custom apps.
As a third-party solution, we are using the K2 Workflow Engine.
K2 has its own implementation for connecting Remote Event Receivers to lists.
There is one workflow implementation connected to hundreds of lists using a custom script that calls a special K2 function to connect K2 Remote Event Receivers to the list.
By the way, there is one critical aspect we must keep in mind: what about the fact that orphaned Remote Event Receivers without an AppIdentifier will be blocked starting this November?
If Microsoft enforces this block, our current workaround of registering them directly via the REST API using the Service Account’s Bearer token might just be a temporary band-aid. If a valid AppIdentifier is strictly required to prevent the RER from being blocked, we need a reliable way to check for its existence immediately. Otherwise, we risk a massive wave of silent failures across our environment in November.
Sincerely yours,
Oliver
Permalink
Hi Oliver, I have passed your feedback and questions to our product group.
Cheers,
Stefan
Permalink
Hi Oliver,
can you please open a support case for this issue and send me the SR number through private message using the “Contact the blog author” option at the top of this page?
We need it to create an official escalation of this topic with PG.
Thanks,
Stefan
Permalink
Hi Stefan,
I’ve submitted the support ticket.
Thanks.
Oliver
Permalink
Hi Oliver,
any feedback from microsoft yet?
Permalink
Hello Timo,
Yes, we received feedback from Microsoft.
As a short-term workaround, we are supposed to set the following debug flag:
Powershell:
$farm = Get-SPFarm
farm.ServerDebugFlags.Add(50008)
farm.Update()
Afterward, an IISReset needs to be performed.
However, performance issues were reported after setting the debug flag.
We are still analyzing these performance issues.
Connecting a Remote Event Receiver via PowerShell without an AppIdentifier works.
The Remote Event Receiver is executed successfully as well.
In the long run, however, this is an issue because Microsoft could not confirm whether this workaround will still work after November 2026.
In November 2026, all orphaned Remote Event Receivers will be blocked and will no longer be executed.
We solved the problem by connecting the Remote Event Receivers via the REST API.
In a provider-hosted app implementation, this is easily handled via an app installer implementation.
Here, you can have the ClientContext created with an App-Only access token and then register the Remote Event Receiver via CSOM.
However, if you connect the Remote Event Receiver via PowerShell like we do, you need to find a way to generate an access token.
Sincerely yours,
Oliver
Permalink
Hi Oliver,
You wrote “performance issues were reported” after implementing the debug flag. Can you elaborate? What kind of performance issues and in which area did you encounter these?
Permalink
Hello Maurice,
Some colleagues have reported that creating nine large document libraries with remote event receivers took approximately 2.5 hours.
However, they use a different deployment routine than we do for our apps.
Deploying our apps takes an average of two minutes.
This process involves creating the app solution as well as fields, content types, and lists.
Therefore, we have not observed any performance issues regarding the deployment of our apps.
Cheers,
Oliver
Permalink
We have 30 SharePoint farms using Windows integrated authentication, so no need for S2S high trust, since we successfully got rid of our (according to Microsoft) obsolete Provider-Hosted Add-Ins.
No way am I registering 30 SPTrustedSecurityTokenIssuer and creating a certificate for each one.
I will implement the event receiver in a farm solution, map the SPItemEventProperties to a RemoteEventProperties (which by the way has no internal Microsoft dependencies) and call our .svc endpoint.
Permalink
Hi Oliver,
Thank you for sharing your detailed findings. We are experiencing similar behavior in our SharePoint SE environment after applying the August 2026 CU, especially around Remote Event Receiver registration and execution.
I wanted to ask you specifically about the issues you are facing so we can compare our symptoms and validate whether our environments align:
What exact errors or failures did you observe when registering RERs after the August CU?
Did existing RERs also fail intermittently, or only newly registered ones?
After enabling the debug flag (50008), what performance issues did you encounter?
In your REST‑based registration approach, did you confirm whether the RER still appears orphaned or receives a valid AppIdentifier?
For third‑party integrations like K2, what specific failures or symptoms did you see?
Your insights will help us understand the full scope of the issue and prepare for the November enforcement.
Thanks again for sharing your experience — it’s extremely helpful.
Sincerely,
Chandra
Permalink
After the CU update my BCS Search Content Sources are unable to index and report this error in ULS:
Host ‘search-webservice.dev02.domain.com’ not in allowlist ‘SPAllowedOutboundHosts’ for property ‘ODataServiceUrl’ in OData based BCS flow. Add ‘search-webservice.dev02.domain.com’ to farm based generic allowlist: ‘SPAllowedOutboundHosts’ to allow usage of this host.
I have followed the instructions etc and have added the host however the issue persists.
This is the output from Powershell:
$farm = Get-SPFarm
$farm.GetGenericAllowedListValues(“SPAllowedOutboundHosts”)
search-webservice.dev02.domain.com
So all seems in order but the URL is still rejected.
Does anyone have a workaround?
Permalink
Hi Keegan,
did you restart all relevant services or the crawl machine to ensure that the new value is being used?
Cheers,
Stefan
Permalink
Hi Stefan,
Yes, this is now resolved. Restarting SP Search and IIS and the SPTIMERV4 was not enough, the only way I could get it to read the value was a server reboot. I’m sure there is a specific service that could have been restarted but all the obvious ones were done.
Thanks
Permalink
Hi Stefan
We have a new SharePoint Server Subscription Edition farm running the August 2026 CU, KB5002893.
SharePoint 2010 workflow initiation forms fail across all web applications on /_layouts/15/IniWrkflIP.aspx, displaying a message that session cookies are disabled.
Changing to false makes the forms work, but we do not consider this an acceptable permanent solution. We saw that this issue was reported with the July 2026 CU. Was it expected to be resolved by the August 2026 CU?
Permalink
Hi Eva,
I’m aware of a variety of issues with workflows in July CU – but this is not on my list.
Might be this was never escalated to Microsoft and therefor not addressed.
Please open a support case to ensure that this can be investigated.
Cheers,
Stefan
Permalink
Stefan,
Does this CU resolve the issue where Infopath forms display an error about session cookies? I know it was targeted for a fix this month, but I cannot find any notes on it.
Thank you for your help,
Alex
Permalink
Hi Alex, sorry – I am not sure.
Permalink
Hi Alex,
I had to solve this issue in my environment a while back. I fixed it by going into my web.config and changing httpOnlyCookies=“true“ to httpOnlyCookies=“false“. This may help you solve your issue.
Permalink
Is this issue relaed to Token Cache resolved ?
Token Cache: Failed to add token from distributed cache. Exception: ‚System.NotSupportedException: Specified method is not supported. at Microsoft.SharePoint.IdentityModel.SPSessionSecurityTokenHandlerV2.NotSupportedCookieTransform.Encode(Byte[] value) at System.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) at System.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(XmlWriter writer, SecurityToken token) at Microsoft.SharePoint.Administration.Claims.SPTokenCacheEntry.SerializeToken(SecurityTokenSerializer tokenSerializer) at Microsoft.SharePoint.IdentityModel.SPDistributedSecurityTokenCacheV2.Put(String key, Object value) at Microsoft.SharePoint.IdentityModel.SPSessionSecurityTokenHandlerV2.AddCachedTokenV1(String cachekey, SPTokenCacheEntry value)‘.
Permalink
This should be resolved with August 2026 CU.
Permalink
Sharepoint July SE farm with migrated Search Admin DB from Sharepoint 2019. Runnig the configuration wizard (GUI) results in an error:
Upgrade [SearchAdminDatabase Name=SP_Search] failed.
Exception: Cannot find the object ‘proc_MSS_GetCrawlErrorOrWarningCounts’, because it does not exist or you do not have permission.
(+Many more messages like that)
It seems a bunch of Stored Procedures are missing in that migrated search database. Others have commented on here: https://blog.stefan-gossner.com/2026/04/14/april-2026-cu-for-sharepoint-server-subscription-edition-is-available-for-download/
I am not willing or able to open a “Microsoft support ticket” at this time, i just leave a comment on here to confirm that this is still an issue.
Permalink
Hi Stefan,
After installing the August 2026 Cumulative Update for SharePoint Server, my Nintex Forms became inaccessible, and I’m getting an “Access Denied” error.
Does anyone have a workaround or solution for this issue?
Thank you.
Permalink
Hi Fadhila,
did you already contact Nintex for this issue?
Cheers,
Stefan
Permalink
Hi Stefan,
Hope you are doing Great 🙂
After installing the August 2026 CU for SharePoint Server Subscription Edition, we noticed that we are no longer able to add new Remote Event Receivers. Powershell give us this error while trying to adding a remote event receiver “Error: Exception calling “ExecuteQuery” with “0” argument(s): “Access denied. You do not have permission to perform this action or access this resource.”
Could you please confirm whether the August 2026 CU introduced any changes affecting Remote Event Receiver registration on SharePoint Onpremise?
Thank you for your guidance.
Regards,
Chandu
Permalink
Hi Chandu,
yes. See here for the explanation and correct implementation:
https://blog.stefan-gossner.com/2026/08/11/august-2026-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-85846
Cheers,
Stefan
Permalink
Why need to disabled WSS_Logging in SharePoint database whenever we do the patching?
Any methods or workaround for this step?
Thank you.
Permalink
Hi Justin,
sounds as if you are using SQL Server Always On.
I don’t know the exact technical limitations here but there are some conflicts between SQL Always On and this logging feature.
Cheers,
Stefan
Permalink
Hi, Stefen,
We have a brand new Sharepoint SE farm, we installed March patch, May patch successfully previously. But today after I installed Aug patch successfully, I got the foolwoing error when run configuration wizard:
Failed to initiate the upgrade sequence.
This is a critical task. You have to fix the failures before you can continue.
An exception of type Microsoft.Data.SqlClient.SqlException was thrown. Additional exception information: A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 – The target principal name is incorrect.)
Nothing changed including service account.
Any information related to this error?
thanks a lot!
Jing