Getting this error in set a condition action while publishing a workflow

Error

Page 1 / 1

This is happening to our SharePoint On Premise 2013 installation (which isn't using Nintex, just the 2010 engine), and I think that their most recent patch has broken something with the Workflow Engine.

The only other information I could find (where people are talking about this) can be found here: Sharepoint 2013 - "Collect Signatures Sharepoint 2010" Workflow - "Type System.CodeDom.CodeBinaryOperatorExpression is n…

As you can see, the error regarding "System.CodeDom" as well as the date are the common threads.

People there are attempting to roll back the patches, and we're in the process of trying to do something similar ourselves... Really hope this gets resolved by Microsoft soon, as we're completely locked out of our workflows and cannot even shut off the Auto Start feature because we can't even publish them!!!

Gah!

Just to add to this and if anyone finds it helpful.

We experienced the same issue this morning, except it was only identified because no workflows were starting anywhere. ULS logs were throwing the same error as above.

There is a Microsoft thread on the issue here: Sharepoint 2013 - "Collect Signatures Sharepoint 2010" Workflow - "Type System.CodeDom.CodeBinaryOperatorExpression is n…

We are on Sharepoint 2013 and Server 2012 R2. Resolved the issue by uninstalling patches on the Web Front End servers:

KB4457034
KB4457045
KB4457056
KB4457026

Then declining the parent KBs:

KB4457920
KB4457916

Patch KBs will depend on your underlying OS.

A lot of people should be adding QA Experience @ Microsoft on their CV. Been nothing but a burning wreck of things that occasionally work the past two years.

Hi,

Thank you so much for prompt reply.

Do you have any idea how long it might take to fix this issue?

Thanks,

Dishant

There is currently a WORKING workaround to this!!!!

Log onto the SharePoint server that your site is on.

You'll need to navigate to the drive where your SharePoint Web installation is installed on. For instance, if you made a Web App on port 80 (and that's where the Workflow in question that is no longer working is located), then the following directory might work:

C:inetpubwwwrootwssVirtualDirectories80‍

Inside of that directory, you will find a file called "web.config"

(I suggest making a BACKUP of this file if you haven't already. Just copy it somewhere safe)

Inside of that file (edit in notepad, notepad++, or whatever editor you choose), you will find a bunch of xml. It'll be faster if you just search for the following line:

<System.Workflow.ComponentModel.WorkflowCompiler>‍

Once you have found that, you will look for the following child nodes:

<authorizedTypes>
      <targetFx version="v4.0">‍‍

(your targetFx may or may not have the version attribute on it... it doesn't matter)

directly after the targetFx node, you should be able to add the following line

<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="*" Authorized="True"/>‍

Please look at the following post by MS if you'd like to understand more about what happened and why this fixes it: After installing .NET security patches to address CVE-2018-8421, SharePoint workflows stop working – Rodney Viana's (MSF…

I have already made this change on my Web App and now my workflows work again!

I hope that this helps!

We stumbled across this this morning.

Thanks Microsoft.

Luckily we caught it on the Dev environments and we're going to skip this round of updates rather than meddling with the web.configs for now.

I'll type out some of the error so others may find it.

soap:ServerServer was unable to process request. Failed to publish workflow

CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.

Condition expression is invalid. The condition expression can not be null

#microsoft

We also experienced this issue after patching over the weekend in preparation to update SharePoint itself. The Web.Config modifications went easily and seamlessly, and resolved the issue immediately. No ISS resets or recycling of app pools.

Same link from above by NM.

https://blogs.msdn.microsoft.com/rodneyviana/2018/09/13/after-installing-net-security-patches-to-address-cve-2018-8421-sharepoint-workflows-stop-working/

File was easy to find and modify. It was located in the default C:inetpubwwwrootwssVirtualDirectories then the folder for your site being impacted.

The section you need to add it too is way down toward the bottom. Stuff in bold below is part of the original file, the lines not in bold are what was added per the Microsoft article above to include the extra line for Nintex. We only had 3 servers so we did it by hand on each of them, only took a few minutes.

<System.Workflow.ComponentModel.WorkflowCompiler>
<authorizedTypes>
<targetFx version="v4.0">

        <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" />
        <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="WhileActivity" Authorized="False" />
        <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="ConditionedActivityGroup"

We performed this fix and are now able to publish successfully. Our scheduled workflows that were errored with "failed on start" are now running again as well. So, that's the good news.

One thing we noticed though is that our previous versions of workflows are now appearing when scheduling site workflows, manually starting list workflows, and the existing schedules are running previous versions instead of the current versions. That's the bad news.

Has anyone else seen this behavior? I'm assuming it is related because it seemed to start right after we updated our config to fix this issue, but I'd love to have someone else validate that. Thanks!

Here is an example of what appears when I am creating a schedule

nintex previous versions appear in workflow scheduler

Checked my environment and am not seeing this behaviour.

That would be odd and annoying for sure.

Ok, thanks for checking! I just created a separate thread for this here:

The below script worked for me. Nintex support recommended this.

https://blogs.msdn.microsoft.com/rodneyviana/2018/09/13/after-installing-net-security-patches-to-address-cve-2018-8421-s…

script: https://gist.github.com/joerodgers/2302b394796c865818839d843bae2dad

nintex worklow‌ failed on start‌

It totally worked! Thank you!!! I had updated Windows 2012 server with the latest patches and it all blew up, same error over and over:

(Server was unable to process request. ---> Failed to publish workflow: <Error> <CompileError="-1" Column="-1" Text="Type System.CodeDom.Code BinaryOperatorExpression is not marked as authorized in the application configuration file.")

I updated Nntex 2013 workflow from 3.3.0 to the latest 3.3.1 but same issue. Then you came along.

Your fix makes sense, it simply adds the permissions to the Web.config. This isn't a workaround... it's the proper fix for the new patches! Thanks so much again.

Everyone remember to restart IIS after you update the Web.config, of course.

Reply

View our Community Site Map

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