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
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 Foundation 2013: November 13, 2018 (KB4461511)
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):
Step by step video on how to fix the SharePoint Workflow issue caused by .NET patch
Symptom
After applying .NET Security Only patch to resolve CVE-2018-8421 (Remote Code Execution Vulnerability) , all SharePoint out of the box Workflows fail to execute and the log will show an error like this:
09/13/2018 01:59:07.57 w3wp.exe (0x1868) 0x22FC SharePoint Foundation Workflow Infrastructure 72fs Unexpected RunWorkflow: Microsoft.SharePoint.SPException: <Error><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″…
The error suggest that System.CodeDom.CodeBinaryOperatorExpression is not in the authorized types.
Cause
Workflow Foundation (WF) will only run workflows when all the dependent types and assemblies are authorized in the .NET config file (or added explicitly via code) under this tree:
<configuration>
<System.Workflow.ComponentModel.WorkflowCompiler>
<authorizedTypes>
<targetFx>
However, after the update, the following lines are necessary for SharePoint 2013 and beyond:
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePrimitiveExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodInvokeExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeFieldReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeThisReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePropertyReferenceExpression” Authorized=”True” />
And for SharePoint 2007 and 2010, use these lines:
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePrimitiveExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodInvokeExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeFieldReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeThisReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePropertyReferenceExpression” Authorized=”True” />
Solution
The solution is to add explicitly the types to all web applications’ web.config:
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePrimitiveExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodInvokeExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeFieldReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeThisReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePropertyReferenceExpression” Authorized=”True” />
Or (for SharePoint 2007 and 2010):
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePrimitiveExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodInvokeExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeMethodReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeFieldReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeThisReferenceExpression” Authorized=”True” />
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePropertyReferenceExpression” Authorized=”True” />
Please notice that sometimes SharePoint Timer Service (SPTimerV4) runs workflows. If you notice that the application showing the error is ULS logs in OWSTIMER.EXE, you should also include the authorized types in [SharePoint Hive Folder]\bin\OWSTIMER.EXE.config. The Hive Folder will change by version of SharePoint. For SharePoint 2016, it is normally at c:\program files\common files\microsoft shared\web server extensions\16. For 2013, at c:\program files\common files\microsoft shared\web server extensions\15.
Additional Information
My colleague Joe Rodgers, who is Sr. PFE, put together this PowerShell script: https://gist.github.com/joerodgers/2302b394796c865818839d843bae2dad
There are two scripts. Normally, the only necessary script is:
Uncomment this line to make the changes:
Add-CodeDomAuthorizedType
If you have Nintex workflows you should run like this:
Add-CodeDomAuthorizedType –IncludeNintexWorkflow
To undo the changes, run:
Remove-CodeDomAuthorizedType
The script needs to run only once on any WFE. All web.config files related to SharePoint on all servers will be modified. New web applications created after that will also include the changes. Even if a new WFE is added to the farm, the entries will also be included in web.config. The change is a permanent requirement from now on since the WF patch. You do not need to undo the change before applying the SharePoint patch addressing it.
There is a second script to update OWSTIMER.exe.config. This one should only run if you see the symptoms in ULS logs with process OWSTIMER.EXE. Otherwise, you do not need to update. if you have the problem though, you need to rerun the script if a new machine is added to the farm. No line needs to be uncommented for this one. The script name is:
Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1
Note
Microsoft is aware of this issue and patches for SharePoint 2010, 2013 and 2016 are being worked as of 9/17/2018. I will update when we have an ETA. I had confirmation from the product team on 9/18/2018 that this information and solution on this post is in the line with the future patch and it is the recommended action plan until the patch is out. If anything change, I will update the post.
Note 2
Some people using third-party workflows (like Nintex) need to also include this:
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeTypeReferenceExpression” Authorized=”True” />
If you are using SharePoint 2010, use this instead:
<authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodeTypeReferenceExpression” Authorized=”True” />
Using the script, you need to add to the line defining types:
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.
In my case I uninstall this updates: KB4457056, KB4457026, KB4457045, KB4457034
After that I can publish workflows
You will not be able to postpone updates forever. We are looking for a better solution and will update this post.
Are the scripts considered the permanent solution or will a future KB fix this issue?
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.
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.
A patch is being worked out for online. Please contact SharePoint Online support for updates.
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
You are correct. You can apply the fix in this post before applying .NET patches to avoid downtime. Use a test environment first.
Hi Rodney
Thank you for this! All our workflows fell over (we use Nintex which is obviously based on SharePoint workflows).
Any chance of this happening to other namespaces in System.dll in the future?
Regards
Hi Christian,
I believe it is unlikely to happen to other namespaces, but it is not ruled out.
Hello Rodney,
I’ve exactly the same problem on a SharePoint 2013 Farm. I was unable to start or deploy workflows. The solution was to uninstall the last .NET Framework update (KB4087364).
Where on the SharePoint Server must this be changed to fix it without uninstalling the update?
Thank you in advance.
Best regards,
Lucian
Where on the SharePoint Server must this be changed to fix to solution without uninstall the update?
Thank you in advance.
Best regards,
Lucian
Post was updated to answer your question.
So which of the gazillion config files am I supposed to be correcting, please?
Post was updated to answer your question.
OK, so when I edited with notepad and added to the end of the authorizedtype list it didn’t work
then I edited with vstudio and put it as the frist of the 4.0’s and it was OK.
not sure if it was a typo at first or the order mattered or something. anyway. Glad for this post!
Post was updated to answer your question.
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?
Script was updated recently to address the problem with SharePoint 2010.
Thanks for sharing it.
Where to update this line?
In every web application web.config?
Post was updated to answer your question.
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/.
Post was updated to answer your question.
Can you elaborate on the solution? Where am I adding the solution? Also, when will MS be releasing an update for this regression?
Just to be sure can you point us to where this configuration file would be located?
Post was updated to answer your question.
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/.
That is correct. Thank you for pointing out to the script.
whats about shrepoint 2010? there isn’t subkey. and adding to
dont fix this problem,
Post was updated to answer your question.
Hi, where can I find this file? Thanks,
Post was updated to answer your question.
Quick question. Where is the location of the .NET config file where the line needs to be changed. I would assume the web.config, but if you could provide a location to the .net config file you modified, that would be appreciated. I am encountering the same issue on Server 2012 R2 and SharePoint 2013.
Post was updated to answer your question.
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
I updated the post and added a link to a script to automate the changes.
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:
I updated the post (and Joe updated the script) to include SharePoint 2010.
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!
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.
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.
Copied the ps script this morning: 15 Sep.
Pasted it in ISE, uncommented the line Add-CodeDomAuthorizedType
Ran the script
Restarted the server
Looked in web.config for the affected application, it contains:
When starting a workflow ULS still reports:
Microsoft.SharePoint.SPException:
at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association, Boolean fallback)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow)
Which SharePoint version are you using? The script recognizes your version and should not need to remove comment from any line.
Line 97.
I have both 2010 and 2013 Foundation farms. They are both impacted.
I removed the patches for now.
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.
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.
Uninstall was the suggestion before we came up with this workaround
This post is only related to KB 4457916 which seems not to be your scenario.
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.
I can’t tell much about it without more detailed analysis. But if restarting the server works, maybe IIS RESET would suffice.
Will this affect SharePoint 2007 – please advise.
I have not heard of any case so far.
I can confirm the issues occur also on SP 2007, with the same error messages.
Applying the work-around solved it, same line as for SP 2010 (dll is present in GAC).
(setup: SP 2007 with Nintex on 2008 R2 boxes)
Thanks for heads up.
The script worked for me in SP2013. Timely help saved us.
Thanks for sharing Rodney!
Is there an impact to SharePoint 2016?
Yes. It also affects 2016.
Hello,
this Script was no Help
Our SharePoiint 2016 still not working
Did you check if the lines were indeed added to web.config?
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
Check if the web.config files were updated and try IISRESET.
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!
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.
Hi,
After running both scripts pause and wait actions stopped working
See the video with step-by-step added to the post.
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
Did you check if the script added the required lines?
At the bottom of the script, do I need to uncomment “# Add-CodeDomAuthorizedType” before running?
You are correct. This line needs uncommenting
Can you confirm if we need to uncomment the line at the bottom of the script that says Add-CodeDomAuthorizedType? In one comment you said that we should not need to uncomment anything in the script and in another you said that we do need to uncomment it. I just want to be sure that I am understanding this correctly.
That is correct.
I apologize for coming back around to this. What is the correct action? Should we uncomment this line or leave it as is. You did not specifically answer my question.
Uncomment:
# Add-CodeDomAuthorizedType
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.
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
This KB is also related to the same issue. The solution applies.
Hi Rodney,
I can confirm the script fixed the issue. Thanks
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.
I’m having the same issue…. Did you ever get this resolved? We are also running Win2008R2 and SharePoint2010.
Will the web.config modification job in the script trigger an iisreset?
It will not recycle. You may need IISRESET
Thanks for sharing this!
Script gave me below error for some reason. Did anyone face same issue?
Exception calling “ApplyWebConfigModifications” with “0” argument(s): “Name cannot begin with the ‘,’ character, hexadecimal value 0x2C. Line 1, position 2508.”
Thanks,
Rahul Babar
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
I tried it could of different ways but still got same error.
Not sure if this is my environment only.
Thanks,
Rahul Babar
Try to run a new workflow, if it does not work, please show me the ULS logs line you see when it fails (truncate if it is too big).
After running the script does one still have to cancel and restart each Nintex Workflow?
The workflows may be running from OWSTIMER which uses a different config file.
I had the same issue with the script:
(Exception calling “ApplyWebConfigModifications” with “0” argument(s): “A web configuration modification operation is already running.”)
I don’t know the overall impact but I just commented out the line #$contentService.ApplyWebConfigModifications();
Script seemed to work for me then, I figured the update on the line before did what needed done… It added to all WFE Servers in the farm and I did an IISReset, workflows and SharePoint Designer started working thereafter.
Hope that helps.
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?
You are good. Can you paste what you see in the ULS logs after the change (the line is too big, so it is ok if you truncate)
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!
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?
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. “
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.
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!
After applying the script it is necessary to IISRESET all servers to take effect.
Thanks so much for posting! Found this right off and was able to get the issue fixed in no time!
We’re seeing the same behavior, but with SP Designer Workflows as well. I assume the same fix applies as for the Out-of-the-box Workflows?
Correct. SP Designer custom workflows qualifies as out-of-the-box for the intent of this post. Non-oob would be the ones created in Visual Studio.
Great, thanks! Now I just need to wait for our server admin to apply the fix and see if it works.
You missed one:
“CodeTypeReferenceExpression”
but thanks for the post nevertheless. Helped a lot.
Do you know which Workflow? It does not seem ours include this type.
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:
It seems that some people using Nintex workflows also need to add:
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?
This one will also affect workflow. The solution is the same though.
Is it mandate to add all the “Type Name” or below is line is fine.
authorizedType Assembly=”System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”*” Authorized=”True”
Initially you blog had the above piece of code, which worked great in Sp 2016 environment. After few hours you added the exact “TypeName”.
Which one can be used.
Initially we were not sure of all the dependencies. When we learned we made it more restrictive.
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.
This line will add all types for System.CodeDom. The entries in the post will add only the types used by oob workflows (an extra line is necessary for Nintex)
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.
In Joe’s script locate -gt 14 and replace by -le 14. This should do it for 2007.
Glad note 2 helped.
So if I understand correctly the two things I would need to do for SharePoint 2007 is change line 4 to
[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”) > null
and change line 26 to
if( $farmMajorVersion -le 14 ) # 2007/2010
That should do it.
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!
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?
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.
My bad. It is line 39:
From:
if( $farmMajorVersion -eq 14 ) # 2010
To:
if( $farmMajorVersion -le 14 ) # 2010, 2007
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?
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
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
The update for web.config is made via SharePoint API. No need to backup. Do undo, run:
Remove-CodeDomAuthorizedType
There are two scripts, the first – Add-CodeDomAuthorizedType.ps1 has the following lines commented, do they all need to be uncommented? and do both scripts need to be ran?
# Get-SPTimerJob | ? { $_.Name -eq “job-webconfig-modification” }
# Add-CodeDomAuthorizedType
# Remove-CodeDomAuthorizedType
The 2nd – Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1 has the following lines commented:
# $serverNames = @(Get-SPServer | ? { $_.Role -ne “Invalid” } | Select -ExpandProperty Name)
# Add-CodeDomAuthorizedTypeToOWSTimerConfig -ComputerName $serverNames
Do these lines also need to be uncommented? This is for Nintex workflows.
For Nintex, you may need to add another type on line 24. I wrote about the change in another reply. This is the line you should uncomment:
Add-CodeDomAuthorizedType
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:
I will pass this to Joe who wrote the script.
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!
Rename the current .config file and run the script again that it will recreate the .config file
Is there any issue if we keep the TypeName=”*” like it was yesterday? Or should we update the line with the update above
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.
I came up on this post last week and we updated last night and had outages. This piece should be removed from this article “all SharePoint out of the box Workflows fail “. We use no ‘out of the box’ workflows. It causes all workflows to fail on sp2013 enterprise On-prem using Nintex. I understand out of the box to mean the workflows that ship with SharePoint.
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.
Thank you, worked perfectly restoring workflow functionality on Windows 2008R2 with SharePoint Foundation 2010.
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.
Not sure if I understand your question. Can you elaborate?
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.
Thank u so much. Thats solved my problem. We have SharePoint 2013.
I’m running Joe’s script to make the web config changes via the timer job. I uncommented the line for running the add function. I’m not seeing the timer job execute though. It’s on our dev system so I wouldn’t be surprised if we don’t have something configured correctly. When I query for the job in powershell I see:
Name Schedule Last Run
—- ——– ——–
job-webconfig-mod… 1/1/0001 12:00:00 AM
I see the timer job definition in CA as well, but it show the same information. I try to run the job and nothing happens via CA or Powershell. Do I need to use stsadm to force the job to execute?
I don’t believe this script was tested properly. 2 issues I had using it:
1) OWSTIMER.EXE.CONFIG may not have configSections for System.Workflow.ComponentModel.WorkflowCompiler
2) the web app fixup script adds modifications to the admin service, but not to web apps.
I was able to resolve 1 by editing the file manually to include the configSections. For #2, I couldn’t get the updates to work, and had lots of failing workflows, so I put the entries in manually.
I will pass the feedback to Joe who wrote the scripts.
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.
Hi Joe,
Thanks very much for the scripts. The first worked beautifully, but I’m getting errors with the OWS Timer script. We’re running SharePoint 2010 with two web servers under NLB. The script seems to be dropping the servername from the UNC?
Set-Content : The filename, directory name, or volume label syntax is incorrect.
At C:\Users\adminjr\Desktop\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:325 char:53
+ $defaultXml.ToString() | Set-Content <<<< -Path $uncPath
+ CategoryInfo : WriteError: (\\\C$\Program F…IMER.EXE.CONFIG:String) [Set-Content], IOException
+ FullyQualifiedErrorId : GetContentWriterIOError,Microsoft.PowerShell.Commands.SetContentCommand
Get-Content : Cannot find path '\\\C$\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\OWSTIMER.EXE.CONFIG' because it does n
ot exist.
At C:\Users\adminjr\Desktop\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:329 char:24
+ Get-Content <<<< -Path $uncPath | Set-Content -Path "$($uncPath)_backup_$(Get-Date -Format 'yyyy_MM_dd_hh.mm.ss').config"
+ CategoryInfo : ObjectNotFound: (\\\C$\Program F…IMER.EXE.CONFIG:String) [Get-Content], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand
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
Thanks, this worked nicely.
For reference, this starts from line 304.
@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.
Is it or
should it look like:
etc?
??
Thanks for the fix, specially adding a note for Nintex.
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?
I would try to stop and restart the workflows that are stuck.
Hi Rodney,
is this issue specifically caused by only KB 4457916/4457035 ?? When I am going through Discussion , someone mentioning “MS Premier Support asked us to uninstall KB4457044 and KB4457055”
And Second Question , Is it OK to run Script to update Config Anytime earlier before Patch push to servers , is it going to Negatively impact current Environment in the meantime ? We have massive amount of Prod servers So Wanted to make Config update ready So that Anytime Enterprise push these updates we are not impacted
It will not impact future patches. I put some updates on the post.
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 ?
Made the changes noted above and workflows still won’t run. ULS error:
RunWorkflow: Microsoft.SharePoint.SPException:
at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association, Boolean fallback)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow)
at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(SPWorkflowHostService host, SPWorkflow workflow, Collection`1 events, TimeSpan timeOut)
at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection`1 events, SPWorkflowRunOptionsInternal runOptions)
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)
We have 2008 R2 and Sharepoint 2010 Foundation, but dont have either KB 4457916/4457035 installed, but are getting the error message (-1, -1) Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.)
(0, 0) Activity ‘ID5’ validation failed: Property “Condition” has invalid value. Condition expression is invalid. The condition expression can not be null.)
Welcome any suggestions or solutions
It seems you have the problem discussed here. The solution will work for you.
Hi Rodney
We have the same issue….We have SharePoint 2010. I have un installed KB227175, KB4054530, KB4457035, I have ran your scripts successfully, I have rebooted several times. All workflows are errorring (SP and Nintex) I have restarted IIS. Still get an error when trying to publish a SP workflow that has an if statement.
Error ‘(-1, -1) Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.)
(0, 0) Activity ‘ID42′ validation failed: Property “Condition” has invalid value. Condition expression is invalid. The condition expression can not be null.)’
Please could you advice me on what I can do
many thanks
What is the process throwing the error? Can you start a new Workflow?
Another month, another .net patch bug. Have you guys stopped testing them?
Thanks for the fix.
It is tested on .NET but not against all products using .NET 🙂
That’s ridiculous
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!
I recommend you to use the script and to run:
Add-CodeDomAuthorizedType -IncludeNintexWorkflow
Please can you advice me. We have the same problem. We have SharePoint 2010 on a 2008R server. I have uninstalled KB4054530, KB22175, KB4457044. I have rebooked several times. I have ran your script as suggested, no errors, web.config updated as expected. I have restarted IIS. We still get the following code when publishing workflows with an If statement (-1, -1) Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.)
(0, 0) Activity ‘ID42’ validation failed: Property “Condition” has invalid value. Condition expression is invalid. The condition expression can not be null.). All workflows are not working. Additional to this our ‘Search’ has a web part error.
Please help. Many thanks Sam
What is the process throwing the error? Do you have the same problem with starting new workflows?
@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?
If you have the same symptoms, the solution applies.
Excellent, this fixed workflows on a 2008R2 server running SP2013, thank you!
Does the respective patch for Windows Server 2016, (I believe it’s KB4457131) have the same impact for SharePoint 2016?
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.
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?
You can run the patches before applying the patches. It is a good idea for it will prevent you from experiencing the problem.
Looks like your script worked for us. The workflow is firing as intended now. Thank you!
I installed the patch 9/15/2018, since then I got following errors
1) in event log with ID 1000
2) “Faulting application name: Fabric.exe, version: 1.0.976.0, time stamp: 0x513fc140”
3) 2013 workflow stop working,
4) Service Bus Message Broker stuck at Starting status.
followed the process of modifying config files. it does not solved the issue.
any other advice.
thanks
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.
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
I’m on Windows 2008 R2 / SharePoint 2013 and was able to run out-of-the-box workflows without any issues. The security patches are installed in this environment. I haven’t tested Nintex yet. Anyone not having any problems with the patch installed?
Thank you VERY much for this – was going a little nuts until I found this. Upon running on my SharePoint 2010 Foundation local server I was getting “local farm not accessible” and found that I had an updated Powershell not compatible with SP2010. Had to run PowerShell.exe -version 2 -NoExit per this article and then all worked well. It took a little time for the SP2010 email to start flowing though. I did create a couple new alerts on a list just to give it a nudge and they all started to come in, FYI in case this all helps someone else reading.
https://sharepoint.stackexchange.com/questions/53953/suddenly-getting-the-local-farm-is-not-accessible-cmdlets-with-featuredependen
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
Does this also affect workflow manager workflows as well? And if so, does the fix also fix those?
I don’t have this information at the moment. If you have a problem, let us know.
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.
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.
This issue is also affecting the App Management Service in SharePoint 2013. I ran both scripts to fix the issue with the workflows and everything seemed ok, this morning when our developers when to deploy new code for an SharePoint App we are working on the deployment just hung and would not install. The message we received led us to believe it was another issue you can run into but after going through the normal fixes we still could not deploy. After some testing we realized it was will all apps on all web applications and all site collections.
I could not find the error logs to assist with the issue but is seemed the Timer Job that adds the app was not completing. In a last ditch effort I removed the security updates from the server and rolled back all the configuration updates. Right now my workflows run as all SharePoint App install as expected.
I can do some more troubleshooting to reproduce the issue. But it will need to wait some since we are on a time crunch with some App changes we are doing.
So this update is affecting more than just the workflows.
Thanks for the heads up. I would assume that if you add the entries to App Management Service config file it would work.
Hey Rodney,
I´m getting this error when I try to publish my workflow now:
Type DP.Sharepoint.Workflow.SendMailWListItemAttachments is not marked as authorized in the application configuration file.
Any idea?
Thx
You need to add this custom type DP.Sharepoint.Workflow.SendMailWListItemAttachments to the authorized types.
Hey,
still getting the error. Could u please help with?
Where should I insert this line? What shoud I use for PublicKeyToken?
If the assembly is in the GAC it will have a public key. If it is only local it will not have. This explains how to get the public key: https://blogs.msdn.microsoft.com/wriju/2008/07/01/how-to-find-public-key-token-for-a-net-dll-or-assembly/
Please contact the component developer for more information about the custom assembly.
Hey,
still getting the same error. Could u tell me where and how should I insert this line?
Thanks
Use the scripts as they will do the work of inserting into the right place.
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…
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.
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?
Some people had similar issue and they explained how they resolved it in the comments.
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?
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.
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.
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?
Sure, here you go:
Somehow the line you were showing me was clipped.
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)
If you have SharePoint 2010, it looks correct. Notice that the changes in the config file of OWSTIMER will only take effect when you stop and start SP Timer Service. Also notice that if you have custom workflow components other types need to be added. Look for the exception in ULS log and check if the type on the error is added to the list.
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?
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?
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.
Applying the fix resulted in File Not Found error when loading sharepoint
A reboot removed that but one of the pages then had a list with an error “couldnt be deserialised”
Will try again later
Also I found with the OWSTimer script the server name wasnt populated in the UNC path so it failed
Thanks for the post, issue Resolved…
Just to help others find this blog when researching their errors, the main error we saw in the ULS logs after updating .net and hitting this problem using Nintex workflows was: w3wp.exe (0x1DF4) 0x3F1C Nintex Workflow 2013 General 00000 Unexpected (http://URL/_vti_bin/NintexWorkflow/Workflow.asmx): Nintex.Workflow.NWSavingWorkflowException: Failed to publish workflow: <CompilerError Line="-1" Column="-1" Text="Type
Part II of the error:
System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line="-1" Column="-1" Text="Type
I get the following error when executing Power Shell function: Add-CodeDomAuthorizedType with
Add-CodeDomAuthorizedType -IncludeNintexWorkflow uncommented:
At line:19 char:5
+ [CmdletBinding()]
+ ~~~~~~~~~~~~~~~~~
Unexpected attribute ‘CmdletBinding’.
At line:20 char:5
+ param
+ ~~~~~
Unexpected token ‘param’ in expression or statement.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnexpectedAttribute
It seems you add ‘uncommented’ in you cmdLet and PowerShell is telling there is no such parameter.
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
)
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
Thank you Rodney, unfortunately the issues still occurs. Do you have you any other suggestions, if not, I may need to contact Microsoft support.
If you still see an issue, please contact support
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.
You may and I recommend you do it. It will avoid downtime.
Thank you, Rodney
Thanks Rodney. This solutions had saved our day on 17th of September for our PROD Instance.
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
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.
How did you uninstall the update? i Couldn’t seem to find the same update in Uninstall section.
Thanks for the info Rodney! Coming across this made us aware of the issue, therefore we were able to prepare and plan for this.
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 mins
is that something related to this issue??
Which error?
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.”
TPL_Ext_SetUpRequeset failed
This error is not related to the patches issue.
we’re experiencing the same issue – Pause actions are not working and throw an error
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
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 wishes
Daniel
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:
KB4457035
KB4457027
KB4457016
KB4346407
KB4344167
Windows:
KB4457139
KB4457426
KB4457146
KB4457055
KB4457044
KB4457008
KB4344177
KB4343899
KB4339284
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
You may want to contact Nintex about this.
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:
KB4457035
KB4457027
KB4457016
KB4346407
KB4344167
Windows:
KB4457139
KB4457426
KB4457146
KB4457055
KB4457044
KB4457008
KB4344177
KB4343899
KB4339284
Can the fix be applied prior to installing the September patches, or does it need to be done after the patches are applied?
Yes. It can and it should reduce downtime.
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 -verbose
Set-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.
$serverNames = @(Get-SPServer | ? { $_.Role -ne “Invalid” } | Select -ExpandProperty Name)
Add-CodeDomAuthorizedTypeToOWSTimerConfig -IncludeNintexWorkflow -ComputerName $serverNames
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?
IIS Reset and restart SP Timer Service
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?
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.
You can. Actually, it will reduce your downtime.
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
Hi Josef,
It is difficult to tell either way without more analysis. The particular problem we are fixing here should not slow down workflows.
Indeed it was a different issue. 2 days before the patch, the certificate on Workflow 2013 server expired. After full reinstall of workflow server, the timeout problem disappeared.
Just FYI, this Log entry give me a lead: Workflow Services Exception System.TimeoutException: The HTTP request has timed out after 330000 milliseconds. —> System.Net.WebException: The request was aborted: The request was canceled.
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?
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/
Thank you!
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,
Rumi
Thank you,
The changes will be added via a SharePoint timer job and it can take some time. Also you may need to IISRESET.
After an IISRESET/REBOOT – I only see one like and the following line added. No other line that includes “syste.CodeDom” can be found in the web.config. Is this the only line needed?
Thanks again for this info!!
Look state of job ‘job-webconfig-modification’. This job needs to run to update web.config files.
Are you saying that all those lines will be added when the scrip is run? I have rebooted the entire farm and the web.config file is only showing that one line I have mentioned.
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.
This is the only line that gets added and none of the other lines:
Don’t use open tags or the line will not be visible in your response.
Ok, sorry Rodney. Here is the line. Also, that particular timer job does not exist on my SP 2016 environment. I just need to know if possibly the script will add only what is necessary based on the .NET version installed?? Here is the only line that includes “system.CodeDom”
authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ NameSpace=”System.CodeDom” TypeName=”CodePropertyReferenceExpression” Authorized=”True”
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..
You may want to open a support case for your scenario.
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.
What do you see in ULS logs? what type is missing?
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, Dictionary`2 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, Collection`1 events, TimeSpan timeOut)
I am seeing the same issue. How to correct?
Having this issue. How to resolve?
Have this same issue, how to resolve
I experience the same error in the owstimer.exe; is there any solution for this (yet)?
Make sure you watch the video of the solution.
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.
If you see the error in ULS, then this is the problem.
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?
Thanks
Martin
Hi Rodney
Thanks for your solution, I want to understand that this solution work for SharePoint 2010 Service pack1 also.
Yes.
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
Yes for both.
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?
No ETA for the patch yet. The workaround is the solution that is being implemented in the patch.
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.
You may need to add the entries to PowerShell.exe.config
Thanks for sharing this! We applied the fix (ran the scripts) before our patching team hit us with the patches. We verified the updates propagated. The patching team applied the patches and rebooted the servers. We found that it still broke workflow functionality. We did rolling IISRESETs across all servers in the farm and the WF were then able to execute.
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)
tengo el mismo problema
Is there an update on when the SharePoint patches will be available so we do not have to use these scripts?
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?
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?
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.
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?
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……….
works like charm! Thank you!
Thank you! Worked like charm for both Nintex and SharePoint workflows!
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.
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!
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
Hi Rodney,
Our dev and prod environments had been migrated first from SP2010 to SP2013 and recently to SP2016. We are facing problem with all work flows as they are based on SP Workflows 2010. As per description, we ran the Powershell scripts. But it did’nt help. We also noticed that workflows with some “Condition” fails or throws error about unautorization of “CodeBinaryOperatorExpression” , while simpler workflows gets verfied in SharePoint Designer 2013. Can you suggest any further steps that can resolve the current issue with work flows.
Regards
This article is poorly written.. If you’re running nintex workflows simply replace LINE 63 with this:
$typeNames = @( “CodeBinaryOperatorExpression”, “CodePrimitiveExpression”, “CodeMethodInvokeExpression”, “CodeMethodReferenceExpression”, “CodeFieldReferenceExpression”,”CodeThisReferenceExpression”, “CodePropertyReferenceExpression”, “CodeTypeReferenceExpression”)
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?
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
Yes, the script missed one type. So Nintex didn’t work still. We just manually added this line below and now everything is working fine.
My Nintex workflows still fail to start after applying this patch! I am being pressed to get this fixed.
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?
If you see the error in the ULS log, yes. Otherwise, no.
Is Microsoft releasing a hotfix or do we have to update the web.config?
The fix will be available on a regular SharePoint CU (no ETA, but my educated guess is that it will come in November)
Hello Rodney Viana,
thanks so lot for ur Post!
Its helped and i have a an addition, if someone not use the script:
in the webconfig add this line too ( Nintex2010 and SharePoint2010 ):
“”
best regards
Stauberle
Unfortunately if you use xml/html tags, the text will not show. Thanks for the intention though.
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.
That is correct. I added a video that also includes this step as we faced it on some cases too.
Hi Rodney
Please 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.
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.
Hi Rodney
Thank 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 regards
Peter
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.
If we will exclude this update and perform next windows updates then still we will face same issues.
Yes.
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?
There will be no reissue. The solution will come in the form of a SharePoint patch.
When the fix (SharePoint patch) gets released, do we need to undo the temporary solution you provided on this post?
You do not need to undo the changes in this post. The fix will come soon. No ETA though.
Can anyone comment on whether the new .Net update (KB 4459922) resolves these issues without the need to manually change the web.config?
This is an issue with SharePoint and will be resolved in a SharePoint fix. .NET will not release any fix because this change was intended to prevent remote code execution.
Will this fix be included in the next SharePoint CU update. Any communication on this by Microsoft?
Thank you, Rodney
This has helped resolve our workflow failing issue with Nintex workflows. It has worked so far without applying timer service fix.
Glad it worked for you.
Nice article
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
See this: https://blogs.msdn.microsoft.com/rodneyviana/2018/10/12/step-by-step-video-on-how-to-fix-the-sharepoint-workflow/
Will running the fix script on SharePoint prior to applying the .NET security patches cause any harm?
It will not cause harm to apply the fix before .NET patches.
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-2013
We 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?)
October CU does not address this issue.
Is there an ETA? for when the next Cumulative update will resolve the issue?
No ETA, I will update when I have it. My educated guess is that it is coming on SharePoint November CU.
Will running the fix script cause any service interruptions? I’d like to know if it requires any offline hours to run.
Just IISRESET and starting and stopping OWSTimer.
For Note 2 and SharePoint 2010 use following where version number needs to be 2.0.0.0
If you use the script it adds version 2.0 if it is SharePoint 2010. Please use the script rather than manually adding values.
This Solution worked for us..! thanks Rodney..
Worked for us..! Thanks Rodney..
Hi All ,
Please help on this , we have 2 WF and 1 app server in SP2010 . while running Owstimer script i am getting the error only for 1 app server ,
Also code only updated in 2 WF’s . But workflows are working fine. below is the error message.
Why this error is coming for Application server , any help/suggestion please.
“Get-WmiObject : Invalid class
At D:\WorkFlowFIX\Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1:371 char:52
+ $timerServiceConfigPath = Get-WmiObject <<<< -Query "SELECT * FROM Win32_Service WHERE name = 'SPTimerV4
'" -ComputerName $computer | SELECT @{Name="PathName"; Expression={$_.PathName.Trim('"')}}
+ CategoryInfo : InvalidOperation: (:) [Get-WmiObject], ManagementException
+ FullyQualifiedErrorId : GetWMIManagementException,Microsoft.PowerShell.Commands.GetWmiObjectCommand
"
Copy the file from one of the WFEs to your APP server.
In some farm scenario’s this will not be sufficient. Certainly when using nintex workflow.
We applied all fixes on the wfe’s. They worked fine. The appserver timer serivce kept complaining though.
Execute this powershell to persist changes to the config db.
$webapp = Get-SPWebApplication -identity http://
$webapp.UpdateWorkflowConfigurationSettings()
Reference:
https://community.nintex.com/community/build-your-own/blog/2015/08/28/the-infamous-failed-to-run-errors-in-the-history-list
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?
It is possible, if the exception you see is the same so it is the same problem.
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?
I suggest you to watch the step-by-step video.
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?
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.
Solution worked! Thank you, Rodney.
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
To suppress the emails for Nintex workflows, go to Central Admin and click on Nintex Workflow management. On the Nintex Workflow Management page you should see a link that says Workflow Error Notifications. Click this and you should seen something that says: “Send Notifications to the Workflow Initiator”. Change the selection to No to suppress the Error and Cancel notifications. You can also redirect those notifications to someone else like the Admin by placing an email address in the box below the radio buttons. HTH.
Does this affect Windows Server 2016?
All Windows versions.
Does this .NET security patch get installed onto Windows Server 2016 or is that sever OS not affected by this?
All Windows versions
We applied the fix on our 2013 SharePoint server and we had the Powershell script in order for it to take affect.
Kind of a NOOB question, but here goes. I have two Sharepoint environments. I ran your script on my Sharepoint 2010 environment and it worked perfectly. Thank you. But on my Sharepoint 2007 environment running WSS 3.0, the script fails with errors on every command. Everything from “..is not recognized as the name of a cmdlet”, to “Unable to find type [Microsoft.Sharepoint.Administration.X]” to “Property ‘X’ cannot be found on this object.” Both environments are on Server 2008 R2 boxes. However, I noticed in my 2010 environment I have a Shareoint 2010 Management Shell. I don’t have that in my 2007 environment. I tried running “Add-PSSnapin “Microsoft.Sharepoint.PowerShell” on that machine, but received an InvalidArgument error. Bottom line, what am I doing wrong to get this script to run in my Sharepoint 2007 environment?
p.s. I now see the first line “Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue | Out-Null” in the script. But don’t receive an error like I do when I run it by itself. I assume that’s because of the “SilentlyContinue” part.
The scripts work with SharePoint 2010+. You have to make manual changes for MOSS 2007.
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.
Hello Rodney,
I think we have the same problem (the workflows failed starting suddenly without any change to the site) but I can’t find an entry tagged 72fs in the logs. It’s worth noting that I don’t have any “SharePoint Foundation Workflow Infrastructure” area entries in the log provided by the server administrator.
My question is: do you think they might have sent me the wrong log files. Or is it possible that the current log level isn’t high enough to show workflows-related errors?
Thanks
Justin
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.
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….
How about not just posting that script on git-hub so people at work can download it…..? WTF
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…
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?
There is no problem in running the scripts before the patches.
Has the problem been fixed?
Thank you for this!
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.
The OWSTimer script should resolve that. If not, I recommend you to open a support case to investigate.
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.
Check out the video. In special the last optional step
Thanks Rodney, It worked like charm. Now my workflows are running
We use Nintex in our 2016 environment . I ran the scripts with -IncludeNintexWorkflow and it did not add the lines as expected to the web.config files. Not sure why it didn’t make that change as it did update the modified date. We manually added the 7 authorizedType lines as well as the authorizedType line for Nintex that contains “CodeTypeReferenceExpression”. Workflows are running now. OWSTIMER script worked as expected.
Hi,
Any news about permanent fix without the workaround?
Hi,
Any news regarding the permanent solution (SP CU)?
Hi,
Is there any news about permanent solution for this issue (to do not use the workaround)?
Patch is coming to SharePoint 2010 to 2016
Do you have any approximate date for the SP patch?
My educated guess is that it should be in November CU which ships normally before 11/15.
I see the November Patch is out
https://docs.microsoft.com/en-us/officeupdates/sharepoint-updates
But 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)
I put the links at the beginning of the post.
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.
The impersonation is a different problem
Thanks for the reply Rodney, any idea of the impersonation problem will be addressed in the future?
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.
Thanks a lot, it resolved my problem.
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.
Nintex problems will not be addressed by the patch.
I have done everything here and I’m still getting the owstimer error in a SP 2016 farm (1 WFE, 1 App, and 1 Search server)for nintex workflows. I have double checked the OWSTimerConfig file on each server, restarted IIS several times as well as the SP Timer without any success. What else can we do to troubleshoot this?
Microsoft.SharePoint.SPException: <CompilerError Line="-1" Column="-1" Text="Type System.CodeDom.CodeTypeReferenceExpression is not marked as authorized in the application configuration file."
Make sure Workflow runs in a WFE machine.
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?
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?
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
You may have forgotten the close ‘}’
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.
It is possible
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…
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.
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.
If you use Nintex you need to follow the OWSTIMER.EXE.config option. Follow the video. It is more straightforward.
Which patch applies to enterprise sharepoint 2013 server?
Follow the second link in the beginning of the post
Yeah my sharepoint servers have that patch installed. the code for web.config fixed it though. Is this normal?
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.
Is SharePoint Web Services and SP Timer Service running on the server?
(The content was deleted per user request)
And yes. Web services and timer services running on all WFE servers.
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.
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.