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

项目
09/13/2018

* FINAL UPDATE VI * SharePoint CUs are out

The Nov 2018 SharePoint CUs

The SharePoint with fixes are available. Some environments using third-party solution may still need to follow the steps on this post:

Description of the security update for SharePoint Enterprise Server 2016: November 13, 2018 (KB4461501) Description of the security update for SharePoint Foundation 2013: November 13, 2018 (KB4461511) Description of the security update for SharePoint Server 2010 Office Web Apps: November 13, 2018 (KB4461527)

Important

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.

We put together a video with step-by-step. It does not need to be a confusing thing. Found the video here (you can go straight to the video instead of following instructions here):

https://blogs.msdn.microsoft.com/rodneyviana/2018/10/12/step-by-step-video-on-how-to-fix-the-sharepoint-workflow/

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 [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:

If you are using SharePoint 2010, use this instead:

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

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

Note 4

Some very rare cases require that you add All entries that exist in your web.config (include the new ones added by the script) to OWSTIMER.EXE.config

I explain this (narration by Keith Richie, thanks Keith Richie for adding narration) in the video referenced in the beginning of this post.

Comments

Anonymous
September 13, 2018
In my case I uninstall this updates: KB4457056, KB4457026, KB4457045, KB4457034After that I can publish workflows
- Anonymous
  September 14, 2018
  You will not be able to postpone updates forever. We are looking for a better solution and will update this post.
  - Anonymous
    September 19, 2018
    Are the scripts considered the permanent solution or will a future KB fix this issue?
    - Anonymous
      September 19, 2018
      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.
      - Anonymous
        September 20, 2018
        I am facing issues in SharePoint Online with sharepoint designer workflows from last one week. They were working perfectly fine but now they are failing to start.Is there any solution for SharePoint Online.
        
        Anonymous
        September 20, 2018
        A patch is being worked out for online. Please contact SharePoint Online support for updates.
      - Anonymous
        October 11, 2018
        Hi Rodney, A quick concern, we excluded the last windows KB updates(11th September). If we will apply this week windows update (9th October) then, Is there any possibilities of getting Workflow failure error. If yes then will this script will help us to fix? SharePoint version: SharePoint 2013 and SharePoint 2016
        
        Anonymous
        October 12, 2018
        You are correct. You can apply the fix in this post before applying .NET patches to avoid downtime. Use a test environment first.
Anonymous
September 13, 2018
Hi RodneyThank 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
- Anonymous
  September 14, 2018
  Hi Christian,I believe it is unlikely to happen to other namespaces, but it is not ruled out.
Anonymous
September 13, 2018
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,LucianWhere on the SharePoint Server must this be changed to fix to solution without uninstall the update?Thank you in advance.Best regards,Lucian
- Anonymous
  September 14, 2018
  Post was updated to answer your question.
Anonymous
September 13, 2018
So which of the gazillion config files am I supposed to be correcting, please?
- Anonymous
  September 14, 2018
  Post was updated to answer your question.
Anonymous
September 14, 2018
OK, so when I edited with notepad and added to the end of the authorizedtype list it didn't workthen 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!
- Anonymous
  September 14, 2018
  Post was updated to answer your question.
Anonymous
September 14, 2018
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?
- Anonymous
  September 15, 2018
  Script was updated recently to address the problem with SharePoint 2010.
Anonymous
September 14, 2018
The comment has been removed
- Anonymous
  September 14, 2018
  Post was updated to answer your question.
Anonymous
September 14, 2018
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/.
- Anonymous
  September 14, 2018
  Post was updated to answer your question.
Anonymous
September 14, 2018
Can you elaborate on the solution? Where am I adding the solution? Also, when will MS be releasing an update for this regression?
Anonymous
September 14, 2018
Just to be sure can you point us to where this configuration file would be located?
- Anonymous
  September 14, 2018
  Post was updated to answer your question.
Anonymous
September 14, 2018
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/.
- Anonymous
  September 14, 2018
  That is correct. Thank you for pointing out to the script.
Anonymous
September 14, 2018
whats about shrepoint 2010? there isn't subkey. and adding to dont fix this problem,
- Anonymous
  September 14, 2018
  Post was updated to answer your question.
Anonymous
September 14, 2018
Hi, where can I find this file? Thanks,
- Anonymous
  September 14, 2018
  Post was updated to answer your question.
Anonymous
September 14, 2018
The comment has been removed
- Anonymous
  September 14, 2018
  Post was updated to answer your question.
Anonymous
September 14, 2018
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
- Anonymous
  September 14, 2018
  I updated the post and added a link to a script to automate the changes.
Anonymous
September 14, 2018
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:
- Anonymous
  September 14, 2018
  I updated the post (and Joe updated the script) to include SharePoint 2010.
Anonymous
September 14, 2018
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!
Anonymous
September 14, 2018
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.
- Anonymous
  September 14, 2018
  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.
  - Anonymous
    September 15, 2018
    The comment has been removed
    - Anonymous
      September 15, 2018
      The comment has been removed
      - Anonymous
        September 16, 2018
        The comment has been removed
Anonymous
September 14, 2018
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.
- Anonymous
  September 14, 2018
  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.
  - Anonymous
    September 15, 2018
    Uninstall was the suggestion before we came up with this workaround
- Anonymous
  September 15, 2018
  This post is only related to KB 4457916 which seems not to be your scenario.
- Anonymous
  October 24, 2018
  We ran into the same issue and we fixed the workflow issue by adding Authorized Type entries to web.config. But we are still having 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.” issue and we had to restart the server to fix this issue. Can you let us know what are the steps to fix this issue.
  - Anonymous
    October 24, 2018
    I can't tell much about it without more detailed analysis. But if restarting the server works, maybe IIS RESET would suffice.
Anonymous
September 14, 2018
Will this affect SharePoint 2007 - please advise.
- Anonymous
  September 15, 2018
  I have not heard of any case so far.
  - Anonymous
    September 16, 2018
    The comment has been removed
    - Anonymous
      September 17, 2018
      Thanks for heads up.
Anonymous
September 15, 2018
The script worked for me in SP2013. Timely help saved us.
Anonymous
September 15, 2018
Thanks for sharing Rodney!
Anonymous
September 15, 2018
Is there an impact to SharePoint 2016?
- Anonymous
  September 15, 2018
  Yes. It also affects 2016.
  - Anonymous
    September 16, 2018
    Hello, this Script was no HelpOur SharePoiint 2016 still not working
    - Anonymous
      September 17, 2018
      Did you check if the lines were indeed added to web.config?
      - Anonymous
        September 19, 2018
        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
        
        Anonymous
        September 19, 2018
        Check if the web.config files were updated and try IISRESET.
Anonymous
September 17, 2018
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!
- Anonymous
  September 17, 2018
  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.
  - Anonymous
    October 10, 2018
    Hi,After running both scripts pause and wait actions stopped working
    - Anonymous
      October 12, 2018
      See the video with step-by-step added to the post.
      - Anonymous
        December 05, 2018
        The comment has been removed
Anonymous
September 17, 2018
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
- Anonymous
  September 17, 2018
  Did you check if the script added the required lines?
Anonymous
September 17, 2018
At the bottom of the script, do I need to uncomment "# Add-CodeDomAuthorizedType" before running?
- Anonymous
  September 17, 2018
  The comment has been removed
  - Anonymous
    September 17, 2018
    The comment has been removed
    - Anonymous
      September 17, 2018
      That is correct.
      - Anonymous
        September 17, 2018
        The comment has been removed
        
        Anonymous
        September 17, 2018
        Uncomment:# Add-CodeDomAuthorizedType
    - Anonymous
      September 18, 2018
      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.
Anonymous
September 17, 2018
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
- Anonymous
  September 17, 2018
  This KB is also related to the same issue. The solution applies.
  - Anonymous
    September 17, 2018
    Hi Rodney,I can confirm the script fixed the issue. Thanks
- Anonymous
  September 17, 2018
  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.
  - Anonymous
    September 24, 2018
    I'm having the same issue.... Did you ever get this resolved? We are also running Win2008R2 and SharePoint2010.
Anonymous
September 17, 2018
Will the web.config modification job in the script trigger an iisreset?
- Anonymous
  September 17, 2018
  It will not recycle. You may need IISRESET
Anonymous
September 17, 2018
The comment has been removed
- Anonymous
  September 17, 2018
  it may be because of the way you copied and pasted. Use this raw view link instead:https://gist.githubusercontent.com/joerodgers/2302b394796c865818839d843bae2dad/raw/711af18082849beb5f4d86691e7f3587ec0b15d6/Add-CodeDomAuthorizedType.ps1
  - Anonymous
    September 17, 2018
    I tried it could of different ways but still got same error.Not sure if this is my environment only.Thanks,Rahul Babar
    - Anonymous
      September 17, 2018
      The comment has been removed
  - Anonymous
    September 17, 2018
    After running the script does one still have to cancel and restart each Nintex Workflow?
    - Anonymous
      September 17, 2018
      The workflows may be running from OWSTIMER which uses a different config file.
  - Anonymous
    September 25, 2018
    The comment has been removed
Anonymous
September 17, 2018
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?
- Anonymous
  September 17, 2018
  The comment has been removed
Anonymous
September 17, 2018
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!
- Anonymous
  September 17, 2018
  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?
  - Anonymous
    September 17, 2018
    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. “
    - Anonymous
      September 17, 2018
      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.
      - Anonymous
        September 18, 2018
        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!
        
        Anonymous
        September 18, 2018
        After applying the script it is necessary to IISRESET all servers to take effect.
Anonymous
September 17, 2018
Thanks so much for posting! Found this right off and was able to get the issue fixed in no time!
Anonymous
September 17, 2018
The comment has been removed
- Anonymous
  September 17, 2018
  The comment has been removed
  - Anonymous
    September 17, 2018
    Great, thanks! Now I just need to wait for our server admin to apply the fix and see if it works.
Anonymous
September 17, 2018
You missed one:"CodeTypeReferenceExpression"but thanks for the post nevertheless. Helped a lot.
- Anonymous
  September 17, 2018
  Do you know which Workflow? It does not seem ours include this type.
Anonymous
September 17, 2018
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:
- Anonymous
  September 17, 2018
  It seems that some people using Nintex workflows also need to add:
Anonymous
September 17, 2018
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?
- Anonymous
  September 17, 2018
  This one will also affect workflow. The solution is the same though.
Anonymous
September 17, 2018
The comment has been removed
- Anonymous
  September 17, 2018
  Initially we were not sure of all the dependencies. When we learned we made it more restrictive.
Anonymous
September 17, 2018
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.
- Anonymous
  September 17, 2018
  The comment has been removed
Anonymous
September 17, 2018
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.
- Anonymous
  September 17, 2018
  In Joe’s script locate -gt 14 and replace by -le 14. This should do it for 2007.Glad note 2 helped.
  - Anonymous
    September 17, 2018
    The comment has been removed
    - Anonymous
      September 18, 2018
      That should do it.
  - Anonymous
    September 18, 2018
    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!
    - Anonymous
      September 18, 2018
      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?
  - Anonymous
    September 18, 2018
    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.
    - Anonymous
      September 18, 2018
      The comment has been removed
- Anonymous
  January 17, 2019
  The comment has been removed
Anonymous
September 17, 2018
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?
- Anonymous
  September 18, 2018
  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
Anonymous
September 18, 2018
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
- Anonymous
  September 18, 2018
  The update for web.config is made via SharePoint API. No need to backup. Do undo, run:Remove-CodeDomAuthorizedType
Anonymous
September 18, 2018
The comment has been removed
- Anonymous
  September 18, 2018
  The comment has been removed
Anonymous
September 18, 2018
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:
- Anonymous
  September 18, 2018
  I will pass this to Joe who wrote the script.
  - Anonymous
    October 08, 2018
    Our workflows run under the SP timer service (OWSTIMER), and although workflows started to run after applying the workaround using both files/scripts, the timer service just keeps crashing every 2-3 minutes. i read in the comment that a section is added at the bottom of the config file instead of the top, and/or a section needs to be added at the top, but the contents of one's config file don't seem to come through when someone pastes in here. could i please request a known-to-work-without-crashing-SP-timer-service config file to be pasted after removing/replacing '' characters from the file, since those are the ones that seem to be the issue - someone else was able to successfully post their config file by replacing those characters with ( and ). Thanks!
    - Anonymous
      October 09, 2018
      Rename the current .config file and run the script again that it will recreate the .config file
Anonymous
September 18, 2018
The comment has been removed
- Anonymous
  September 18, 2018
  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.
Anonymous
September 18, 2018
The comment has been removed
- Anonymous
  September 18, 2018
  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.
Anonymous
September 18, 2018
Thank you, worked perfectly restoring workflow functionality on Windows 2008R2 with SharePoint Foundation 2010.
Anonymous
September 18, 2018
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.
- Anonymous
  September 18, 2018
  Not sure if I understand your question. Can you elaborate?
- Anonymous
  September 18, 2018
  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.
Anonymous
September 18, 2018
Thank u so much. Thats solved my problem. We have SharePoint 2013.
Anonymous
September 18, 2018
The comment has been removed
Anonymous
September 18, 2018
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.WorkflowCompiler2) 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.
- Anonymous
  September 18, 2018
  I will pass the feedback to Joe who wrote the scripts.
  - Anonymous
    September 18, 2018
    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.
    - Anonymous
      September 19, 2018
      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.SetContentCommandGet-Content : Cannot find path '\\C$\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\OWSTIMER.EXE.CONFIG' because it does not 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
      - Anonymous
        September 19, 2018
        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
      - Anonymous
        September 24, 2018
        The comment has been removed
      - Anonymous
        September 25, 2018
        @fredericklin, I was unable to repo the issue described on my SharePoint 2010 test farm, but I updated the function in an attempt to resolve the issue. The function will also handle a failure in the service location discovery more gracefully.
