August 2026 CU for SharePoint Server 2019 is available for download

- - 35 Comments
Important: If your current farm patch level is September 2025 CU, execute the following PowerShell script to correct the folder permissions on the relevant folders otherwise installing the SharePoint fixes will fail:
Fix-SeptemberCU-Permission-Problem.ps1

Alternatively you can also remove the NT Authority\system account from WSS_WPG and IIS_IUSRS local security groups of the SharePoint machines.

For more details check this article: Trending Issue: SharePoint fixes fail to install after installation of September 2025 CU

The product group released the August 2026 Cumulative Update for SharePoint Server 2019 product family. SharePoint Server 2019 is patched with a language dependent and a language independent fix.

The KB article for August 2026 CU will be available at the following Location in a couple of hours:

  • KB 5002894 – August 2026 Update for SharePoint Server 2019 (language independent)
    This is also a security update!
  • KB 5002896 – August 2026 Update for SharePoint Server 2019 (language dependent)
    This is also a security update!

The downloads for August 2026 CU are available through the following links:

Important: It is required to install both fixes (language dependent and independent) to fully patch a SharePoint server. This applies also to servers which do not have language packs installed. The reason is that each SharePoint installation includes a language dependent component together with a language independent component. If additional language packs are added later (only) the language dependent fix has to be applied again.

It is irrelevant which language you pick on the drop down in download center. Even the language dependent fixes are all in the same package for all languages.

After installing the fixes you need to run the SharePoint 2019 Products Configuration Wizard on each machine in the farm. If you prefer to run the command line version psconfig.exe ensure to have a look here for the correct options.

Please ensure to have a look at the SharePoint Patching Best Practices before applying new fixes.

 
SharePoint 2019 August 2026 CU Build Number:

Language independent fix: 16.0.10417.20198
Language dependent fix: 16.0.10417.20198
 

Related Links:

