Unable to publish or run workflows with Task based actions (Assign Flexi task, Assign to-do task, Request approval, Request data, Request review) after installing the July 2021 CU for SharePoint 2013, 2016, 2019.
spNoCodeXomlCompilter.IsGoodWorkflow: Potentially malicious SetVariableActivity
CompileBytes: Web [web URL] , Site [Site URL], Tenant , Error parsing xoml:
Workflow Compilation XPath killswitch resulted in an exception: System.InvalidOperationException: This feature has been temporarily disabled
Error saving from workflow export file.: Nintex.Workflow.NWSavingWorkflowException: Failed to publish workflow: This feature has been temporarily disabled.
To resolve the issue, add the following lines to all of the SharePoint web application's web.config:
<authorizedType Assembly="mscorlib, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Int64" Authorized="True" /> <authorizedType Assembly="mscorlib, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Int64" Authorized="True" />
These need to be added in the authorizedTypes config section (configuration -> System.Workflow.ComponentModel.WorkflowCompiler -> authorizedTypes -> targetFx)
This issue is coming from a new change to address Common Vulnerabilities and Exposures that were delivered in the July Public Updates for SharePoint Server.
We will provide an update once the resolution has been included in an updated build of Nintex Workflow for SharePoint On Premises.
For us also all scheduled workflows (even without those mentioned task actions) started to getting "Failed on Start" errors after this same July 2021 CU patch. Do you know if it's relevant to this?
We are seeing the same behavior as @orkun. Scheduled Workflow are still failing. It does look related to the July 2021 security patch. Does something need to be added to the OWSTIMER.EXE.CONFIG?
Hi @jaxner , Actually we were able to solve the scheduled workflows issue by running the powershell command in the following article: https://support.microsoft.com/en-us/topic/some-scenarios-of-sharepoint-2010-workflow-are-affected-after-applying-the-july-security-update-for-sharepoint-server-kb5004862-be361cd6-9f54-48c4-b890-2c4b7cf49d13
Putting autherizedType in config worked only for some workflows and in my case when it reached to pause action it failed again.
Using reference link to 2010 PowerShell commands worked to run dead workflows, waiting to see scheduled workflows tomorrow, but some workflows still not working, so checking all workflows, still under testing.
Applied PowerShell but doing that shouldn't be compromise security as mentioned below? Is there any permanent solution to this.
As said earlier the workflow worked shows logs like below. This shows it keeps trying and after 5 hours when I applied PowerShell it worked.
While the one which still showing in failed stated have logs like below, ran only once never tried again, Any ideas on how this will run back?
It's the same list with restarted instance and failed instance, all new items created have a successful running workflow, but I am not clear how Nintex Service or something pick back failed to start workflows from some queue in DB
This workflow is in an error state but it's running, shows with yellow background, but tries in logs show a different pattern, not clear how frequently Nintex process checks is there any fixed pattern? like every 5 or 15 mins. @joshua_tan
Hi there. Just wondering if the July 29, 2021 update for Nintex, version 126.96.36.199 fixes this issue?
I can see from the Release Notes that the July Nintex patch has this bullet point:
Fixed an issue with publishing and running workflows containing Task-based actions if the SharePoint July CU 2021 patch is installed (254741).
Is that addressing this issue? If yes, could you please update guidance in this article.
Thanks very much.
Does the August CU 2021 fix this issue with the workflows not starting?
@Vladimir - I have that version of Nintex installed and it is not working ... waiting for "premium" support now almost 4 hours
Is there any news about this issue? did nintex release a new version to fix this?
Thx in advance.
@Vladimir Just installed the new version of Nintex 188.8.131.52 (last release) and the lines were not present in the web.config, we had to add them manually.
@allan thank you for sharing your experience and the additional information
Important note about this.
After speaking with Microsoft and Nintex we found that when it is indicated in the article that the lines need to be added in ALL the web.config files it means the ones of the web applications but also the web.config of the OWSTimer if it has been modified before. This is located here:
C:Program FilesCommon Filesmicrosoft sharedWeb Server Extensions16BINOWSTIMER.EXE.CONFIG
Note that the 16 will be a 15 in SHP 2013 and 14 in SHP 2010.
Also needs to be checked that these entries are not overwritten here:
$webApp = get-spwebapplication [webappurl]
We are currently in discussion for this topic with my colleagues and need to decide if we would go for newest SP 2016 patch ( last installed for us is June 2021 ) , but we are not sure if its worth going for it or its better for waiting the final solution and not a workaround. Does this workaround work for all of you or you still have some issues?
From what I can read in this discussion, the July 29, 2021 update for Nintex, version 184.108.40.206, is not fixing this issue and you still need a manual update, is that right?
Aside of all this, is there any date on which we can expect a final solution for this problem?
Thanks in advance!!