Anonymous
September 18, 2018
Is it or should it look like: etc?
- Anonymous
  September 18, 2018
  ??
Anonymous
September 18, 2018
Thanks for the fix, specially adding a note for Nintex.
Anonymous
September 18, 2018
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?
- Anonymous
  September 18, 2018
  I would try to stop and restart the workflows that are stuck.
Anonymous
September 18, 2018
The comment has been removed
- Anonymous
  September 18, 2018
  It will not impact future patches. I put some updates on the post.
  - Anonymous
    September 18, 2018
    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 ?
Anonymous
September 18, 2018
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, Collection1 events, TimeSpan timeOut) at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection1 events, SPWorkflowRunOptionsInternal runOptions)
- Anonymous
  September 18, 2018
  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)
Anonymous
September 18, 2018
The comment has been removed
- Anonymous
  September 18, 2018
  It seems you have the problem discussed here. The solution will work for you.
  - Anonymous
    September 19, 2018
    The comment has been removed
    - Anonymous
      September 19, 2018
      What is the process throwing the error? Can you start a new Workflow?
Anonymous
September 18, 2018
Another month, another .net patch bug. Have you guys stopped testing them?Thanks for the fix.
- Anonymous
  September 18, 2018
  It is tested on .NET but not against all products using .NET :)
  - Anonymous
    October 02, 2018
    That's ridiculous
Anonymous
September 19, 2018
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!
- Anonymous
  September 19, 2018
  I recommend you to use the script and to run:Add-CodeDomAuthorizedType -IncludeNintexWorkflow
Anonymous
September 19, 2018
The comment has been removed
- Anonymous
  September 19, 2018
  What is the process throwing the error? Do you have the same problem with starting new workflows?
Anonymous
September 19, 2018
@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?
- Anonymous
  September 19, 2018
  If you have the same symptoms, the solution applies.
Anonymous
September 19, 2018
Excellent, this fixed workflows on a 2008R2 server running SP2013, thank you!
Anonymous
September 19, 2018
Does the respective patch for Windows Server 2016, (I believe it's KB4457131) have the same impact for SharePoint 2016?
- Anonymous
  September 19, 2018
  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.
  - Anonymous
    September 20, 2018
    A follow-up question, our patching cycle is coming up this weekend. Our test environments (both 2013/2016) got the patch and workflows stopped working and I ran the script and got them working again. Is there any harm in running the script BEFORE the patch is installed?
    - Anonymous
      September 20, 2018
      You can run the patches before applying the patches. It is a good idea for it will prevent you from experiencing the problem.
Anonymous
September 19, 2018
Looks like your script worked for us. The workflow is firing as intended now. Thank you!
Anonymous
September 19, 2018
I installed the patch 9/15/2018, since then I got following errors1) in event log with ID 10002) "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
- Anonymous
  September 19, 2018
  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.
  - Anonymous
    September 19, 2018
    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
Anonymous
September 19, 2018
The comment has been removed
Anonymous
September 19, 2018
The comment has been removed
- Anonymous
  September 19, 2018
  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
Anonymous
September 19, 2018
Does this also affect workflow manager workflows as well? And if so, does the fix also fix those?
- Anonymous
  September 19, 2018
  I don't have this information at the moment. If you have a problem, let us know.
Anonymous
September 19, 2018
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.
- Anonymous
  September 19, 2018
  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.
Anonymous
September 19, 2018
The comment has been removed
- Anonymous
  September 19, 2018
  Thanks for the heads up. I would assume that if you add the entries to App Management Service config file it would work.
  - Anonymous
    September 19, 2018
    The comment has been removed
    - Anonymous
      September 19, 2018
      The comment has been removed
      - Anonymous
        September 20, 2018
        The comment has been removed
        
        Anonymous
        September 20, 2018
        The comment has been removed
      - Anonymous
        September 20, 2018
        The comment has been removed
        
        Anonymous
        September 20, 2018
        Use the scripts as they will do the work of inserting into the right place.
  - Anonymous
    September 20, 2018
    You are right it probably would. I just needed it back up so patches where removed. Once they are done with the code I will add them in. I am really surprised this was not caught it testing. This seems like a pretty big change and it cannot be just affecting SharePoint. Thanks...
Anonymous
September 19, 2018
We have uninstalled this security patches update KB4457056, KB4457026, KB4457045, KB4457034 from All SharePoint farm server and rebooted the server. after that we are able to start Nintex workflows.
Anonymous
September 20, 2018
Hi there, Thanks for this blog, it's been a lifesaver in understanding why we started having issues with workflows! I made the changes suggested to owstimer.exe.config and web.config using the PS scripts, but while workflows would then run, those that had a pause step would never unpause. In the end I had to uninstall the problem patches.Any ideas about stalled paused workflows?
- Anonymous
  September 20, 2018
  Some people had similar issue and they explained how they resolved it in the comments.
  - Anonymous
    September 20, 2018
    The only comments I noticed were about updating owstimer.exe.config per the updated PS script, but I've done that. Searching comments for 'pause', the only other person who mentioned this word spoke about having to remove pause steps to get workflows to work.I did see a few comments about 'App Management Service', but didn't think that was relevant?Could you point me to a comment I'm missing?
    - Anonymous
      September 20, 2018
      According to a similar case we had here, the solution was to make the changes to OWSTIMER.exe.config (which is responsible for resuming paused workflows) and restart the SharePoint Timer Service to have the config file to be applied (it happens during initialization) and to have paused workflows to continue. So, make sure service is restarted on all servers after the changes and check if it is indeed running. If there is problems in the config it will fail to start.
      - Anonymous
        September 20, 2018
        Yes, I'm afraid I did that. Before I did, workflows were logging an error when they should've come off pause. After I did, timer jobs were running, but workflows were not coming off pause and nothing was being logged.
        
        Anonymous
        September 21, 2018
        The previous version of the script had a bug that would add section definition at the end of .config file and this definition must be the first child. Can you paste your .config file?
      - Anonymous
        September 23, 2018
        Sure, here you go:
        
        Anonymous
        September 24, 2018
        The comment has been removed
      - Anonymous
        September 26, 2018
        Hmm, perhaps since it's xml with greater than/less than signs? I've replaced them with parenthesis and will try again:(?xml version="1.0" encoding="utf-8"?)(configuration) (configSections) (sectionGroup name="System.Workflow.ComponentModel.WorkflowCompiler" type="System.Workflow.ComponentModel.Compiler.WorkflowCompilerConfigurationSectionGroup, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35") (section name="authorizedTypes" type="System.Workflow.ComponentModel.Compiler.AuthorizedTypesSectionHandler, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /) (section name="authorizedRuleTypes" type="System.Workflow.ComponentModel.Compiler.AuthorizedTypesSectionHandler, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /) (/sectionGroup) (/configSections) (runtime) (/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" /) (/authorizedTypes) (/System.Workflow.ComponentModel.WorkflowCompiler)(/configuration)
        
        Anonymous
        September 26, 2018
        The comment has been removed
      - Anonymous
        September 30, 2018
        Hi James,Thanks, I've done much more methodical testing and realise that even with the patches uninstalled the workflows fail to come off PAUSE with the owstimer changes.I've tested with and without those changes and notice this shows in uls logs with the changes:Load Workflow Assembly: System.IO.FileNotFoundException: Could not load file or assembly 'System.Workflow.ComponentModel.XmlSerializers, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. File name: 'System.Workflow.ComponentModel.XmlSerializers, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.Load(String assemblyString) at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadWorkflowAssembly(SPWorkflowManager manager, String name) WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog]. We do use a number of info path forms and the pause workflow that I've been testing is related to one of them. Might this be the issue? Any idea how to correct?
      - Anonymous
        October 01, 2018
        I noticed the web.config files that were updated by this script had previous entries in the same section that was modified by the script and some of these seemed to be relevant to the error, so I copied/pasted the entire section into owstimer.exe.config, restarted, tested and workflows now come off pause.I'm not sure if this is overkill, but rather than adding just the couple entries I thought were needed, only to find an additional error or two after retesting that flagged more missing entries, I figured I'd just go for the whole section.Does that seem the right way to go or do you think this will cause a problem?
      - Anonymous
        October 04, 2018
        We have the same error that James had with pause in workflow. The error is "Load Workflow Assembly: System.IO.FileNotFoundException: Could not load file or assembly ‘System.Workflow.ComponentModel.XmlSerializers, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified."James stated he re-added entries back to owstimer.exe.config to resolve this issue. Entries that were present before the MS Script run. What are these entries? It sounds like we are missing some entries that we need to resolve this pause issue. SharePoint 2010 Designer Workflows with pause.
Anonymous
September 20, 2018
Applying the fix resulted in File Not Found error when loading sharepointA reboot removed that but one of the pages then had a list with an error "couldnt be deserialised"Will try again later
Anonymous
September 20, 2018
Also I found with the OWSTimer script the server name wasnt populated in the UNC path so it failed
Anonymous
September 20, 2018
Thanks for the post, issue Resolved...
Anonymous
September 20, 2018
The comment has been removed
- Anonymous
  September 20, 2018
  The comment has been removed
Anonymous
September 20, 2018
The comment has been removed
- Anonymous
  September 21, 2018
  It seems you add ‘uncommented’ in you cmdLet and PowerShell is telling there is no such parameter.
  - Anonymous
    September 23, 2018
    Apologies, the above was not clear - there is no "uncommented" in the code. Below is an extract of code that is generating the previously mentioned unexpected attribute CmdletBinging error. Add-CodeDomAuthorizedType -IncludeNintexWorkflow [CmdletBinding()] param( [parameter(Mandatory=$false)][switch]$IncludeNintexWorkflow )
    - Anonymous
      September 24, 2018
      Looks correct to me. It may be something went wrong during copy and paste. Try to copy the raw copy of the script from here: https://gist.githubusercontent.com/joerodgers/2302b394796c865818839d843bae2dad/raw/1d62103684200c54aef0569b4da34c58c67c6833/Add-CodeDomAuthorizedType.ps1
      - Anonymous
        September 24, 2018
        Thank you Rodney, unfortunately the issues still occurs. Do you have you any other suggestions, if not, I may need to contact Microsoft support.
        
        Anonymous
        September 25, 2018
        If you still see an issue, please contact support
Anonymous
September 20, 2018
The 7 lines of code works for us. Thank you.Question: Can we apply the solution before the patch happens?, to make sure we have no workflows Fail. we still have other environments not yet patched.
- Anonymous
  September 21, 2018
  You may and I recommend you do it. It will avoid downtime.
  - Anonymous
    September 23, 2018
    Thank you, Rodney
Anonymous
September 21, 2018
The comment has been removed
Anonymous
September 21, 2018
There's a small mistake in the script. It's probably not breaking, but, the check to see if the patch has already been applied is $contentService.WebConfigModifications | ? { $.Name -eq "NetFrameworkAuthorizedTypeUpdate" }).Count -gt 0 It shoudl be:$contentService.WebConfigModifications | ? { $.Owner -eq "NetFrameworkAuthorizedTypeUpdate" }).Count -gt 0
Anonymous
September 21, 2018
In my case the KB4457036 was also problematic and must be removed. Even the Add-CodeDomAuthorizedType Patch didn't work with him .After I had removed it, all Workflows run again.
- Anonymous
  September 21, 2018
  How did you uninstall the update? i Couldn't seem to find the same update in Uninstall section.
Anonymous
September 21, 2018
Thanks for the info Rodney! Coming across this made us aware of the issue, therefore we were able to prepare and plan for this.
Anonymous
September 23, 2018
Thanks Rodney for your post, after we did the changes in web config file manually it seems that workflows can publish but , we now seem to have issues with all actions that have a Pause /wait like “Pause”, “Wait for”, “Wait Until” actions.Any workflow which has a pause action is not working anymore and also throws up an error after 5 minsis that something related to this issue??
- Anonymous
  September 24, 2018
  Which error?
  - Anonymous
    September 24, 2018
    We have also tried the config entries with the scripts and had no luck. Removed the patches and workflows run, but any workflows with a pause for duration step get stuck with status "Pausing for x minutes."
  - Anonymous
    September 25, 2018
    TPL_Ext_SetUpRequeset failed
    - Anonymous
      September 26, 2018
      This error is not related to the patches issue.
- Anonymous
  September 24, 2018
  we're experiencing the same issue - Pause actions are not working and throw an error
- Anonymous
  September 25, 2018
  Hello Rodney, we have installed the patches last week and the same day I have applied the fix. It helped with the workflows running and publishing, but since last week, on random list (with workflows) I am experiencing issues with timeouts when creating or editing items. It usually ends as "The server was unable to save the form at this time. Please try again" but sometimes it save the item after 5-6 minutes. Do you think this might be connected with a patch or the applied fix?Regards
- Anonymous
  September 25, 2018
  Pause or delay activities cause workflows to dehydrate. The workflow timer job resumes them after the pause or delay. This means the workflows will resume in the SharePoint timer process.You should check the owstimer.config files on all servers with SP bits installed. In case they're missing the authorized type entries rerun the provided script for owstimer.Best wishesDaniel
Anonymous
September 24, 2018
We're running Windows 2008R2 and SharePoint 2010. I ran the script with Nintex flag (Add-CodeDomAuthorizedType -IncludeNintexWorkflow), but still getting errors. Also tried IIS reset and no luck. The following updates were installed this weekend:.NET:KB4457035KB4457027KB4457016 KB4346407KB4344167Windows:KB4457139KB4457426KB4457146KB4457055KB4457044KB4457008KB4344177KB4343899KB4339284
Anonymous
September 24, 2018
Hi Rodney,Will it affect the current farm if the updates are applied? Will the running Nintex workflows be affected in any way or will the script fixes the issue after the update is done?My concern is if the current running workflows needs to be re-run after the patch and script is run.Thank you,Neha
- Anonymous
  September 25, 2018
  You may want to contact Nintex about this.
Anonymous
September 24, 2018
Rodney,We are running Windows 2008R2 and SharePoint 2010. We ran the powershell scripts above (Add-CodeDomAuthorizedType -IncludeNintexWorkflow), but still getting errors. We applied the following patches this weekend:.NET:KB4457035KB4457027KB4457016KB4346407KB4344167Windows:KB4457139KB4457426KB4457146KB4457055KB4457044KB4457008KB4344177KB4343899KB4339284
Anonymous
September 24, 2018
Can the fix be applied prior to installing the September patches, or does it need to be done after the patches are applied?
- Anonymous
  September 25, 2018
  Yes. It can and it should reduce downtime.
Anonymous
September 24, 2018
Getting these errors. Why this complex script? Can you not post what the owstimer.exe.config file is supposed to look like?PS D:\Installs\Hotfixes> .\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1 -IncludeNintexWorkflow -verboseSet-Content : The network path was not found.At D:\Installs\Hotfixes\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:327 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 not exist.At D:\Installs\Hotfixes\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:331 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 Get-Content : Cannot find path '\\C$\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\OWSTIMER.EXE.CONFIG' because it does not exist.At D:\Installs\Hotfixes\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:334 char:36+ [xml]$xml = Get-Content <<<< -Path $uncPath + CategoryInfo : ObjectNotFound: (\\C$\Program F...IMER.EXE.CONFIG:String) [Get-Content], ItemNotFoundException + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand Add-ConfigSections : Cannot bind argument to parameter 'XmlDocument' because it is null.At D:\Installs\Hotfixes\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:338 char:44+ Add-ConfigSections -XmlDocument <<<< $xml + CategoryInfo : InvalidData: (:) [Add-ConfigSections], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Add-ConfigSections Add-AuthorizedTypes : Cannot bind argument to parameter 'XmlDocument' because it is null.At D:\Installs\Hotfixes\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:341 char:45+ Add-AuthorizedTypes -XmlDocument <<<< $xml -IncludeNintexWorkflow:$IncludeNintexWorkflow.IsPresent + CategoryInfo : InvalidData: (:) [Add-AuthorizedTypes], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Add-AuthorizedTypes Set-Content : The network path was not found.
- Anonymous
  September 25, 2018
  The comment has been removed
Anonymous
September 24, 2018
Would we need to do a restart on the Timer service on the WFEs or does the script just install and start working? Do the users need to clear their browser cache?
- Anonymous
  September 25, 2018
  IIS Reset and restart SP Timer Service
Anonymous
September 25, 2018
While after running the scripts our workflows start normally (including Nintex), workflows now get 'stuck' in the idle condition if they go to a Nintex state change. Is anyone else having this problem?
Anonymous
September 25, 2018
Can you run the script before the patches are deployed or would this cause a different issue. We have not deployed these specific patches yet and are trying to figure out the easiest way to minimize disruption.
- Anonymous
  September 25, 2018
  You can. Actually, it will reduce your downtime.
Anonymous
September 25, 2018
Hello Rodney, we have installed the patches last week and the same day I have applied the fix. It helped with the workflows running and publishing, but since last week, on random list (with workflows) I am experiencing issues with timeouts when creating or editing items. It usually ends as "The server was unable to save the form at this time. Please try again" but sometimes it save the item after 5-6 minutes. Do you think this might be connected with a patch or the applied fix?Regards
- Anonymous
  September 25, 2018
  Hi Josef,It is difficult to tell either way without more analysis. The particular problem we are fixing here should not slow down workflows.
  - Anonymous
    September 26, 2018
    The comment has been removed
Anonymous
September 25, 2018
I am getting the same errors in 2010 workflows even when the two specific KBs (4457916/4457035) are not installed, but the others B4457135 (Windows 2012 Server) , KB4457037, KB4457042 are installed. Are they related to the same issue for these KBs too?
- Anonymous
  September 26, 2018
  Yes. This is the same issue. You can find the list of KBs causing the issue at https://blogs.msdn.microsoft.com/dotnet/2018/09/11/net-framework-september-2018-security-and-quality-rollup/
  - Anonymous
    October 02, 2018
    Thank you!
Anonymous
September 25, 2018
hello:I ran the script in our SP2016 farm and it appears to have fixed the problem. But, when I search for the lines in web.config, I cannot fine the exact lines described in the KB. After running the script, I open up the web.config file in Notepad++ and search for NameSpace="System.CodeDom" and nothing comes up. Are the exact same lines that are documented in this blog added via the script ?Thank you,RumiThank you,
- Anonymous
  September 26, 2018
  The changes will be added via a SharePoint timer job and it can take some time. Also you may need to IISRESET.
  - Anonymous
    September 27, 2018
    The comment has been removed
    - Anonymous
      September 27, 2018
      Look state of job 'job-webconfig-modification'. This job needs to run to update web.config files.
      - Anonymous
        September 27, 2018
        The comment has been removed
        
        Anonymous
        September 27, 2018
        They are supposed to. There is a job that updates web.config. Check if it ran. I talked about it in one of the responses. Worst case you may add the lines manually.
      - Anonymous
        September 27, 2018
        The comment has been removed
        
        Anonymous
        September 27, 2018
        The comment has been removed
      - Anonymous
        September 28, 2018
        The comment has been removed
Anonymous
September 26, 2018
Thanks for Sharing Rodney! Unfortunately though this workaround only partially worked for us so we had to completely uninstall the .Net updates to get workflow going again. We run SharePoint 2013, however many of our sites we're migrated from SharePoint 2010 and still have the look and feel of 2010. When we applied the fix all of our 2013 sites started working but our migrated 2010 sites did not. Obviously we can't avoid .Net updates going forward so my concern is that when the CU comes out will it address the migrated 2010 sites or are we looking at rebuilding sites/workflows. Not sure if you have any insight on that or not but wanted to bring it up..
- Anonymous
  September 26, 2018
  You may want to open a support case for your scenario.
