After installation of September 2025 CU for SharePoint Server 2016, 2019 and Subscription Edition customers might notice a Health Analyzer entry similar to this:
Cause
September 2025 CU for SharePoint added a deny ACL to the _LAYOUTS directory of SharePoint in the 16 and 14 hive to prevent write access to this folder from accounts in this group.
The existing health rule which verifies the permissions for this group is not aware of this design change in SharePoint and incorrectly reports elevated permissions.
Workaround
Ignore the Health rule result.
Permalink
Additional information: so far we did not receive a support case for this issue – only reports about this message in blog comments and forums.
If this is a concern for your company please open a ticket with Microsoft support to ensure that we can work with our product group to update for this health rule.
Permalink
Subject: Critical issues after installing September 2025 CU for SharePoint Server
Body:
Dear Stefan,
After installing the September 2025 Cumulative Update for SharePoint Server (in our case SharePoint Subscription Edition / SharePoint 2019 with SQL Server 2019 and SQL Server 2022 ), we are facing severe issues:
-Central Administration returns HTTP 500 errors,
-multiple farm jobs (e.g. AnalyticsJobDefinition) fail with timeouts or access denied,
-solution deployments (.wsp) fail with access denied to system directories (e.g. \Template\Layouts).
Unfortunately, the provided guidance and workarounds (such as moving farm accounts between groups) do not resolve the problem in our production farm.
We urgently request:
– Escalation of this case to the SharePoint product group,
– Release of a corrected CU or hotfix addressing this regression,
– Official guidance ensuring that we can maintain security compliance while keeping SharePoint fully operational.
This issue has a critical impact on our production environment and business operations.
Thank you in advance for your prompt assistance.
Wiktor Krzysztoforski
Permalink
Hi Wiktor,
please open a ticket with Microsoft. That is the only way that we can investigate the different issues and escalate them to the product group.
Thanks for your understanding,
Stefan
Permalink
Hi Wiktor,
about the last topic (solution deployment) please check this article:
https://blog.stefan-gossner.com/2025/09/12/trending-issue-solution-deployment-fails-after-installing-september-2025-cu/
Chances are high that the SharePoint Farm Service account is a member of the local administrators group which causes this problem.
After removing the account from local administrator restart the SharePoint timer service. There is a good chance that other timerjob related issues are caused by the same issue.
Cheers,
Stefan
Permalink
Tested,
same issue
Permalink
Hi Wiktor,
did you restart the timer service after removing the farm account from local administrator group?
The permissions are assigned on process start. Changes to the admin group afterwards require a restart of the service to get active.
Cheers,
Stefan
Permalink
Yes,
still same issue.
Permalink
Hi Wiktor,
ok – in this case I would suggest to open a ticket with Microsoft Support to get this investigated in more details.
Cheers,
Stefan
Permalink
Like Wiktor, we also are seeing HTTP ERROR 500, when trying to access Central Administration website and SharePoint Team/MySites, after deploying the SPSE Sep 2025 CU, despite having performed all the recommended instructions (remove farm service from local admins, remove local service and system accounts from WSS_WPG, restart timer service, ensure that all services running a local system were changed to farm account) prior to the CU deployment. After deploying the CU and running config, we also noticed that local system was put back into the WSS_WPG group, which we then removed again.
Wiktor, Did you create a MS case? Do you have any updates on resolving the 500 error?
Permalink
Looks like the Central Admin website 500 error might be related a new entry in the Central Admin’s web.config, within the System.webServer | modules section, for name=SPRequestFilterModule. The line was not in the previous (pre-CU config) version of the web.config. If commented out, the CA site starts working again. Are there troubleshooting steps available to determine what might have gone wrong during the deployment of the new module?
Permalink
Hi Stefan,
The issue occurred on SP SE + SQL 2019 (it does not appear on SP SE + SQL 2022).
Fred Heath is correct — after commenting out the line in web.config
Central Administration started working again.
Stefan, my kind request for clarification:
Should this be treated only as a temporary workaround?
Will Microsoft release a new patch to properly address this issue?
As far as I know, SPRequestModule is one of the key SharePoint modules – it is responsible for creating the SPRequest context (database connections and request handling).
Disabling it may cause Central Admin or Web Applications to stop functioning.
Therefore, this step should only be used as a temporary workaround (e.g., to verify whether the problem is caused by SPRequest), but it should not be considered a permanent solution.
I raised ticket to Microsoft Supprot.
thx,
Wiktor
Permalink
Hi Wiktor,
please confirm if you commented out the SPRequestModule or the SPRequestFilterModule
Commenting out SPRequestModule will lead to sever memory leaks as this module is responsible to reclaim memory allocated with SPRequest objects.
SPRequestFilterModule is responsible for AMSI and disabling this by removing the line from the web.config will leave your server open to a variety of attack vectors and should be avoided.
If SPRequestFilterModule was causing the issue, please check this article:
https://blog.stefan-gossner.com/2023/10/17/trending-issue-module-sprequestfiltermodule-could-not-be-found-after-september-october-2023-cu/
If this does not resolve the issue I would recommend to open a ticket with your AV solution provide to get analyzed why the AMSI integration with the AV solution causes 500 server errors.
Cheers,
Stefan
Permalink
Hi Fred, this “new entry” is the AMSI integration with SharePoint. It was introduced 2-3 years ago as a new security feature.
It seems you decided to disable AMSI at this time.
If you get a 500 server error here – this should to be investigated in detail!
Please check this article to see if you are running into this issue:
https://blog.stefan-gossner.com/2023/10/17/trending-issue-module-sprequestfiltermodule-could-not-be-found-after-september-october-2023-cu/
If not, you should open a ticket with your AV solution provider to investigate why the AMSI integration with this AV solution causes 500 server errors.
Cheers,
Stefan
Permalink
Wiktor,
The issue was occurring for us with SPSE + SQL 2022.
The issue was not for the SPRequestModule but instead for the SPRequestFilterModule.
Stefan,
Thanks for the article link from 2023. That fixed our issue!
We did have AMSI enabled before the CU install/config, but are using a 3rd party A/V product and not MS Defender.
Permalink
Follow-up post, On a different mid-size SharePoint SE farm. I followed the recommendations of removing the farm account from the local Administrators group, and removed the Local System and Local Service from the WSS_WPG group, then applied the Sept. patch. This farm did not have any issues with Central Admin throwing a 500 error after applying the September update. I will test deploying Nintex solutions once all servers have been updated.
Permalink
Hi Stefan,
I am able to successfully deploy Nintex solutions after the changes above were made and the Sept. SharePoint SE CU was installed. Note, I had to manually remove Local System from the WSS_WPG group after running the PSConfig wizard. Running the PSConfig wizard puts the Local System back into the WSS_WPG group for each server.
Permalink
Hi Stephen,
thanks for your confirmation!
About the problem with local system account: I cannot repro that Local System is added back after removing it from all managed service accounts in Central Administration.
If psconfig adds the account back even if you removed Local System from all managed Service Accounts I would suggest to open a support case with Microsoft to get this investigated.
Cheers,
Stefan
Permalink
One of the SPSE WFE server we got this error when psConfig executed after 25H2 update for SharePoint Server Subscription Edition. all other no failures.
Unable to create a Service Connection Point in the current Active Directory domain. Verify that the SharePoint container exists in the current domain and that you have rights to write to it. Microsoft.SharePoint.SPException: The object LDAP://CN=Microsoft SharePoint Products,CN=System,DC=,DC=plc,DC=,DC=com doesn’t exist in the directory. at Microsoft.SharePoint.Administration.SPServiceConnectionPoint.Ensure(String serviceBindingInformation) at Microsoft.SharePoint.PostSetupConfiguration.UpgradeTask.Run() Failed to secure the SharePoint resources. An exception of type System.UnauthorizedAccessException was thrown. Additional exception information: Attempted to perform an unauthorized operation. System.UnauthorizedAccessException: Attempted to perform an unauthorized operation. at System.Security.AccessControl.Win32.SetSecurityInfo(ResourceType type, String name, SafeHandle handle, SecurityInfos securityInformation, SecurityIdentifier owner, SecurityIdentifier group, GenericAcl sacl, GenericAcl dacl) at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, SafeHandle handle, AccessControlSections includeSections, Object exceptionContext) at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, AccessControlSections includeSections, Object exceptionContext) at System.Security.AccessControl.FileSystemSecurity.Persist(String fullPath) at Microsoft.SharePoint.Administration.SPResourceAccess.SecureResources(Boolean isSingleBox, EventHandler1 progressUpdateEvent) at Microsoft.SharePoint.PostSetupConfiguration.SecurityTask.Run() at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()
Permalink
Hi Sudesh,
this is not specific to this CU.
That error occurs with all Sharepoint Versions and patches if the creation of the Service Connection Point in AD fails.
Cheers,
Stefan