Workflows failing on start after applying July 2025 SharePoint CU/critical security patch

Hi ,  Sorry that you are having issues with your Nintex workflows. We recently published an article in regards to this issue. Please make sure to update your web.configs as mentioned in the article below. 

https://support.microsoft.com/en-us/topic/some-scenarios-of-sharepoint-2010-workflow-are-affected-after-applying-the-july-security-update-for-sharepoint-server-kb5004862-be361cd6-9f54-48c4-b890-2c4b7cf49d13

If you still have issues, please contact Nintex support

Okay thank you! Regarding the section in the technote “f the blocked parts are "out of the box" workflows or workflow activities, contact Microsoft Support.”

I’m assuming Nintex workflows would not be out of the box?

If so, then running the recommended powershell cmdlets may be the most expeditious workaround. 

That is correct

Does it works? My LazyApproval still stuck in running stage after perform those steps cthat recommended.

It does - If you are running into issues, I suggest raising a support ticket at support@nintex.com 

if we recall correctly this was the exact solution that we did for July 2024 security patch;

Add-PSSnapin Microsoft.SharePoint.PowerShell
$farm=Get-SPFarm
$farm.EnablePreParseSecurityCheckForWorkflow = $false
$farm.update()

and also i have verified that even though it set to false, still unable to fix the workflow issue. We have raised to Nintex as well pertaining to this.

We had issues with Nintex workflows as well, but they didn’t fail on start. The way ours presented was that it would error out on email notification steps every time. “Failed to send notification. Access denied.”  This was not a permissions related issue.

I found this post on Microsoft and used a combination of suggested solutions to fix the issue. https://learn.microsoft.com/en-us/answers/questions/5495733/issues-after-applying-sharepoint-2019-updates-kb50

What fixed it for us was updating the web.config (I only needed 6 of those 13 that were mentioned by Martin Chipev because the other 7 were already in my web.config.

Going into this, I had previously removed the node from owstimer.exe.config mentioned by Martin Maryska in the August 7 post (to fix another workflow issue after applying SharePoint CUs!), but had added all of that back per Martin Chipev's post. This produced a situation where email notifications started working again, but would intermittently fail. So then, I went back to my previous version of the owstimer.exe.config without that node. After that it has worked consistently.

I did also reset IIS and restart the SharePoint Timer service.

I also ran the powershell script that was mentioned by Muhammed Sameer P - though I don't know if this made any difference.

Add-PSSnapin Microsoft.SharePoint.PowerShell
$farm = Get-SPFarm
$farm.EnablePreParseSecurityCheckForWorkflow
$farm.EnablePreParseSecurityCheckForWorkflow = $false
$farm.Update()

So, to summarize:

1. Added the following to web.config under <System.Workflow.ComponentModel.WorkflowCompiler> <AuthorizedTypes> <TargetFx version="v4.0">

<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="*" Authorized="True" />

<authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Int64" Authorized="True" />

<authorizedType Assembly="mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Int64" Authorized="True" />

<authorizedType Assembly="Nintex.Workflow, Version=1.0.0.0, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow." TypeName="" Authorized="True" />

<authorizedType Assembly="Nintex.Workflow, Version=1.0.0.0, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow" TypeName="RunNowParameterOptions" Authorized="True" />

<authorizedType Assembly="Nintex.Workflow.Live, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bd539bd4aa1e2820" Namespace="Nintex.Workflow.Live.Actions" TypeName="*" Authorized="True" />

2. Made sure my owstimer.exe.config did not contain the <System.Workflow.ComponentModel.WorkflowCompiler> node

3. Reset IIS and restarted SharePoint Timer service.

And maybe this powershell  cmdlet

Add-PSSnapin Microsoft.SharePoint.PowerShell
$farm = Get-SPFarm
$farm.EnablePreParseSecurityCheckForWorkflow
$farm.EnablePreParseSecurityCheckForWorkflow = $false
$farm.Update()

I hope this can help someone else with the same issues.

Absurd to have to go through all that after applying required patch. 

Hi ​@krettig ,

The web.config entries are on Web Application level, any changes in OWSTimer.exe.config?

Regards,

​@soni  - Ultimately, I ended up using the version of owstimer.exe.config that I had when the problem started.  So, for me, no changes had been needed.  I did, however, make a change and then revert that change back. There was a previous issue with Nintex workflows after a previous SharePoint update that had led me to removing the <System.Workflow.ComponentModel.WorkflowCompiler> node they referenced in the comments of post I linked.

So, if you’re having this problem and haven’t removed that before, then yes, a change may be needed to that file.