Several customers have reported issues when deploying custom solutions after installing the September 2025 CU for SharePoint Server 2016, 2019, and Subscription Edition.
The following error is returned when deploying the solution:
Cause
The cause of this issue is a combination of new permissions assigned to the WSS_WPG and IIS_IUSRS Windows security groups — intended to enhance SharePoint Server security — and a misconfiguration of the SharePoint Farm Service account.
Starting with September 2025 CU, write access to the _LAYOUTS directory has been removed from the WSS_WPG and IIS_IUSRS groups. One of the accounts in these groups is the SharePoint Farm Service account, which is used by the SharePoint Timer Service.
The issue occurs if the Farm Service account has been added to the local administrators group on the SharePoint server, which is not recommended. For security reasons, the Farm Service account should be a low-privileged account.
Solution
A fix for this issue has been released with October 2025 CU for SharePoint
Remove the SharePoint Farm Service account from the local administrators group on all SharePoint servers and restart the SharePoint Timer Service afterwards.
This ensures that write operations to the _LAYOUTS directory are not performed by the SharePoint Timer Service (OWSTIMER.EXE), but instead by the SharePoint Administration Service (WSSADMIN.EXE), which runs under the Local System account and should have the necessary permissions to add solution files to the _LAYOUTS directory.
Also verify that the local system account (NT AUTHORITY\SYSTEM) is NOT a member of the WSS_WPG or the IIS_IUSRS windows security group. If it is a member of this group follow the Solution steps in this article to resolve this – otherwise the SharePoint Admin Service will run into the same access denied problem:
Trending Issue: SharePoint fixes fail to install after installation of September 2025 CU
In this case remove the local system account (NT AUTHORITY\system) from the WSS_WPG group on all SharePoint servers and restart the SharePoint Administration Service afterwards.
Permalink
I’m already a bit confused. I understand that if the farm administrator user is not a local administrator, they won’t be able to run the updates, but they can run PSCONFIG.
Which user should we or can we use to install the updates and then run PSCONFIG?
Following Microsoft’s recommendations, I did this:
Use a SharePoint farm administrator account that is not a member of the WSS_WPG group
Grant that account permissions on the SharePoint databases
Run the configuration wizard (PSCONFIG) that launches to complete the update with that same account
But now I can only deploy solutions including the -local parameter. Would it be possible without -local so that it deploys to all servers as usual?
Thanks, regards
Permalink
Hi Enrique, it sounds as if the Farm Service Account is in the local admin group. This is not recommended and starting with September 2025 CU no longer supperted.
Cheers,
Stefan
Permalink
Here https://blog.stefan-gossner.com/2025/09/10/trending-issue-copy-sidebyside-files-for-in-place-upgrade-failed-when-running-sharepoint-configuration-wizard/
“Member of the Administrators group on each Sharepoint server in the farm”
Permalink
This is about the farm admin account – not the farm service account.
Permalink
what type of account do you recommend installing the KB updates?
Permalink
The setup account. Means the account used to install SharePoint. This account of course must not be used as a managed service account in SharePoint. Otherwise use another SharePoint administrator account.
Cheers,
Stefan
Permalink
We have the same issues and performed the solution from https://blog.stefan-gossner.com/2025/09/10/trending-issue-copy-sidebyside-files-for-in-place-upgrade-failed-when-running-sharepoint-configuration-wizard/
and https://blog.stefan-gossner.com/2025/09/11/trending-issue-sharepoint-fixes-fail-to-install-after-installation-of-september-2025-cu/ but still no progress on installation.
The Deployment Status remains as: Deploying(scheduled at 9/12/2025 2:59 PM ) with no error message. Anything else we could check?
Permalink
Hi Daniel, this is a different problem. It seems it does not start the timer job. The permission issue would result in a failed deployment.
For this issue I would recommend to check if the owstimer.exe process is running. If yes, please open a ticket with Microsoft to get assistance with this issue.
Cheers,
Stefan
Permalink
Hi Stefan, this service is running, Get-SPSolution returns it on 3 servers (as deployed $false) and on the 4th server it does not return it. Timer service runs on all 4 of them,.
Permalink
This is not a known issue for this CU. Please open a ticket with Microsoft support to get this analyzed.
Cheers,
Stefan
Permalink
Hi Stefan,
thank you for the quick reply. I can confirm that owstimer.exe is running. Also I see lots of other scheduled jobs being processed in the Jobs Status (Monitoring).
Just opened a ticket now for that issue.
Permalink
Hi Stefan,
just had the call with MS support. And the fix was to set the status of timerjobs back to Online (was Offline). Not to confuse with Status in Windows Services (there it was running).
Here is how to enable the jobs:
$farm = Get-SPFarm
$disabledTimers = $farm.TimerService.Instances | where {$_.Status -ne “Online”}
if ($disabledTimers -ne $null) {
foreach ($timer in $disabledTimers) {
Write-Host “Timer service instance on server ” $timer.Server.Name ” is not Online. Current status:” $timer.Status
$timer.Status = [Microsoft.SharePoint.Administration.SPObjectStatus]::Online
$timer.Update()
}
}
else {
Write-Host “All Timer Service Instances in the farm are online! No problems found”
}
Permalink
Hi Daniel,
indeed it is possible to set the timer service instances offline using PowerShell.
Seems this has been done earlier in your farm for the affected servers.
Cheers,
Stefan
Permalink
Hi Stefan,
we never did this knowingly. The support engineer said that the CU installation probably turned it off and was not able to turn them on again after the installation.
So even after server restarts they stayed offline. Tricky 🙂
Permalink
Hi Daniel,
thats an interesting assumption – but our code does not set any TimerServiceInstance to Offline during patch install or while running the configuration wizard.
I just checked our source code.
If this happens again I would suggest to open a support case with Microsoft to get this analyzed.
Cheers,
Stefan
Permalink
Hi Stefan,
For info – I had the same issue as Daniel in my single SP server Test farm. That is, WSP Solution deployments were hanging with “Deploying(scheduled at 9/12/2025 2:59 PM )”. And the Timer Service instance was with the status “Disabled” (Windows Service “SPTimerV4” was running).
We hadn’t disabled the Timer Service instance on our own. And WSP Solution deployments worked with August 2025 CU installed (so the instance must have been running then).
Daniel’s script plus restarting the Windows Service “SPTimerV4” helped.
For reference – quick info about my environment:
– SharePoint 2016
– 1 SP server, 1 SQL server
– Previous update level: August 2025 CU
– Used as Test environment – for testing CUs, code changes and other things before Production
– The environment is configured according to “good practices”. Therefore, the only thing I had to do before the September 2025 CU installation was to reconfigure the Service Accounts as per the article https://blog.stefan-gossner.com/2025/09/11/trending-issue-sharepoint-fixes-fail-to-install-after-installation-of-september-2025-cu/
Permalink
Thanks Martins,
that’s interesting. I will keep an eye on this to see if there is a pattern.
Cheers,
Stefan
Permalink
yep same here , just confirming it’s been happening since at least SP2013 days
sometimes during CU updates, it just sets the admin timer jobs to “offline” and you have to manually set them back to “Online”
it’s very concerning if you’re not aware of it, because it looks like a whole lot of things break… but if you have the scripts ready it’s an easy fix
this same issue also happened to me on two farms after installing Sept 2025 CU for SP2016
there’s even an article about this common issue:
https://learn.microsoft.com/en-us/troubleshoot/sharepoint/administration/administrative-timer-jobs-not-run-after-upgrad
“An unexpected event during the upgrade prevented the timer service instance object from being brought back online.”
Permalink
Hi Stefan,
with this security patch, code stopped working.
We have a solution for provisioning site collections after a request has been approved in a list and it stopped working after patching SP SE with Spetember CU.
I tried it also in my dev environment, and it is the same thing. This was already in production and running for quite some time now.
The code is inside event receiver, ItemUpdated event:
SPSecurity.RunWithElevatedPrivileges(delegate ()
{
using (SPSite eSite = new SPSite(properties.WebUrl))
{
using (SPWeb eWeb = eSite.OpenWeb())
{
try
{
SPWebApplication webApp = eSite.WebApplication;
SPSite newSite = webApp.Sites.Add(new SPSiteCollectionAddParameters()
{
SiteUrl = item[Constants.FieldSiteUrl]?.ToString(),
Title = item[Constants.FieldNaslovSkupine]?.ToString(),
Description = “”,
LCID = 1060,
WebTemplate = “STS#3”,
OwnerLogin = SPHelper.GetUsernameFromClaim( new SPFieldUserValue(properties.Web, item[Constants.FieldLastnikMesta]?.ToString()).User.LoginName),
CreateFromSiteMaster = false
});
….
And it now throws errors
System.UnauthorizedAccessException: 0x80070005owssvr.dll: (unresolved symbol, module offset=000000000004F778)
at 0x00007FFD559CF778 owssvr.dll: (unresolved symbol, module offset=00000000001C7DFF)
at 0x00007FFD55B47DFF Microsoft.SharePoint.Library.ni.dll: (unresolved symbol, module offset=00000000000B2384)
at 0x00007FFD5A0C2384
at Microsoft.SharePoint.SPGlobal.HandleUnauthorizedAccessException(UnauthorizedAccessException ex, Boolean allowCompleteRequest)
at Microsoft.SharePoint.Library.SPRequest.CreateSite(Guid gApplicationId, String bstrUrl, Int32 lZone, Guid gSiteId, Guid gDatabaseId, Guid gSiteSubscriptionId, String bstrDatabaseServer, String bstrDatabaseName, String bstrDatabaseUsername, String bstrDatabasePassword, String bstrTitle, String bstrDescription, UInt32 nLCID, String bstrOwnerLogin, String bstrOwnerUserKey, String bstrOwnerName, String bstrOwnerEmail, String bstrSecondaryContactLogin, String bstrSecondaryContactUserKey, String bstrSecondaryContactName, String bstrSecondaryContactEmail, Boolean bADAccountMode, Boolean bHostHeaderIsSiteName, Int32 iDatabaseVersionMajor, Int32 iDatabaseVersionMinor, Int32 iDatabaseVersionBuild, Int32 iDatabaseVersionRevision, Int32 iSprocsVersionMajor, Int32 iSprocsVersionMinor, Int32 iSprocsVersionBuild, Int32 iSprocsVersionRevision, String bstrSiteSchemaVersion, Boolean bCreateFromMaster, String bstrDenyPermMaskGroupId, Guid gDesignPackageId, Guid DepartmentId)
at Microsoft.SharePoint.Administration.SPSiteCollection.AddInternal(SPSiteCollectionAddParameters param)
at Microsoft.SharePoint.Administration.SPSiteCollection.Add(SPSiteCollectionAddParameters param)
Permalink
Hi Robin,
please open a ticket with SharePoint developer support at Microsoft to check custom code issues.
Cheers,
Stefan
Permalink
Hi Stefan,
I did some troubleshooting and apparently SP code now checks if user creating a site collection is in Farm administrators group, which is not ideal.
BR
Robi
Permalink
Hello, after following your procedure, I deployed a solution to my environment, which is composed of 2 Front-End Web Servers (IIS) and 2 Application Servers (Central Administration + Service Applications). The solution was successfully deployed on both Front-End Web Servers (IIS) and on one of the Application Servers, but on the other one it fails with an “Access Denied” error to the LAYOUTS folder.
I have already checked all permissions, group memberships, restarted services, fully rebooted the server, removed and re-deployed the solution, etc., but the problem still persists since the update, and now only on this one server.
BR
Permalink
Hi Felipe,
on the affected server perform the following checks:
1) the local WSS_WPG windows security group on the affected server does NOT contains NT AUTHORITY\system
2) the local Administrators windows security group on the affected server does NOT include the SharePoint farm service account
3) restart SPTimerV4
4) restart SPAdminV4
5) redeploy the solution
After following these steps it should work.
Cheers,
Stefan
Permalink
thanks, sorry, I have in local administrators All domain users
Permalink
Hi Felipe,
this is not recommended from a security perspective.
From a SharePoint perspective the SharePoint farm service account needs to be removed from the local administrators group.
Cheers,
Stefan
Permalink
Hello. Thank you so much for your help. I had the same issue (all of them actually) after i applied this patch. Solution deployment was fixed after these steps, but somehow the farm account reappeared in the Administrators group on all servers and solution deployment fails again. We have a High Availability SPP 2019 onprem farm with 2FE + 1CA, 2APP, 2*Search. Could it be that the farm account reappeared once the psconfig was rerun (i though would be a good idea to do that after i fixed the permissions group WSS_WPG -it had the system account, IIS_IURSS – it had the adm account and Administrators – it had the farm account)?
Permalink
Hi Andreea,
SharePoint does not add the farm account to the local administrators group. Sounds like something specific to your environment.
E.g. a desired state configuration which reverted your change.
Cheers,
Stefan
Permalink
Hello Stefan,
Thank you very much for your explanation. I will check the security logs. There is still one aspect I don’t fully understand.
In my environment, the farm service account is also used as the identity for several application pools and timer service, including the SecurityTokenServiceApplicationPool. After I removed the farm account from the local Administrators group, this app pool immediately stopped due to insufficient permissions, which caused ADFS authentication to fail (Server error in / application)
When I re-added the farm account to the Administrators group, the STS app pool started successfully again.
It seems that the account is missing some local permissions required to run STS without administrative privileges. Is there a Microsoft-recommended way to grant these permissions so the farm account can remain outside the Administrators group without breaking STS or authentication?
Best regards,
Andreea
Permalink
Hi Andreea,
the farm service account should not be used for any other purpose.
Application Pools should have a different account assigned than the farm service account.
Please create a separate managed account for the application pools and update the assignment.
Cheers,
Stefan
Permalink
Now I am totally lost. According to this article https://learn.microsoft.com/en-us/sharepoint/install/account-permissions-and-security-settings-in-sharepoint-server-2016 (and 2019) the farm service account should be the identifier.
Permalink
Hi and thank you for your Blog.
We have a SP2016 with Microsoft Workflow Manager.
So we have to upgrade and also change local Accounts to Service Accounts.
Is it possible to take a Snapshot from the whole Farm (including SQL) and if something goes wrong just revert back? Or are there implications for VM-Snapshots?
Thank you
Andi
Permalink
Hi Andi,
cold snapshots of the environment (all SharePoint Servers plus WFM servers plus SQL server or servers – if different for WFM and SharePoint) would be supported.
Cold means that all machines have to be shutdown before the snapshots are taken.
Snapshots of running servers are not supported as there is no way to guarantee a consistent state between all machines.
Cheers,
Stefan
Permalink
There is another one got broke: If you create e-discovery, create a case, create a search and export, after search gets done, perform “Download Results”, it will download an exe file, with “publisher unknown”. The application error out with
ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of https://blah.com/sites/ediscovery/_layouts/15/ddm/1033/DiscoveryDownloadManager.application?url=https://blah.com/sites/ediscovery/case1&listId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx&itemId=2&download=True resulted in exception.
Following failure messages were detected:
+ File, ADODB.dll, has a different computed hash than specified in manifest.
Permalink
Hi Alex,
please open a ticket for this. This needs some investigation.
Cheers,
Stefan
Permalink
SharePoint 2016 :
Since the spfarm account is not anymore in the Local Admin group, i cannot get rid of the alerts “This Distributed Cache host may cause cache reliability problems” and “More Cache hosts are running in this deployment than are registered with SharePoint” on one of the servers, even after removing the cache cluster on the affected server (it doesn’t appear after running Get-CacheHost on the another cache server).
I tried also Stop-CacheCluster and Start-CacheCluster, Stop-SPDistributedCacheServiceInstance and Remove-SPDistributedCacheServiceInstance. But nothing help against these alerts, even when the cache does not exist anymore or is online, up and App Fabrice service running (now disabled and stopped but without any help against the alerts)
Also the web servers don’t seem to redirect the FBA Auth anymore to “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\IDENTITYMODEL\LOGIN\default.aspx”
Permalink
Hi Fabrice,
if you need assistance to troubleshoot these issues I would recommend to open two support cases with Microsoft to get them analyzed.
Cheers,
Stefan
Permalink
My problem is also gone thanks to https://learn.microsoft.com/en-us/troubleshoot/sharepoint/administration/administrative-timer-jobs-not-run-after-upgrad