(Nintex) Workflows failed to run (after security patching)

It’s been a while¹ since I’ve had to debug obscure SharePoint issues but hey ho, my life remains a rollercoaster of excitement.

A client environment recently had the following updates and cumulative updates applied, which including their SharePoint 2016 Enterprise infrastructure.

• KB5043051 - 2024-09 CU
• KB5043124 - 2024-09 Servicing Stack Update
• KB5002624 - Security Update for MS Sharepoint Enterprise Server 2016 (Description of the security update for SharePoint Enterprise Server 2016: September 10, 2024 (KB5002624) - Microsoft Support)

KB500264 comes with ‘known issues’ that it might knacker workflows:

You might experience an issue in which SharePoint workflows can't be published because the unauthorized type is blocked. This issue also generates event tag "c42q0" in SharePoint Unified Logging System (ULS) logs.

But that (of course) didn’t stop the infrastructure company gaily deploying the patches anyway without any testing. (Yeeeeeehaw.)

Shortly thereafter all workflows duly stopped running with the atypical “Workflow failed to start” message in the workflow status and the customary very little else in the way of usable or meaningful help in the workflow history or ULS logs.

In my experience, security updates routinely break SharePoint workflow (especially if you happen to be running Nintex Workflow) due to its reliance on typed assemblies that SharePoint/Microsoft will commonly treat as being unsafe. Custom entries in your web.config may be stripped out or overridden, and these will almost certainly be caused by other CUs and security updates (e.g., KB5004862)

So initially this was exactly the issue and the fix (which affects versions all the way back to SharePoint 2010) is simple. For each web.config in your enviroment (typically a machine with the web frontend role) find the authorizedTypes section and add the following:

<authorizedTypes>
     <targetFx version="v4.0">
        <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />
    </targetFx>
   </authorizedTypes>

Whilst you’re there, double-check that these puppies also exist:

<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" />

as these have a habit of being munched. Saving the file should be enough to force IIS to recycle the application pool but if you can afford an IISReset then that’s definitely worth doing.

Don’t forget that the OWSTimer has its own web.config (you knew that, right?) So for any delayed actions that are run in the timer service, this may need updating. (And it’s rarely a bad idea to clear out the timer service cache.)

There are also a bunch of other workflow and Nintex actions that may also be marked as not authorized. When looking in the ULS logs, you may see EventIDs like c42q8, c42ra, or c42rh (although there are a mixture of others), and you may see error messages like:

<Error><CompilerError Line="-1" Column="-1" Text="Type System.Workflow.ComponentModel.Serialization.ArrayExtension is not marked as authorized in the application configuration file." />
<CompilerError Line="-1" Column="-1" Text="Type System.Workflow.ComponentModel.Serialization.ArrayExtension is not marked as authorized in the application configuration file." />
</Error>

In this case, you can find the offending item(s) in your web.config and change the ‘Authorized’ attribute to be True (as above). If it’s Nintex, then search the Nintex Community since they have multiple threads covering all the various entries you may need, depending on what you’re using and what has been broken.

Despite the changes, we were still getting some weird issues with very specific workflows, and in our case those that were using a state machine activity. They would initialise, start and run, but then fail with ‘Workflow failed to run’. You may encounter messages like this:

RunWorkflow: System.InvalidOperationException: This feature has been temporarily disabled.

and somewhere before that, under a category of Legacy Workflow Infrastructure, an entry like this:

Potentially malicious XOML node

Again, this is the security system getting involved. You can either work out which action or assembly it is blocking, and modigy your web.config accordingly, or if all else fails, and you have the necessary permissions, you can disable the security checking entirely (yeeehah!), in Powershell or SharePoint Management Shell:

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

This should breathe life back in to your workflows, but don’t forget that these changes are very unlikely to be immune from future CUs and security patches and you may need to do this all again in the future. Don’t you just love SharePoint?