January 2026 CU for SharePoint Server 2019 is available for download

15 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!

3. 

   Priya
   On 13. March 2026 Permalink

   Hi Stefan,

   just checking—could you please advise whether this issue has been resolved in the March 2026 patching?

   Thank you!

   Reply
   1. 

      Stefan Goßner
      On 13. March 2026 Permalink

      Hi Priya,
      yes it is resolved – for most TagMappings.

      But if you have custom tag prefixes it might require to allow list them using PowerShell.
      If March CU does not resolve the issue, check the ULS log for the TagMapping it complains about (ULS tags: 4fhgk, 4fhgl) – message: “Failed to GetType for TagMapping tagType …”)

      At the end of the message it will tell you about the blocked TagMapping – e.g. MyPrefix:MyClass.
      MyPrefix will be the Tag Prefix in this context.

      To allow list it you need to run this PowerShell script:

      add-pssnapin *
      $f = get-spfarm
      $f.AddGenericAllowedListValue(“AllowedTagPrefixesWhichAreNotWebControlsList”, “MyPrefix”);
      $f.update()
      iisreset

      Cheers,
      Stefan

      Reply
4. 

   priya
   On 13. March 2026 Permalink

   Thank you for the reply Stefan. we will try to install the March CU and let update to you once complete. thank you!

   Reply
5. 

   Priya
   On 18. March 2026 Permalink

   Hi Stefan,

   We have installed the March CU package, but the issue still persists.
   We reviewed the ULS logs and identified the relevant tag prefix. We then executed the recommended PowerShell script to allow-list the prefix. However, the error continues to occur.
   We also verified the web.config file, the control’s tag prefix and the SafeControls entry is present and matches the assembly details.

   we are encountering the following error:

   “Skipping security validation for tagType PS:LikeControl because its tag prefix PS is allow-listed by admin in the farm configuration list AllowedTagPrefixesWhichAreNotWebControlsList

   Failed to GetType for TagMapping tagType ps:LikeControl

   Application error when access xx/xxx/xxx/Post.aspx,
   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()….”.

   Could you please advise on any additional checks or steps we might have missed?
   Thank you for your guidance.

   Reply
   1. 

      Stefan Goßner
      On 18. March 2026 Permalink

      Hi Priya,
      in this case ensure to open a support case with Microsoft to ensure this gets analyzed.
      Cheers,
      Stefan

      Reply
6. 

   Holger Wurbs
   On 26. March 2026 Permalink

   I have a solution for your problem. The issue is that Microsoft restricted the controls that can be included within a DataFormWebPart because its content is XSL which means, it will be deserialized on runtime. I assume that this is a result of resolving any of the CVEs listed above. Microsoft has hardcoded a list of allowed controls (tagprefixes, namespaces and assemblies) but it can be extended by a JSON-Property in der Farm PropertyBag (SPFarm.Properties) called “RegisterTagPrefixJson”

   First you need to identify which Control you have included in the DFWP that is not part of standard repertoire. Similar to adding SafeControls to the web.config (for using controls on parsed ASPX pages outside the scope of DFWPs), you then need to add this control in the following way. The TagPrefix needs to be lowercase.

   For example you have a Control MyPrefix:MyClass referencing the namespace MyNamespace.MyClass in the Assembly MyAssembly then you need to add:

   $farm = Get-SPFarm
   $farm.Properties[“RegisterTagPrefixJson”] = “[{“”TagPrefix””:””myprefix””,””Namespace””:””MyNamespacec””,””Assembly””:””MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=012abcd34567890a””}]”
   $farm.Update()

   As the property will be “cached” (static property) in Microsoft.SharePoint.EditingPageParser. You need to iisreset the FrontEnd server after this. This appears to be undocumented and maybe there are other ways to accomplish this but the referencing code is new since January CU and I haven’t found any official documentation about it.

   I hope this helps.

   Reply
   1. 

      Stefan Goßner
      On 26. March 2026 Permalink

      Hi Holger,
      thanks for the suggestion. In general a SafeControl entry should be sufficient if it is a server control with assembly/namespace.
      There is currently an open issue for User Control (*.ascx) which is not convered – but also cannot be enabled using the method you highlighted.
      Cheers,
      Stefan

      Reply