I came across this issue on a few environments lately where ALL workflows in a farm on premise stopped working. Or more specifically, all workflows reported "Failed to start" when triggered to run.

It appears that it is being caused by a .Net Update. One of my colleagues Ozell Walcott found this post from Rodney Viana who details the issue and solution at https://blogs.msdn.microsoft.com/rodneyviana/2018/09/13/after-installing-net-security-patches-to-address-cve-2018-8421-s…

I have not run the powershell script linked in the solution.

Recent update by the original poster

Important - Recent update by the original poster Rodney

As some companies cannot make changes based on Blog posts, we worked on a public KB that can be found here: https://support.microsoft.com/en-us/help/4465015/sharepoint-workflows-stop-after-cve-2018-8421-security-update

The KB has a watered down version of Joe's script. If you have Nintex workflows, favor the scripts on this post.

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:

<System.Workflow.ComponentModel.WorkflowCompiler>

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

And for SharePoint 2007 and 2010, use these lines:

Solution

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

Or (for SharePoint 2007 and 2010):

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 aSharePoint Hive Folder]inOWSTIMER.EXE.config. The Hive Folder will change by version of SharePoint. For SharePoint 2016, it is normally at c:program filescommon filesmicrosoft sharedweb server extensions16. For 2013, at c:program filescommon filesmicrosoft sharedweb server extensions15.

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:

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

Page 1 / 1

Thanks Andrew Glasser .. this was happening on our dev environment as well, assuming the patches have still not gone to QA or production, but thanks for pointing it out.

Do we know when MS will resolve this?

Regards,

Shrini

This worked for my server. Everything is back on working.

My workflows were on Failed on Start status. I was also not able to publish any workflow, was getting below error:

I thankfully didn't run into this issue (yet), but wanted to thank Andrew Glasser for posting this valuable solution. It is this type of help that keeps this community strong.

Linking to a couple of other message threads about this:

We had the same issue, However we had to uninstall the security update to get our workflows running again in our SharePoint 2016 environment.

Microsoft will hopefully drop a hotfix update shortly to allow us to update to the latest security requirements.

Thanks everyone for the feedback. I checked the original post and there have been some updates. So keep checking back on the original post for any hotfix updates. But I did see that a public KB was created, so something may be in the works, or they may keep this as the solution (since it went to KB).

=========================

As some companies cannot make changes based on Blog posts, we worked on a public KB that can be found here: https://support.microsoft.com/en-us/help/4465015/sharepoint-workflows-stop-after-cve-2018-8421-security-update

The KB has a watered down version of Joe's script. If you have Nintex workflows, favor the scripts on this post.

I also ran into this issue but found that the scripts did not work for me. The web.config script didn't make any changes to the web.config file, so I had to apply the changes manually. The owstimer script made the changes but that did not fix the issue - owstimer still threw out the 'unauthorized' messages. I am planning to roll back the .Net update instead.

This worked perfectly thanks a lot.

Our network team said they tried these solutions but we still are experiencing issues. For now we have rolled back while the network team works directly with Microsoft.

How is it added to the OWSTimer.EXE? What's the format Headers Sections?

My Monday morning has been fun

Hey everyone! Microsoft has finally address the issue and the details can be see at Microsoft .Net Framework security update‌ thanks Alistair Cloke‌!

Andrew/Alistair. Thanks for the article and the update. I run the Microsoft script in out SP2010 environments and it appears to have resolved all Nintex workflows, except for Nintex Projects. I've also looked at your link from today, but it's not clear how Microsoft has addressed the issue. Do you mean they are not promoting the addition of the allowing the assemblies? Do you know what other assemblies we would have to add for Nintex Project Workflow 2010? - Thanks Deon

Please note that if you are using the automated powershell linked at https://blogs.msdn.microsoft.com/rodneyviana/2018/09/13/after-installing-net-security-patches-to-address-cve-2018-8421-sharepoint-workflows-stop-working/#comment-21195 then the assembly reference for

wasn't added to my web.configs and I kept getting errors publishing. Added manually and voila...

Hi guys,

Looks like there's one piece missing from the puzzle. We've been struggling with this for a long time, and there was little help from either MS or Nintex support engineers, unfortunately, as they kept referring to Rodney Viana's article without giving the workflow architecture a thorough thought. However, one of our admins deserves credit for recalling that application servers running timer jobs without web applications deployed heavily depend on workflow configuration settings cached in appropriate content/config databases. This led us to run something like $nwWebApps | foreach{$_.UpdateWorkflowConfigurationSettings()} via PowerShell, and, finally, scheduled workflows work and there are virtually no cases of "failed on start" that plagued us for over a month now.

Hurray. Hope this helps if there's still anyone suffering.

Someone had posted this in Rodney's comment thread two months ago. Wish we had seen it at that time.

October 17, 2018 at 4:20 am

Wish we had seen it earlier as well. Thank you for posting this update here since we just referred back to this article today looking for a fix. Your post was exactly what we needed to solve our scheduled workflow issue puzzle.

Thanks for the confirmation

Andrew Glasser‌ thank you very much for sharing your insight on this. Helped me fix the issue on my newly created VM

after we applied the fix everything seems to be working until I tried to start the timer service and it tells me I have an xml error in the OWSTimer.exe.config file.

at a quick glance I don't see any strange xml .

any thoughts, the error is on 2nd to last line supposedly

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="KWizCom.SharePoint.Foundation" publicKeyToken="30fb4ddbec95ff8f" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-20.0.0.00" newVersion="13.3.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="KWizCom.Foundation" publicKeyToken="30fb4ddbec95ff8f" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-20.0.0.00" newVersion="13.3.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
<System.Workflow.ComponentModel.WorkflowCompiler>
<authorizedTypes>

<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" />
<authorizedType Assembly="System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeTypeReferenceExpression" Authorized="True" />

</authorizedTypes>
</configuration>

Symptom

Cause

Solution

Additional Information

Note

Note 2

Note 3

Reply

View our Community Site Map

Symptom

Cause

Solution

Additional Information

Note

Note 2

Note 3

Reply

View our Community Site Map

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded