After installing .NET security patches to address CVE-2018-8421, SharePoint workflows stop working (KB 4457916/4457035)


*** FINAL UPDATE II *** Narrowed down the types that need authorization, more info on the scripts, information on Nintex workflows too

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


Comments (167)

  1. Vito says:

    In my case I uninstall this updates: KB4457056, KB4457026, KB4457045, KB4457034
    After that I can publish workflows

    1. You will not be able to postpone updates forever. We are looking for a better solution and will update this post.

      1. Brent Olliver says:

        Are the scripts considered the permanent solution or will a future KB fix this issue?

        1. The issue will be resolved in future SharePoint CUs. The solution will be to add these entries though. Applying this fix will not prevent you from applying future patches.

  2. Christian Schreuder says:

    Hi Rodney

    Thank you for this! All our workflows fell over (we use Nintex which is obviously based on SharePoint workflows).

    Any chance of this happening to other namespaces in System.dll in the future?

    Regards

    1. Hi Christian,

      I believe it is unlikely to happen to other namespaces, but it is not ruled out.

  3. Lucian says:

    Hello Rodney,

    I’ve exactly the same problem on a SharePoint 2013 Farm. I was unable to start or deploy workflows. The solution was to uninstall the last .NET Framework update (KB4087364).

    Where on the SharePoint Server must this be changed to fix it without uninstalling the update?

    Thank you in advance.

    Best regards,
    Lucian

    Where on the SharePoint Server must this be changed to fix to solution without uninstall the update?

    Thank you in advance.

    Best regards,
    Lucian

    1. Post was updated to answer your question.

  4. Mark Taylor says:

    So which of the gazillion config files am I supposed to be correcting, please?

    1. Post was updated to answer your question.

  5. Mark Taylor says:

    OK, so when I edited with notepad and added to the end of the authorizedtype list it didn’t work
    then I edited with vstudio and put it as the frist of the 4.0’s and it was OK.
    not sure if it was a typo at first or the order mattered or something. anyway. Glad for this post!

    1. Post was updated to answer your question.

  6. r Move says:

    Hi,
    We are facing this issue but we are unable to fix it according to your solution. We are using Sharepoint 2010. The symptom is exactly the same but the cause and solution does not math with our web.config we are using .net 2.0 as Sharepoint 2010 needs. Any suggestion?

    1. Script was updated recently to address the problem with SharePoint 2010.

  7. Mateusz says:

    Thanks for sharing it.

    Where to update this line?

    In every web application web.config?

    1. Post was updated to answer your question.

  8. ChrisD says:

    Thanks for this.

    However, it should be clarified which web.config(s) need to be edited.
    I understand the web.config of every Web Application needs to be modified, on every WFE, correct?

    Assuming my understanding is correct, is it not worthwhile to look for a more industrialized solution, for enterprises with large farms and many web app’s?
    E.g. using SPWebConfigModification and PowerShell, as described in http://nikcharlebois.com/modify-sharepoint-web-config-using-powershell/.

    1. Post was updated to answer your question.

  9. spadmin says:

    Can you elaborate on the solution? Where am I adding the solution? Also, when will MS be releasing an update for this regression?

  10. Justin Castleman says:

    Just to be sure can you point us to where this configuration file would be located?

    1. Post was updated to answer your question.

  11. Christian.D says:

    Thanks for this.

    However, it should be clarified which web.config(s) need to be edited.
    I understand the web.config of every Web Application needs to be modified, on every WFE, correct?

    Assuming my understanding is correct, is it not worthwhile to look for a more industrialized solution, for enterprises with large farms and many web app’s?
    E.g. using SPWebConfigModification and PowerShell, as described in http://nikcharlebois.com/modify-sharepoint-web-config-using-powershell/.

    1. That is correct. Thank you for pointing out to the script.

  12. Pavel Shevchenko says:

    whats about shrepoint 2010? there isn’t subkey. and adding to

    dont fix this problem,

    1. Post was updated to answer your question.

  13. anjelo says:

    Hi, where can I find this file? Thanks,

    1. Post was updated to answer your question.

  14. sharepoint admin says:

    Quick question. Where is the location of the .NET config file where the line needs to be changed. I would assume the web.config, but if you could provide a location to the .net config file you modified, that would be appreciated. I am encountering the same issue on Server 2012 R2 and SharePoint 2013.

    1. Post was updated to answer your question.

  15. Bekim Dauti says:

    Hi Rodney,

    Thank you so much for the valuable information, as we’ve been struggling these past three days with the workflow issue! Kindly, would you tell us the path where the solution should be added?

    Thanks in advance!

    peace and blessings,

    Bekim

    1. I updated the post and added a link to a script to automate the changes.

  16. John says:

    This fix also works for SharePoint 2010 with a modification to the version.

    The is no section in the 2010 config, so this change goes under:

    1. I updated the post (and Joe updated the script) to include SharePoint 2010.

  17. SharePoint Admin says:

    Wanted to confirm this issue in our environment and wanted to express my deep appreciation for the quick identification of the issue. We had the same errors you documented above and we applied your fix to the web.config files on all web front end and App servers. We performed IISRESETs after making the changes to the web.config files. We tested afterwords and we can now publish workflows, have an automated workflow start, and manually start workflows.

    Again Thanks for the quick turnaround on the issue!

  18. Chase Huber says:

    two sharepoint foundation 2010 farms, ran the powershell fix on each, still broken.
    rebooted, iisreset, checked that the entries are in web.config,
    still same error in uls.

    1. Both the post was recently updated to fix the problem with SharePoint 2010. We tested on a lab and it worked. Please give it a try again.

      1. Chase Huber says:

        Copied the ps script this morning: 15 Sep.
        Pasted it in ISE, uncommented the line Add-CodeDomAuthorizedType
        Ran the script
        Restarted the server
        Looked in web.config for the affected application, it contains:

        When starting a workflow ULS still reports:

        Microsoft.SharePoint.SPException:
        at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web)
        at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association, Boolean fallback)
        at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow)

        1. Which SharePoint version are you using? The script recognizes your version and should not need to remove comment from any line.

          1. Chase Huber says:

            Line 97.

            I have both 2010 and 2013 Foundation farms. They are both impacted.
            I removed the patches for now.

  19. BCornelius says:

    In our 2010 environment, adding the patch with an IISREST did not resolve the Workflow issues. However it did introduce an error with web parts: “Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.” We have since removed the 2 .Net patches which resolved the web parts issue, but not the work flow issue. The .Net patches that were installed last night are KB4457038 and KB4457030. Removing the patches seems to have touched about a dozen previously installed .Net patches.

    1. BCornelius says:

      As a follow up, MS Premier Support asked us to uninstall KB4457044 and KB4457055. Both are Windows patches that had been installed this month. On reboot, WF’s were working.

      1. Uninstall was the suggestion before we came up with this workaround

    2. This post is only related to KB 4457916 which seems not to be your scenario.

  20. Gene Coleman says:

    Will this affect SharePoint 2007 – please advise.

    1. I have not heard of any case so far.

      1. Robert van Egmond says:

        I can confirm the issues occur also on SP 2007, with the same error messages.
        Applying the work-around solved it, same line as for SP 2010 (dll is present in GAC).
        (setup: SP 2007 with Nintex on 2008 R2 boxes)

  21. Abu Shaeeb says:

    The script worked for me in SP2013. Timely help saved us.

  22. Thanks for sharing Rodney!

  23. Noral Kuhlmann says:

    Is there an impact to SharePoint 2016?

      1. Söllner Robert says:

        Hello,
        this Script was no Help

        Our SharePoiint 2016 still not working

        1. Did you check if the lines were indeed added to web.config?

          1. sravs says:

            Our SharePoint 2016 on premises has same issues. I have updated web.config file as per in the blog. I can able to publish workflow now. But there is issue to start the workflow. We are having an issue as failed to start and workflow is cancelled by system account. I did remove cache in designer.

            Thanks in advance

          2. Check if the web.config files were updated and try IISRESET.

  24. Jordi says:

    Hi,

    Many thanks for the workaround.
    Which could be the side effect of keeping this entry in the web.config? Any security concern?
    On the other hand, as soon as a real fix be released, should we remove the entry in all the web.configs or that entry must remain? What about new web applications (after the fix be released)?
    Thanks!

    1. The namespace being enabled contains only workflow operations. We are still evaluating the risks but it seems safe so far. Come back to this post as we are presently evaluating this.

  25. Robert Söllner says:

    Our SHP 2016 also have that problem, but the script does not help 🙁
    The develeop farm, also SHP 2016, have no problems with this update

    1. Did you check if the script added the required lines?

  26. esstwokay says:

    At the bottom of the script, do I need to uncomment “# Add-CodeDomAuthorizedType” before running?

    1. You are correct. This line needs uncommenting

      1. Justin Castleman says:

        Can you confirm if we need to uncomment the line at the bottom of the script that says Add-CodeDomAuthorizedType? In one comment you said that we should not need to uncomment anything in the script and in another you said that we do need to uncomment it. I just want to be sure that I am understanding this correctly.

          1. Justin Castleman says:

            I apologize for coming back around to this. What is the correct action? Should we uncomment this line or leave it as is. You did not specifically answer my question.

          2. Uncomment:
            # Add-CodeDomAuthorizedType

        1. CClondon says:

          Aha, yes. This worked for me thanks. Had to restart IIS afterwards too. Unbelievable this slipped through testing really.

          The powershell file contains two methods, if you look, at it, half the code is part of Add-CodeDomAuthorizedType, and half is part of Remove-CodeDomAuthorizedType (to undo the fix). To Apply this fix you need to call the Add-CodeDomAuthorizedType method so just remove the ‘#’ from Add-CodeDomAuthorizedType at the bottom of the file. If you don’t uncomment this it will never actually enter that function or do anything.

  27. Sebastian says:

    Hi,
    we are facing the same issue, but the mentioned update are not installed in our environments. Only KB4457035 was installed lately (Windows Server 2008, SharePoint 2010). Is there any solution for that KB available as well? Removing the KB from all SharePoint servers including a reboot sadly did not work

    1. This KB is also related to the same issue. The solution applies.

      1. Sebastian says:

        Hi Rodney,

        I can confirm the script fixed the issue. Thanks

    2. BCornelius says:

      We’re on 2008R2 and SP2010. .Net patches 030/038 were removed. Premier Support asked us to additionally remove Windows Updates KB4457044 and KB4457055. That restored workflow functionality for us.

  28. martin says:

    Will the web.config modification job in the script trigger an iisreset?

    1. It will not recycle. You may need IISRESET

  29. Rahul Babar says:

    Thanks for sharing this!
    Script gave me below error for some reason. Did anyone face same issue?
    Exception calling “ApplyWebConfigModifications” with “0” argument(s): “Name cannot begin with the ‘,’ character, hexadecimal value 0x2C. Line 1, position 2508.”

    Thanks,
    Rahul Babar

      1. Rahul Babar says:

        I tried it could of different ways but still got same error.
        Not sure if this is my environment only.

        Thanks,
        Rahul Babar

        1. Try to run a new workflow, if it does not work, please show me the ULS logs line you see when it fails (truncate if it is too big).

      2. Dave CLay says:

        After running the script does one still have to cancel and restart each Nintex Workflow?

        1. The workflows may be running from OWSTIMER which uses a different config file.

  30. Trevor Fielder says:

    I downloaded the script and ran it on 2010 environment but it did not have any effect on the issue. Verified I saw the new authorization types in the web.config. I did not reboot only IIS reset. Anything else I should be doing?

    1. You are good. Can you paste what you see in the ULS logs after the change (the line is too big, so it is ok if you truncate)

  31. We tried all of the fixes mentioned and we got it working two times for a few minutes and then it went back to failing again. I have more than 600 workflows that I will have to rerun later. They are piling up every minute. Emails aren’t getting sent. Documents are not getting secured. Word documents are not being created and sent to Image Now. Please make this a top priority!

    1. Can you paste the ULS logs entry with the error after the change? Did you double-check the changes are indeed in place in web.config?

      1. I ran the workflows watching ulsviewer and never saw any messages about the issue at all. We desperately need a fix and appreciate your help. We were not sure which web.configs to change on which servers. The system administrator who updated web.config and ran the powershell said:
        “I ran the powershell as administrator on the WFE servers, so I have to presume it ran. I am not sure which web.config needs to be changed honestly. The information was unclear but I presumed the powershell would help that. If I could be given an actual location to check I would. “

        1. If you do not see message with tag 72fs in ULS logs it is because it is not this issue you are facing. If you run the script (you need to uncomment ‘# Add-CodeDomAuthorizedType’) the whole farm web.config file will be updated.

          1. Thank you for your help. This morning, workflows were running again although I have had to remove Pause statements from workflows. Previously, the Pause statements made them work and now the Pause statements keep them from working. I’ve also had to republish some workflows. We don’t know why the fix applied yesterday started working today. The system administrator did not make any additional changes since yesterday. I really appreciate your help!

          2. After applying the script it is necessary to IISRESET all servers to take effect.

  32. Kathy Murphy says:

    Thanks so much for posting! Found this right off and was able to get the issue fixed in no time!

  33. Chad Kealey says:

    We’re seeing the same behavior, but with SP Designer Workflows as well. I assume the same fix applies as for the Out-of-the-box Workflows?

    1. Correct. SP Designer custom workflows qualifies as out-of-the-box for the intent of this post. Non-oob would be the ones created in Visual Studio.

      1. Chad Kealey says:

        Great, thanks! Now I just need to wait for our server admin to apply the fix and see if it works.

  34. søren nielsen says:

    You missed one:
    “CodeTypeReferenceExpression”

    but thanks for the post nevertheless. Helped a lot.

    1. Do you know which Workflow? It does not seem ours include this type.

  35. Eric Halsey says:

    We used the script, the lines were added but now we are getting the following error in ULS. Looks to me like this is another type being used that isn’t in the script?
    RunWorkflow: Microsoft.SharePoint.SPException:

    1. It seems that some people using Nintex workflows also need to add:

  36. Alex Kim says:

    It seems KB 4457920 (Security and Quality Rollup updates for .NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, and 4.7.2 for Windows 8.1, RT 8.1, and Server 2012 R2) does not have KB 4457916/4457035, even if it is a roll up update strange. It won’t break the workflow?

    1. This one will also affect workflow. The solution is the same though.

  37. Palani says:

    Is it mandate to add all the “Type Name” or below is line is fine.
    authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”*” Authorized=”True”

    Initially you blog had the above piece of code, which worked great in Sp 2016 environment. After few hours you added the exact “TypeName”.

    Which one can be used.

    1. Initially we were not sure of all the dependencies. When we learned we made it more restrictive.

  38. Palanee says:

    Hi Rodney,

    Will the below entry works ———“authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”*” Authorized=”True” —— Or———- do i need to add the lines mentioned in the blog. Please confirm.

    1. This line will add all types for System.CodeDom. The entries in the post will add only the types used by oob workflows (an extra line is necessary for Nintex)

  39. Noral Kuhlmann says:

    You mention in your solution that this will fix both SharePoint 2007/2010 so can you please have Joe Rodgers create a PowerShell script for SharePoint 2007 … for both the Web.Config and Timer scripts. It would be appreciated by many.

    Also, thank you for Note 2 – We use Nintex as well in our SharePoint 2016 environment.

    1. In Joe’s script locate -gt 14 and replace by -le 14. This should do it for 2007.
      Glad note 2 helped.

      1. Noral Kuhlmann says:

        So if I understand correctly the two things I would need to do for SharePoint 2007 is change line 4 to
        [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”) > null

        and change line 26 to
        if( $farmMajorVersion -le 14 ) # 2007/2010

      2. Leaha Loredana says:

        Runing the scripts solved the problem partially, this means i ran the script with SPFARM account and only this accoutn can publish the workflows. This is not how it shoudl happen. We have thousand of workflows which need to be published with other users. Please let me know how this can be fixed. This is very bad and it has a huge impact n our environment. Thank you in advance!

        1. The script should resolve the issue to all users. It is a change to Workflow Foundation configuration for the web application. What is the ULS log error you are seeing?

      3. Allen says:

        For 2007…you commented change the following… “In Joe’s script locate -gt 14 and replace by -le 14. This should do it for 2007.” Looking at the scripts per your download, I can’t find anything with “-gt14” in PS scripts. Can you explain further please.

        1. My bad. It is line 39:
          From:
          if( $farmMajorVersion -eq 14 ) # 2010
          To:
          if( $farmMajorVersion -le 14 ) # 2010, 2007

  40. Robert says:

    Hi, on sharepoint 2010 we are using timers, I have found the OWSTIMER.EXE.config but the file has no real contents just

    Can I have some advice about how to include the relevant xml in here please?

    1. Joe prepared a script for it too. However, you only need to run if you are having problems and ULS logs show the process as OWSTIMER.EXE

  41. Gyorgy Herman says:

    While the OWSTimer related script (Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1) makes a backup of the original OWSTIMER.EXE.CONFIG file,
    the script (Add-CodeDomAuthorizedType.ps1) that modifies the sharepoint webapplications web..config files doesn’t create backup of the original web.config.
    It would be nice if the Add-CodeDomAuthorizedType.ps1 would be improved to also include the web.config backup functionality.
    Could you improve it

    1. The update for web.config is made via SharePoint API. No need to backup. Do undo, run:
      Remove-CodeDomAuthorizedType

  42. Devin Kelley says:

    There are two scripts, the first – Add-CodeDomAuthorizedType.ps1 has the following lines commented, do they all need to be uncommented? and do both scripts need to be ran?

    # Get-SPTimerJob | ? { $_.Name -eq “job-webconfig-modification” }

    # Add-CodeDomAuthorizedType
    # Remove-CodeDomAuthorizedType

    The 2nd – Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1 has the following lines commented:

    # $serverNames = @(Get-SPServer | ? { $_.Role -ne “Invalid” } | Select -ExpandProperty Name)
    # Add-CodeDomAuthorizedTypeToOWSTimerConfig -ComputerName $serverNames

    Do these lines also need to be uncommented? This is for Nintex workflows.

    1. For Nintex, you may need to add another type on line 24. I wrote about the change in another reply. This is the line you should uncomment:

      Add-CodeDomAuthorizedType

  43. Chad C says:

    When you update the OWStimer.exe.config file, you may need to add the System.Workflow.ComponentModel.WorkflowCompiler sectiongroup to the top of the config file. Otherwise, your timer service will continually fail because it doesn’t know how to set these settings. Here is our config file the seemed to work:

    1. I will pass this to Joe who wrote the script.

  44. Ramiro says:

    Is there any issue if we keep the TypeName=”*” like it was yesterday? Or should we update the line with the update above

    1. I would remove the entry with “*” and add these known-types instead. We used it before because we were not sure which types were necessary.

  45. Rich says:

    I came up on this post last week and we updated last night and had outages. This piece should be removed from this article “all SharePoint out of the box Workflows fail “. We use no ‘out of the box’ workflows. It causes all workflows to fail on sp2013 enterprise On-prem using Nintex. I understand out of the box to mean the workflows that ship with SharePoint.

    1. As it is not possible to determine which dependencies each third-party workflows have, I can only guarantee that the OOB are failing (and I also heard about Nintex). I added a note for Nintex that requires an extra type for the feedback I received. You may need to follow up with your supplier if these types are not enough.

  46. Thank you, worked perfectly restoring workflow functionality on Windows 2008R2 with SharePoint Foundation 2010.

  47. Is there’s any way to keep my patching cycle working with avoiding such behavior, we’re looking for a better solution as you mentioned before.

    1. Not sure if I understand your question. Can you elaborate?

    2. The solution in this post is exactly like the solution that will be provided in the patch. I confirmed with the product team. Applying this solution will not prevent you to apply any patch.

  48. Ahmad Nazzal says:

    Thank u so much. Thats solved my problem. We have SharePoint 2013.

  49. Tim B says:

    I’m running Joe’s script to make the web config changes via the timer job. I uncommented the line for running the add function. I’m not seeing the timer job execute though. It’s on our dev system so I wouldn’t be surprised if we don’t have something configured correctly. When I query for the job in powershell I see:
    Name Schedule Last Run
    —- ——– ——–
    job-webconfig-mod… 1/1/0001 12:00:00 AM

    I see the timer job definition in CA as well, but it show the same information. I try to run the job and nothing happens via CA or Powershell. Do I need to use stsadm to force the job to execute?

  50. Daniel says:

    I don’t believe this script was tested properly. 2 issues I had using it:
    1) OWSTIMER.EXE.CONFIG may not have configSections for System.Workflow.ComponentModel.WorkflowCompiler
    2) the web app fixup script adds modifications to the admin service, but not to web apps.
    I was able to resolve 1 by editing the file manually to include the configSections. For #2, I couldn’t get the updates to work, and had lots of failing workflows, so I put the entries in manually.

    1. I will pass the feedback to Joe who wrote the scripts.

      1. Joe Rodgers says:

        I have posted a revised version of the owstimer update script at ~6:30 EDT on 09-18-2018 to address the missing element in the owstimer.exe.config file. If you have already run the Add-CodeDomAuthorizedTypeToOWSTimerConfig function against a farm, the function will only add the missing elements (and necessary child elements). Otherwise, the function will add all necessary config updates.

        1. James says:

          Hi Joe,

          Thanks very much for the scripts. The first worked beautifully, but I’m getting errors with the OWS Timer script. We’re running SharePoint 2010 with two web servers under NLB. The script seems to be dropping the servername from the UNC?

          Set-Content : The filename, directory name, or volume label syntax is incorrect.
          At C:\Users\adminjr\Desktop\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:325 char:53
          + $defaultXml.ToString() | Set-Content <<<< -Path $uncPath
          + CategoryInfo : WriteError: (\\\C$\Program F…IMER.EXE.CONFIG:String) [Set-Content], IOException
          + FullyQualifiedErrorId : GetContentWriterIOError,Microsoft.PowerShell.Commands.SetContentCommand

          Get-Content : Cannot find path '\\\C$\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\OWSTIMER.EXE.CONFIG' because it does n
          ot exist.
          At C:\Users\adminjr\Desktop\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:329 char:24
          + Get-Content <<<< -Path $uncPath | Set-Content -Path "$($uncPath)_backup_$(Get-Date -Format 'yyyy_MM_dd_hh.mm.ss').config"
          + CategoryInfo : ObjectNotFound: (\\\C$\Program F…IMER.EXE.CONFIG:String) [Get-Content], ItemNotFoundException
          + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand

          1. Eric Fintel says:

            We had the same problem. We are running SharePoint 2010. Our fix was to modify a portion of the code as follows:
            $idx = 0
            foreach( $timerServiceConfigPath in $timerServiceConfigPaths )
            {
            Write-Verbose -Message “Processing server: $($timerServiceConfigPath.ComputerName)”

            # convert local path to UNC PATH
            $uncPath = “\\$($ComputerName[$idx])\$($timerServiceConfigPath.PathName)” -replace “:”, “$”
            $idx = $idx + 1

  51. Paul Moscatt says:

    Is it or

    should it look like:

    etc?

  52. PURNA says:

    Thanks for the fix, specially adding a note for Nintex.

  53. Kelly says:

    After the fix, workflows are running but some are stuck in a “starting” state. Does this go inline with this issue? Or is this a separate issue?

    1. I would try to stop and restart the workflows that are stuck.

  54. Mohanghimire says:

    Hi Rodney,
    is this issue specifically caused by only KB 4457916/4457035 ?? When I am going through Discussion , someone mentioning “MS Premier Support asked us to uninstall KB4457044 and KB4457055”

    And Second Question , Is it OK to run Script to update Config Anytime earlier before Patch push to servers , is it going to Negatively impact current Environment in the meantime ? We have massive amount of Prod servers So Wanted to make Config update ready So that Anytime Enterprise push these updates we are not impacted

    1. It will not impact future patches. I put some updates on the post.

      1. Mohanghimire says:

        Hi Rodney,
        So if I apply Config Modification now , but September impactful patch has not applied yet (will be applied after 4-5 days), In the interim my Environment has Zero impact adding those tags , right ?

  55. Lori Williamson says:

    Made the changes noted above and workflows still won’t run. ULS error:

    RunWorkflow: Microsoft.SharePoint.SPException:
    at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web)
    at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association, Boolean fallback)
    at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow)
    at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(SPWorkflowHostService host, SPWorkflow workflow, Collection`1 events, TimeSpan timeOut)
    at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection`1 events, SPWorkflowRunOptionsInternal runOptions)

    1. Check if the changes are indeed in web.config. If it is, try an IISRESET. What is the full ULS log entry (you can trim as it is a huge message)

  56. Rick says:

    We have 2008 R2 and Sharepoint 2010 Foundation, but dont have either KB 4457916/4457035 installed, but are getting the error message (-1, -1) Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.)
    (0, 0) Activity ‘ID5’ validation failed: Property “Condition” has invalid value. Condition expression is invalid. The condition expression can not be null.)

    Welcome any suggestions or solutions

    1. It seems you have the problem discussed here. The solution will work for you.

      1. Hi Rodney
        We have the same issue….We have SharePoint 2010. I have un installed KB227175, KB4054530, KB4457035, I have ran your scripts successfully, I have rebooted several times. All workflows are errorring (SP and Nintex) I have restarted IIS. Still get an error when trying to publish a SP workflow that has an if statement.
        Error ‘(-1, -1) Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.)
        (0, 0) Activity ‘ID42′ validation failed: Property “Condition” has invalid value. Condition expression is invalid. The condition expression can not be null.)’
        Please could you advice me on what I can do
        many thanks

        1. What is the process throwing the error? Can you start a new Workflow?

  57. Matt says:

    Another month, another .net patch bug. Have you guys stopped testing them?

    Thanks for the fix.

    1. It is tested on .NET but not against all products using .NET 🙂

  58. Asier says:

    Under SharePoint 2010, the version for the Nintex workaround must be changed from 4.0.0.0, to 2.0.0.0. Could you add this info to the “Note 2”? Thanks!

    1. I recommend you to use the script and to run:
      Add-CodeDomAuthorizedType -IncludeNintexWorkflow

  59. Please can you advice me. We have the same problem. We have SharePoint 2010 on a 2008R server. I have uninstalled KB4054530, KB22175, KB4457044. I have rebooked several times. I have ran your script as suggested, no errors, web.config updated as expected. I have restarted IIS. We still get the following code when publishing workflows with an If statement (-1, -1) Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.)
    (0, 0) Activity ‘ID42’ validation failed: Property “Condition” has invalid value. Condition expression is invalid. The condition expression can not be null.). All workflows are not working. Additional to this our ‘Search’ has a web part error.
    Please help. Many thanks Sam

    1. What is the process throwing the error? Do you have the same problem with starting new workflows?

  60. Mick says:

    @Rodney, we do not have any of the KB’s listed but we do have KB4457144 recently installed and are now seeing these errors. Can you confirm this update can also be a cause?

    1. If you have the same symptoms, the solution applies.

  61. Gareth Roberts says:

    Excellent, this fixed workflows on a 2008R2 server running SP2013, thank you!

  62. Daniel says:

    Does the respective patch for Windows Server 2016, (I believe it’s KB4457131) have the same impact for SharePoint 2016?

    1. As far as I know it is related to .NET Security-Only patches. However, I would test any update in a staging environment before applying to production.

  63. Anthony G says:

    Looks like your script worked for us. The workflow is firing as intended now. Thank you!

  64. ruiming liu says:

    I installed the patch 9/15/2018, since then I got following errors
    1) in event log with ID 1000
    2) “Faulting application name: Fabric.exe, version: 1.0.976.0, time stamp: 0x513fc140”
    3) 2013 workflow stop working,
    4) Service Bus Message Broker stuck at Starting status.

    followed the process of modifying config files. it does not solved the issue.
    any other advice.

    thanks

    1. AppFabric crashing is not related to this issue. The steps here are to resolve issues when you see in ULS logs event 72fs and something like “Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” in the error message.

      1. ruiming liu says:

        Hi Rodney,
        I cannot really say this is related to this patch. the Sharepoint 2013 workflow stop working after we deployed this patch over the weekend.
        all the error messages in Event view are related the Workflow managers, Fabric is just one of them.

        After hours research, I found the causes.
        the application pool account for Workflowmangementpool was removed from both WindowsFabricAdministrators and WindowsFabricAllowedUsers group.

        I added the account back to these two groups. SharePoint 2013 workflows all work again.

        this may not directly related to the patch. hope someone will find this information useful.

        thanks for your post.

        Ruiming

  65. NoName says:

    I’m on Windows 2008 R2 / SharePoint 2013 and was able to run out-of-the-box workflows without any issues. The security patches are installed in this environment. I haven’t tested Nintex yet. Anyone not having any problems with the patch installed?

  66. bbernicky says:

    Thank you VERY much for this – was going a little nuts until I found this. Upon running on my SharePoint 2010 Foundation local server I was getting “local farm not accessible” and found that I had an updated Powershell not compatible with SP2010. Had to run PowerShell.exe -version 2 -NoExit per this article and then all worked well. It took a little time for the SP2010 email to start flowing though. I did create a couple new alerts on a list just to give it a nudge and they all started to come in, FYI in case this all helps someone else reading.
    https://sharepoint.stackexchange.com/questions/53953/suddenly-getting-the-local-farm-is-not-accessible-cmdlets-with-featuredependen

    1. Noral Kuhlmann says:

      PowerShell 2.0 is based on .Net 2.0/3.5. You most likely have PowerShell 3.0 or later which is based on .Net 4.0

  67. Johnny B says:

    Does this also affect workflow manager workflows as well? And if so, does the fix also fix those?

    1. I don’t have this information at the moment. If you have a problem, let us know.

  68. Sravs says:

    We have updated web.config file as per in the blog on our SharePoint on premises environment. But there are some 2010 workflows are not running. they are always having issue with failed to start those 20010 workflows. Any suggestion for to start all 2010 workflows.

    Thanks in advance.

    1. If it is not SharePoint OOB, you should contact your supplier. The problem happens on all OOB workflows, so it is either works for all or not.

Skip to main content