Your farm patched clean. Every workflow on the 2010 engine is now off — by design.— The Reveille Bugle · Quick Answer
Quick answer: the September 2026 cumulative update for SharePoint Server Subscription Edition (KB5002908) disables the SharePoint 2010 workflow engine by default on every site collection — existing ones included. Approvals stall, items sit in “In Progress,” and Nintex for SharePoint on-premises workflows stop outright. The fix is one PowerShell cmdlet per site collection, below. Nothing is lost; the engine is switched off, not removed.
Why this one hurts
Nothing fails loudly. The CU installs clean, the farm reports healthy, and the workflows simply never start. Most teams find out from the business, days later.
01 — The Symptom
What you’re seeing
Any of these, starting the day the September CU landed.
- SharePoint 2010-era workflows won’t start — manually or on item creation — anywhere in a site collection.
- Nintex for SharePoint (on-premises) workflows stop functioning farm-wide.
- Workflows that do start hang in “In Progress” and never create tasks.
- Workflows with InfoPath task forms throw “The specified form template could not be found.”
None of this is corruption, and none of it is your build. Microsoft is retiring the legacy workflow engines for security reasons, and September was the 2010 engine’s date. (Workflow health is one of the things Reveille checks continuously on SharePoint — the full test list is published here.)
02 — The Causes
Four causes, ranked by likelihood
Start at the top. The first one accounts for most of this month’s tickets.
| # | Cause | How to confirm |
|---|---|---|
| 1 | The 2010 workflow engine is disabled by design. KB5002908 turns it off on all site collections, new and existing. | Run Get-SPLegacyWorkflowEnabledSites. If the affected site collection isn’t listed, this is your cause. |
| 2 | The bulk re-enable missed site collections. Teams that prepared often enabled only the “known” workflow sites. | Same cmdlet — diff its output against everywhere workflows actually run, including archived and departmental sites. |
| 3 | InfoPath task forms. The September CU also blocks InfoPath browser rendering (“InfoPath is deprecated”), so 2010 workflows with InfoPath forms fail even where the engine is on. | Error says “The specified form template could not be found.” Reported on the September CU thread; no supported re-enable. |
| 4 | PSConfig wasn’t run everywhere. The CU requires the Products Configuration Wizard on each farm server; a skipped server leaves the farm half-upgraded. | Check upgrade status in Central Administration; look for servers still pending. |
03 — The Fix
Re-enable the engine where the business needs it
One cmdlet per site collection, in the SharePoint Management Shell.
Three things worth knowing. First, the cmdlets ship from the August 2026 CU onward, so farms that patched August can run them before installing September — that’s the clean path if you haven’t patched yet. Second, Nintex published an action-required notice with a bulk script that enables the engine across every site collection hosting Nintex Workflow, so you don’t hand-walk hundreds of URLs. Third, there is no supported fix for the InfoPath form rendering block — treat cause #3 as your forcing function to rebuild those workflows, because re-enabling buys time, not a future.
Microsoft’s rationale is attack surface: the 2010 engine is unsupported code paths in a farm that regulators assume is patched. Every site collection you re-enable is a deliberate, documented exception — keep the list.
04 — Next Month
October does this again — to your 2013 workflows
The same switch flips for the SharePoint 2013 engine in the October 2026 CU.
September was not a one-off. Per Microsoft’s announcement, the October 2026 CU disables SharePoint 2013 workflows by default the same way. Inventory now with Get-SPWorkflow2013EnabledSites, pre-enable with Enable-SPWorkflow2013, and decide per site collection whether the answer is an exception or a migration. (If you’re still on SharePoint 2016 or 2019: the August 2026 CU was your last update ever — your farms are now unsupported, which is its own problem.)
The structural lesson is that this failure was invisible to infrastructure monitoring. Servers up, services green, CPU flat — and every approval in the company stopped. The signal that mattered was at the content layer: did a workflow actually start, run, and create its task? That is the check a patch window needs before the business finds out for you.
Reveille for Microsoft 365
Reveille runs over 95 out-of-the-box M365-specific tests — including SharePoint Timer Job status, Windows Event Log checks, current health warnings and errors, and synthetic site transactions that create, check out, retrieve, check in, and delete a document on a schedule. Run those before and after a CU and a silently disabled workflow engine shows up in minutes, not in next week’s escalation. See Reveille for Microsoft 365 →
Quick answers
