The product group released the October 2025 Cumulative Update for SharePoint Workflow Manager.
The KB article for October 2025 CU will be available at the following Location in a couple of hours:
- KB 5002785 – October 2025 Update for SharePoint Workflow Manager
The download for October 2025 CU is available through the following link:
This CU requires SharePoint Workflow Manager Client version 16.0.19127.20262 to be installed on all servers in the Workflow Manager farm AND all servers in the SharePoint Server farm.
For detailed download and installation instructions see the KB article above.
Permalink
KB Article throws an error “Sorry, page not found
Try searching Microsoft Support to find a solution ”
I have a question,
do you mean we can skip the August Workflow manager CU and directly install the October CU to overcome/remediate the System.Memory.Dll missing issues with the AUG CU?
Permalink
Hi Nixon,
yes – you can see that I wrote “…will be available at the following Location in a couple of hours…”
And yes – there is no need to apply August CU for SPWFM before.
Be aware that the actual fix for the missing assembly issue is not in the SPWFM fix but in the SPWFM client component version 16.0.19127.20262 which is referenced in this article.
SPWFM fix and SPWFM client component always have to be in sync – so both are required.
Cheers,
Stefan
Permalink
The KB5002786 article says: “If you’re running 2013-type workflows, you must install the August 2025 update for SharePoint Workflow Manager to your farm before you install this cumulative update.”
Does that mean that I only need the August 2025 update, if active workflows are running and on a fresh WFM installation without any running workflows I can omit the August 2025 update and directly install the October 2025 WFM-update?
Permalink
Hi Hans,
you can always directly go to October 2025 CU for SPWFM.
Cheers,
Stefan
Permalink
After this update we get a “SQL connection string is incorrect as data source is missing” error. “keyword not supported: ‘trust server certificate'”
Our SQL connection string is: “Data Source=;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=True;TrustServerCertificate=False”
We used the wizard to originally configure WFM and it was working fine. But now we can’t connect to the DB to make any changes or to leave the farm to uninstall it WFM and start over. How can we make this change manually on the server?
Permalink
Hi Rodney,
this is interesting – haven’t seen this flavour.
Please open a support case with Microsoft as this requires some investigation.
Cheers,
Stefan
Permalink
I attempted to join the farm again without using the enable ssl connection option to sql. SB joins fine but not WF. I also get a keyword not supported: ‘asynchronous processing’ Thanks
Permalink
Hi Rodney,
yes – that is another known issue which is currently being investigated.
In case you cannot wait for a fix, here is a workaround (not sure if it would work for the trust server certificate issue as well as we did not see that before):
The workaround is to leave the SPWFM, remove SBmanagementDB and WFmanagementDB and recreate the farm as part of a disaster recovery (https://learn.microsoft.com/en-us/sharepoint/governance/sp-wf-mgr-farm-restore-disaster-recovery)
This will resolve the issue as the unsupported keyword exists in the management database only.
Cheers,
Stefan
Permalink
Hi Stefan
I have the same problem as Rodney on all 5 of our farms patched to October KB5002785 and SharePoint October CU.
The problem in fact started with the August KB5002750 update
– Upgraded the SQL library from System.Data.SqlClient to Microsoft.Data.SqlClient.
And appears to be related to Backwards incompatibility between the above clients
https://github.com/dotnet/SqlClient/issues/1780
Microsoft.Data.SqlClient
internal const string TrustServerCertificate = “Trust Server Certificate”;
System.Data.SqlClient
internal const string TrustServerCertificate = “TrustServerCertificate”;
So now the Workflow Manager Configuration wizard no longer works
Specified SQL connection string is incorrect as data source is missing. ConnectionString: Data Source=SPRD;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=True;Trust Server Certificate=False
It appears that the workflow manager is still referencing System.Data.SqlClient
As a work around I use scripts and remove TrustServerCertificate=False
Cheers
Rene
Permalink
Hi Rodney, was your SPWFM farm on the August 2025 SPWFM update already? Or were you able to skip August 2025 and go directly to the October 2025 SPWFM update?
Thank you,
Chad
Permalink
We skipped over August and Sept. We had to update the connection string on the db to join the farm.
Permalink
Hi Stefan,
Hoping you can help us with this issue.
We’ve been having SharePoint (SP) 2013 Style Workflow (WF) errors ever since deploying the Aug 2025 Workflow Manager (WFM)/WF Client and Sep 2025 SPSE CU. We were hoping that the Oct 2025 WFM/SPSE CUs would resolve the issue, but after installing them today, the issue persists. We are only experiencing the issue on our production SP/WFM farm. I’m guessing that the issue is being caused by the running of specific workflows that are running on production but not on our test farm. We have a lot of site collections and workflows running on production and have not been able to isolate which WF(s) may be the cause of the issue, so we have been unable to replicate the issue on our test farm.
Our farm is disconnected from the Internet, and as it is very difficult for me to copy full error messages into this post, I’ll manually type and summarize them below. Have you had other reports of this issue? Since this is causing a significant production impact, if you don’t have a quick fix or workaround for us, we’ll need to open a MS case. Our farm’s 2010 WFs are running without issue. The 2013 WFs can’t be transitioned to 2010 WFs as a workaround because they depend on features only present in 2013 style WFs.
When we first started noticing the issue, workflows were taking several minutes instead of several seconds to process. Now, I don’t believe any workflows are completing successfully. They either never show a record of attempting to start or end up in a Suspended or Terminated Internal State. Example message: The workflow exceeded the maximum number of attempts to process a message.
The WF service keeps being terminated unexpectedly, and then auto restarts 30 seconds later and stays running for about 7 seconds before it fails again.
Errors:
Microsoft-Workflow | Operational log:
Event ID: 358
Dispatcher encountered an unexpected exception: System.AggregateException: One or more errors occurred.
System.InvalidCastException: Specified cast is not valid.
ParallelAsyncResult.OnBranchCompleted
AsyncResult.End
Application log:
Source: .NET Runtime
Event ID: 1026
Application: Microsoft.Workflow.ServiceHost.exe
Framework Version: v4.0.30319
Description: The process as terminated due to an unhandled exception.
Exception Info: System.InvalidCastException
AsyncResult.End[[System._Canon, mscorlib
Application log:
Source: Application Error
Event ID: 1000
Faulting application name: Microsoft.Workflow.ServiceHost.exe, version: 16.0.19127.20262
Faulting module name: KERNALBASE.dll, version: 10.0.20348.3932
Exception code: 0xe0434352
Fault offset: 0x000000000003f46c
Faulting process id: 0x2934
System log:
Event ID: 7031
The Workflow Manager Backend service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 30000 milliseconds: Restart the service.
Permalink
Hi Fred,
you got bad luck – this is a known issue in all Post-RTM SPWFM updates.
A hotfix is currently in the works.
Best would be to open a support case with Microsoft, send me the SR number using “Contact the blog author” at the top right and I will ensure that you get the fix as soon as it is available.
Cheers,
Stefan
Permalink
Hi Stefan,
Thanks for the info! We just opened a case and sent you our SR number. Do you have any idea if the hotfix is expected to be available in the days, weeks, or months timeframe?
Best Regards,
Fred
Permalink
Hi Stefan,
Will you be sharing this hotfix here? I am seeing the same exact error here after installing KB5002785 on our SPWFM server (which is also a SP2019 app server). I removed the SPWFM client from all servers, installed the latest client then ran KB5002785 and rebooted, now I get the following in eventviewer:
Faulting application name: Microsoft.ServiceBus.MessageBroker.exe, version: 16.0.19127.20262, time stamp: 0xa9e6ed85
Faulting module name: KERNELBASE.dll, version: 10.0.17763.7553, time stamp: 0x296284f5
Exception code: 0xe0434352
Fault offset: 0x0000000000041b39
Faulting process id: 0x2b0c
Faulting application start time: 0x01dc428a6930c0aa
Faulting application path: C:\Program Files\Service Bus\1.1\Microsoft.ServiceBus.MessageBroker.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 6fe5f121-b885-4f2e-bb64-ff445b257d0c
Faulting package full name:
Faulting package-relative application ID:
Thanks for the help!
Permalink
Hi cmillerLCE,
from the error you pointed its not clear that it is the same problem. There is no evidence for an InvalidCastException. In addition its a different process – Microsoft.ServiceBus.MessageBroker.exe vs. Microsoft.Workflow.ServiceHost.exe.
Sounds more as if you are running into a different issue which might need further analysis.
I would recommend to open a support case with Microsoft to get this issue analyzed.
Cheers,
Stefan
Permalink
Hi Fred,
fyi: the fix for the InvalidCastException is now available.
If you have a ticket open with Microsoft the engineer should be able to send the fix to you.
Cheers,
Stefan
Permalink
Hi Stefan,
can I found the fix for this problem on an official site from Microsoft?
We have the same issue that “Microsoft.Workflow.ServiceHost.exe” crashes. Everything is up-to-date.
Best regards
Kevin
Permalink
Hi Kevin,
for customers who did not open a support case the fix will be made available next week with the regular November 2025 CU.
Cheers,
Stefan
Permalink
Hi Stefan,
Our Microsoft support case engineer sent the link a couple days ago. The hotfix resolved our issue! Thanks for your support!
Best Regards,
Fred
Permalink
https://support.microsoft.com/en-US/help/5002785 : – still this link throws 404 error message
Permalink
KB article KB5002785 is still not available (20 october 2025)
Permalink
Yes. I have escalated this internally.
Permalink
When running the upgrade the Workflow Manager Configuration Wizard shows 2 green marks (Upgrade current Workflow Manager Farm and Configuration succesful). But in the details it shows what looks like an error:
Starting
Starting.
Started.
Reading WF upgrade policy file.
Validating current DB versions against versions specified in the upgrade policy file.
The token provider service was not available when obtaining a token for ‘https://:9355/WorkflowDefaultNamespace/$STS/Windows/’.
Can you advise?
Permalink
Hi Robert,
I haven’t seen this. My recommendation would be to open a ticket with Microsoft Support as this will require deeper analysis.
Cheers,
Stefan
Permalink
Got just published. Should be replicated to all regions in a couple of minutes.
Permalink
So, our SPWFM is installed on the SP Farm’s WFE server 2016. Since this software now requires Windows Server 2019, I assume I need to stand up a new 2019 server for SPWFM and somehow move the databases so I don’t lose the workflows. Is there an article on how to do this? [p.s. I installed it last month on the 2016 servers and it’s working fine.] This article says it can be installed on the SharePoint servers, so why does it have to be on 2019? https://learn.microsoft.com/en-us/sharepoint/governance/install-and-configure-workflow-for-sharepoint-server
p.s. Unfortunately, I no longer have a test system to play around with, so the fewer changes/risks the better until we migrate to SPSE.
Permalink
Hi Marlene,
the main reason is that Window Server 2016 was already in extended support – so near end of its lifetime when SPWFM was released.
Setting up a new server on an aged Operating System is not recommended.
This article explains how to migrate from classic WFM to SPWFM while migrating to a new machine:
https://joshroark.com/upgrading-sharepoint-and-wfm-at-the-same-time/
Cheers,
Stefan
Permalink
We already migrated to SPWFM. The MS tech worked with us and installed it on the SP 2016 WFE server last April/May 2024. Is it necessary to move it to 2019 since we’ve been running on 2016 for over a year? If we must migrate, I assume in the article above I don’t have to do the ‘Move Databases’ section since it will be on the same SQL server.
Thank you so much Stefan. God bless.
Permalink
Hi Marlene,
if you check the system requirements in the download page you will find the following:
https://www.microsoft.com/en-us/download/details.aspx?id=104867
Supported Operating Systems
Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server 2022
I hope this answers your question.
Cheers,
Stefan
Permalink
Thank you! I’ll leave it as-is and assume the KB system requirements are not 100% correct.
Permalink
Can I install the October SPWFM update a few days after applying the October 2025 SharePoint updates or will the workflows no longer run because they are the September version?
Permalink
Hi Marlene,
depends on which version of SPWFM you have installed.
If it is a version older than August 2025 CU for SPWFM, you should first patch SPWFM and afterwards SharePoint to ensure that the Workflows continue to work after SharePoint has been upgraded.
Cheers,
Stefan
Permalink
I have the September 2025 CU version installed. So, I’ll proceed with installing the October 2025 SPWFM a few days after the SharePoint October 2025 KBs. Hopefully, the hot fix for SPWFM will be out by then. Thanks!!
Permalink
FYI. I’m still in the midst of troubleshooting and hoping a hotfix will be released soon, but here’s what I’m dealing with on SharePoint SE at Sep 2025 CU and SharePoint Workflow Manager at Oct 2025 CU:
1) Running Get-WFFarmStatus shows that the WorkflowServiceBackend keeps trying to start up but eventually winds up in the Stopped state, indicating it is failing to run.
2) Application Event Log shows Event 1000, Application Error with Faulting application name: Microsoft.Workflow.ServiceHost.ext, version: 16.0.19127.20262.
3) Application and Service Logs -> Microsoft-Workflow -> Operational:
Event 358, Microsoft-Workflow:
System.MissingMethodException: Method not found: ‘Void Microsoft.Workflow.Tracing.WorkflowEventSource.MaxMessageProcessingAttemptsOverflow(System.String, System.String, Int32, Int32, Int64, Int64, Microsoft.Workflow.Tracing.EventTraceActivity)’.
4) So, using Microsoft Copilot’s assistance, I wrote a PowerShell script to take a look at the version of the Microsoft.Workflow.Tracing.dll in the Global Assembly Cache, and use reflection to see if the method existed and the parameters for the method.
The version of Microsoft.Workflow.Tracing.dll was 16.0.15601.20416. The method existed in the .dll, but the method parameters were different.
5) Root Cause: Method Signature Mismatch
Microsoft.Workflow.Tracing.dll version 16.0.15601.20416, which defines:
MaxMessageProcessingAttemptsOverFlow(
string scopePath,
string sessionId,
int unknownFailureQuota,
int knownFailureQuota,
int actualUnknownFailure,
int actualKnownFailure,
EventTraceActivity traceActivityId)
But the Workflow Manager runtime (likely updated via a newer CU) expects:
MaxMessageProcessingAttemptsOverFlow(
string scopePath,
string sessionId,
int unknownFailureQuota,
int knownFailureQuota,
long actualUnknownFailure,
long actualKnownFailure,
EventTraceActivity traceActivityId)
The difference is in the actualUnknownFailure and actualKnownFailure parameters — int vs long (Int32 vs Int64).
So to resolve this CoPilot was suggesting installing a different version of the Microsoft.Workflow.Tracing.dll that has the compatible definition for the MaxMessageProcessingAttemptsOverFlow method.
To see if I could find a different version of the Microsoft.Workflow.Tracing.dll, I installed SharePoint Workflow Client and SharePoint Workflow Manager on a test server. Then, upgraded it to the Aug 2025 CU.
The version of Microsoft.Workflow.Tracing when doing that was 16.0.10001.10000. And it had the expected MaxMessageProcessingAttemptsOverFlow with the expected parameters.
My next step will likely be backing up Microsoft.Workflow.Tracing version 16.0.15601.20416 and then copying over and installing the 16.0.10001.10000 version, and see if that resolves my issues. Hopefully, the hot fix will address this issue as well.
Permalink
Hi Stefan,
I updated our SharePoint Workflow Manager with the new client and manager. It will not configure as we are using a SQL Alias. I’m seeing this error in the Event Viewer “The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is “SERVERNAME” (the actual name of ther server rather than the Alias) The TLS connection request has failed. The attached data contains the server certificate.”
is there a way to roll this back?
Thanks for any guidance.
Permalink
Hi Shawn,
it might be you are using a self-signed certificate from the SQL server.
If you are using an SQL Alias you need to install a SAN certificate on the SQL which allow to configure multiple names for the same server.
You can request this either from an internal or an external certificate authority.
Alternatively you need to disable encryption on SQL level and update the connection strings used by WFM to use Encrypt=False
Cheers,
Stefan
Permalink
was getting this after updating with OCT CU, as a workaround we set ForceEncryption flag to No in SQL server
Open SQL Server Configuration Manager, expand SQL Server Network configuration, choose Protocols properties for a desired SQL Server instance (in this case, it is a default instance). Set ForceEncryption option in Flags tab to No and restart sql services
PS C:\Program Files\Workflow Manager\1.0> Get-WFFarm
Get-WFFarm : Keyword not supported: ‘asynchronous processing’.
At line:1 char:1
+ Get-WFFarm
+ ~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-WFFarm], ArgumentException
+ FullyQualifiedErrorId : System.ArgumentException,Microsoft.Workflow.Deployment.Commands.GetWFFarm
PS C:\Program Files\Workflow Manager\1.0> get-sbfarm
get-sbfarm : 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.)
At line:1 char:1
+ get-sbfarm
+ ~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-SBFarm], SqlException
+ FullyQualifiedErrorId : Microsoft.Data.SqlClient.SqlException,Microsoft.ServiceBus.Commands.GetSBFarm
Permalink
Hi,Rebecca
I have same issue. Make sure the table ServiceConfig your Workflow Management DB contains the correct values for WorkflowServiceInstanceMgmtDBConnectionString and WorkflowServiceResourceMgmtDBConnectionString. The update adds the asynchronous processing property to the connection string. This property should be removed.
I hope it helps you.
Permalink
Good morning. Any update on the hot fix? I’m waiting on installing Oct SPWFM on server 2016 until it’s solid. We’re currently running September SPWFM.
Have a blessed day!
Permalink
I recently installed the October 2025 SPWFM CU (without installing the August 2025 CU) and after the October 2025 SP CU was installed. All looked good (all services were running). When testing a workflow using the WMQuicktest.exe I get, test failed – data or messaging layer is unavailable. I thought it was a communication error and unregistered the SPWFM farm from the SP farm to re-register it. I can no longer register the SPWFM farm to the SP Farm.
At some point in my trail and error to get my SPWFM farm back I saw the an “Unauthorized Access is denied due to invalid credential. I do not use a self-sign certificate.
Can this be fixed without rebuilding the SPWFM from scratch?
Permalink
I believe we have figured out the issue. We had a reverse proxy (in SPWFM farm) for a custom workflow solution. After removing that installation and then re-building a new farm with both the August and October 2025 updates, I was able to successfully publish workflows and register the SPMWF to the SP Farm.
We are now migrating data using the disaster recovery process (option 2 – onto different WF server – from 3 to 1). In the past I have done this migration after we have set up a new SPWFM farm (configured with defaults and auto-generated cert). Today when I do it, there are a number of errors and the process cannot be completed. Should option 2 be run without an existing farm in place? Another notable difference is that we are moving from a 3 server SPWFM farm to a 1 server SPWFM farm.