July 2021 CU for SharePoint Server 2019 is available for download

The product group released the July 2021 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 July 2021 CU will be available at the following Location in a couple of hours:

  • KB 5001975 – July 2021 Update for SharePoint Server 2019 (language independent) – This is also a security update!
  • KB 5001974 – July 2021 Update for SharePoint Server 2019 (language dependent)

The download for July 2021 CU is available through the following link:

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 July 2021 CU Build Number:

Language independent fix: 16.0.10376.20001
Language dependent fix: 16.0.10376.20001

Related Links:

26 Comments


    1. we still have issues running workflows with task based actions after installing the July 21 CU. We would not recommend to install the CU when using Nintex. We open a support case with Nintex.

      Reply

        1. Hi Pepe,
          be aware that the script in the KB should only be used as a temporary workaround as it effectively disables the security fix.
          A permanent solution should be applied by working with the relevant 3rd party vendor and afterwards its important to revert the change from the article.
          Cheers,
          Stefan

          Reply

          1. Hi, Stephan. Of course, I was suggesting the PS command only as a Workaround while they had time to install the last version of the Nintex software, which should include patch to solve the issue permanetly. I am sorry if I did not expressed it correctly.

            Thank you for the clarification 🙂


  1. Good day everyone.

    after the installtion of cu 07-2021 KB 5001975 – Sharepoint 2019 on prem I have also the same problem

    SharePoint 2019 July 2021 CU Build Number:

    Language independent fix: 16.0.10376.20001
    Language dependent fix: 16.0.10376.20001

    There was a display issue after the last update. that is, upon opening, for example:

    /_layouts/15/viewlsts.aspx the opened page is empty/blank

    Perhaps someone faced a similar situation and can tell what caused it and how to fix it?

    Reply

    1. Hi,

      Our analysis so far is as follows:

      It shows that sites like “AllItems.aspx” are not rendered.
      List information is included in the loaded web pages (web source code) but there seems to be no master pager information for rendering.
      Only Calendars and Forms Libraries are rendered correctly.
      Removing July’s windows updates and security fixes led to no improvement.
      After restoring the machine from backup (without July SP-CU) the sites are rendering correctly again.
      So the issue must reside in the July SP2019 CU that made changes on the server.
      Since the content and config DBs of the now working pages are still upgraded (16.0.10376.20001) there seems to be no issue with the upgrade in the databases but only with static code on the webfrontends.

      Hoping for a quick hotfix for the CU.

      Cheers,
      Andreas

      Reply

      1. Hi Andreas,
        please ensure to open a support case to ensure that this issue is investigated.
        Cheers,
        Stefan

        Reply

      2. We have the same issue only happening on libraries with Modern Views, no impact on libraries with Classic Views. Commenting to follow this thread.

        Reply

        1. Please install both CU fixes.

          Reply

    2. Stefan,

      Will the changes mentioned in the Nintex article be updated in a future CU? I am not a big fan of updating the Web.Config manually.

      Reply

      1. Hi Gene,
        from what I see: this issue has not yet been reported to the Microsoft product group.
        I would recommend to open a support case with Microsoft if you need Microsoft to investigate this issue.
        Cheers,
        Stefan

        Reply

    3. Hi Marco,
      please ensure to open a case with Microsoft support.
      Cheers,
      Stefan

      Reply

  2. There isnt a security update for language dependent?

    Reply

  3. Hallo,

    auf allen unserer getesteten SP2019-Farmen ist nach der Installation der Juli-Patches das Aufrufen der meisten Listen nicht mehr möglich. Auch Seiten wie “Websiteinhalte” oder “Papierkorb” lassen sich nicht mehr aufrufen.
    Der Quelltext von Seiten wie “AllItems.aspx” hat zwar Inhalt (man sieht z.B. die Elemente einer Liste im Quellcode), aber es wird in keinem gängigen Browser etwas gerendert.
    Die Server sind auf Englisch installiert. Das Problem besteht auch im deutschen Sprachpaket.

    Kann das jemand reproduzieren?

    Reply

  4. For me this was resolved by installing the language dependent KB5001974 and doing an IIS reset. The language dependent package was not automatically available because it’s not a security update, so I only had KB5001975 installed after getting everything Windows Update offered. I had to download the other update manually and install it from file.

    Reply

    1. That seems to do the trick for our SP2019 farms, too!
      After installing the wssloc (kb5001974) all lists are loading again.
      Uhhh, that’s a trap!
      Thank you so much!!!

      Reply

  5. Ich habe gerade das KB5001974 manuelle heruntergeladen und installiert dann die System neu gestartet!
    Jetzt ist ein zugriff auf die Seiten wieder möglich /_layouts/15/viewlsts.aspx

    Gruß
    Marco Freie

    Reply

  6. Sometime, surprises after Microsoft CU updates…Anyway after the patch KB5001974 installation everything is working fine…Just lose time for additional SP config wizard…
    Microsoft july gift…. 😀

    Reply

  7. Hi Stefan, Applying the KB5001974 is just a work around or is that the permanent fix ? If its a work around, can we expect this issue to be fixed in the next month patching ?

    Reply

    1. Hi Karthik,
      Microsoft Support always recommends to install the complete CU rather than individual fixes.
      Cheers,
      Stefan

      Reply

  8. Hi, Stefan.

    We have detected that in SharePoint 2019 the Input Search box in the sites (the one with the text “Search this site” – ID=”ctl00_PlaceHolderSearchArea_SmallSearchInputBox1_csr_sbox”) has changed its Input Type from “Text” to “Search”. Is this an intended change? Is there any article explaining the reason behind this?

    Thank you!

    Reply

    1. Hi Pepe,
      to be honest I was not aware of this change befor I read about it here and I’m also not aware of any article discussing this.
      The out of the box UI elements in SharePoint are to documented in technical details and changes here are usually also not discussed.
      If this is important for you I would suggest to open a support ticket with Microsoft to get more insights here.
      Cheers,
      Stefan

      Reply

      1. Thank you. I will review it 🙂

        Reply

        1. Just a note. Probably this is part of a Fix indicated in the patch notes: Fixes an accessibility issue in which screen readers don’t read the drop-down functionality of the Search this site field as combo boxes in classic sites.

          Given this seems to be a feature, we will most probably adapt. Thanks again!

          Reply

Leave a Reply

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