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 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 July 2026 CU will be available at the following location in a couple of hours:
- KB 5002882 – July 2026 Update for SharePoint Server Subscription Edition
This is also a security update!
The download for July 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 July 2026 CU Build Number: 16.0.19725.20434
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
FYSA a little hidden gem in this KB:
Known issues in this update
After you run PSConfig, run the following PowerShell commands. This setting disables a defense-in-depth feature that is currently under development that may cause a regression. Existing actor token validation checks remain in place.
$farm = Get-SPFarm
$farm. DisableActorTokenAudienceValidation = $true #disables only the defense-in-depth validation
$farm.update ()
Permalink
Before I ran this, the workflows were failing with “not authorized”. SPWFM & client version 16.0.19725.20210.
Permalink
Hi Stefan,
Greetings of the Day!!
We have a SharePoint Subscription Edition farm with multiple roles (App, WFE, Search, Workflow).
Regarding the farm property DisableActorTokenAudienceValidation, do we need to run the script on every SharePoint server, or is running it once enough?
What are the consequences if some servers enforce audience validation while others do not?
Thanks,
Chandra
Permalink
Hi Chandra,
this is a setting on the SPFarm object which will be persisted in the configuration database.
Executing it on one server should be sufficient.
Cheers,
Stefan
Permalink
Hi Stefan,
Thanks for the information.
Just to reconfirm, if we do not set this property (i.e., leave Actor Token Audience Validation enabled), is there any functional impact on the farm such as workflow communication, OAuth tokens, or search components? Please advise.
Thanks,
Chandra
Permalink
Hi Stefan,
Thank you for confirming that the change only needs to be executed once on any server since it is stored on the SPFarm object.
As a follow‑up, could you please clarify the functional impact at the farm level if we do not set DisableActorTokenAudienceValidation? Specifically, would leaving the audience validation enabled affect Workflow Manager communication, OAuth tokens, or Search components in any way?
Thanks,
Chandra
Permalink
Hi Chandu,
sure – Office Online Server integration and SharePoint 2013 workflows (actually the communication between WFM/SPWFM and SharePoint) might fail.
Cheers,
Stefan
Permalink
Hello Stefan,
Hope you are Doing Great 🙂
We installed the July 2026 CU for SharePoint Server Subscription Edition, and we are encountering the known issue related to actor token audience validation that you documented.
As part of our remediation, we first ran PSCONFIG on all servers in the farm to ensure all binaries and configuration states were fully synchronized. After completing PSCONFIG across the farm, we applied the temporary workaround you recommended
$farm = Get-SPFarm
$farm.DisableActorTokenAudienceValidation = $true
$farm.Update()
Even after PSCONFIG and applying this workaround, we are still experiencing the same 403 Forbidden errors with our Workflow Manager workflows.
The ULS logs continue to show
“The app principal does not exist”
“Failed to initialize m_pSiteAppPrincipal”
“Un‑whitelisted client sent us an OAuth token”
CSOM/REST calls blocked with HTTP 403
Token cache write failures
Claim validation failures (appId and tenant claims empty)
The behavior did not change after PSCONFIG and setting DisableActorTokenAudienceValidation, so workflows continue to fail.
Can you please confirm if the workaround must be applied on every farm server, or if an additional step (such as an IIS reset, farm restart, or re-registering Workflow Manager OAuth tokens) is required for the setting to take effect?
Thank you for documenting this known issue — any additional guidance would be greatly appreciated.
Thanks !
Regards,
Chandu
Permalink
Hi Chandu,
the workaround only needs to be applied on a single server in the farm, as it modifies a farm-level property that exists only once across the entire farm.
That said, the symptoms you’re describing appear to be different from the behavior affected by this property — particularly the “app principal does not exist” error.
Given that, I would recommend opening a support ticket with Microsoft so the issue can be investigated in more detail and the root cause can be properly identified.
Cheers,
Stefan
Permalink
Hi,
After installing july 2026 patches, there is again an issue with SharePoint Designer custom forms.
Error in ULS logs is
Unsafe control=Microsoft.SharePoint.WebPartPages.DataFormParameter, Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c for having property traversal char in attribute value.
Resolution is to add web.config entry
Is this new security feature, or was it added to disable SharePoint Designer support?
Permalink
Web.config entry:
Permalink
Hi Robi,
after June/July 2026 CU you need to apply this additional setting:
PS:> $f = Get-SPFarm
PS:> $f.PreserveAttributeConsistency = $false
PS:> $f.update()
PS:> IISRESET
Regarding the web.config entry – please post it by replacing angular brackets with []
Cheers,
Stefan
Permalink
[SafeControl Assembly=”Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” Namespace=”Microsoft.SharePoint.WebPartPages” TypeName=”DataFormParameter” Safe=”True”
AllowPropertiesTraversal=”True” /]
Permalink
From what I have tested, if web.config key is present, there is no need for $f.PreserveAttributeConsistency = $false
creating forms works.
Permalink
it removes Web.config entry when posting
you can find it at
https://r0b3r70.com/2026/07/15/fixing-sharepoint-designer-errors-july-2026-cu/
Permalink
After the July 2026 CU for subscription edition we did see issues with our custom applications, editing the DisableActorTokenAudienceValidation resolved that issue. However, I now noticed that Nintex forms are broken. Has anyone else seen that issue. Could that be fixed by with the fix I see listed here for the designer forms issues?
Permalink
Hi Bob,
I don’t know how Nintex Forms are implemented and if they are in any way related to the forms configured with SharePoint Designer 2013.
My suggestion would be to contact Nintex on this.
Cheers,
Stefan
Permalink
Hi Stefan,
would you be able to share in more detail what this does “DisableActorTokenAudienceValidation”
Thank you
Permalink
Hi Robi,
my understanding is, that this is an artefact of an unfinished functionality which is planned for a future release.
As the functionality is not finalized it should be disabled for now to ensure that it does not cause problems.
Cheers,
Stefan
Permalink
PS:> $f = Get-SPFarm
PS:> $f.PreserveAttributeConsistency = $false
PS:> $f.update()
PS:> IISRESET
is this also wild for sharepoint 2016 on -prem?
Permalink
Hi Luca,
instead of these command try first if the issue is resolved by adding the following entry to the web.config:
<SafeControl Assembly=”Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” Namespace=”Microsoft.SharePoint.WebPartPages” TypeName=”DataFormParameter” Safe=”True”
AllowPropertiesTraversal=”True” />
Cheers,
Stefan
Permalink
After this update, I’m still having issues after a reboot with the crawl hanging and the Search Topology not displaying. I have to restart the SharePoint Search Host Controller service on the server to clear it up. (I tried changing the service to Automatic (Delayed Start), but no change.) Is there a fix for this?
Permalink
Marlene, could you please share more details about your issue? I think I am experiencing those too.
Permalink
Hi all. Did you sort this issue? Have you found out if it was linked to the patching or not?
Permalink
It was 1st reported after the May update. I’m running server 2022. Here is the May article conversation. https://blog.stefan-gossner.com/2026/05/12/may-2026-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-63503
Permalink
Can we skip the June 2026 CU and install the July 2026 CU or, because there was a feature update in the June 2026 CU, must we install the June CU and then the July CU?
Permalink
Hi Alex,
SharePoint fixes are cumulative. You never need to install an intermediate fix. The most recent one includes all the previous fixes and feature updates.
Cheers,
Stefan
Permalink
Since installing the update I am seeing the following critical error:
w3wp.exe: All query processing components are in ‘Failed’ status.
Search config all looks ok in Central admin though. Is anyone else seeing a similar issue?
Permalink
Hi Stefan,
Good day! If the the current environment is running August 2025 CU, does the “Fix-SeptemberCU-Permission-Problem.ps1” still have to be run? If so, does it have to be run before or after applying the July 2026 patch?
Permalink
Hi Adrian, no – it is only required if September 2025 CU was installed. If you skip it – no action required.
Permalink
Thanks.
Permalink
Not sure if the July security patch fix the problem of workflow start failed issue.
Permalink
Hi Tong,
the problem introduced in June 2026 CU was fixed with July CU.
You might still have to allow list certain types depending on the specific workflow actions in use by your workflows.
See here for details:
https://blog.stefan-gossner.com/2026/07/17/trending-issue-sharepoint-2010-workflows-are-failing-after-installing-july-2026-cu/
Cheers,
Stefan
Permalink
Hi Stefan,
I am running into an issue while applying a patch using your Install-SPSE_Fix PowerShell script and was wondering if you could help look into it.
Environment & Details:
Farm Build: February build
Account: Farm Setup Account
Script Behavior: The script runs properly at first—it successfully stops the services and starts them back up as expected.
IIS Status: I confirmed that IIS remains up and running during the patch installation.
Issue:
After running for about 20 to 30 minutes, the installer stops and throws Error 1603.
(Note: The long execution time itself is expected in our environment, but the process fails at the end with error 1603).
Any insights or guidance on what might be causing this error would be greatly appreciated!
Thanks in advance!
=======
A part of the log file:
MSI (s) (58:68) [15:36:46:530]: Product: Microsoft SharePoint Server Subscription Edition Core – Update ‘Security Update for Microsoft SharePoint Server Subscription Edition (KB5002882)’ could not be installed. Error code 1603. Additional information is available in the log file C:\Users\userAcoount\AppData\Local\Temp\sts-x-none_MSPLOG.LOG.
MSI (s) (58:68) [15:36:46:532]: Windows Installer installed an update. Product Name: Microsoft SharePoint Server Subscription Edition Core. Product Version: 16.0.14326.20450. Product Language: 0. Manufacturer: Microsoft Corporation. Update Name: Security Update for Microsoft SharePoint Server Subscription Edition (KB5002882). Installation success or error status: 1603.
MSI (s) (58:68) [15:36:46:532]: Note: 1: 1729
MSI (s) (58:68) [15:36:46:532]: Product: Microsoft SharePoint Server Subscription Edition Core — Configuration failed.
MSI (s) (58:68) [15:36:46:532]: Windows Installer reconfigured the product. Product Name: Microsoft SharePoint Server Subscription Edition Core. Product Version: 16.0.14326.20450. Product Language: 0. Manufacturer: Microsoft Corporation. Reconfiguration success or error status: 1603.
Property(S): ERRORNEEDASPNET = ASP.NET must be installed before installing this product.
Property(S): ERRORNEEDIIS6PLUS = Microsoft Internet Information Server (IIS) 6.0 or greater must be installed before installing this product.
Property(S): mmode_Ref = mmode_Ref
Property(S): CannotConvertText = This option is not available for the product you currently have installed. Click OK to return to the Maintenance Mode Options dialog and make a different selection. Note that you may need to uninstall the current product before installing a different one.
Permalink
Hi Mounir,
if you run the script as administrator it should have the permissions to stop the w3svc service.
It might be that there are some policies on your machine which restrict what the local administrator can do.
In this case my advise would be to stop IIS before.
Don’t get confused by the property messages. These are just checks done. The log file contains everything that was checked and they do not indicate that the check actually failed.
The 1603 error indicates that you might have run into the issue that is fixed by the script in the blue box at the top of this article:
https://aka.ms/stefangossner/Fix-SeptemberCU-Permission-Problem.ps1
Cheers,
Stefan
Cheers,
Stefan
Permalink
Hi Stefan,
Thanks! I’ve tried the following steps:
Running PowerShell as administrator
Stopping IIS before running the script (based on some search results)
I haven’t installed the September patch, as this is a new farm built in February 2026.
Permalink
Hi Stefan
Here is how I can install the patch:
Clear the contents of …\AppData\Local\Temp.
Install the June Patch and run PSConfig.
Download and install the new patch file, then run PSConfig
Cheers
Permalink
Hi Stefan.
Did you ever received any issue with the Distributed Cache after applying that CU.
Since we did, the user SessionToken can’t be put within the Distributed Cache with the following message in ULS, meaning only the WeakCache is used on each front ends as main consequence all users have to reauthenticate each time their web browser reach a different WFE:
Session cookie transform was triggered unexpectedly. This path should not be reached in normal operation. To disable this protection, set the farm property ‘SessionCookieTransformProtectionEnabled’ to false.
So, after applying the following setting:
$farm = Get-SPFarm
$farm.Properties[“SessionCookieTransformProtectionEnabled”] = $false;
$farm.Update()
Then user SessionToken can be stored within the Distributed Cache but after the initial authentication on one WFE, the following request on the other WFEs the following error occurs:
Unexpected error occurred in method ‘GetObject’ , usage ‘Distributed Logon Token Cache’ – Exception ‘System.NotSupportedException: Specified method is not supported.
at Microsoft.SharePoint.IdentityModel.SPSessionSecurityTokenHandlerV2.ReadToken(XmlReader reader)
at System.IdentityModel.Tokens.SecurityTokenHandlerCollection.ReadToken(XmlReader reader)
at Microsoft.SharePoint.Administration.Claims.SPTokenCacheEntry..ctor(SerializationInfo info, StreamingContext context)
at ReadSPTokenCacheEntryFromXml(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] )
at System.Runtime.Serialization.ClassDataContract.ReadXmlValue(XmlReaderDelegator xmlReader, XmlObjectSerializerReadContext context)
at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator reader, String name, String ns, Type declaredType, DataContract& dataContract)
at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator xmlReader, Type declaredType, DataContract dataContract, String name, String ns)
at System.Runtime.Serialization.DataContractSerializer.InternalReadObject(XmlReaderDelegator xmlReader, Boolean verifyObjectName, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.XmlObjectSerializer.ReadObject(XmlDictionaryReader reader)
at Microsoft.SharePoint.DistributedCaching.SPDistributedCacheUtils.ByteArrayToObject[T](Byte[] Buffer)
at Microsoft.SharePoint.DistributedCaching.SPDistributedCacheUtils.PostProcessData[T](Byte[] secretKey, Object cachedObject, Boolean bDecrptyData, SPDistributedCacheTelemetryData teleData)
at Microsoft.SharePoint.DistributedCaching.SPDistributedCacheUtils.PostProcessData[T](Byte[] secretKey, Object cachedObject, Boolean bDecrptyData)
at Microsoft.SharePoint.DistributedCaching.SPDistributedCache.GetObject[T](String key)’.
If you have a look on ReadToken methods of the Microsoft.SharePoint.IdentityModel.SPSessionSecurityTokenHandlerV2 class, some of them seems to be not implemented by raising a Not Supported Exception and they override the implementation of System.IdentityModel.Tokens.SessionSecurityTokenHandler.
For information, ou web applications are using a Trusted Identity Provider which was working perfectly fine before that CU.
Thank you in advance for your feedback.
Regards
Permalink
Hi Vladimir,
I have not seen this. My suggestion would be to open a support case with Microsoft to ensure this is properly investigated.
Cheers,
Stefan
Permalink
Hi Stefan / Vladimir,
We are experiencing the same problem and have a support ticket out. Apparently this issue is now raised with teh product group.
Interestingly, we do not have the SessionCookieTransformProtectionEnabled value in our property bag (certainly not there after July CU)
Greg
Permalink
Hi Stefan,
We get in touch with Adam Sorenson then published that blog post regarding to that issue: — removed —
Permalink
Hi Vladimir,
the workaround in this article is very dangerous and the SharePoint product group requested to have this link removed.
This setting must not be used as it will expose the servers to significant security risk.
In case you applied it: it is recommended to revert this change asap.
Cheers,
Stefan
Permalink
We have the same error.
07.24.2026 11:05:28.27 w3wp.exe (0x3818) 0x21A4 SharePoint Foundation Claims Authentication axu98 Unexpected Session cookie transform was triggered unexpectedly during encode. This path should not be reached in normal operation. To disable this protection, set the farm property ‘SessionCookieTransformProtectionEnabled’ to false. 54552aa2-ea3e-9003-2ae1-bab6ae66484c
07.24.2026 11:05:28.27 w3wp.exe (0x3818) 0x21A4 SharePoint Foundation DistributedCache aa6e7 Unexpected Unexpected error in ObjectToByteArray – Exception ‘System.NotSupportedException: Specified method is not supported. at Microsoft.SharePoint.IdentityModel.SPTokenCache.NotSupportedCookieTransform.Encode(Byte[] value) at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(XmlWriter writer, SecurityToken token) at Microsoft.IdentityModel.Tokens.SecurityTokenSerializerAdapter.WriteTokenCore(XmlWriter writer, SecurityToken token) at Microsoft.SharePoint.Administration.Claims.SPTokenCacheEntry.SerializeToken(SecurityTokenSerializer tokenSerializer) at Microsoft.SharePoint.Administration.Claims.SPTokenCacheEntry.GetObjectData(SerializationInfo info, StreamingContext context) at System.Runtime.Serialization.XmlObjectSerializerWriteContext.GetObjectData(ISerializable obj, SerializationInfo serInfo, StreamingContext context) at System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteISerializable(XmlWriterDelegator xmlWriter, ISerializable obj) at System.Runtime.Serialization.ClassDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context) at System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteDataContractValue(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle) at System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithoutXsiType(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle) at System.Runtime.Serialization.DataContractSerializer.InternalWriteObjectContent(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver) at System.Runtime.Serialization.DataContractSerializer.InternalWriteObject(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver) at System.Runtime.Serialization.XmlObjectSerializer.WriteObjectHandleExceptions(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver) at System.Runtime.Serialization.XmlObjectSerializer.WriteObject(XmlDictionaryWriter writer, Object graph) at System.Runtime.Serialization.XmlObjectSerializer.WriteObject(Stream stream, Object graph) at Microsoft.SharePoint.DistributedCaching.SPDistributedCacheUtils.ObjectToByteArray(Object obj)’. 54552aa2-ea3e-9003-2ae1-bab6ae66484c
Permalink
Yes – our product group is currently investing the issue and are also testing possible workarounds which will allow to mitigate the issue without exposing the servers to critical security risks.
Permalink
Not All Heroes Wear Capes.
Permalink
Thank you for the update, Stefan. We are also seeing the same issue affecting our users. We appreciate that the product group is investigating this and hope Microsoft can provide a safe workaround as soon as possible.
Permalink
Hi Stefan,
Just wondering if there’s any update on this? Have you heard anything new from Microsoft product group?
Permalink
Hi Jey,
not yet.
Cheers,
Stefan
Permalink
Any update on this ?
Permalink
A fix for this is planned to be including in the upcoming August 2026 CU.
Permalink
The fix for below Known issue from July 2026 CU is described as “Fixes an issue in which Distributed Cache (DCache) does not work after the July 2026 Public Update is installed” in August 2026 CU that’s released yesterday ?
“Customers in multi-front-end SharePoint farms with Trusted Provider or Forms authentication may face repeated authentication prompts or multiple sign-ins. This should not impact customers who have configured farms with Windows authentication. As a mitigation, configuring sticky sessions on the reverse proxy will address the majority of scenarios. Microsoft is working on a fix in the subsequent product update. While disabling SessionCookieTransformProtectionEnabled may appear to work around the issue, Microsoft does not recommend it. This setting safeguards authentication and turning it off can expose the farm to security vulnerabilities.”
Permalink
August CU should fix it. The fix was checked in for all products versions (SP2016, SP2019, SPSE)
Permalink
Hi,
there is an issue in July 2026 patches, where when you want to open workflow status page, it wrongly encodes { } and guid for workflow instance id:
{d36682d4-aa45-4de7-acbc-242f56ac7363}
is formatted as:
%257bD36682D4%252dAA45%252d4DE7%252dACBC%252d242F56AC7363%257d
and it throws error
Invalid WorkflowInstanceID parameter in URL.
if you manually copy instance id from workflow history list to url, then you can open workflow status page
Permalink
Yep, experiencing the same issue as Robi
Permalink
Hi Stephan,
Has anyone found the solution to this issue?
FYI SharePoint is showing the wrong link for both new and existing workflow entries.
Cheers.
Graham.
Permalink
Were you able to fix this ? I am getting the same errors.
Permalink
We found this Microsoft work around which is working
https://support.microsoft.com/en-us/servicing/office/update/2026/july-known-issues
Cheers.
Graham.
Permalink
Stephan,
I am on Sp2016 Test Farm.
I added the below to the web.config and SPD could not connect to the site. I then rolled back those changes, verified SPD could open the site, and executed ‘$farm.Properties[“PreserveAttributeConsistency”] = “False”..
I still have the original problem, verified via uls log errrors. Is there a step I am missing?
[] to the web.config and conducted IISReset
Permalink
Hi Peggy,
did you also apply this change:
PS C:> $farm = Get-SPFarm
PS C:> $farm.AddGenericAllowedListValue(“AllowedTagPrefixesWhichAreNotWebControlsList”, “xsl:template”)
PS C:> $farm.Update()
This is required to fix the problem introduced in January 2026 CU.
The PreserveAttributeConsistency should not be required if this entry is in the web.config:
<SafeControl Assembly=”Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” Namespace=”Microsoft.SharePoint.WebPartPages” TypeName=”DataFormParameter” Safe=”True”
AllowPropertiesTraversal=”True” />
Cheers,
Stefan
Permalink
Stefan,
Thank you for your response.
I executed the below and I am still getting the errors referencing :[ Re-definition of tag found, maintaining consistency of
attributes across duplicate tags for security. To bypass validation, disable farm property ‘PreserveAttributeConsistency’]. I verified [‘$farm.Properties[“PreserveAttributeConsistency”] = “False”]
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(“AllowedTagPrefixesWhichAreNotWebControlsList”, “xsl:template”)
$farm.Update()
Permalink
Hi Peggy, this message is expected and not indicating a problem.
Cheers,
Stefan
Permalink
SharePoint SE – Unknown SQL Exception 18452 occurred. Login failed.
Hello Everyone,
I am troubleshooting an authentication/connectivity block on our newly migrated SharePoint Server Subscription Edition (SE) farm. The farm was deployed last month using the May 2026 baseline files, and we are running a NTLM environment.
Our Architecture (MinRole):
WFE Server: Front-end with Distributed Cache role.
APP Server: Application with Search role.
DB Server: SQL Server.
The Problem:
Last month we applied Windows OS updates to all the servers and the site was down.
This month we applied OS updates to the DB Server. Site was up. Then we applied OS Updates to App server, site went down and we reverted it. Then we applied OS updates on WFE server. The site is up. However, in WFE the SharePoint Caching Service stopped running.
When running Get-SPFarm or running PSConfig on the WFE, it throws the following errors:
PowerShell / PSConfig: “Cannot access the local farm. Verify that the local farm is properly configured…”
Configuration Wizard: “Failed to detect if this server is joined to a server farm.”
The Error Logs:
Checking the Windows Event Viewer on the WFE during a database connection attempt shows:
Unknown SQL Exception 18452 occurred.
Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.
What We Have Verified So Far:
Network connectivity is fully operational: Test-NetConnection from the WFE to SQL Port returns TcpTestSucceeded : True.
AD Domain trust is healthy: Test-ComputerSecureChannel on the WFE returns True.
Local machine groups are clean: NT AUTHORITY\SYSTEM is not present inside the local WSS_WPG or IIS_IUSRS groups.
DisableLoopbackCheck is already set to 1 in the registry.
The key LmCompatibilityLevel was completely missing from HKLM:\SYSTEM\CurrentControlSet\Control\Lsa. We tried manually creating it as a DWORD and setting it to 3 (to force NTLMv2), followed by a Netlogon restart and iisreset, but the SQL 18452 Untrusted Domain error persists. Reverted it as we are still getting the same error.
Current Farm State:
If we run (Get-SPFarm).Status directly on the APP Server(NO OS updates), it returns Online and can see the database fine. The block is localized strictly to the newly updated WFE server.
Any help on how to get the error is greatly appreciated.
Permalink
Hi Susan,
it really looks as if there is a problem with AD from the error message:
“Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.”
The other errors are most likely caused by the fact that the authentication to SQL fails.
My recommendation would be to open a ticket with Microsoft focusing on this authentication problem to ensure that the support case reaches the correct team.
SharePoint is most likely just a victim here and raising the case against SharePoint might cause delays in problem resolution.
Cheers,
Stefan
Permalink
Thank you for the reply. I will open a ticket with Microsoft.
One quick question: Since LmCompatibilityLevel = 3 didn’t bypass this new July 2026 security hardening block on the WFE, is anyone aware of any other specific registry flags that Microsoft introduced in the mid-2026 security baselines that forcefully strips domain metadata from local service accounts?
Thanks again.
Permalink
Surprisingly the issue happened after OS updates.
Permalink
This matches my earlier response that SharePoint is just a victim here.
Cheers,
Stefan
Permalink
Hi Susan,
please verify if it is related to this kerberos related OS change:
https://blog.stefan-gossner.com/2026/04/23/trending-issues-kerberos-failures-in-sharepoint-and-other-applications-starting-april-2026/
Cheers,
Stefan
Permalink
Our environment uses NTLM.
Permalink
Hi Susan,
I hope you’ve solved the problem. I encountered a SQL 18452 Untrusted Domain error with one of my clients. The problem was this: I had installed SQL Server using an Active Directory account with local administrator privileges (e.g., spsql_admin). During the installation, SPN records were being created in the AD object belonging to the SQL Server Engine service account (e.g., spsql_engine) using the privileges of the account I used for the installation (spsql_admin). However, I realized that due to the security hardening implemented by the AD administrator on the DC, my “spsql_admin” account was unable to correctly create the SPN records for the “spsql_engine” AD object. I was getting this error when connecting to the SQL Server from SSMS on another server. Afterwards, I temporarily granted Domain Admin privileges to the “spsql_admin” account for use during the installation and was able to connect to the SQL Server easily from other servers. I would like to ask you to check the SPN records for your SharePoint Setup account, your SharePoint Farm Service account (not the SharePoint Service account!), and the account you use for the Engine service in SQL Server. If you wish, I can share examples of SPN records from a running production environment.
Note to Stefan: If you think that I am misleading Susan or providing incorrect/incomplete information, could you please delete this post?
Permalink
Thanks for providing this information. Unfortunately, the issue still exists. Could you let me know if you are using Kerberos or NTLM authentication?
Permalink
NTLM
Permalink
Hi Stefan,
After installing the July 2026 CU for SharePoint Server Subscription Edition, we started experiencing issues with Business Data Connectivity (BDC) fields that are backed by a custom WCF service.
A few observations:
The BDC Service Application is accessible and appears healthy in Central Administration.
The external content type and BDC model were working correctly before the CU installation.
Existing BDC values are still displayed correctly in Display/View Forms.
However, when opening an item in Edit Form, the BDC fields fail to load.
The Entity Picker no longer returns any results and displays the following error:
“Business Data Connectivity is configured incorrectly. Administrators, see the server log for more information.”
The issue affects lookups and entity resolution only. Previously saved values can still be viewed, which suggests the metadata and stored values remain intact, but runtime retrieval from the external system is failing after the July 2026 CU.
Have you seen any similar BDC/WCF-related issues after the July 2026 CU, or are there any known changes that could affect Entity Picker functionality while leaving the BDC Service Application itself operational?
Permalink
Hi Mo,
sorry – just saw this comment.
What was the previous CU you upgraded from?
Cheers,
Stefan
Permalink
Hi Stefan. We have the same issue. All WCF connection in BCS are failing to connect to cannot create a new connections with WCF webservices. We did install June CU prior and We now installed July CU as well. We are on SharePoint Server 2016
Permalink
Hi Navin,
I would recommend to analyze the ULS log for specific problems.
Cheers,
Stefan
Permalink
Hi Stefan, how are you?
I installed the latest July patch on my SharePoint SE farm.
I’m experiencing 3 problems:
1- the 2013 workflows don’t work, they keep retrying;
2- SharePoint Designer crashes unexpectedly when selecting people or groups;
3- And the third issue is that in the modern view, the content appears blank…
Permalink
Hi Luis,
the first issue can happen if the script in the known issue section of the July CU fix has not been executed.
The others are not known issues and my recommnedation would be to open two separate support cases for these individual issues if you need assistance to get them analyzed and resolved.
Cheers,
Stefan
Permalink
Hi Stefan, After Installing July 2026 CU the SharePoint 2016 with .net applications are very slow, Can you help on this?
Permalink
Hi Suresh,
sorry – this is very generic information and it is also not clear what “SharePoint 2016 with .net applications” means.
Cheers,
Stefan
Permalink
Hi Stefan,
We have encountered a serious issue after applying the July 2026 CU to SharePoint 2019 in a farm using Forms Based Authentication (AspNetSqlMembershipProvider).
Existing FBA users can continue to log in successfully.
However:
Newly created FBA users cannot log in.
Users whose passwords are reset can no longer log in.
ULS logs show:
Membership Provider ‘AspNetSqlMembershipProvider’ username/password check failed
and
The security token username and password could not be validated.
We verified that:
The users exist in the ASP.NET membership database.
PasswordFormat = 2 (Encrypted) for both working and failing users.
IsApproved = 1 and IsLockedOut = 0.
Existing users and newly reset users have the same password format and salt characteristics.
The issue started immediately after applying the July 2026 CU.
The Web.Configs for STS, WebApp, Central Admin are ok.
Any suggestions?
Permalink
Hi Paul,
has the script from the “Known Issues” section of the July 2026 CU KB Article been executed?
Cheers,
Stefan
Permalink
Yes, we disabled the SessionCookieTransformProtectionEnabled but we have the same issue.
The scenario mentioned in the “Know issues in this update” section about Forms Based Authentication is not same scenario. The issue is also happing on DEV servers which is a single server farm. Making this false on DEV does not resolve our issue for users who are registered new or have reset their password after the patch.
Permalink
Hi Paul,
I think Stefan mean DisableActorTokenAudienceValidation part, not SessionCookieTransformProtectionEnabled . As the article describe SessionCookieTransformProtectionEnabled setting is not recommended.
Permalink
👍
Permalink
Thanks Hasan. We are running under SharePoint 2019 version which doesn’t have this property .
Permalink
Hi Paul,
indeed SP2019 does not have this property – but the issue present in SPSE which is resolved by changing this property also does not exist in SP2019.
So it is not the same issue.
Cheers,
Stefan
Permalink
Hi Team, We are getting Access denied error with existing JSOM code after install SharePoint subscription July CU. errors are like „Handling access denied for non browser request. IsOAuth: ‚False‘. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)), StackTrace: at Microsoft.SharePoint.SPWeb.ValidateFormDigest() at Microsoft.SharePoint.Client.SPClientServiceHost.ValidateFormDigest(HttpContext context) at Microsoft.SharePoint.Client.SPClientServiceHost.OnBeginRequestInternal() at Microsoft.SharePoint.Client.SPClientServiceHost.OnBeginRequest()
Permalink
Hi Vincent,
this seems to be something new.
My recommendation would be to open a support case with Microsoft to get this analyzed.
Cheers,
Stefan
Permalink
Thank you, Stefan. I have already opened a Microsoft support case. We observed that after applying the patch, requests for custom CSS and JavaScript files result in a “too many redirects” error.
I have not received a response from Microsoft Support since yesterday. I will share an update once we receive a resolution.
Permalink
Following the installation of the July 2026 CU on multiple SharePoint SE farms, we noticed that requests for the AppWebProxy.aspx site include additional HTTP headers.
Content-Security-Policy: frame-ancestors ‘self’ teams.microsoft.com *.teams.microsoft.com *.skype […]
X-Frame-Options: SAMEORIGIN
Both of these headers are unexpected. They prevent our Provider-hosted Add-ins from loading. The Developer Tools console now contains the following errors:
Framing ‘https://apps-generated-app-id.dnszone.company.ch/’ violates the following Content Security Policy directive: “frame-ancestors ‘self’ teams.microsoft.com […]”. The request has been blocked.
I was able to get rid of this error and the Content-Security-Policy header in the responses by switching the flag EnableCSPHeaderForPage on the SPFarm object as described here: https://blog.stefan-gossner.com/2024/03/12/control-content-security-policy-header-for-sharepoint-pages/
However, the second response header header now causes an error:
Refused to display ‘https://apps-generated-app-id.dnszone.company.ch/’ in a frame because it set ‘X-Frame-Options’ to ‘sameorigin’.
Since we observe this behaviour on five farms, I can hardly imagine that all of those farms are misconfigured. Therefore, I assume this behaviour was changed with the July 2026 CU. Is this already under investigation on your side?
Permalink
Hi Paul,
this indeed sounds like a problem that should be investigated.
Please open a ticket with Microsoft Support to investigate if there is a workaround or if a fix is required.
Cheers,
Stefan
Permalink
Hi Stefan
Thank you for your response at this late time; I appreciate that. We will proceed as you suggested.
Cheers,
Paul
Permalink
Hi Paul
The same problem was discovered on my SP SE farm.
Have you had any response from Microsoft on that? I’m wondering if this is something that can be fixed by workaround or it was implemented as a patch for vulnerabilities and it is by design.
With this info I would know how to talk with client application that uses iFrames.
Regards,
Zygmunt
Permalink
Hi Zygmunt — here is the fix for:
Framing ‘https://apps-generated-app-id.dnszone.company.ch/’ violates the following Content Security Policy directive: “frame-ancestors ‘self’ teams.microsoft.com […]”. The request has been blocked.
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(„AllowIframeAppAuthorizePageDomains“,““)
$farm.AddGenericAllowedListValue(„AllowIframeAppAuthorizePageDomains“,““)
…
$farm.Update()
The above FQDN(s) can be wildcarded… After applying this, restart the IIS app pool on the Web Front Ends to get it into effect immediately.
Permalink
Sorry, blog ate everything inside of my greater-than and less-than signs in the previous post. Fixed:
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(“AllowIframeAppAuthorizePageDomains”,”{FQDN-of-one-of-your-Web-Apps}”)
$farm.AddGenericAllowedListValue(“AllowIframeAppAuthorizePageDomains”,”{FQDN-of-another-one-of-your-Web-Apps}”)
…
$farm.Update()
Permalink
HI Stefan,
Microsoft documentation has noted at July update:
“If you’re currently running SharePoint Workflow Manager, you must install SharePoint Workflow Manager (KB5002799) to your farm before you install this cumulative update.”
It is november 2025 update.
We have installed newest one 16.0.19725.20210.
Should we really reinstall to the erlier version?
Permalink
Hi Adam,
the documentation is misleading here.
You need to have at least this version installed. Newer or latest version is of course recommended.
Cheers,
Stefan
Permalink
Hello Stefan.
Could you provide any information about issue – clients FedAuth cookie reauthentication in sharepoint sites – Subscribtion Edition?
Is there any solution about issue?
Any suggestions?
https://adamsorenson.com/trending-issue-with-distributed-cache-and-july-2026/
Permalink
Hi Sergey,
the issue is currently under investigation.
Workaround right now would be to configure use sticky sessions in the load balancer or use a single frontend server instead of multiple frontend servers.
Cheers,
Stefan
Permalink
Hi Sergey,
just received the info that the fix for this issue will be included in August CU.
For the time being sticky sessions are recommended.
Cheers,
Stefan
Permalink
When I tried to update the UserProfile PictureUrl with picture located in sharepoint site, the error is happening at Commit()
This code work until we apply July 2026 patch. We can upload picture through userporfile service though.
$picturepath is valid URL in sharepoint
$profile[“PictureURL”].Value = $picturePath.
$profile.Commit()
Error:
$profile.Commit()
Exception calling “Commit” with “0” argument(s): “The property value was invalid. This could be caused by invalid non-text characters.”
At line:1 char:1
+ $profile.Commit()
+ ~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : InvalidValueException
Do you have any idea the patch cause this issue?
Thank you
Permalink
Hi Shekar,
without more details its hard to say what went wrong. My suggestion would be to check the ULS log for specific errors before this message for the same correlation.
Cheers,
Stefan
Permalink
so this is uls log
It says the URL is not safe eventhough it is a valid url.
07/30/2026 13:48:36.56 PowerShell_ISE.exe (0x2774) 0x3B58 SharePoint Portal Server User Profiles 9s8zh Unexpected SPServiceContext.Current is null f9024c46-1416-0004-583a-1ef91614dd01
07/30/2026 13:48:36.56 PowerShell_ISE.exe (0x2774) 0x3B58 SharePoint Portal Server User Profiles 373ze Unexpected Url is not safe: https://mysites.hostname.com/User Photos/personimage.jpg f9024c46-1416-0004-583a-1ef91614dd01
07/30/2026 13:48:36.56 PowerShell_ISE.exe (0x2774) 0x3B58 SharePoint Portal Server User Profiles ajk32 High UserProfile.Commit failed with the following reason: Microsoft.Office.Server.UserProfiles.InvalidValueException: Url is not safe: https://mysites.hostname.com/User Photos/personimage.jpg at Microsoft.Office.Server.UserProfiles.UserProfile.Commit(Boolean allowUnsafeUpdates) while computing Property PictureURL for Account domain\accountid at Checkpoint Got Property DataType f9024c46-1416-0004-583a-1ef91614dd01
07/30/2026 13:48:36.56 PowerShell_ISE.exe (0x2774) 0x3B58 SharePoint Foundation Monitoring b4ly High
Permalink
Got it!
“9s8zh Unexpected SPServiceContext.Current is null” is causing this.
Has this ever worked before from a PowerShell script?
Can you please enable Verbose logging and repeat the test and check which of the following two event ids occur before the 9s8zh: bjomn, bjomo
Cheers,
Stefan
Permalink
Yes. It worked perfectly before applying July 2026 patch. I just tested in my Dev environtment to reproduce it. And got same errir.
$profile.Commit() work without PictureUrl property update.
there is no much information on the logs thought
Permalink
Hi Shekar,
I just sent you some sample code to evaluate by email.
Please let me know if this resolves the issue.
Cheers,
Stefan
Permalink
Hi Stefan
I’m facing the same Issue: Unable to update the property PictureUrl of a UserProfile since it’s apparently not safe (anymore).
In ULS I see: SPServiceContext.Current is null
(The entry before reads: EventId:avv34 – EditUserProfile_Commit Start: My Scenario Start)
Please let us know if there’s a workaround.
Kind regards
Permalink
Hi Nicolas,
at this time you need to use this workaround:
$f = Get-SPFarm
$f.ServerDebugFlags.Add(53534);
$f.Update()
iisreset
Cheers,
Stefan
Permalink
Hi Stefan,
I just discovered that we had the same problem as Shekar with the update of the profile pictures on our prod and test SPSE farms after CU update July. There was always the error: Update-SPProfilePhotoStore : The property value was invalid. This could be caused by invalid non-text characters. This PS script worked perfectly bevor the update.
After reading our comment I added the server debug flag “53534” and the script startet working again – no more errors. Can you explain if this is a known error in July update and also what did I just add with 53534?
BR Alex
Permalink
Hi Alex,
yes – this is a known problem introduced in July 2026 CU.
The debug flag disables the specific code path that causes the issue.
A fix for SP2019 and SPSE is planned to be released next week.
Cheers,
Stefan
Permalink
Thanks Stefan for the update.
Since with adding 53534 I disabled a code path in SharePoint, do we need to do a ServerDebugFlags.Remove(53534) or fixes the CU update for August this by itself? If this is unclear at the moment, maybe you could make a post about this after the new CU update is released.
Thanks,
Alex
Permalink
Hi Alex,
I assume you will have to remove the flag after the fix is installed.
Cheers,
Stefan
Permalink
Thanks, Stefan. Much appreciated.
@Alex: I recommend adding the flag only temporary and removing it after having run the dependent code.
-> IISReset is not needed
Permalink
I worked.
Permalink
Hello Stefan.
Could you confirm that issue – clients FedAuth cookie reauthentication in sharepoint sites – Subscribtion Edition had fixed in August CU?
https://support.microsoft.com/en-us/servicing/office/hotfix/august/5002893
Thank you!
Permalink
Yes
Permalink
Thank you!
Permalink
Hello Stefan,
could you please confirm that the https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-55040 is fixed after applying the July update even if I set “DisableActorTokenAudienceValidation” to true?
$farm = Get-SPFarm
$farm. DisableActorTokenAudienceValidation = $true #disables only the defense-in-depth validation
$farm.update ()