January 2026 CU for SharePoint Server 2019 is available for download

8 Comments

1. 

   Prashant Kumar
   On 16. January 2026 Permalink

   Subject: SharePoint 2019 January Security Updates – Risk & Workflow Manager Issues

   Hi Stefan,
   We have January security updates available for SharePoint 2019. Before proceeding, I wanted to highlight the current risk and status, based on our recent patching experience.
   As part of the November 2019 updates, we encountered an issue where our classic Workflow Manager (WFM) setup broke post‑patching. Since then, we have been actively working to restore the workflows but are still facing blocking issues.
   We have followed all remediation steps and guidance published by Microsoft, including:

   Official Microsoft documentation:
   https://learn.microsoft.com/en-us/sharepoint/governance/update-to-spworkflow-manager-when-upgrading-farms

   Community guidance on upgrading SharePoint and Workflow Manager together:
   https://joshroark.com/upgrading-sharepoint-and-wfm-at-the-same-time/

   Despite following the documented steps, we are encountering failures at multiple points. The two major issues observed are:

   Reconfiguring Workflow Manager on the original server

   The configuration fails with an error asking to remove the Workflow Manager folder, even though the folder does not exist on the server.

   Configuring Workflow Manager on a different server in the farm

   The setup fails with SQL connection errors, and
   We are unable to reuse the old server certificates, since the certificate key was reset earlier, blocking the configuration process.

   Due to these unresolved issues, classic workflows remain impacted, and we are still working toward a stable remediation.
   given this situation, shall we move forward with Jan patch does it affect the classic workflow manager?

   Thanks,
   Prashant

   Reply
   1. 

      Damien
      On 21. January 2026 Permalink

      Hello,

      The error indicating the presence of the “workflow manager” directory is due to a registry key that must be deleted.
      After that, installation can proceed.
      In addition, it is necessary to migrate to the SharePoint workflow manager.

      Reply
      1. 

         Prashant Kumar
         On 21. January 2026 Permalink

         Thanks for the update. We followed the registry key deletion workflow and ensured that no related entries were left behind. However, we are still encountering the same error.
         Do we have any other documentation or article that provides a more practical approach for upgrading SPWFM from Classic?

         Reply
2. 

   Priya
   On 26. January 2026 Permalink

   Hi Stefan,

   we have installed the Jan 2026 patching to UAT environment on 23 Jan 2026. after install the patch some of the custom webpart unable to open. ‘The type is not registered as safe’ error. checked the SP logs, ‘Error=The type is not registered as safe. at Microsoft.SharePoint.EditingPageParser.VerifyControlOnSafeList(String dscXml, RegisterDirectiveManager registerDirectiveManager, SPWeb web, Boolean blockServerSideIncludes, Boolean blockPropertyTraversal) at Microsoft.SharePoint.WebPartPages.DataFormWebPart.CreateChildControls() at Microsoft.SharePoint.WebPartPages.XsltListViewWebPart.CreateChildControls() at System.Web.UI.Control.EnsureChildControls() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 37a3f0a1-0846-f0d0-e699-1c63a39b04ef’. These custom webpart we are using very long time, and recently there is no changes on these webpart. please advice on this.
   thank you!

   Reply
   1. 

      Stefan Goßner
      On 26. January 2026 Permalink

      Hi Priya,
      you need to identify the specific webpart that is causing the problem and add it in the SafeControls section of the web.config.
      See here for details:
      https://blog.stefan-gossner.com/2020/09/25/trending-issue-after-installing-september-2020-cu-and-pu-custom-pages-and-controls-fail-to-render/
      If you cannot identify the webpart, please open a ticket with Microsoft support to get assistance.
      Cheers,
      Stefan

      Reply
      1. 

         Priya
         On 27. January 2026 Permalink

         Hi Stefan,

         thank you for the update.
         We have troubleshot as per your guide, and identified the affected control related to the issue. On the post page, we are using a Custom Web Part along with a Script Web Part. The Script Web Part includes an XSL file that contains the Like control. The issue appears to be caused by the following line in the XSL:

         We verified the web.config file and confirmed that the control is already registered as a Safe Control.
         We also attempted to update the assembly version and PublicKeyToken, however, the issue still persists.
         When we comment out the PS:LikeControl line in the XSL file, the page loads successfully, but the Like functionality is no longer available.
         Could you please advise on this issue and suggest how we can resolve it while retaining the Like functionality?

         Thank you!

         Reply
         1. 

            Stefan Goßner
            On 27. January 2026 Permalink

            Hi Priya,
            we have meanwhile identified the issue as a problem in January 2026 CU.
            Please open a ticket to get informed when a fix has been made available.
            Cheers,
            Stefan

            Reply
            1. 

               Priya
               On 28. January 2026 Permalink

               Hi Stefan,

               Noted, thank you for the update!