The end of SharePoint 2010 workflows

On July 6, Microsoft announced that they will be retiring SharePoint 2010 workflows from November 1, 2020. I decided when reading the news that I would hold fire on writing something just to let the dust settle a little bit.

So after being inspired by John Liu’s blog post, I’ve decided to keep my own rolling list of resources to help myself and hopefully others transition from SharePoint 2010 workflows to Power Automate.

Background

Microsoft had stated in 2016 that support would continue for SharePoint 2010 workflows until 2026, but with this month’s announced they specified that:

– Starting August 1st, 2020, SharePoint 2010 workflows will be turned off for newly created tenants.  

– Starting November 1st, 2020, Microsoft will begin to remove the ability to run or create SharePoint 2010 workflows from existing tenants.

Support update for SharePoint 2010 workflows in Microsoft 365

This applies to both out-the-box and custom SharePoint 2010 workflows, but only in Microsoft 365. If you are still on premises this does not apply to you as they are still being supported until 2026 at the time of writing, but I imagine you have your own issues to deal with!

For SharePoint 2013 workflows, Microsoft announced they will remain supported, but depreciated. So that means that SharePoint 2013 workflows will be turned off by default for new tenants starting in November 2020, but Microsoft will provide a PowerShell script to activate the workflow engine. 

What does this mean?

Unless Microsoft has a change of heart, what this means is that over the next 4 months all SharePoint 2010 workflows will need to be re-developed using Power Automate, Nintex or any other another third-party workflow solution.

Microsoft offer a modernization scanner that (amongst other things), will understand where “classic” workflow is being used and sort of grade them based on number of actions and complexity. However, this scanner only works for SharePoint Online, so if you’ve yet to migrate to Microsoft 365 you will need to use another assessment/ inventory tool to get this sort of information about your SharePoint 2010 workflows.

What I’m going to do

So for myself, my organisation has several SharePoint 2010 and Nintex workflows on premise that have yet to be migrated to Microsoft 365 and are largely still in use.

As part of discovery work conducted previously, I’ve used a combination of ShareGates site report to get the high level information about my sites(s), the SharePoint Migration Assessment Tool to get information about my SharePoint workflows and a PowerShell script to get similar information about the Nintex workflows.

Even with a complete list of SharePoint 2010 workflows, there is still some documented pain points that will require some thought to overcome – this won’t be a straight copy/ paste into Power Automate 😀

However, with that said the plan is essentially the same as before; assess the active workflows, consolidate where possible and re-build the SharePoint workflows in Power Automate – only in a much shorter time frame…

Resource list

I will keep updating this list as I see new articles, or information from Microsoft and others.

Background information

Guidance and other useful info

Tools

How to fix SharePoint workflow files that are checked out

I recently ran into an issue where I was getting the dreaded “failed on start” error for some of the workflows in a SharePoint 2010 environment. At first I was concerned that some sort of Microsoft KB had killed workflows again as described here and here.

However, that didn’t appear to be the case. After some investigation I noticed that the files that make up a particular list/ library workflow were checked out!

The problem(s)

This first issue was the “failed on start” error message in the workflow field within the list. It was a pretty niche edge case though as it appeared to only affect newer workflows that contained a send email action.

Another interesting issue was that when creating brand new workflows to test if the error persists brought its own set of problems. Once published, the new workflow would appear as normal to be ran manually for a new list item and would proceed to fail on start.

Workflows failing on start from within SharePoint 2010.

However, any new list items would not have the workflow listed to be ran against. Jumping back into SharePoint Designer proved equally useless as clicking on the workflow within the list just brought you to a SharePoint error.

Then I found that digging deeper into the workflow files within SharePoint Designer showed that some of the files that make up a workflow were in a checked out state – what?

You are unable to check these files in, as when you try you receive a message stating:

“Server error: you cannot discard check out because there is no checked in version of the document. please delete this document instead”.

After googling this, as I’d never seen this before led me to this brilliant post on SharePoint stack exchange which brought me to a resolution. Specifically, this comment:

I also would like to thank TashasEv for his answer. It provided the key clue I needed for troubleshooting a similar problem. In my case, it was not the Document content type which had the title set to Required, but the User Workflow Document content type.

This is one of two content types that are shown listed when (in SPD) you right-click on the Workflows folder in the left Navigation panel (the other being Folder). I used the Administration Web Page (it’s a button in SPD when on the Properties tab for the Workflows folder). Changing the Title property of this content type to Optional solved the issue.

https://sharepoint.stackexchange.com/questions/75978/workflow-files-wont-check-in-cant-undo-checkout

Solution

So as described in the above post, here are the steps involved:

1. Find the hidden properties menu

  • Open SharePoint Designer 2010 and open the site where you workflow is running
  • Press All Files > Workflows
Open Workflows from with All Files in SharePoint Designer.
In Workflows, after clicking on the affected workflow you will see all the files associated that are in a checked out state.
  • Right-click on any workflow (I selected the affected one) > press Properties
“Hidden” properties button can be found by right-clicking on a workflow.

2. Set the title of the user workflow document content type to optional

  • Within Properties, under Content Types > select User Workflow Document
  • Under Customization > press Edit content type columns
Within the User Workflow Document, press the edit content type columns button.
  • Select the Title column > then press Administration Web Page
  • This will open a browser window, under column settings set the column to Optional
Make the hidden title column optional from the administration web page.

3. Re-publish the affected workflow(s)

  • Navigate to the affected workflow(s) via the Lists and Libraries section
  • Open your workflow, make a small amend > Save and Publish

