The product group released the August 2026 Cumulative Update for SharePoint Workflow Manager.
This CU consists of a fix for SharePoint Workflow Manager and the SharePoint Workflow Manager client components which need to match SharePoint Workflow Manager.
The KB article for August 2026 CU will be available at the following location in a couple of hours:
- KB 5002864 – August 2026 Update for SharePoint Workflow Manager
The download for August 2026 CU is available through the following link:
- Download August 2026 Update for SharePoint Workflow Manager
- Download SharePoint Workflow Manager Client version 16.0.19725.20522
This CU requires SharePoint Workflow Manager Client version 16.0.19725.20522 to be installed
- on all servers in the Workflow Manager farm AND
- on all servers in the SharePoint Server farm
For detailed download and installation instructions see the KB article above.
Permalink
Hi Stefan,
I installed August CU for Workflow, but I’m still getting errors
SQL command processing error. Database info: dbserver\SP2022_WFM_SB_Gateway. Exception: command text: [dbo].[GetContainerById], exception = System.ArgumentException: Keyword not supported: ‘asynchronous processing’.
at Microsoft.Data.SqlClient.SqlConnectionStringBuilder.GetIndex(String keyword)
at Microsoft.Data.SqlClient.SqlConnectionStringBuilder.set_Item(String keyword, Object value)
at System.Data.Common.DbConnectionStringBuilder.set_ConnectionString(String value)
at Microsoft.Data.SqlClient.SqlConnectionStringBuilder..ctor(String connectionString)
at Microsoft.Cloud.InfrastructureCommon.EncryptionHelper.IsConnectionStringEncrypted(String connectionString)
at Microsoft.Cloud.InfrastructureCommon.SecretsManagerHelper.DecryptDbConnectionString(String encryptedSecret)
at Microsoft.ApplicationServer.Messaging.Broker.Sql.GetContainerByIdAsyncResult.ProcessSqlResult(SqlDataReader reader)
at Microsoft.Cloud.ServiceBus.Common.Sql.SqlStoreAsyncResult.SqlCommandAsyncResultCallback(IAsyncResult result). TrackingId: 96a23b94-10a4-4513-9081-c2baf08f88fb_B35spWF, SubsystemId: NoSystemTracker.
Is rebuilding a farm only way?
Permalink
Hi Stefan,
I rebuilt the farm and it is working now.
cheers
Permalink
After applying August CU, I’m getting “Access Denied” errors for standard users. My Site Owner account can manually start / run workflows without issue. ULS logs show “Un-whitelisted client sent us an OAuth token. Client Id” despite being a registeredIssuerName. I’ve re-registered the tokenIssuers and recycled all services and times. Unsure of next steps or if this is genuinely broken.
Permalink
Hi Garrett,
I double checked – this message should you quoted should not cause workflows to fail – it is just an information and a default value is used afterwards.
Are there other events which indicate a problem?
Thanks,
Stefan
Permalink
Just some followup diagnostics:
Any list item creation that triggers a 2013 workflow returns Access Denied.
ULS shows the workflow’s actor token arriving with no appid claim, so the
client identity falls back to nameid and then fails a whitelist check:
Claims Authentication 9s649 Identity Actor has no AppIdAcr claim.
Claims Authentication ajau7 SPSecurityTokenServiceManager!GetProviderByName:
Searching Trusted Security Token Issuers for
input @
Security Token 9pplc Could not get value for application identifier.
Security Token 9ppk9 Token app id claim value is emtpy.
Security Token 9ppld Could not get value for tenant identifier.
Claims Authentication 9ppnp Value from actor token. Type: ‘app_displayname’,
Value: ”.
Application Auth. cm9q2 Un-whitelisted client sent us an OAuth token.
Client Id : ”.
Claims Authentication bk9su Claims Windows Sign-In: Sending 401 … because
the request is not from a browser.
The decoded actor token has correct iss (00000005-0000-0000-c000-000000000000@
), correct aud (00000003-0000-0ff1-ce00-000000000000/@),
the invoking user’s SID in outernameid, and trustedfordelegation true. Only
appid is absent.
Ruled out so far:
– Trust registration. Get-SPTrustedSecurityTokenIssuer shows the WorkflowManager
issuer registered as @, realm matching
Get-SPAuthenticationRealm exactly.
– Version mismatch. SPWFM, SPWFM Client and SPSE all at 16.0.19725.20522.
Client present on every SharePoint server per the KB5002864 notes.
– Generic allowlists. Nothing OAuth or application-authentication related in
$farm.SupportedGenericAllowedListNames.
– STS config. No client-ID collection on Get-SPSecurityTokenServiceConfig.
– App infrastructure. App Management and Subscription Settings both Online.
– Re-registering the issuer, re-registering the workflow service, and adding
00000005-0000-0000-c000-000000000000 as an issuer — no change.
– Reproduces with a brand new workflow on a new list with a new history list,
and is unaffected by item-level or list-level permission changes.
Since the SPWFM client ID is generated per installation rather than being one
of the well-known first-party GUIDs, I’m unclear how any SPWFM farm’s ID would
be on a whitelist of known clients. Is this a known August CU regression, and
is there a ServerDebugFlag or supported workaround?
Permalink
Hi Garrett,
please open a ticket with Microsoft Support to ensure this can be properly analyzed.
Cheers,
Stefan
Permalink
Sorry to send you down a rabbit hole. I did end up fixing this, either by dumb luck or something entirely different. I think it has to do with Re-running Set-SPAppPrincipalPermission but it is working again.
Permalink
ok, great 🙂
Permalink
Apologies again as the above fix was incorrect and I feel really dumb. The issue is exactly this and is reproducible on my farm and is centered on SP Users granted permissions via AD groups. When permission is directly assigned to domain/user WF fires as expected. When permission is granted via domain/ the workflow fails with the Access Denied (above logging holds true). Tested with generic AD groups (domain users) as well as custom security groups.
Permalink
Hi Garrett, in this case, please open a ticket with Microsoft support.
Permalink
Hi Garett,
beware of Primary AD group issue
https://joshroark.com/sharepoint-profile-sync-and-the-domain-users-group-the-primary-group-problem/
if you are using domain users group to assign permissions, workflow will throw access denied.
Permalink
Hello Stefan!
I tried to find any info about right process for deploy workflow manager security patches in multiserver WFM farm without success. Different AI says differrent process. Is there any article which describes best practice for this activity?
thank you for your help in advance
Gabor
Permalink
Did anyone get a resolution to the issue where the workflows kick off but do not run if the person who entered the list item was granted permissions through an active directory security group? I read the article about primary group, but I don’t have the security groups as audiences and I don’t pull them into user profiles. Everything worked until I applied this patch.
Permalink
Can I upgrade directly to this version from 16.0.19127.20336?
Permalink
Yes