After installing July 2026 CU you might experience the issue that Office Online Server will fail to show Office and PDF documents.
Symptoms
The issue is typically reflected in the ULS logs with entries similar to the following:
w3wp.exe (0xXXXX) SharePoint Foundation Claims Authentication ahds5 Unexpected SPJsonWebSecurityBaseTokenHandler: ValidateTokenIssuer rejected Issuer '00000003-0000-0ff1-ce00-000000000000@...random-guid...' because no registered STS matches the signing certificate 'CN=SharePoint Security Token Service, OU=SharePoint, O=Microsoft, C=US'
Current Status
This issue is currently under investigation by the product group.
Workaround
Seems we have a workaround!
$stsm = Get-SPSecurityTokenServiceConfig
$live = $stsm.LocalLoginProvider.SigningCertificate
$pub = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$live.Export('Cert'))
$realm = $stsm.NameIdentifier # e.g. 00000003-0000-0ff1-ce00-000000000000@
New-SPTrustedSecurityTokenIssuer -Name "LocalSelfIssuerWopiFix" -Description "Re-trust farm self-issuer after KB5002891" -Certificate $pub -RegisteredIssuerName $realm
Ensure to restart IIS (IISRESET) on each server of the SharePoint farm .
Solution
The fix for this issue is included in August 2026 CU
Permalink
Hi Stephen,
Thanks for your update.. Could you please share the workaround mentioned here
Workaround
There is known workaround available at this time.
Permalink
Hi Ashish,
the line was missing a “no”. I fixed it.
There is no workaround available at this time.
Cheers,
Stefan
Permalink
The title says “SP2016” but nothing mentioned on the body… Just to clarify, does it also happens to SPSE ?
Permalink
Hi Andre,
in theory it can also happen in SPSE – but only if you did not apply the script in the “Known Issue” section of KB https://support.microsoft.com/en-us/servicing/office/update/2026/5002882
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()
If you applied this required step it should not happen.
Permalink
Hello, do you know if the issue happens with a SP 2019 Farm?
Permalink
Hi Kristine, SP2019 is not affected.
Permalink
Hi Stefan,
I am seeing below errors in OOS logs when i try to access documents like word excel on sharepoint 2016 sites after installing SharePoint 2016 related July 2026 patches. Apart from SP2010 workflow issues now the new addition of issues related to OOS also started.
Getting WOPI 401 unauthorized error
WOPI CheckFile: Catch-All Failure [exception:Microsoft.Office.Web.Common.EnvironmentAdapters.WopiUserUnauthorizedException: WOPI 401 —> System.Web.HttpException: Unauthorized –
— End of inner exception stack trace —
at Microsoft.Office.Web.Apps.Common.WopiTalky.AddHostResponseDataAndThrow(Exception exception, HttpRequestAsyncResult result)
at Microsoft.Office.Web.Apps.Common.WopiTalky.LogAndThrowWireException(HttpRequestAsyncResult result, HttpRequestAsyncException delayedException)
at Microsoft.Office.Web.Apps.Common.WopiDocument.LogAndThrowWireException(HttpRequestAsyncResult result, HttpRequestAsyncException delayedException)
at Microsoft.Office.Web.Common.HttpRequestAsync.End()
at Microsoft.Office.Web.Apps.Common.WopiDocument.CheckWopiFile()]
Permalink
Hi John,
yes that the symtom on the OOS side. On SharePoint side the Claims token from OOS are rejected by SP2016 resulting in the 401 unauthorized being reported in OOS.
This the issue discussed here in this blog post.
Cheers,
Stefan
Permalink
Hi Stefan do you have an approximate date when the issue will be resolved?
In our farm 2016 we have the same situation.
Permalink
Hi Alex,
engineering is working on a fix for the issue but I do not have a date.
Cheers,
Stefan
Permalink
I found this blog because we have the exact same issue.
We are still on SP 2016. The patch went very smooth last week so we didn’t expect to encounter any issue but here we are:
-Getting WOPI 401 unauthorized error
WOPI CheckFile: Catch-All Failure [exception:Microsoft.Office.Web.Common.EnvironmentAdapters.WopiUserUnauthorizedException: WOPI 401 —> System.Web.HttpException: Unauthorized –
Needless to say, I will be following this forum and hope that someone finds a fix soon.
Permalink
We are also experiencing this issue. Hopefully MSFT gets the fix soon.
Permalink
We are experiencing exactly the same issue after installing the July 2026 SharePoint 2016 CU.
After the update, Office Online Server can no longer open documents. We have verified the WOPI configuration, certificates, DNS, authentication, and connectivity between SharePoint and OOS, with no configuration issues found. IIS logs show the WOPI requests are rejected with HTTP 401, and the SharePoint ULS logs report:
Issuer name is not registered
Microsoft.SharePoint.IdentityModel.SPJsonWebSecurityBaseTokenHandler.ValidateTokenIssuer
We also have a sandbox environment cloned from production before applying the July CU, and Office Online Server continues to work correctly there, which strongly suggests the issue was introduced by this update.
Thank you for publishing this information. It matches our environment and symptoms exactly. Please keep us informed if Microsoft provides a workaround or releases a fix.
Permalink
Hello,
Have the Microsoft team considered adding a note to the SP2016 patch page that this is a known issue, just to prevent other people from falling into the trap and applying the patch before the fix is released
Note: I mean updating this https://support.microsoft.com/en-us/servicing/office/update/2026/5002891
Thank you
Permalink
We are experiencing the same issue in our SP16 farm. We also have a SPSE Farm that is NOT experiencing the issue, and we did execute the PowerShell to prevent this/disable the problematic feature.
We are planning to wait for a fix.
Permalink
Hi Stefan, we installed the July 2026 CU on our SPSE farm and we are having issues with OOS – users attempting to open office documents in the web view are getting errors like “You do not have permissions to open this file in the browser”. We notice this issue only on the farms where there are multiple web front ends. We did run the DisableActorTokenAudienceValidation script. We notice ‘401’ unauthorized responses to calls from the OOS server to the _vti_bin/wopi.ashx/files/ endpoint on the WFEs where the access_token is passed in the request. If we point the OOS to just one WFE, then it all works but only for sessions that originate from that WFE, fails for users who get signed in to any other WFE. This all worked fine before the CU, so could this possibly be related to the development work being done related to tokens? Any other customers with multi-server SPSE farms reporting the same issue?
Permalink
Hi Sanjeev,
did you apply the script as requested in the known issues section of the SPSE KB article?
https://support.microsoft.com/en-us/servicing/office/update/2026/5002882
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.
Cheers,
Stefan
Permalink
Hi Stefan, yes in my comment above, I did note that: “We did run the DisableActorTokenAudienceValidation script.”. Although we ran it a day or so after we installed the CU – does the timing matter? If I call that property now, it returns the value ‘True’. We also re-ran the PSConfigUI again on all the servers yesterday.
Permalink
Hi Sanjeev,
no it does not matter,
In this case I would recommend to open a ticket with Microsoft to get this analyzed.
Cheers,
Stefan
Permalink
Hi Stefan,
Do we still not have any workaround for Office Online issue with SP 2016?
Please confirm.
Permalink
Hi Aditya,
the issue causing this does not allow a workaround.
A fix is in the works.
Cheers,
Stefan
Permalink
Any ETA on this one and MS will release the fix?
Permalink
Please see the correction:
Any ETA on this one and how MS will release the fix?
Permalink
Hi Aditya,
there is no ETA at this time but an out-of-band fix is planned – means it should arrive before August CU.
Cheers,
Stefan
Permalink
August CU? I think this is the last CU released by MS for SP 2016.
Permalink
I was talking about the date when August CU would usually be released. So this fix should arrive before that date.
Permalink
Stephan ,
Thank you for providing updates on this issue.
Is the ‘$farm. DisableActorTokenAudienceValidation’ solution not compatible with SharePoint 2016? The July CU is applied on a SP2016 Test Farm.
Permalink
Hi Peggy,
no it is not. This property does not exist in SP2016.
Cheers,
Stefan
Permalink
Hi Stefan,
I am facing this issue as well after the July patch installation.
Please would it worth to unistall this patch? I mean if I would unistall this patch and would install for example the June patch – do you think the opening of office documents would work again?
Thank you.
Permalink
Hi Tomas,
SharePoint fixes cannot be uninstalled. Only if you have a snapshot from before installing July 2026 CU you could pursue this path.
But you would also have to revert the databases to the earlier state as databases upgraded to July 2026 CU cannot be mounted with June 2026 CU or earlier.
Cheers,
Stefan
Permalink
Sorry, I am not pretty sure about this – has to be made rollback just of office online servers (I have 2 nodes in farm) or as well as all sharepoint servers? (I am using sharepoint 2016 on premises).
Thank you.
Permalink
Hi Tomas,
this is not a problem with OOS – the problem is in SP2016.
It does not matter which patch level OOS has – the problem will always occur if July 2026 CU for SP2016 is installed.
Cheers,
Stefan
Permalink
Oh ok I understand now.
Many thanks for you information, Stefan!
BR,
Tomas
Permalink
Hi ,
Can i check this issue only happening after installed patch in OOS server or SP2016 server?
Permalink
This is caused by the SP2016 fix
Permalink
Can i confirm this is sharepoint 5002891?
Permalink
Yes. This is the fix introducing this issue
Permalink
Hi,
Any news about the fix ? Have the Microsoft teams announced a date?
Thanks
Regards
Permalink
Hi Berliozm,
the fix is still in the works and a release date has not been announced.
Usually the fix will only be announced when it has been released.
Cheers,
Stefan
Permalink
We decompiled the affected assembly and can share the exact root cause plus a configuration-only workaround that does not require patching any binaries.
ROOT CAUSE
The regression is a single flipped branch in Microsoft.SharePoint.IdentityModel.dll, in:
SPJsonWebSecurityBaseTokenHandler.ValidateTokenIssuer(X509SecurityToken signingKey, string tokenIssuer)
The method resolves the token’s signing certificate to a registered STS via:
manager.TrustedSecurityTokenServices.GetProviderBySigningCertificate(signingKey.Certificate, tokenIssuer)
Comparing the July 2026 build (16.0.5561.1001) with RTM (16.0.4312.1000), the only behavioral change is the “provider == null” branch (ULS tag 1848479):
Before: logged “ValidateTokenIssuer accepted Issuer … because no registered STS matches the signing certificate” and returned -> token accepted.
After: logs “ValidateTokenIssuer rejected Issuer …” and throws SecurityTokenException(“Issuer name is not registered”).
In other words, the CU turned a fail-open path into fail-closed (a legitimate security hardening).
WHY IT BREAKS WOPI / OOS
The WOPI callback token that OOS presents back to SharePoint is a self-issued (loopback) token: issuer 00000003-0000-0ff1-ce00-000000000000@, signed by the farm STS certificate.
The local self-issuer is represented by SPLocalLoginProvider, whose RegisteredIssuerName is the farm NameIdentifier and whose SigningCertificate is the farm STS certificate. However, GetProviderBySigningCertificate only enumerates the persisted TrustedSecurityTokenServices collection, and that collection does NOT contain the LocalLoginProvider. So for the farm’s OWN self-issued token the lookup returns null.
Pre-CU, null was accepted; post-CU, null is rejected -> HTTP 401 -> OOS “WOPI 401 unauthorized”. The reject branch is unconditional (no farm property, registry key, or feature flag guards it), which is consistent with the “no workaround” observation.
CONFIGURATION-ONLY WORKAROUND (no binary patching)
Explicitly register the farm’s own STS as a trusted token issuer, so the signing-certificate lookup finds a match instead of returning null:
$stsm = Get-SPSecurityTokenServiceConfig
$live = $stsm.LocalLoginProvider.SigningCertificate
$pub = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$live.Export(‘Cert’))
$realm = $stsm.NameIdentifier # e.g. 00000003-0000-0ff1-ce00-000000000000@
New-SPTrustedSecurityTokenIssuer -Name “LocalSelfIssuerWopiFix”
-Description "Re-trust farm self-issuer after KB5002891"-Certificate $pub -RegisteredIssuerName $realm
# then, on each server in the farm:
# iisreset (and recycle the SecurityTokenServiceApplicationPool)
Notes:
– RegisteredIssuerName must equal the farm NameIdentifier (the issuer of the self-issued tokens). If different tenants emit different issuer realms, the “@*” context-id wildcard can be used instead.
– The certificate passed to New-SPTrustedSecurityTokenIssuer must be public-only (no private key) – hence the Export(‘Cert’) round-trip above.
– This does not weaken the CU hardening: it only re-establishes trust for the farm’s own signing certificate, which is implicitly trusted anyway. External-issuer validation stays enforced.
– Fully reversible: Get-SPTrustedSecurityTokenIssuer | ? Name -eq “LocalSelfIssuerWopiFix” | Remove-SPTrustedSecurityTokenIssuer. The registration lives in the config DB and replicates farm-wide.
This is derived from decompiled-code analysis rather than a supported fix, so please validate it in a test farm before production. Feedback on whether it holds up across multi-tenant / host-named site collections would be very welcome.
Permalink
Thank you. This worked for us.
Permalink
it works for me, SP2016 on-prem
$stsm = Get-SPSecurityTokenServiceConfig
$live = $stsm.LocalLoginProvider.SigningCertificate
$pub = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$live.Export(‘Cert’))
$realm = $stsm.NameIdentifier # e.g. 00000003-0000-0ff1-ce00-000000000000@
New-SPTrustedSecurityTokenIssuer -Name “LocalSelfIssuerWopiFix” -Description “Re-trust farm self-issuer after KB5002891”
-Certificate $pub -RegisteredIssuerName $realm
then, on each server in the farm:
iisreset (and recycle the SecurityTokenServiceApplicationPool)
Permalink
Hi Nail,
thanks for sharing and Steve, thanks for confirming!
I have added the workaround in the article above.
Permalink
Thanks for confirming!
If you experience a powershell error with certificate environment …( New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$live.Export(‘Cert’)))
try to export certificate in base64 format from frontend sharepoint server. certificate store (local machine level). container sharepoint\certificates. Certificate: issued to ‚SharePoint Security Token Service‘. without private key. For an example export it to C:\SharePointSecurityTokenService.cer.
then run:
$pub = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(‚C:\SharePointSecurityTokenService.cer‘)
Permalink
Thanks Nail for the fix, also works for me SP 2016 on-prem.
Permalink
Worked! Single SP2016 server and separate OOS machine.
Command to undo:
Get-SPTrustedSecurityTokenIssuer | Where-Object Name -eq „LocalSelfIssuerWopiFix“ | Remove-SPTrustedSecurityTokenIssuer -Confirm:$false
iisreset
Permalink
Since encountering this bug, we needed to remove the bindings to OOS to force SharePoint to open office documents in the desktop app (Because otherwise, users can’t open attached documents in list items). I am glad someone finally found a workaround but since we have a way of opening documents atm, we will wait for the official fix.
Permalink
Thanks all the workaround work fine for us
Permalink
Do we need to run this only OOS servers or on all servers (APP, WFE,Search, OOS)? Is there any risk with this commands ?
Permalink
It needs to be run on one server in the SharePoint farm. Not on a server in the OOS farm.
Permalink
The workaround perfectly works, thanks a lot!
T.
Permalink
Thanks Stefan, above given workaround fixed our issue.
Office Online is back up and running.
Permalink
Hi Stefan, I need to patch both my SharePoint 2016 farm as well as OOS due to the recent vulnerabilities. Is it still advised to patch the OOS server first? or due to the issues caused by the SP2016 patch, should that patch order change?
Permalink
Hi Ray
the sequence does not really matter.
Cheers,
Stefan
Permalink
Thank you so much for the feedback. Appreciate you sir!
Permalink
Hi Stefan,
could this new workaround also work for our SE farm? We have here also problems with accessing office dokuments.
Thanks Marcel
Permalink
Hi Marcel,
I don’t think so. It just fixes the issue which is addressed through the script in the KB article for SPSE:
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 ()
Cheers,
Stefan
Permalink
the same issue happened for SPSE after applying July CU
Permalink
Hi Farid,
this indicates that you did not apply the required steps outlined in the KB article for July CU for SPSE:
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 ()
Cheers,
Stefan
Permalink
what’s the fix for if the documents opens in browser, but the search preview does not work SPSE?
Permalink
Hi Abdul,
the required script from the the SPSE KB should help:
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 ()
Cheers,
Stefan
Permalink
Hi Stefan and Abdul,
the specific question was:
If OOS integration itself works and only the search preview is missing:
You need to rerun the search crawl. Probably a full crawl.
Permalink
Now the KB is out: https://support.microsoft.com/en-us/kb/KB5002891
Permalink
Hi Stefan,
Should we proceed with installing this July update in the Production environment using the documented workaround to mitigate the known issue, or would it be preferable to wait for the official security update that includes a permanent fix?
Thanks,
Babu M.
Permalink
Hi Babu,
this depends on your specific requirements.
Cheers,
Stefan
Permalink
Hi Stefan,
I run SP2016 and OOS but have not yet run the July CU update but just to confirm, once all the binaries have been installed and I’ve run PSConfig on all SP servers (I have 2x WFE and 2x APP) do I run:
$stsm = Get-SPSecurityTokenServiceConfig
$live = $stsm.LocalLoginProvider.SigningCertificate
$pub = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$live.Export(‘Cert’))
$realm = $stsm.NameIdentifier # e.g. 00000003-0000-0ff1-ce00-000000000000@
New-SPTrustedSecurityTokenIssuer -Name “LocalSelfIssuerWopiFix” -Description “Re-trust farm self-issuer after KB5002891” -Certificate $pub -RegisteredIssuerName $realm
Or:
$farm = Get-SPFarm
$farm. DisableActorTokenAudienceValidation = $true #disables only the defense-in-depth validation
$farm.update ()
Permalink
Hi Neil,
only the first script – the second one only applies to SPSE and not to SP2016.
Be aware that KB 5002891 has been updated to include a slightly updated script:
# Get STS certificate
$stsm = Get-SPSecurityTokenServiceConfig
$live = $stsm.LocalLoginProvider.SigningCertificate
# Export public certificate only (without private key)
$bytes = $live.Export("Cert")
$tempFile = "$env:TEMP\STS_Public.cer"
Set-Content -Path $tempFile -Value $bytes -Encoding Byte
# Load public certificate
$pub = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($tempFile)
# Verify it does NOT contain private key
$pub.HasPrivateKey
# Get realm
$realm = $stsm.NameIdentifier
# Create trusted issuer
New-SPTrustedSecurityTokenIssuer -Name "LocalSelfIssuerWopiFix"
-Description "Re-trust farm self-issuer after July PU" -Certificate $pub
-RegisteredIssuerName $realm
# IIS Reset on all SharePoint servers
iisreset
Cheers,
Stefan
Permalink
I’m having this problem; I already followed the Microsoft procedure, but it didn’t fix it. I’m still getting the error X-WOPI-ServerError: Verifying signature failed.
Permalink
I’ve already solved the problem.
Remove-SPWOPIBinding -All:$true
New-SPWOPIBinding -ServerName ….
Set-SPWOPIZone……
Iisreset
Permalink
Thanks for this. This also fixed it for me
Permalink
Thanks, Stefan. I see the August update is out, and you’ve said it’s fixed within that. I don’t see it in the improvements and fixes. Or is it deemed a security issue, rather than a nonsecurity issue? Just want to ensure I’m good to roll this update into production. Thank you!
Permalink
Hello, thks 4 the workaround it works perfect for us!
Just hope that M$ fix what they broke….
Many thks.
Permalink
Is the August OOS update expected to resolve this issue? If we haven’t installed the July CU yet, should we install the August OOS update first and then the July CU or what are the proper steps to update so it won’t break?
Thanks!
Permalink
Hi Staci,
not the OOS update.
This is a SharePoint issue. But the August update for SP2016 fixes it.
Cheers,
Stefan
Permalink
The August patches have been released. Do you have any updates on whether there are any known issues or impacts with the following updates, or if they are working fine?
KB5002905
KB5002906
Please let me know your observations or recommendations.
Permalink
Usually it takes a couple of days or weeks till issues are identified.