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

Wed, Jan 29, 2025 4-minute read

If you enjoyed the first exciting instalment of this series on Nintex workflows in SharePoint failing to run after security patching and were sad that that was seemingly the end of it, then DON’T WORRY! BECAUSE IT’S BACK.

That’s right, just when you thought all was fine and hunky-dory in the world, your friendly IT service providers once again went ahead and did some more server patching and once again went ahead and managed to knacker Nintex workflows. Specifically workflows using the state machine activity with the behaviour being that workflows simply would never reinflate after switching state.

In thise case, the patches were:

None of these patches mentioned any known issues in the advisory, but that didn’t stop me automatically assuming it was just the same as last time and that the web.config entries would have been blatted.

Well my smugness lasted about 18 seconds when I discovered that the web.configs all looked mostly intact. The modified dates on the web.config did indicate that they had been touched, but I didn’t work out what had changed.

But it did mean it needed some actual troubleshooting. The details of what I did are not particularly of interest - mostly checking web.configs again, making sure the WFEs in the environment were the same, etc, to no avail. More suspiciously was that, unlike last time, I was unable to find a smoking gun issue in the logs.

What I did find was a post on the Nintex community forum which ultimately led to a different (older) post which although different (this was wofklows with pause activities were not… unpausing) the comments and thread was interesting and at least pointing to the same thing - deferred execution of Nintex workflows essentially means it’s handed off to the timer service.

And therein lay the problem. In previous patches/hacks to workflows running, it was common to update the SharePoint timer service config file (OWSTimer.config) file to include the same authorizedTypes that were being added to the web.config.

You remember that from the previous post, right?

Flashback:

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.)

WELL IT TURNS OUT that’s not such great advice. Anymore, at least.

Now, it seems, having an OWSTimer.config that is out of sync with a web.config can cause issues, and it’s now best to not update the timer config file to include authorizedTypes.

The fix, thuslyfore, is to rip all those entries out of it. Here’s how.

  1. Find the OWSTimer.config file

SharePoint 2013 C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\BIN\OWSTIMER.EXE.CONFIG

SharePoint 2016 and Sharepoint 2019 C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\BIN\OWSTIMER.EXE.CONFIG

  1. Backup the OWSTIMER.EXE.CONFIG by creating a copy and giving the copied file a .bak extension (in case the changes need to be reverted)
  2. Edit the OWSTIMER.EXE.CONFIG file with Notepad.
  3. Delete the following node (and all content within this node) from the file.
<System.Workflow.ComponentModel.WorkflowCompiler>
...
</System.Workflow.ComponentModel.WorkflowCompiler>

Yes, the whole node1.

  1. Do this on each server in your Farm hosting a timer service. Save the modified OWSTIMER.EXE.CONFIG file.
  2. Now would be a good time to clear out the timer cache
  3. Restart the SharePoint Timer Service

This should hopefully do it. One thing you might need to do is to restart any workflows that were running at the point it broke.

  1. I mean, if you have other things in there that don’t appear to relate to Workflows, or you know you have something custom running in the timer service that needs it, then maybe leave ’em alone. ↩︎

Posts in this Series