August 2025 CU for SharePoint Server Subscription Edition is available for download

- - 25 Comments

The product group released the August 2025 Cumulative Update for SharePoint Server Subscription Edition.

Monthly SharePoint Server Subscription edition updates are released as a single unified “uber” package containing both the language independent and language dependent fixes. Language independent and language dependent fixes will no longer be released separately. This is similar to the full server packages released for SharePoint 2013.

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

  • KB 5002773 – August 2025 Update for SharePoint Server Subscription Edition
    This is also a security update!

The download for August 2025 CU is available through the following link:

It is irrelevant which language you pick on the drop down in download center. It will always download the same package.

After installing the fix you need to run the SharePoint 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 Server Subscription Edition August 2025 CU Build Number: 16.0.18526.20518
 
Important: To minimize the installation time for SharePoint Server Subscription Edition Fixes, please follow the guidance in the following article: Solving the extended install time for SPSE CUs

 
Related Links:

25 Comments


  1. Hi everyone,

    on our DEV machine, the SPSE update installed correctly, the wizard ran fine, but any SP site incl. Central Admin only returns HTTP 500 Internal Server Error.

    Does anyone else experience this issue?

    Reply

    1. Hi Adrian, the ULS log should provide a detailed error message.
      Cheers,
      Stefan

      Reply

  2. Hi Stefan. Can we get more clarity on what “Improves the People Picker Search experience” mean? we have an environment that queries more than 20 distinct ADs, and People Picker Search is miserably slow (it seems to search the user on each AD in sequence, instead of querying them all in parallel). I wonder if this change could help us with situations like this…
    Thanks!

    Reply

    1. Hi Andre,
      the fix is not related to AD searches.
      Cheers,
      Stefan

      Reply

  3. We had been awaiting the release of this cumulative update for several weeks, as the support engineer had informed us that it would resolve the issue we encountered with the NodeRunner process of the search SA.

    Today, we proceeded with the installation and performed the necessary tests. Unfortunately, our expectations were not met, as the problem with the NodeRunner process remains present in our farm. Even after applying this cumulative update, events 1000 and 1026 continue to occur, just as they did before the installation.

    Please let us know the next steps you would recommend to address this issue.

    Reply

    1. Continue to work with the support engineer and let him know that the issue you are seeing still occurs as it seems to be a different issue from the one that got fixed.

      Reply

  4. Dear Stefan,

    In March there was a bug introduced concerning the Query Logging Timer Job not properly closing SQL Connections until the pool max size of 100 was reached and other Timer Jobs started to fail as well: https://blog.stefan-gossner.com/2025/03/11/march-2025-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-36142

    You said in the blog post of July CU that it was fixed in June CU: https://blog.stefan-gossner.com/2025/07/08/july-2025-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-36101

    We recently installed July CU and saw that it still was not fixed. After installing August CU just today we can confirm that the Query Logging Timer Job still has issues with closing properly the SQL connection and every run opens a new one.

    ULS Log extract:

    ULS Log: 08/14/2025 16:27:31.59 OWSTIMER.EXE (0x1170) 0x1218 SharePoint Server Search Query ajfv9 High QueryLogProcessor: AssignDocIdsToResults error: System.InvalidOperationException: The method ‚EndExecuteReader‘ cannot be called more than once for the same execution. at Microsoft.Data.SqlClient.SqlCommand.VerifyEndExecuteState(Task completionTask, String endMethod, Boolean fullCheckForColumnEncryption) at Microsoft.Data.SqlClient.SqlCommand.InternalEndExecuteReader(IAsyncResult asyncResult, String endMethod, Boolean isInternal) at Microsoft.Data.SqlClient.SqlCommand.EndExecuteReaderInternal(IAsyncResult asyncResult) at Microsoft.Data.SqlClient.SqlCommand.EndExecuteReader(IAsyncResult asyncResult) at Microsoft.Office.Server.Search.Administration.AsyncSqlSession.EndExecuteReader(IAsyncResult ar) at Microsoft.Office.Server.Search.Query.QueryLogProcessor.AssignDocIdsToResults(SearchServiceApplication searchApp) at Microsoft.Office.Server.Search.Query.QueryLogProcessor.ProcessRawQueryLogs() 76b2bba1-c1e2-e071-27f6-9c0247bfb6ac

    Can you please check back with the support team to make sure they can introduce a fix in the next CU? We disabled now the Timer Job on all our farms.

    Kind regards,
    Marc Anselmi

    Reply

    1. Hi Marc,
      it is not that trivial.
      Such a request can only be done in context of a support case of an affected customer. But if the issue is not resolved, the original customer that opened a support case should have reported back as well that the issue is not resolved. I you would like to start an investigation yourself, please open a case with Microsoft support.
      Cheers,
      Stefan

      Reply

    2. Hi Marc
      Glad to hear we are not alone with the Problem. Since installing CU July the Query Logging Timer Job is failing as soon as 100 connections are reached in the SearchLinkStore-DB.
      We just opened an support case with Microsoft Today…. hope they will fix it soon.
      Kind regards
      Andrea

      Reply

      1. Hi Andrea

        Good to hear that there are now support cases open. Can you update us on that matter in case Microsoft plans to integrate a fix in the next CU?

        Kind regards,
        Marc Anselmi

        Reply

    3. Hi Marc,
      I checked the original fix request – from the callstack you provided the issue you are facing is different from the one fixed in June 2025 CU.
      Its the same error message and same symptom – but the EndExecuteReader method is invoked from a different code path.
      That will most likely require a new fix request.
      Cheers,
      Stefan

      Reply

      1. Hi Stefan,

        Yes the callstack issue is different. “EndExecuteReader” is the one I get and “EndExecuteNonQuery” was the one fixed in June. But as you saw, the symptoms are the same.

        I will probably open also a support case next to the other ones to hopefully have it fixed for next CU.

        Kind regards,
        Marc

        Reply

        1. Hi Marc
          I have just received the following information from MS Support:

          I wanted to share a quick update regarding the issue we’ve been tracking. After reviewing the current status and available options, it appears that a resolution is expected with the upcoming September patch. As such, we’ll need to wait for its release to proceed with a fix.

          So hopefully the update solves the problem 🙂

          Cheers
          Andrea

          Reply

          1. Did September CU solve something for you?

            Not for me, at least. Jobs are still failing. MS support case is open for over a month…


  5. Hi Stefan,

    Hope you are Doing Great 🙂

    I’ve been following up with you over the last few releases, and unfortunately, we’re still seeing the same behavior with the following timer jobs.

    We’ve applied the latest August CU to both our lab and test farms, but the three jobs listed below continue to fail with the following error.

    “Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and the max pool size was reached.”

    As a temporary workaround, we’re restarting the Search and SharePoint Timer Services, which helps resolve the issue momentarily.

    We also opened a case with Microsoft last month and shared all relevant logs and details. The support team confirmed that the Product Group is currently investigating.

    Affected Timer Jobs:

    Query Logging
    Prepare Query Suggestions – Timeout expired
    Analytics Timer Job for Search Service Application (Enterprise Search Service)

    Please let us know if there are any updates or additional steps we should consider.

    Thanks,
    Chandu

    Reply

    1. Hi Chandu,

      we are currently on SP2016 with our prod farm but we have the same issue on our new SPSE test farm (version 16.0.18526.20508). Since we want to migrate in September can you, Stefan or someone else please tell me what exactly those mentioned timer jobs are for and how severe is this bug really is?

      Thanks and regards,
      Alex

      Reply

      1. Hi Alex,
        did you receive any help from Microsoft support regardin this issue “Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and the max pool size was reached.”?

        Reply

    2. Hi Chandu, the best option is to open a ticket with Microsoft support.
      Cheers,
      Stefan

      Reply

  6. Just wanted to share that we are also seeing SQL timeouts due to max pool size in several farms after applying KB5002768. Exceptions from timer jobs in event viewer (id 6482 and 6398) and health check jobs that fails. I’ve just opened a support case.

    Reply

  7. Hello there.

    I’m encountering some issues with workflows after the recent security update.

    The SWFM Wizard It’s prompting me about a missing DLL named System.Memory. Is there a way to revert to the previous state? I’m using SharePoint 2016.

    Thanks

    Reply

  8. Hello Stefan,

    We are currently approaching the transition from SharePoint 2016 (SP16) to SharePoint Server Subscription Edition (SPSE), which is causing a high level of tension. Additionally, we are experiencing issues with the latest Cumulative Update (CU).

    For example an issue with timer jobs, such as Query Logging, Prepare Query Suggestions, and the Analytics Timer Job for the Search Service Application are failing. This behavior is indeed linked to a known issue introduced in the August 2025 Cumulative Update (CU) for SPSE, as confirmed by both Microsoft and community sources. 🙂

    But no show Stopper 🙂

    Reply

  9. Dear Stefan,

    One of my customers noticed an issue: when they try to add a filter to a calculated column (result type: Single line of text), and this column is empty (as a result of the formula), the filter shows two possible options for the empty values — one labeled “Empty” and another that is completely blank.

    If they choose the default option (“Empty”), it does not display rows where this value is empty too, but as the result of the calculated column.

    They mentioned that they started noticing this strange behavior around the time the administrator installed the August CU referenced in this post. Could this be caused by the CU, or is this the expected behavior in such cases?

    Thank you in advance,
    Tamás

    Reply

    1. Hi TTomi,
      its always possible that a CU has an undesired side effect – if this is the case here or if this is expected behaviour is hard to say without some research.
      If you need assistance I would suggest to open a ticket with Microsoft Support to get this analyzed in more details.
      Cheers,
      Stefan

      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.