35 Comments


  1. New month, new troubles 🙂 Did something change with BDC model validation, I’m now getting errors like
    Import-SPBusinessDataCatalogModel : Type ‘BCSServiceProxy.Claim’ is not permitted to be used in BCS and
    Import-SPBusinessDataCatalogModel : Type ‘BCSServiceProxy.Country[]’ is not permitted to be used in BCS for every model (I’m aware of the new BDC file import restriction but don’t know if this is related)

    Reply

    1. I have some additional info – on another farm with existing models they are not loaded – an example
      BCS type ‘Nullable1' in namespace 'System' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not in the 'BCSAllowedTypeNames' generic list. To permit this type, add entry 'Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|Namespace=System|TypeName=Nullable1′ to the ‘BCSAllowedTypeNames’ generic list.

      BCS type ‘Nullable`1’ from assembly ‘mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ is being blocked.

      So it looks like there is a new BCSAllowedTypeNames parameter that needs to be populated, how to do this. I’m now certain this issue will be present also in SPSE farm.

      Reply

      1. Seems semi-related, not sure if this readds those assembly types. Worth a shot though!

        From the KB article section „Improvements and fixes“

        „Disables file-backed Business Data Connectivity (BDC) model import by default to improve security. Use the Enable-BdcmFileImport PowerShell cmdlet to enable this functionality for a site collection.“

        Reply

        1. agree, although not the cause. But it did alert me to think there have been other related security changes. Opened a ticket with MS when I realised the issue will also be present on SPSE farm once patched.

          There’s a method to add the “offending” bcs types to allowlist and it’s fixed on the farm with existing models, but importing those models is still under investigation.

          Reply

      2. I’m having the same problem. Do you know where „BCSAllowedTypeNames“ should be populated? I tried the BDC service application proxy property bag, but to no avail. I used the value suggested in the ULS log. Is it the correct format?

        ULS:
        BCS type ‚SecureStoreProvider‘ in namespace ‚Microsoft.Office.SecureStoreService.Server‘ from assembly ‚Microsoft.Office.SecureStoreService, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c‘ is not in the ‚BCSAllowedTypeNames‘ generic list. To permit this type, add entry ‚Assembly=Microsoft.Office.SecureStoreService, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.SecureStoreService.Server|TypeName=SecureStoreProvider‘ to the ‚BCSAllowedTypeNames‘ generic list.

        Reply

        1. I understood Microsoft does not publish the details, but the required commands can actually be patched together from the info on this site 😉 Stefan can remove the comment if not allowed.

          the format is
          $farm = Get-SPFarm
          $farm.AddGenericAllowedListValue(‘ListName’, ‘value exactly from ULS logs’)
          $farm.Update()
          iisreset

          Reply

          1. I got it fixed now! I had to add a bunch of other entries to the list as well, but got it working in the end. Thank you very much for the info!


          2. Excellent! I still can’t import models so hoping MS will be able to resolve it, otherwise our migration will be further delayed


  2. Sharepoint 2019 is end-of-life but we still get a CU in August and that the KB for said CU mentions future CUs. Interesting.

    Reply

  3. Tested search, not working (topology unavailable in Central Admin) same as per May CU

    Reply

  4. August CU for SharePoint 2019 is a surprise. But what if we will face some post-patching issues but we cannot open a MS Support Case due to end of support for this product? 🙂

    Does Microsoft plan to release more CUs for 2019?

    Reply

      1. I think this is just copy and paste from the same fixes in the SPSE KB article.

        Reply

    2. Afaik there are currently no plans for further CUs

      Reply

  5. Good morning Stefan,

    Does this CU address the „Trusted Provider or Forms authentication“ issue introduced in Julys CU?

    Reply

  7. Hello Stefan,

    Any insight on why MS released CU in AUG? END of life with JULY .. Are we supposed to adopt this CU and will there be additional CU in future?

    Reply

    1. Due to the fact that there were a large number of outstanding critical fixes for security issues. Fixing them for just SPSE would have allowed malicious actors to reverse engineer the fix and exploit the issues on SP2016 and SP2019 servers which have not yet been taken offline.

      Reply

  8. Another month, another issue. Seems to have gone backwards, and am once again getting Nintex Workflows “Failed to Start”. They are automatically being cancelled by System account.

    I checked the fix from the previous issue, ran the script and confirmed that the modification was still present.

    Anyone else having WF issues at this time?

    Thanks

    Reply

  9. Since this update, my external lists connected to Dynamics CRM don’t work anymore.

    When I go on SP Designer, under “External Content Types”, and then try to edit the “External Content Type Operations”, I receive the following error : Type System.Data.IDataReader is not permitted to be used in BCS

    I am currently in the process of migrate this SharePoint, but some critical operations cannot be accomplished by my users. What workaround can I use to unblock this situation?

    Reply

  10. Following on from my WF failed to start issue, I am also finding that WF will not publish once exported to a separate list.

    I have also raised this with Nintex support, provided them ULS logs, and am awaiting an update

    Reply

    1. Never mind, Nintex was deactivated on that particular site, after reactivated it, workflow are working fine.

      Reply

  12. Hello,

    I have a further update regarding ongoing issue with Nintex WF’s, namely WF’s with a Pause action, failing to run, as opposed to failing to start, which they did previously. I was able to extract the following from ULS logs:

    08/23/2026 08:06:03.93
    OWSTIMER.EXE (BDCAAPPR648:0x2690)
    0x2514
    SharePoint Foundation
    Legacy Workflow Infrastructure
    4letu
    High
    Block the namespace: clr-namespace:System.CodeDom;Assembly=System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, type: CodeBinaryOperatorExpression.Right d0f933a2-cf4c-0087-f182-22fe456634e4

    Nintex were also able to extract the following:

    08/22/2026 21:25:29.20
    OWSTIMER.EXE (BDCAAPPR648:0x20B8)
    0x077C
    SharePoint Foundation
    Legacy Workflow Infrastructure
    72fs
    Unexpected
    RunWorkflow: System.InvalidOperationException: This feature has been temporarily disabled.

    As you can see, the WF is trying to run in the OWSTimer.exe process, which of course as we know isn’t a thing. Nintex advised me to check all OWSTimer files for any authorized types, and remove. On checking, there were no authorized types in any of said files.

    For info, we do have multiple WFE’s all served by a LB.

    From what I can tell, all of the web configs do contain the required modifications, as I ran the scripts provided by Stefan

    Please advise what else I can check, as I have another Production farm awaiting patching

    Many thanks

    Scott

    Reply

    1. Hi Scott,

      check the owstimer.exe.config file in the bin directory. Ensure that there are no authorizeType entries included – otherwise the web.config entries will be ignored.

      Cheers,
      Stefan

      Reply

  13. Hi Stefan,

    All OWS Timer config files were checked prior to me posting the comment. There are no authorized types of any kind in any of the files, across all SharePoint servers.

    Is there anything else it could be

    Thanks

    Scott

    Reply

  14. Following some more deep diving of web configs last night, I found the following assembly to be absent from the required web configs, namely the ones running the SP Foundation Web application service

    Subsequent testing confirmed that all WF’s, especially ones with pauses are now completing as expected.

    I will be patching the remaining production farm this week, ensuring said assembly exists

    Many thanks for your support in this matter

    Scott

    Reply

  15. For some reason the assembly did not paste

    „“

    Reply

  16. Hello again,

    Meant to say that I was successful in resolving the Nintex issue, turned out to be the missing assembly for System.CodeDom “*” on all WFE/APP servers.

    I have now had a different issue reported involving the Document ID service. The following error has been found in the ULS Logs.

    DocumentId/GetProvider: Assembly ‘Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ is not in the farm allowlist ‘AllowedDLCAssemblies’. Blocked. Farm Admin must add it via SPFarm.AddGenericAllowedListValue to allow loading. 995035a2-0fe4-0087-ca9d-41bae6acadd8

    When searching the web configs, I am unable to find “AllowedDLCAssemblies”

    If someone can confirm the correct assembly, I can add it and confirm working.

    Thanks

    Scott

    Reply

    1. Hi Scott,

      this is not in the web.config. It is a farm property.

      Try this

      $farm = Get-SPFarm $farm.AddGenericAllowedListValue(“AllowedDLCAssemblies”,”Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”) $farm. Update()

      Cheers,
      Stefan

      Reply

  17. Morning Stefan,

    Thanks again for the info. I can confirm this has indeed resolved the issue.

    Regards

    Scott

    Reply

    1. Perfect! Thanks for the update. 😊

      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.