SharePoint security fixes released with December 2024 PU and offered through Microsoft Update

11 Comments

1. 

   Robert
   On 12. December 2024 Permalink

   This patch seems to have stopped Nintex Workflows from running successfully. It seems like a similar issue to the September 2024 patch. Any ideas on this?

   Reply
   1. 

      Stefan Goßner
      On 12. December 2024 Permalink

      Hi Robert,
      Do you mean a new issue that did not exist in October CU?

      In case you were upgrading from a fix before September CU please see here:
      https://blog.stefan-gossner.com/2024/12/11/resolved-trending-issue-problems-with-workflows-after-applying-september-2024-cu-for-sharepoint-2016-2019-se/

      Quote: “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.”

      Cheers,
      Stefan

      Reply
2. 

   Joel Axner
   On 4. January 2025 Permalink

   Nintex Workflow features that leverage the Timer Service (Scheduled Workflows and LazyApprovals) failed for me after this patch. It was discovered that the OWSTIMER.EXE.CONFIG file was modified. We backed up the current file and set the OWSTIMER.EXE.CONFIG back to its default content to resolve the issue.

   Reply
   1. 

      Stefan Goßner
      On 5. January 2025 Permalink

      Hi Joel,
      SharePoint adds several trusted types to the owstimer.exe.config with December CU. Instead of reverting this and removing the types added by SharePoint it is recommended that all required trusted types for 3rd party components is added to the config file as well.
      Cheers,
      Stefan

      Reply
      1. 

         ruiming Liu
         On 10. January 2025 Permalink

         Hi Stefan,
         thanks for all the information you have posted here. they are very helpful.

         I try to use the solution you recommended. Is there more detailed information you can share?
         we contacted Nintex support. they suggested we delete all authorized trusted types in the timer job config file. will it cause any issues for SharePoint itself?

         thanks,

         Ruiming

         Reply
3. 

   Joel Axner
   On 6. January 2025 Permalink

   I apologize. I will reconnect with Nintex support on the topic. Their support recommended removing the authorized types.
   However, it was my understanding that the workflow-related configuration was previously pulled from the configuration database and by adding types to the OWSTIMER.EXE.CONFIG the server now uses the information in the config file instead of the information added to the config database by the following commands
   $webapp = Get-SPWebApplication -identity http:// $webapp.UpdateWorkflowConfigurationSettings()

   Is the above understanding correct?

   Also, can we automate the deployment of the authorized types to all the servers? Like we can with the SPWebConfigModification class?

   Thanks!

   Reply
   1. 

      Joel Axner
      On 9. January 2025 Permalink

      Nintex support continues to insist that the correct course of action is to remove the AuthorizedTypes from the OWSTIMER.EXE.CONFIG. They stated the following.
      “These entries essentially, are the same , when a workflow runs on the lazy approval it is looking for the authroized types, since these have been in your web.config file it’s conflicting.
      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.
      Hence, you do not need to add any more lines for Nintex. You just need to remove the additional references that were added.”

      Since removing the Authorized Types from the timer service config solves the problem, I will continue with that solution.

      Reply
      1. 

         ruiming Liu
         On 11. January 2025 Permalink

         Hi Joel, Stefan.

         I like to share what I have done,
         Based on the information from both you and Stefan.
         I actually copied all Authorized Types from web.config to Owstime.exe.config file.
         it seems it solved the Nintex issues.

         I could have copied more than I needed. Do you think this is a valid solution or workaround for the Nintex issues? I have reached out to Nintex support for a list of authorized Trust types.

         thanks again for your information.

         Ruiming

         Reply
4. 

   ruiming Liu
   On 10. January 2025 Permalink

   Hi Joel,
   We have exactly the same issues as you had.
   I tried the method you used. It did solve the Nintex issues. We were a little concerned about deleting an entire section of authorized types since they were just added by the patch.

   I also tried Stefan’s solution, but it did not solve the issues. I may have done it incorrectly. I simply merged authorized types from the owstimer.exe config to the web.config since there are more than 200 authorized types. Some of them are duplicated. I hope Stefan can provide us with more detailed information.

   so, Will you continue with the solution suggested by Nintex?

   Thanks for your information.
   Ray.

   Reply
5. 

   Vishal Agarwal
   On 13. January 2025 Permalink

   After Installing this patch my all-email notifications are in (c:/inetpub/mailroot/queue) folder and event logs are showing warning from 12/15 that

   Message delivery to the host ’40.xx.xx.114′ failed while delivering to the remote domain ‘xxx.com’ for the following reason: The connection was dropped by the remote host.

   We haven’t made any changes in SMTP Server. It just stops the notifications.

   Even simple alerts notification on list/library are not working.

   Could you please help on it.

   Reply
   1. 

      Stefan Goßner
      On 13. January 2025 Permalink

      Hi Vishal,
      this is not controlled by SharePoint.
      If you need assistance for this I would recommend to open a ticket with the Microsoft Exchange support team.
      Cheers,
      Stefan

      Reply