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 2016 product family.
This CU also includes Feature Pack 1 which was released with December 2016 CU and Feature Pack 2 which was released with September 2017 CU.
The KB articles for August 2026 CU should be available at the following locations in a couple of hours:
- KB 5002905 – August 2026 Update for SharePoint Server 2016 (language independent)
This is also a security update! - KB 5002906 – August 2026 Update for SharePoint Server 2016 (language dependent)
This is also a security update!
The downloads for August 2026 CU are available through the following links:
- Download August 2026 Update for SharePoint Server 2016 (language independent)
This is also a security update! - Download August 2026 Update for SharePoint Server 2016 (language dependent)
This is also a security update!
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 2016 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.
SharePoint 2016 August 2026 CU Build Numbers:
Language independent fix: 16.0.5565.1001
Language dependent fix: 16.0.5565.1001
To understand the different version numbers please have a look at my article which explains the different SharePoint build numbers.
Please ensure to have a look at the SharePoint Patching Best Practices before applying new fixes.
Related Links:
- Technet: Updated Product Servicing Policy for SharePoint Server 2016
- Blog: SharePoint Patching Best Practices
- Blog: Common Question: What is the difference between a PU, a CU and a COD?
- Blog: SharePoint Patching demystified
- Blog: Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE
- Technet: Update Center for Microsoft Office, Office Servers, and Related Products
- Blog: SharePoint Server 2016 Patch Build Numbers Powershell Module
- Blog: SharePoint Server 2016 Zero-Downtime Patching Demystified
- Blog: SharePoint does not have a build version. Full Stop.
Permalink
Whoa…patches after EOL? I’m surprised!
Permalink
Sometimes a wish comes true. 🙂
Permalink
Hi Stefan. Thank you for all you do for the SP admins community. If we have skipped July patches due to the known issue with OOS integration, will this CU introduce the same problem?
Thank you.
Permalink
No it will not. But ensure to evaluate it carefully as this CU again includes a large number of security fixes and unexpected side effects might occur with this CU as well.
Cheers,
Stefan
Permalink
Hi Stefan, if I had installed the Jul 2026 CU, will the Aug 2026 CU resolved the OOS issue ?
Permalink
Yes
Permalink
Hi Stefan!
Is August 2026 CU for SP2016
KB5002905 (language independent) & KB5002906 – (language dependent)
Or
KB5002905 (language independent) & KB2910992 – (language dependent) which is only 5.4 MB
Love your site — thanks for all you do for the SP community!
Permalink
The fix has meanwhile been corrected
Permalink
Hi Stefan,
why do we still get security fixes for SharePoint 2016/2019?
Regards
Walter
Permalink
To protect customers who are still running unsupported farms.
Permalink
Do you know how long we will get Updates?
Regards
Walter
Permalink
You should not expect further CUs.
Permalink
is the Language dependent full pack is available to download for August CU?
Permalink
Yes it is now available
Permalink
Hi Stefan
Any idea when the language dependant update will be available to download? Clicking through the links brings me to https://www.microsoft.com/en-us/download/details.aspx?id=108759 which doesn’t appear to be the right kb. Installing it says that no products will be affected.
Permalink
It is available meanwhile
Permalink
The KB page mention notifications of features that will be disabled in September and November updates … Are these mentions really concerns SP2019, wich is out of support ?!?
As there is the same text on the SPSE page, it looks like a copy/paste which may not applies to SP2019. Can someone on the MS team check that KB content ?
Permalink
I asked to get these KB comments reviewed
Permalink
For language independent patch you wrote currently unavailable due to technical problems
Problem is in description of language dependent patch https://support.microsoft.com/en-us/servicing/office/hotfix/august/5002906
published incorrect link https://www.microsoft.com other part of link is published as plain text.
Correct link is: https://www.microsoft.com/en-us/download/details.aspx?id=108759
Permalink
Hi Volodymyr, the correct link has meanwhile been update. The one you mentioned is not the correct one.
Permalink
Hi Stefan, does the August 2026 patch fix CVE-2026-55040, a critical (CVSS 9.1) unauthenticated JWT authentication-bypass in on-prem Microsoft SharePoint Server (Subscription Edition / 2019 / 2016 → SharePoint Online/M365 not affected).
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2026-55040
or do you reckon we still need to run August patch including CVE-2026-55040.
Thanks
Permalink
This issue was already fixed with July 2026 CU.
Permalink
Hi folks.
Do you have any info yet on whether this update fixes the search service application issue (Unable to retrieve topology component health states. This may be because the admin component is not up and running)?
The suggested fix (to set SPSearchHostController service startup type to Automatic with delayed start and restart farm) doesn’t work for us.
Because of this we are stuck at April 2026 CU level. Since May 2026 CU I did not find any valid and functional mitigation and missing subsequent CUs is exposing us to threats.
With best wishes to all of you.
Many thanks also to Stefan, who’s blog is invaluable.
Permalink
No this is not addressed
Permalink
And is there a plan to fix it or issue some guidance? I also have this problem on a SharePoint 2019 farm.
Since March 2021, I have successfully updated them regularly almost every month and these updates has never broken our search “layer”. On the other hand, I understand that hardening security is important,
We do not have a contract that would allow us to escalate a case with MS support.
Stefan, I do not blame you, but a series of latest various problems (failing workflows, lost OOS integration) seems to me like a conscious pressure on customers to upgrade their environments to a higher version of the product (SP Online or SP SE).
Permalink
The introduced problems are a side effect of a need to push a very large number of security fixes into several consecutive CUs in a very short time. Testing all possible side effects of 30+ fixes in a single CU against a large number of possible configurations is challenging.
And the introduced problems affected SPSE as well – not just SP2016 and DP2019
Permalink
OK, I can understand that. But I want to move forward with issue, so I’m looking further and according to the log entries it looks like a communication/network problem.
Failed to connect to system manager. SystemManagerLocations: net.tcp:////AdminComponent1/Management
System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp:////AdminComponent1/Management/NodeController.
TCP error code 10061: No connection could be made because the target machine actively refused it <!!! ip-address-of-hostname !!!>:808
However, my farm is a single server and looking for possible solutions leads me to the area of checking various network properties of the farm (disableloopbackcheck, WCF endpoints, IIS enabled protocols, SMS bindings).
Has anyone already followed these steps and managed to succeed?
Permalink
In my experience, there is usually no need to change the Startup type of the service.
I have seen this resolved by simply restarting the SharePoint Search Host Controller (SPSearchHostController) service. After restarting the service, wait a few minutes and check whether the Search Service Application can connect successfully.
If the issue persists, restart the SPSearchHostController service again and allow several minutes for the search components to re-establish communication. In many cases, the Search Service Application eventually reconnects and the topology health information becomes available without any additional configuration changes.
It’s also worth noting that I currently have an active Microsoft Support case open regarding this issue (on SPSE), so Microsoft is aware of the behavior and is investigating it. Based on my experience so far, repeated restarts of the SPSearchHostController service have been sufficient to restore connectivity without modifying any configuration.
Permalink
I have tested the August CU and a sandbox solution gives an exception that not occurs with the July CU. The exception that occors is: Unable to load assembly group. The user assembly group provider returned a file name containing invalid file name characters.
Do you know if this is a known issue? Thank you.
Permalink
Not yet.
Permalink
Hi Stefan, when I deactivate the solution within the site collection and try to activate it again I get the same error message. It seems that something goes wrong with the parsing/processing of the assembly definitions within the manifest.xml that is part of the wsp file. Within the manifest.xml there is a location defined: Assemblies\Microsoft.Crm.SharePoint.CrmGridFeature.dll. Maybe the \ is detected as invalid character.
Permalink
Please open a ticket with Microsoft to this analyzed.
Permalink
Do these patches fix the OOS and workflow issues introduced last month?
Permalink
Yes
Permalink
Hi Stefan, below July known issue fixed in August patch???
Customers in multi-front-end SharePoint farms with Trusted Provider or Forms authentication may face repeated authentication prompts or multiple sign-ins. This should not impact customers who have configured farms with Windows authentication. As a mitigation, configuring sticky sessions on the reverse proxy will address the majority of scenarios. Microsoft is working on a fix in the subsequent product update. While disabling “SessionCookieTransformProtectionEnabled” may appear to work around the issue, Microsoft does not recommend it. This setting safeguards authentication and turning it off can expose the farm to security vulnerabilities.
Permalink
Yes it was fixed
Permalink
Hi Steffen,
Hi Steffen,
We understand that the July 2026 SharePoint CU has a known issue impacting Office document functionality. Could you please confirm whether it is supported to install the August 2026 CU directly on our current SharePoint build without first installing the July 2026 CU?
Additionally, please advise if there are any risks, prerequisites, or recommended steps associated with this upgrade path.
Permalink
Hi Habib,
of course this is supported. SharePoint fixes are cumulative. You can always just install the most recent CU.
Cheers,
Stefan
Permalink
Hi Stefan,
We had issues with 2010 styled workflows and Office Online after installing July 2026 patch. In order to resolve 2020 styled workflows, we did changes in the web config files.
After installing August 2026 patch, will these issues be resolved automatically?
Please confirm.
Permalink
Hi Aditya,
the need to add entries to the web.config to allow specific types is by design and expected. It gives administrators full control over the allowed types. So that will NOT change with August CU as it is a new security feature.
But the OOS issue is resolved with August CU.
Cheers,
Stefan