Anonymous
September 26, 2018
The fix (Add-CodeDomAuthorizedType.ps1) worked for the workflow failures caused by w3wp.exe process but the other workflow failures caused by OWSTIMER.EXE is not resolved by applying "Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1", any suggestions ?I have verified the config files in all servers the OWSTIMER.EXE.CONFIG and could find that it is updated as shown below. Also, restarted the Timer service several times.
- Anonymous
  September 27, 2018
  What do you see in ULS logs? what type is missing?
  - Anonymous
    September 30, 2018
    Engine RunWorkflow: System.Workflow.ComponentModel.Compiler.WorkflowValidationFailedException: The workflow failed validation. at System.Workflow.Runtime.WorkflowDefinitionDispenser.ValidateDefinition(Activity root, Boolean isNewType, ITypeProvider typeProvider) at System.Workflow.Runtime.WorkflowDefinitionDispenser.LoadRootActivity(Type workflowType, Boolean createDefinition, Boolean initForRuntime) at System.Workflow.Runtime.WorkflowDefinitionDispenser.MruCache.GetOrGenerateDefinition(Type type, String xomlText, String rulesText, Byte[] md5Codes, Boolean initForRuntime, Boolean& exist) at System.Workflow.Runtime.WorkflowDefinitionDispenser.GetRootActivity(Type workflowType, Boolean createNew, Boolean initForRuntime) at System.Workflow.Runtime.WorkflowRuntime.InitializeExecutor(Guid instanceId, CreationContext context, WorkflowExecutor executor, WorkflowInstance workflowInstance) at System.Workflow.Runtime.WorkflowRuntime.Load(Guid key, CreationContext context, WorkflowInstance workflowInstance) at System.Workflow.Runtime.WorkflowRuntime.GetWorkflowExecutor(Guid instanceId, CreationContext context) at System.Workflow.Runtime.WorkflowRuntime.InternalCreateWorkflow(CreationContext context, Guid instanceId) at System.Workflow.Runtime.WorkflowRuntime.CreateWorkflow(Type workflowType, Dictionary2 namedArgumentValues, Guid instanceId) at Microsoft.SharePoint.Workflow.SPWinOeHostServices.Send(SPWorkflow workflow, SPWinOeWorkflow winoeworkflow, SPWorkflowEvent e) at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(SPWorkflowHostService host, SPWorkflow workflow, Collection1 events, TimeSpan timeOut)
    - Anonymous
      October 01, 2018
      I am seeing the same issue. How to correct?
    - Anonymous
      October 01, 2018
      Having this issue. How to resolve?
    - Anonymous
      October 01, 2018
      Have this same issue, how to resolve
    - Anonymous
      October 31, 2018
      I experience the same error in the owstimer.exe; is there any solution for this (yet)?
      - Anonymous
        October 31, 2018
        Make sure you watch the video of the solution.
        
        Anonymous
        November 02, 2018
        Hi Rodney,thx for pointing out the video. In my case the error is not happening on every workflow - just every once-in-a-while an automatically started workflow will fail to start. So I would not assume it's due to some missing authenticated-types entries in the owstimer.exe.config.
        
        Anonymous
        November 05, 2018
        If you see the error in ULS, then this is the problem.
      - Anonymous
        March 14, 2019
        Hi all,we have followed the steps and while they seem to have worked for some workflows, there are workflows that fail to wake up after pausing, and when the 5 minute timer job runs there is this very error in the ULS. Simple workflows (log "hi", pause for a minute, log "done") wake up and work perfectly fine, the more advanced ones simply do not wake up at all, and the only meaningful errors in the ULS are the "Engine RunWorkflow: System.Workflow.ComponentModel.Compiler.WorkflowValidationFailedException: The workflow failed validation. "It does not matter if it's a workflow that existed before the updates (and running the scripts), or if it's a brand new one - if it has some actions (that we haven't narrowed down yet) it does not wake up.Any suggestions?
        
        Anonymous
        March 21, 2019
        See the last part of the video and see if it resolves the issue.
Anonymous
September 27, 2018
Hi We are experiencing issue in SP2007, we have updated a test environment web.config however are still receiving issues with custom actions from ilovesharepoint.activities and spd activities. Does anyone have idea what needs adding for these features?ThanksMartin
Anonymous
September 27, 2018
Hi RodneyThanks for your solution, I want to understand that this solution work for SharePoint 2010 Service pack1 also.
- Anonymous
  September 27, 2018
  Yes.
Anonymous
September 27, 2018
I just wanted to add we have SharePoint 2010 and applied the solution highlighted above and observed workflows completing thereafter. However, I have since noticed that the workflows are producing many 'errors' in the workflow history prior to completing which were not there before. I have tried re-publishing the workflow but am still observing the errors occurring. Would an IIS reset/ SP Timer Service restart help this issue or is there something else i should do?Thanks Anthony
- Anonymous
  September 27, 2018
  Yes for both.
Anonymous
September 27, 2018
KB4458613 also causes this issue it seems in my SharePoint 2013 farm. Uninstalling the updates helped. I did not try the PowerShell work around here. Is the fix going to be placed into the next Microsoft patch? Or should we just do this work around?
- Anonymous
  September 27, 2018
  No ETA for the patch yet. The workaround is the solution that is being implemented in the patch.
Anonymous
September 27, 2018
We seem to be having issues with Workflows that are started via powershell rather than by the front end. These workflows stay "In Process" it seems forever. Were were able to get both scripts to run and that solved several issues but multiple workflows started by powershell scripts never actually begin processing.
- Anonymous
  September 27, 2018
  You may need to add the entries to PowerShell.exe.config
Anonymous
September 28, 2018
The comment has been removed
Anonymous
September 28, 2018
Hello, since I updated the windows update is giving me problems and errors such as:Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (935e9b38-7270-4ff4-acbc-78b33f3a9bac).Reason: The device is not ready.Technical Support Details:System.IO.FileNotFoundException: The device is not ready. at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize () at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances (Boolean isAdministrationServiceJob)
- Anonymous
  October 18, 2018
  tengo el mismo problema
Anonymous
September 28, 2018
Is there an update on when the SharePoint patches will be available so we do not have to use these scripts?
Anonymous
October 01, 2018
HI,thanks for your solution and it worked for first part by adding entries to webconfig file. However even after runnign second script for updating timer service, we are still getting Nintext workflows Pause stage errors. I can see all the 6 entries in webconfig across all the SPSevrers in 2010. I do have included -includenintexworkflow, but still I am not able to run the workflows which has pause condition. Any suggestion?
- Anonymous
  October 03, 2018
  I posted this above. (Basically, replace the entire contents of in owstimer.exe.config with the contents from one of from one of the web.config files that were updated by the first script. For me, there're 36 'authorisedType' entries, which includes the seven news ones introduced by the script.)Give it a try and let us know if it helps you, too!---I noticed the web.config files that were updated by this script had previous entries in the same section that was modified by the script and some of these seemed to be relevant to the error, so I copied/pasted the entire section into owstimer.exe.config, restarted, tested and workflows now come off pause.I’m not sure if this is overkill, but rather than adding just the couple entries I thought were needed, only to find an additional error or two after retesting that flagged more missing entries, I figured I’d just go for the whole section.Does that seem the right way to go or do you think this will cause a problem?
Anonymous
October 01, 2018
For those of you using Nintex workflows who are having problems with workflows getting stuck at pauses and state changes, republishing the workflow should fix this.
- Anonymous
  October 08, 2018
  Isn't republishing only going to help new instances of workflows started since the republish? For existing workflows already on pause, republishing is simply going to leave them unning the previous version of the workflow, so aren't they still going to be bugged?
Anonymous
October 01, 2018
Hi Rodney,I have to update our web.configs manually - and it didn't fix our issue.. can you confirm whether this looks correct? <author..........
Anonymous
October 03, 2018
works like charm! Thank you!
Anonymous
October 03, 2018
Thank you! Worked like charm for both Nintex and SharePoint workflows!
Anonymous
October 03, 2018
We have run the script (including nintex) and we are still experiencing issues with nintex workflows not running and sharepoint designer workflows with pauses in starting, but not completing successfully and just generating errors.We have ran the script, ran IIS reset, restarted SP Timer Service all to no avail. Also unable to re-publish any nintex workflows as we receive a 'server was uable to process requestion. ---> failed to publish workflow.
- Anonymous
  October 03, 2018
  Try replacing the entire contents of in owstimer.exe.config with the contents from one of from one of the web.config files that were updated by the first script. For me, there're 36 'authorisedType' entries, which includes the seven news ones introduced by the script.) After doing this and running fresh workflows that had a 5 minutes pause, they'd come off pause as intended.Give it a try and let us know if it helps you, too!
Anonymous
October 03, 2018
2018-09 Security and Quality Rollup for .NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2 for Windows 8.1 and Server 2012 R2 for x64 (KB4457920). the steps described in the solution were performed and nevertheless the flows run in error
Anonymous
October 04, 2018
The comment has been removed
Anonymous
October 04, 2018
The comment has been removed
- Anonymous
  October 08, 2018
  I missed off the Nintex bit so my Nintex workflows still aren't working, is there an easy bit of script to get that added?
  - Anonymous
    October 09, 2018
    Chris yes, there's a function built in to remove the changes. Simply comment out the #Add-CodeDomAuthorizedType and then uncomment out Remove-CodeDomAuthorizedType. Then when you're ready to re-run, comment out the Remove-CodeDomAuthorizedType and uncomment out Add-CodeDomAuthorizedType -includeNintexWorkflow -- that adds the necessary assemblies back to webconfig
- Anonymous
  October 09, 2018
  The comment has been removed
Anonymous
October 05, 2018
My Nintex workflows still fail to start after applying this patch! I am being pressed to get this fixed.
Anonymous
October 05, 2018
Fix worked great, thank you!The only thing still not working for us are custom workflows with a task process. End users will now get the task notification via Outlook but cannot use the "open this task" button to connect and approve/reject items. Is this related?
- Anonymous
  October 08, 2018
  If you see the error in the ULS log, yes. Otherwise, no.
- Anonymous
  October 12, 2018
  Is Microsoft releasing a hotfix or do we have to update the web.config?
  - Anonymous
    October 12, 2018
    The fix will be available on a regular SharePoint CU (no ETA, but my educated guess is that it will come in November)
Anonymous
October 10, 2018
The comment has been removed
- Anonymous
  October 12, 2018
  Unfortunately if you use xml/html tags, the text will not show. Thanks for the intention though.
Anonymous
October 10, 2018
Just in case anyone CONTINUES to have problems try going ahead and copying ALL of the entries from one of your web.configs and to the [SharePoint Hive Folder]\bin\OWSTIMER.EXE.config and see if that solves you problem. For some reason I needed more than the recommended list and scripts added in order for the Timer service to successfully kick of workflows for instance if I start them via powershell.
- Anonymous
  October 12, 2018
  That is correct. I added a video that also includes this step as we faced it on some cases too.
  - Anonymous
    October 17, 2018
    Hi RodneyPlease can I give you some constructive feedback on this? Your article would be much more helpful if the point made by Jonathan Brauer "try going ahead and copying ALL of the entries from one of your web.configs and to the [SharePoint Hive Folder]\bin\OWSTIMER.EXE.config" were stated clearly IN THE TEXT at the top of this article, not in the video or buried here in the comments.We should not have to watch the last few minutes of a video to find out a crucial piece of information. It should be plain and centre, in text, at the top of the article.Some of us work in environments where access to video is locked down. If you had just made that point in text at the top of the article I would have saved hours looking into this issue. It would be good for others if you could make that change now. Thank you.
    - Anonymous
      October 17, 2018
      Thank you for the suggestion Peter. As a matter of fact I added this information tothe video I refer to on the beginning of the post.
      - Anonymous
        October 17, 2018
        Hi RodneyThank you for your reply. I think we are talking at cross-purposes. I cannot watch the video at work; all access to YouTube is blocked in my organisation. That's just the way it is.What I was suggesting you do is add a textual update to the Solution section of your blog post, such as:"copy ALL of the entries from one of your web.configs to [SharePoint Hive Folder]\bin\OWSTIMER.EXE.config"In my case, it was 39 “” entries that had to be copied from web.config to OWSTIMER.exe.config. That should be stated in the Solution section, without needing to watch the video.Best regardsPeter
        
        Anonymous
        October 17, 2018
        Done. I have updated the post to add a new note to address this. In the video, there is a very detailed step-by-step. The situation requiring this, by the cases coming here, are very rare though.
Anonymous
October 11, 2018
If we will exclude this update and perform next windows updates then still we will face same issues.
- Anonymous
  October 12, 2018
  Yes.
Anonymous
October 11, 2018
We uninstalled the two .NET patches affecting workflows/Nintex workflows for on-prem SharePoint 2016 to wait for a re-issue. Is there any update on this?
- Anonymous
  October 12, 2018
  There will be no reissue. The solution will come in the form of a SharePoint patch.
Anonymous
October 11, 2018
When the fix (SharePoint patch) gets released, do we need to undo the temporary solution you provided on this post?
- Anonymous
  October 12, 2018
  You do not need to undo the changes in this post. The fix will come soon. No ETA though.
Anonymous
October 12, 2018
Can anyone comment on whether the new .Net update (KB 4459922) resolves these issues without the need to manually change the web.config?
- Anonymous
  October 12, 2018
  The comment has been removed
  - Anonymous
    October 13, 2018
    Will this fix be included in the next SharePoint CU update. Any communication on this by Microsoft?
Anonymous
October 12, 2018
Thank you, RodneyThis has helped resolve our workflow failing issue with Nintex workflows. It has worked so far without applying timer service fix.
- Anonymous
  October 12, 2018
  Glad it worked for you.
Anonymous
October 12, 2018
Nice article
Anonymous
October 14, 2018
Hi Rodney, I am stuck in bit complicated scenarios which related to this update surely. my client is using Nintex for building workflow, they have both lists, site workflow. I have applied the scripts for both web application web,config and OWSTIMER.exe.config (including the nintex enteries).Following are the issues i am facing.1. One of the site workflow failing with the same cause, though the other site workflow works fine.2. One of the list workflow, while pausing for some minutes, throwing failed to run in Workflow History. Regards,Shakir
- Anonymous
  October 15, 2018
  See this: https://blogs.msdn.microsoft.com/rodneyviana/2018/10/12/step-by-step-video-on-how-to-fix-the-sharepoint-workflow/
Anonymous
October 15, 2018
Will running the fix script on SharePoint prior to applying the .NET security patches cause any harm?
- Anonymous
  October 15, 2018
  It will not cause harm to apply the fix before .NET patches.
Anonymous
October 15, 2018
Has the OCT 9th SharePoint cumulative update addressed this issue?https://support.microsoft.com/en-us/help/4461458/october-9-2018-cumulative-update-for-sharepoint-enterprise-server-2013We uninstalled the server updates as Vito did and that resolved our issue but have also stopped any further updates until we know that this addressed as per your first note... (If not, is there an ETA yet?)
- Anonymous
  October 15, 2018
  October CU does not address this issue.
  - Anonymous
    October 17, 2018
    Is there an ETA? for when the next Cumulative update will resolve the issue?
    - Anonymous
      October 17, 2018
      No ETA, I will update when I have it. My educated guess is that it is coming on SharePoint November CU.
Anonymous
October 15, 2018
Will running the fix script cause any service interruptions? I'd like to know if it requires any offline hours to run.
- Anonymous
  October 15, 2018
  Just IISRESET and starting and stopping OWSTimer.
Anonymous
October 15, 2018
For Note 2 and SharePoint 2010 use following where version number needs to be 2.0.0.0
- Anonymous
  October 15, 2018
  If you use the script it adds version 2.0 if it is SharePoint 2010. Please use the script rather than manually adding values.
Anonymous
October 16, 2018
This Solution worked for us..! thanks Rodney..
Anonymous
October 16, 2018
Worked for us..! Thanks Rodney..
Anonymous
October 16, 2018
The comment has been removed
- Anonymous
  October 17, 2018
  Copy the file from one of the WFEs to your APP server.
Anonymous
October 17, 2018
The comment has been removed
- Anonymous
  December 18, 2018
  Wish we had seen your comment a couple of months earlier. Had to reinvent the wheel. Support engineers from both MS and Nintex were also unaware of this.
Anonymous
October 17, 2018
I've had several issues with Powershell Workflows (not related to sharepoint) since a couple weeks ago. Do you think this issue would be affecting those as well since it's based on Workflow Foundation?
- Anonymous
  October 17, 2018
  It is possible, if the exception you see is the same so it is the same problem.
Anonymous
October 19, 2018
I am still having problems after applying the fix with overdue approval email notifications, the emails are never being sent, I applied the fix for both web.config, and owstimer.exe on all servers.Anyone with similar issue?
- Anonymous
  October 19, 2018
  I suggest you to watch the step-by-step video.
  - Anonymous
    October 22, 2018
    Thanks for your response, I actually did, and performed all the steps including adding all entries to the owstimer.exe.config on all servers. Does nayone have the overdue emails working after applying the fix?
Anonymous
October 21, 2018
Hi Rodney,I am new to Share Point and faced this issue last week. We are using SP 2010. . After I have added authorized types in web.config, most of the eforms work flows start working. But it doesn't solve for file upload and still 'Failed On Start' after people uploaded the file. I need to check out/in as a share point admin to change the status every time people uploaded the file. Please advise how to solve.
Anonymous
October 22, 2018
Solution worked! Thank you, Rodney.
Anonymous
October 22, 2018
We have a mixture of SP2010 Workflows and Nintex and since a patch update over the weekend I am receiving hundreds of error notifications saying workflow has ended unexpectedly and WFNAME failed to run. Does anyone know how to stop the workflows from running? We have over 100 workflows and some of them are on list items with lists of 2000 items. I don't know how to resolve this issue so any suggestions would be appreciated
- Anonymous
  October 24, 2018
  The comment has been removed
Anonymous
October 23, 2018
Does this affect Windows Server 2016?
- Anonymous
  October 23, 2018
  All Windows versions.
Anonymous
October 23, 2018
Does this .NET security patch get installed onto Windows Server 2016 or is that sever OS not affected by this?
- Anonymous
  October 23, 2018
  All Windows versions
Anonymous
October 23, 2018
We applied the fix on our 2013 SharePoint server and we had the Powershell script in order for it to take affect.
Anonymous
October 24, 2018
The comment has been removed
- Anonymous
  October 24, 2018
  The scripts work with SharePoint 2010+. You have to make manual changes for MOSS 2007.
Anonymous
October 24, 2018
Thank you Rodney, this worked perfectly to resolve the issue in SP2010 SP2 14.0.7106.5002 August 2013 CU Mark 2, on Windows2008 Service Pack 2 Build 6002. Followed by an IISRESET.No need to uninstall any KB's.
Anonymous
October 24, 2018
The comment has been removed
- Anonymous
  October 24, 2018
  It is a complicated situation. I can't tell what is happening, but I can tell you that applying the scripts will not affect your environment negatively even if the problem is not related to the patch.
Anonymous
October 26, 2018
I notice that the reference for 3rd party / Nintex wasn't added, although I ran the script multiple times with the -IncludeNintexWorkflow switch. Took some investigation to locate this problem. Added manually....
Anonymous
October 26, 2018
The comment has been removed
- Anonymous
  October 29, 2018
  I'm at work, and managed to download it without issue. I also downloaded it directly from 3 different clients when there to fix their servers. No need for you to be rude to someone who is helping you just because YOUR network admins block everything...
Anonymous
October 28, 2018
Not all servers in our farm were patched. Can I add this web.config changes to all the servers irrespective of it is patched or not, because the script updates all servers. Is there any known impact due to having the config changes in place without the patches in servers?
- Anonymous
  October 29, 2018
  There is no problem in running the scripts before the patches.
Anonymous
October 29, 2018
Has the problem been fixed?
Anonymous
October 29, 2018
Thank you for this!
Anonymous
October 29, 2018
Hello Rodney,I have a SharePoint 2010 environment with Nintex. I ran the script and now my automated workflows are stuck in "in progress" and it never completes.
- Anonymous
  October 29, 2018
  The OWSTimer script should resolve that. If not, I recommend you to open a support case to investigate.
  - Anonymous
    October 31, 2018
    Hi Rodney,After security patch installed we made changes in web.config entries all looks good and working only one case failed till now which is email enabled list on item create workflow its showing error Failed on Start (retrying) in Nintex workflow. We added Nintex entries as well and made changes in OWSTIMER.EXE.config we are using SharePoint 2010. I checked workflow running with most of the workflow actions but getting error on Set a Condition workflow action and if use Run If its getting stuck. Please suggest.
    - Anonymous
      November 01, 2018
      Check out the video. In special the last optional step
  - Anonymous
    November 01, 2018
    Thanks Rodney, It worked like charm. Now my workflows are running
Anonymous
October 30, 2018
The comment has been removed
Anonymous
November 02, 2018
Hi,Any news about permanent fix without the workaround?
Anonymous
November 02, 2018
Hi,Any news regarding the permanent solution (SP CU)?
Anonymous
November 05, 2018
Hi,Is there any news about permanent solution for this issue (to do not use the workaround)?
- Anonymous
  November 05, 2018
  Patch is coming to SharePoint 2010 to 2016
  - Anonymous
    November 12, 2018
    Do you have any approximate date for the SP patch?
    - Anonymous
      November 12, 2018
      My educated guess is that it should be in November CU which ships normally before 11/15.
      - Anonymous
        November 14, 2018
        I see the November Patch is outhttps://docs.microsoft.com/en-us/officeupdates/sharepoint-updatesBut cannot determine if any of the deployments address this issues.https://support.microsoft.com/en-us/help/20181113/security-update-deployment-information-november-13-2018 Any ideas? (Security Manager is pressuring us to get latest updates out but everything is on hold because of this issue)
        
        Anonymous
        November 14, 2018
        I put the links at the beginning of the post.
      - Anonymous
        November 19, 2018
        Does the update just add the types to the webconfig or does it address other issues. We have a 2010 designer workflow that fails on an impersonation step even after applying the script to modify the config files. We have not tried the November update yet.
        
        Anonymous
        November 20, 2018
        The impersonation is a different problem
      - Anonymous
        November 21, 2018
        Thanks for the reply Rodney, any idea of the impersonation problem will be addressed in the future?
- Anonymous
  November 21, 2018
  Okay so I have applied the november update to our test system and found an issue with workflow, although different to previous issue, it is not working as expected. I then applied the scripts also as suggested (we do not have Nintex but thought it might be worth a try) . Yet still we are having problems. The upgrade process was a three day process on our test system and somewhat disappointed that it seems to be time wasted. I will now have to do further investigation to determine what is going wrong and will feedback here.
Anonymous
November 08, 2018
Thanks a lot, it resolved my problem.
Anonymous
November 16, 2018
We uninstalled the .NET patches and waited for the fix rather than running the scripts. We run Nintex workflows in SharePoint 2016 on-prem. We are waiting a few days before installing the Nov patch to see if any other issues are flagged. Would be interested to hear if anyone installs the patch who is in the same situation.
- Anonymous
  November 20, 2018
  Nintex problems will not be addressed by the patch.
Anonymous
November 19, 2018
The comment has been removed
- Anonymous
  November 20, 2018
  Make sure Workflow runs in a WFE machine.
  - Anonymous
    November 20, 2018
    Thanks, but I don't understand your suggestion. The farm is configured with MinRoles and the App server is running the Microsoft SharePoint Foundation Workflow Timer Service, are you saying that it should be running on the Front-end with Distributed Cache server?
    - Anonymous
      November 26, 2018
      Did this get answered? I'm in the same situation, SharePoint 2016 on prem with nintex workflows. Since the latest patch doesn't address nintex we are going to run the scripts. We also have servers with minroles. Not clear on the directions for the timer script. Also, do you not run the 2nd timer script unless you see errors?
    - Anonymous
      December 04, 2018
      I added lines on SP2013 webconfig files and still getting error:Type System.CodeDom.CodePropertyReferenceExpression is not marked as authorized in the application configuration file.
      - Anonymous
        December 04, 2018
        See the video and follow the steps.
Anonymous
November 19, 2018
Rodney, We applied all the patches and they are still not working. I went ahead and made the changes per the video to accommodate Nintex but I"m still getting and error when I try to run it. .\Add-CodeDomAuthorizedType.ps1 and I get the error. Am I running it incorrectly?At c:\WFScripts\Add-CodeDomAuthorizedType.ps1:195 char:1+{+~Missing closing '}' in statement block.+CategoryInfo :ParserError: (:) [], ParseException+FullyQualifiedError: MissingEndCurlyBrace
- Anonymous
  November 20, 2018
  You may have forgotten the close '}'
Anonymous
November 19, 2018
Hello Rodney,Just want to know if it is possible to uninstall this security update after it is installed on our SharePoint servers. I am asking if in case it break my SharePoint environment.
- Anonymous
  November 20, 2018
  It is possible
Anonymous
November 26, 2018
I patched a SharePoint Server 2013 last Saturday after waiting the last 2 months because of the "WF-Problem". I installed latest .NET patch (KB4467240) and SP November CU (KB4461511). Yesterday I realized, that half of the Workflows are not working. I uninstalled the .NET update and for now it's all working. The November CU should resolve this Problems according to the KB description… don't know whats going on...
- Anonymous
  November 26, 2018
  The patch will not fix problem with Nintex WF. For those, you still have to follow this post (see the video). If you do not have third-party WFs, I suggest you to open a case with Microsoft to have your issue investigated.
Anonymous
November 27, 2018
I am using SharePoint 2010 along with Nintex workflow, Got the issue and fix by above solution, but this is working on all new workflows, any exiisting workflow which has "pause for" is still failing, i tried after re publishing the workflow but same issue. any solution for perviously created workflows ?how can i make sure that i need to use the OWSTIMER.EXE.config option.
- Anonymous
  November 27, 2018
  If you use Nintex you need to follow the OWSTIMER.EXE.config option. Follow the video. It is more straightforward.
Anonymous
November 27, 2018
Which patch applies to enterprise sharepoint 2013 server?
- Anonymous
  November 27, 2018
  Follow the second link in the beginning of the post
  - Anonymous
    November 27, 2018
    Yeah my sharepoint servers have that patch installed. the code for web.config fixed it though. Is this normal?
Anonymous
November 28, 2018
I ran the script (Add-CodeDomAuthorizedType.ps) on one WFE A and after completion of the script I checked and found that Web config files are updated with required entries on another WFE B and Application server C but on the same WFE A where script ran the web config files are not having those entries although web config files showing latest modification date. Any Idea.
- Anonymous
  November 29, 2018
  Is SharePoint Web Services and SP Timer Service running on the server?
- Anonymous
  November 29, 2018
  (The content was deleted per user request)
  - Anonymous
    November 29, 2018
    And yes. Web services and timer services running on all WFE servers.
    - Anonymous
      November 29, 2018
      Hit wrong button and deleted post. I was saying the exact same thing happened to us. In fact when we tried to remove entries using the same script it removed from all others and ADDED them to the original server. We restored configs and tried again from another WFE. Same thing again, this time with the new server we ran it on not getting the entries . We have a ticket open but no help yet. We also have nintex so this is just step one.
Anonymous
November 30, 2018
I am having this same issue on one of three farms, Our Dev and Production farms are not experiencing the issue but our QA farm is having the issue since the upgrade. How do I fix this while keeping the web.config the same on all environments. I do not want to fix the ones that are not experiencing the error.
Anonymous
December 05, 2018
The comment has been removed
- Anonymous
  December 06, 2018
  The comment has been removed
Anonymous
December 06, 2018
We installed KB4461501, the update that fixes this issue. Since then, we can't open 2010 Workflows on certain SharePoint Designer installs. It just doesn't open, when opening a global workflow we get a message that SharePoint Designer couldn't open it, try pressing F5 etc.Strangely, on some installations of SharePoint Designer it works. SP1 for Designer doesn't help.
Anonymous
December 18, 2018
The comment has been removed
- Anonymous
  December 18, 2018
  The configuration had been imported when Nintex Workflow was activated, but the new config file changes introduced to remedy authorizedTypes were ignored by OWSTIMER.exe as it continued to use the initial version of workflow config settings from the database.
- Anonymous
  January 03, 2019
  We also struggled long time with a customer as there has been only a few nintex workflows which didn´t work after the fix. The workflows worked pretty well as long as we triggered it manually or triggered the "workflow" timer job manually. Reason: then it ran on the forntend on which the extra authorized type for 3rd party workflows (see Note 2) was added. But if it was triggered by the timer service it ran on the application server where the web.config was not edited."Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1" didn´t help, but adding the extra authorized type from note 2 to the application server web.config did the trick.It turned out
- Anonymous
  February 17, 2019
  Thanks for your update. I'm on about my fifth attempt at a fix. I have run both versions of the script and also manually copied the into the web config. I've also run the powershell to update the web apps workflowconfig as your stated. I've republished workflows. All is fine except certain scheduled workflows. Can you please confirm Nintex, scheduled, site workflows work as expected?
  - Anonymous
    March 21, 2019
    Nintex should work too if you run with the switch. It may be that the workflows you are running require to add other entries. Please contact your vendor.
Anonymous
January 02, 2019
Is it a best practice to keep a backup of the files that the script is modifying? If the answer is yes, how do I know which files is it going to modify?
Anonymous
January 10, 2019
Could anyone please let me know if there are any patch updates, for these faulty patches, released by microsoft which resolves issues for Sharepoint workflows, Nintex workflows and Designer workflows for sharepoint 2010 servers.
Anonymous
January 15, 2019
Do the latest patch updates released by microsoft in the month of December 2018 or January 2019 resolve these issues for Sharepoint workflows, Nintex workflows and Designer workflows for sharepoint 2010 servers.
Anonymous
January 15, 2019
(The content was deleted per user request)
- Anonymous
  January 17, 2019
  Are you on a SharePoint server added to the farm?Do you see a problem when running these 2 commands?Add-PSSnapin "Microsoft.SharePoint.PowerShell"Get-SPFarm
Anonymous
January 22, 2019
Only 4 servers in the farm have this patch. Can I still run the script? The blog says the script adds entries on all servers. What happens if these entries are added to the servers which don't have the patch? (or) should I consider adding entries to web.config manually?
- Anonymous
  January 22, 2019
  The script will add entries to all existing servers and any new server you add later. No need to run again.
Anonymous
January 22, 2019
The comment has been removed
Anonymous
January 25, 2019
The $contentService.Update() wouldn't run, so I had to change to if( $updateRequired = $true).
- Anonymous
  March 21, 2019
  Thanks for the feedback.
Anonymous
February 12, 2019
Thank you Rodney, this resolved the workflows issues in my SharePoint 2010 server for many web applications.
Anonymous
February 12, 2019
The comment has been removed
Anonymous
February 13, 2019
I have already executed script Add-CodeDomAuthorizedType and now we started using Nintex workflows and getting similar issues. Can I run this script again with parameter IncludeNintexWorkflow or do I have to cleanup previously added entries first?
Anonymous
February 21, 2019
I noticed that you said this should be ran once and that it should have been fixed in November. But, we are still having to run this script every month when updates are pushed to .Net Framework. It seems to only break Nintex workflows that simply send out an email. Any workflows that have other steps work fine. Do you have any clue why we are continuing to have this issue?
- Anonymous
  March 21, 2019
  The script should resolve it and it should not be necessary to rerun it. Not sure what is happening
Anonymous
February 26, 2019
We installed January CU and it does fix part of the issue. We are now able to publish workflows via designer. The problem we are having is any workflows that utilize the pause for duration will not run. It's stuck and will not continue after the duration. If we remove the .net update then those workflows will work without any issues. is this happening to anyone else?
- Anonymous
  March 21, 2019
  See the last part of the video.
Anonymous
March 01, 2019
Hi Rodney, We have 2 WFE and 2 APP SP2016 servers in our farm. 1 APP server got the .Net patch installed. Then Nintex Workflow failed (as expected). We run the script for web.config and owstimer.exe.config (updating on all servers). However, a week later the .Net patches got applied on the remaining 2 WFE and 1 APP servers. This caused the Nintex Workflow to have issues again. Why is this? I thought the script changes in the config file should fix it forever? Do we have to run now the script every time we get new .Net patches?
- Anonymous
  March 21, 2019
  The script should resolve the problem even if the patches is applied later. It may be another cause.
Anonymous
March 06, 2019
Hello Rodney,What should be the rollback plan for this Security update. We have share point 2013 environment and have Nintex workflow installed. We want to apply this security update and want to know the roll back procedure if this update cause any issue to my farm. could u please let me know if it is possible/supported this security update if my farm got any issue because of this.
Anonymous
March 22, 2019
Hello Rodney Is any solution for SP2010 SP2 on Windows Server 2012 R2 environment ? Description of the security update for SharePoint Server 2010 Office Web Apps: November 13, 2018 (KB4461527) only supported on Windows server 2008 OS version , thank you.
- Anonymous
  March 27, 2019
  SharePoint 2010 is supported in Windows Server 2012 R2 if it is installed the slipstream bits. See it here:https://support.microsoft.com/en-us/help/2724471/sharepoint-2010-support-for-windows-server-2012-and-windows-server-201
  - Anonymous
    March 27, 2019
    Hello Rodney , Thanks , we're already running the SP 2010 SP2 on Windows server 2012 a few years , now the problem is if we installed the new MS .NET security patches the workflow will not working , Microsoft only provide the solution for SP 2010 in Windows server 2008 (KB4461527) , the security patches can't working in Windows server 2012 , thank you .
Anonymous
April 04, 2019
The comment has been removed
- Anonymous
  April 17, 2019
  It looks like you added the session to the wrong place. Anyway, I am not sure why you had to include the configuration changes to spucworkerprocessproxy.exe.config. I suggest you to open a support case, this does not look like a standard scenario.
Anonymous
April 18, 2019
Hi Rodney, we have SP 2013 enterprise farm and we have many sharepoint 2010 list workflows created and published using SP designer 2013. now the windows update tool inside our SP application server, is showing the "Microsoft .Net framework 4.7.2 for windows server 2008 R2 KB4054530" update. so i have these questions before we install the update:- 1. as of April 2019 will this update still cause issues with workflows? 2. if yes , then do we need to update the web.config ? or to run the Add-CodeDomAuthorizedType.ps1 script? or we have to uninstall this update from control panel? Or any of these options will work? 3. also can we just exclude this update from windows update tool and apply the others windows server 2008 R2 updates listed inside the Windows update tool?Thanks
- Anonymous
  April 24, 2019
  All .NET updates will contain the code that will break workflows. You just need to run the PowerShell command once (it is to fix SharePoint, not .NET) for this problem. You can run the PowerShell even if the .NET update is not installed. DO NOT exclude this .NET update. It is a security update.
  - Anonymous
    May 01, 2019
    Hi Rodney.now i always prefer to avoid running scripts on our live environment, and keep the change as simple as possible, even if it requires manual modifications . now in your above solution you mentioned that "The solution is to add explicitly the types to all web applications' web.config: "... so can i just do this? in our case we have SP enterprise 2013, and we only have one application server and 2 web applications (central admin web application and the web application containing our site collections), so can i just modify the 2 web applications' web.config files? and where i need to add the types inside the web.config?

通过

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

* FINAL UPDATE VI * SharePoint CUs are out

The Nov 2018 SharePoint CUs

Important

Symptom

Cause

Solution

Additional Information

Note

Note 2

Note 3

Note 4

Comments

其他资源

通过

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

*** FINAL UPDATE VI *** SharePoint CUs are out

The Nov 2018 SharePoint CUs

Important

Symptom

Cause

Solution

Additional Information

Note

Note 2

Note 3

Note 4

Comments

其他资源

* FINAL UPDATE VI * SharePoint CUs are out