Now, when you run the workflow(s) affected they should complete as normal, and if you check the files within the All Files > Workflows section in SharePoint Designer they should be checked in and all OK.

SharePoint and Nintex workflows failing on start after .NET security update

Updated


I’ve wrote part two on this issue with my full resolution steps here:

SharePoint and Nintex workflows failing on start – part two


The problem


I had this issue myself in the last week where EVERY SINGLE workflow across the farm on premise stopped working. SharePoint Designer and Nintex workflows all reported “Failed to start” when triggered to run.

The workflows stopped working due to a series of .NET security updates Microsoft released in September 2018. Microsoft released a public KB article on this – with resolution steps which can be found below:

But also this msdn blog post contains all the solution scripts and steps that includes Nintex workflows also (transcript below):

I noticed shortly after the fix was implemented that some of my SharePoint designer workflows were exhibiting odd behaviour. For example the screenshot below shows a SharePoint desinger workflow that previously worked without issue or errors in the history after the fix was applied:

Someone on reddit had already spotted this which drew my attention to the common issue, this only presents itself for workflows with pause steps!

I will update this post with my findings once this latest fix is applied.

Symptom

After applying .NET Security Only patch to resolve CVE-2018-8421 (Remote Code Execution Vulnerability) , all SharePoint out of the box Workflows fail to execute and the log will show an error like this:

09/13/2018 01:59:07.57 w3wp.exe (0x1868) 0x22FC SharePoint Foundation Workflow Infrastructure 72fs Unexpected RunWorkflow: Microsoft.SharePoint.SPException: <Error><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″…

The error suggest that System.CodeDom.CodeBinaryOperatorExpression is not in the authorized types.

Cause

Workflow Foundation (WF) will only run workflows when all the dependent types and assemblies are authorized in the .NET config file (or added explicitly via code) under this tree:

<configuration>

<System.Workflow.ComponentModel.WorkflowCompiler>

<authorizedTypes>

<targetFx>

However, after the update, the following lines are necessary for SharePoint 2013 and beyond:

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePrimitiveExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodInvokeExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeFieldReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeThisReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePropertyReferenceExpression” Authorized=”True” />

And for SharePoint 2007 and 2010, use these lines:

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePrimitiveExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodInvokeExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeFieldReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeThisReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePropertyReferenceExpression” Authorized=”True” />

Solution

The solution is to add explicitly the types to all web applications’ web.config:

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePrimitiveExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodInvokeExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeFieldReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeThisReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePropertyReferenceExpression” Authorized=”True” />

Or (for SharePoint 2007 and 2010):

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePrimitiveExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodInvokeExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeFieldReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeThisReferenceExpression” Authorized=”True” />

<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePropertyReferenceExpression” Authorized=”True” />

Please notice that sometimes SharePoint Timer Service (SPTimerV4) runs workflows. If you notice that the application showing the error is ULS logs in OWSTIMER.EXE, you should also include the authorized types in [SharePoint Hive Folder]\bin\OWSTIMER.EXE.config. The Hive Folder will change by version of SharePoint. For SharePoint 2016, it is normally at c:\program files\common files\microsoft shared\web server extensions\16. For 2013, at c:\program files\common files\microsoft shared\web server extensions\15.

Additional Information

My colleague Joe Rodgers, who is Sr. PFE, put together this PowerShell script: https://gist.github.com/joerodgers/2302b394796c865818839d843bae2dad

There are two scripts. Normally, the only necessary script is:

Add-CodeDomAuthorizedType.ps1

Uncomment this line to make the changes:

Add-CodeDomAuthorizedType

If you have Nintex workflows you should run like this:

Add-CodeDomAuthorizedType -IncludeNintexWorkflow

To undo the changes, run:

Remove-CodeDomAuthorizedType

The script needs to run only once on any WFE. All web.config files related to SharePoint on all servers will be modified. New web applications created after that will also include the changes. Even if a new WFE is added to the farm, the entries will also be included in web.config. The change is a permanent requirement from now on since the WF patch. You do not need to undo the change before applying the SharePoint patch addressing it.

There is a second script to update OWSTIMER.exe.config. This one should only run if you see the symptoms in ULS logs with process OWSTIMER.EXE. Otherwise, you do not need to update. if you have the problem though, you need to rerun the script if a new machine is added to the farm. No line needs to be uncommented for this one. The script name is:

Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1

Note

Microsoft is aware of this issue and patches for SharePoint 2010, 2013 and 2016 are being worked as of 9/17/2018. I will update when we have an ETA. I had confirmation from the product team on 9/18/2018 that this information and solution on this post is in the line with the future patch and it is the recommended action plan until the patch is out. If anything change, I will update the post.

Note 2

Some people using third-party workflows (like Nintex) need to also include this:

<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeTypeReferenceExpression” Authorized=”True” />

Using the script, you need to add to the line defining types (line 24):

CodeTypeReferenceExpression

Example:
$typeNames = @( CodeBinaryOperatorExpression, CodePrimitiveExpression, CodeMethodInvokeExpression, CodeMethodReferenceExpression, CodeFieldReferenceExpression,CodeThisReferenceExpression, CodePropertyReferenceExpression“, “CodeTypeReferenceExpression”)

Note 3

Joe updated his script to add a switch for Nintex workflows.

Call this way to include the extra type required by Nintex:

Add-CodeDomAuthorizedType -IncludeNintexWorkflow

(all credit to Rodney Viana for this information)