Resolved: Trending issue: problems with Workflows after applying September 2024 CU for SharePoint 2016/2019/SE

- - 24 Comments

In September 2024 CU a new security fix was included which added a restriction for Workflow actions. Only actions in namespaces which are explicitly allow listed by an administrator through an authorizedType entry in the web.config and owstimer.exe.config can be used.

As this modification is also required for workflow actions in 1st party assemblies shipped with SharePoint it caused significant efforts and concerns.

With December CU Microsoft has released an update to mitigate this: all required Namespaces for Workflow actions shipped with SharePoint are now automatically allow listed.

To achieve this the following entries are added to the web.config and the owstimer.exe.config files when running the SharePoint configuration wizard after applying December 2024 CU:

<authorizedType Assembly="Microsoft.Office.Access.Server.Application, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.Access.Server.Macro.Runtime" TypeName="*" Authorized="True" />
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="*" Authorized="True" />
<authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />
<authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />

In situations where 3rd party workflow actions are used it will still be required to update the web.config.

The vendor of the 3rd party workflow actions should be able to provide guidance on the required web.config modifications to allow list any additional required types.

24 Comments


  1. Good afternoon, Stefan.

    Just curious if we already applied the workaround to the web.configs in September, do we need to make any changes or reverts before applying the December CU or just go ahead and install?

    Thank you and Happy Holidays!

    Daniel

    Reply

    1. Hi Daniel,
      you can just install it – but I would still double check if any duplicates are in the web.config afterwards (e.g. due to different formatting)
      They do not hurt but unnecessarily increase the size of the web.config file.
      Cheers,
      Stefan

      Reply

  2. Thanks again, Stefan – On Nintex farms, if there are no authorizedtype assemblies listed in owstimer.exe.config at all, then Nintex workflows running in the owstimer.exe process (site workflows and list workflows that have pauses, state changes, or another action that would cause them to move from w3wp.exe processing to owstimer.exe processing) refer to the authorizedtype assemblies in the web.config file of the corresponding web application.

    With this December SharePoint update injecting authorized types into owstimer.exe.config, it seems that we should be on the lookout for additional missing assemblies that Nintex may require in owstimer.exe.config. Sound accurate?

    Reply

    1. Hi Brett,
      yes. 3rd party assemblies and namespaces are not added by SharePoint.
      If such assemblies/namespaces are required they need to be added either through custom features coming with the 3rd party or manually added by a SharePoint admin.
      Cheers,
      Stefan

      Reply

    2. Here is an example of an OWS Timer exe config file from one of our WFE’s:

      <appDomainManagerAssembly value="Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      <appDomainManagerType value="Microsoft.SharePoint.SPAppDomainManager" />

      As you can see, there are no Authorized type assemblies for Nintex.

      Does this mean that a manual update of all OWS config files is required.

      Many thanks

      Reply

  3. On thing I struggle with all that stuff is. I have a workflow that try to retrieve Emails from a multiple user fields in a SharePoint 2010 Workflow. I get the claims back but without patching non of the Email adresses will get returned by the workflow and they crash with an unspecific error.

    It was partiall fixed with:
    <targetFx version="v4.0">
    <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />
    </targetFx>
    </authorizedTypes>

    and

    $farm.EnablePreParseSecurityCheckForWorkflow = $false

    Any thoughts on that?

    Reply

    1. Hi Stefan,
      do not use $farm.EnablePreParseSecurityCheckForWorkflow = $false
      This will disable several security fixes.
      In addition as it did not help the issue seems to be unrelated. I would suggest to open a support case with Microsoft to investigate where the unspecified error comes from.
      Cheers,
      Stefan

      Reply

      1. With all the entries provided above the EnablePreParseSecurityCheckForWorkflow = $false is not required anymore.
        Thanks for your help throughout the years.

        Reply

  4. Hi Stefan,

    I came across a SharePoint 2010 workflow in our environment that was still having issues after applying the December 2024 CU. It was being executed in owstimer, and this authorized type was not listed in owstimer.exe.config on any server in our farm:

    The workflow uses an out-of-the-box Feedback Process activity. Just wanted to pass this along.

    Reply

  5. The authroizedType block was stripped from my previous comment. Trying again.

    authorizedType Assembly=”Microsoft.Office.Workflow.Actions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” Namespace=”Microsoft.Office.Workflow.Actions” TypeName=”*” Authorized=”True”

    Reply

  6. Hello,

    We applied the Dec 2024 CU to both our Production farms prior to Xmas break, and have returned to a number of WF’s giving a fail to start etc.

    Based on the information, I am under the impression that Dec CU now negates the need to manually update the web config files, and that entries in the OWSTimer Config files are no longer required.

    Please confirm this is the case, or do I need to update all OWSTimer files?

    Many thanks

    Reply

    1. Hi Scott,
      with December CU SharePoint adds all required SharePoint namespaces as authorizedType as well to the web.config and the owstimer.exe.config file.
      Manual updates are only required for namespaces for 3rd party or custom workflow actions integrated with SharePoint.
      Cheers,
      Stefan

      Reply

  7. Anyone have any news on this? Nintex support points me to the September 2024 post issue fix, but the fix is ​​already applied.
    That said, it tells me I need to ask Microsoft. Is it possible that after a month of the patch being released there is no evidence of a fix?

    Reply

    1. Hi Massimiliano,

      December 2024 CU includes a fix which updates the config files with all namespaces required by workflow actions shipped with SharePoint.
      Nintex specific workflow actions have to be allow listed manually be the administrator. Nintex owns this and needs to provide guidance on the specific namespaces that need to be allow listed.

      About your question related that a month after a patch is released no fix is available: cut of date for the next CU is usually the day before releasing the previous CU. So the earliest CU a fix can be included would be the 2 months later than the CU that introduced the issue. But only if the issue was reported very quick after the CU has been released, Support was able to identify the issue as a regression and the PG was able to implement a fix in only a couple of days. If this takes longer a fix would be in a later CU.

      Cheers,
      Stefan

      Reply

  8. I applied Dec 2024 CU on my SP 2019 server farm. I lost to create or update SharePoint 2013 designer workflows. How can I get them back to work. Is there any fix/workarround?

    Reply

  9. I have applied Dec 2024 CU on my SP 2019 Server Farm. However, the SP designer 2013 workflow doesnt work. I don’t see the workflow in designer. I cannot manually run the workflow on sharepoint list. It throws some error.
    I verified the entries in web.config file. But still no 2013 desginer workflow shows in SP Designer

    Reply

  10. We just ran the January 2025 updates and now the workflows are “Failing to start”. I had this problem with the December 2024 update and taking out the Authorized Types from the OWSTIMER.EXE.CONFIG file fixed it. Nothing was changed on the owstimer.exe.config file last night but one entry was placed into the web.config file for the web app:

    <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />

    I tried commenting that line out and doing an IISRESET but still had the same issue so put it back in.

    I have a case opened with Nintex to try to resolve this.

    Reply

    1. please let us know if you got the issue fixed , if yes then please share the guide

      Reply

      1. I updated Nintex WF/Form to the latest version. No problems after the update. Ran the FEB Microsoft updates and Workflow broke again. I had to edit the web.config file because the authorized types were not in the config file. I’m really getting tired of “fixing” Nintex every time Microsoft makes updates.

        Reply

    2. Hello David,

      There is a newer version of Nintex WF/Forms available from their community, that resolves this issue. I have applied this version along with the Feb CU, and to date, no issues have been reported with any WF.

      https://help.nintex.com/en-US/platform/ReleaseNotes/NintexSharePoint2019.htm

      Nintex Workflow
      General
      Updated installer to include a fix for a September CU issue that caused publishing problems on some workflows. To learn more, see this Microsoft Article.

      Hope this helps

      Reply

      1. HI Scot, we have today done the Feb CU Update and also the Nintex Patch but no workflow is further running if we using the “waiting for” action or if we wait until another workflow is finished.

        Reply

        1. Hi Björn,
          when using “waiting for” the workflow will not continue in the w3wp.exe but in the owstimer.exe.
          That means you either have to add all the autorizedType entries also to the owstimer.exe.config file or you have to remove the whole autorizedTypes section from the owstimer.exe.config to ensure that it will use the configuration from the web.config.
          Cheers,
          Stefan

          Reply

          1. Thanks Stefan, its working now again.


  11. I have added the above entries in web.config but workflow still not working and showing following error in logs:

    Potentially malicious xoml node: <ns2:BuildAssignmentsXmlActivity __Context="{ActivityBind ROOT,Path=__context}" Value="<my:Assignments xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD" xmlns:pc="http://schemas.microsoft.com/office/infopath/2007/PartnerControls"><my:Assignment><my:Assignee><pc:Person><pc:DisplayName/><pc:AccountType/><pc:AccountId>[%ID4522.ReturnValue%]</pc:AccountId></pc:Person></my:Assignee><my:Stage>0</my:Stage><my:AssignmentType>Serial</my:AssignmentType></my:Assignment></my:Assignments>" ReturnValue="{x:Null}" x:Name="ID4521" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:ns2="clr-namespace:Microsoft.Office.Workflow.Actions;Assembly=Microsoft.Office.Workflow.Actions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" />

    I then added following entry in web.config, restarted timer job, restarted workflow but getting same error.

    <authorizedType Assembly="Microsoft.Office.Workflow.Actions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.Office.Workflow.Actions" TypeName="*" Authorized="True" />

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.