The issue described in this article currently affects only customers which executed the SharePoint Configuration Wizard after installing the language independent fix from September 2025 CU and the installation of the language dependent fix.
Starting with October 2025 CU for SharePoint Server (all versions) most customers might be affected by this problem – so addressing the issue now will prevent problems in the future.
To enhance security September 2025 CU for SharePoint restricts the Windows WSS_WPG windows security group and the IIS_IUSRS windows security group from writing into the SharePoint _LAYOUTS directory (c:\program files\common files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS).
The WSS_WPG and IIS_IUSRS groups include all SharePoint service accounts including the
- SharePoint Farm Service Account
- SharePoint Windows Service Accounts
- SharePoint Application Pool Accounts
A problem will occur if the local system account of Windows (NT Authority\system) is included in the WSS_WPG windows security group or the IIS_IUSRS windows security group :
The reasons is that the Windows MSI installer runs as local system and will no longer be allowed to add the updated files into the _LAYOUTS directory. This is generic will occur when trying to install a SharePoint fix if the local system account is a member of the WSS_WPG or the IIS_IUSRS group:
When checking the MSI installer log (in %localappdata\temp) – either sts-x-none_MSPLOG.LOG or the most recent wssmui-…_MSPLOG.LOG – you will find an error similar to this (the subdirectory and file name below LAYOUTS may vary):
Error 1310. Error writing to file: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\ppsma\1033\DesignerInstall\en\Microsoft.PerformancePoint.Scorecards.DesignerPlugins.dll.deploy. System error 0. Verify that you have access to that directory.
Cause
The local system account is the default account for the following SharePoint Windows Services if not changed by a SharePoint Administrator:
- Claims to Windows Token Service
- Document Conversion Launcher Service
Solution
A fix for this issue has been released with October 2025 CU for SharePoint
- Open “Configure Service Accounts” in the “Security” Section of the SharePoint Central Administration Website and verify the credentials used for all configured Services and Application Pools.
Replace all local machine accounts (e.g. Local System and Local Service) with domain accounts.
The required permissions account used for the Claims to Windows Token Service can be found in this document:
(SharePoint Server Subscription Edition no longer uses this service – so no specific permissions are required for this SharePoint Version.) - After the service accounts have been corrected, remove the system and local service account from the WSS_WPG and IIS_IUSRS groups
After these steps have been performed it will be possible again to install SharePoint fixes.
We recently identified that even with the steps above the SharePoint configuration wizard adds the local system and local service account to the WSS_WPG group when reprovisioning the SharePoint windows services. This issue is currently being investigated.
Permalink
Hi.
I had issues with side by side copy but not with patch install.
Both sts and wssloc installed just fine and I have local system, network service and local service (yes 3 accounts) in wss_wpg group.
Where it ststes that we should remove this users from that group, I can’t find it on offical docu.
Also why install went trough?
I understand why psconfig was unsuccesfull, but I don’t why install went ok.
Regards,Greg
Permalink
Hi Gregecslo,
for September 2025 CU you will most likely not have a problem as the code change comes with September CU and is activated with running the config wizard.
But October CU will then hit you.
Cheers,
Stefan
Permalink
Greg What issue did you have with SideBySide copy? What was your fix?
Permalink
Hi
My sharepoint farm admin account was used as sp service account and therefor added to wss_wpg group.
I created new farm admin and ran psconfig with that one.
Permalink
OK but will there be “official” statement somwhere that those accounts need to be removed from WSS_WPG group?
I know that it is logical and all but still it would be cool to have that in official documentation.
Permalink
First PG needs to be made aware that there are systems where these accounts are in this group.
I have a couple of farms where this is not the case as I did not configure anything with local system.
Cheers,
Stefan
Permalink
Hey Stefan,
Investigating our SharePoint 2019 farms in Test and Prod, the Claims To Windows Token Service and Document Conversions Launcher Service are not started on any of our servers but in Manage Service Accounts, they are still set to Local System. Do we still need to change them to a domain service account even if they are not being used?
Thank you.
Permalink
Hi Daniel,
yes exactly. It does not matter if they are started or not. The fact that the account is configured in managed service accounts causes the account to be added to WSS_WPG and will continue to be added to this group going forward if the account is not removed in manage service accounts.
Cheers,
Stefan
Permalink
I have removed both local users from the WSS_WPG group.
However, I still have the following issue in the Health Analyzer (SP16 on-premises) :
Title Verify various user groups don’t have elevated permissions.
Severity 2 – Warning
Category Security
Explanation
If a Security Principals associated with SharePoint Server processes has elevated privileges, it may put the SharePoint Server at risk. WSS_WPG has unexpected permission(s) on folder C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS. See “https://learn.microsoft.com/sharepoint/install/account-permissions-and-security-settings-in-sharepoint-server-2016” for guidance on the correct settings.
Do I need to change the permissions on these folders too ?
Permalink
Hi Olivier,
it might be that the health rule does not take the new security settings into consideration.
Please check if the two folders have this settings for WSS_WPG:
Write – Deny
(some additional permissions for Read, Execute and List are ok)
This is the expected setting.
Permalink
Hi Olivier,
I was just able to reproduce this – indeed the health rules seem to miss the new security settings.
Please open a ticket with Microsoft Support and send me the SR number using the “contact the blog author” option at the top right of this page.
Thanks,
Stefan
Permalink
Hi Olivier and Stefan,
I have the same symptom (the health rule doesn’t seem to take into account the security change).
Did you open a ticket with Microsoft and if so, did they resolve the case ?
Thanks,
Jeff Ruel
Permalink
Hi Jeff,
I received a support case for another customer and was able to identify the root cause.
To resolve the issue a programmatic change in our product will be required which I have requested.
Cheers,
Stefan
Permalink
Thanks for the quick reply Stefan.
Will this programmatic change be included in the next CU (october) ?
Thanks,
Jeff
Permalink
Most likely not. There are other high priority issues that need to be addressed first.
For now just ignore this health rule report.
Cheers,
Stefan
Permalink
Thanks for the heads up on this one. My WSS_WPG also has a local NT AUTHORITY\NETWORK SERVICE account. Is that going to be a problem?
Permalink
Hi Marlene,
I’m not aware of a service or process running under this account which would require write access to the _LAYOUTS directory – so I don’t think that this will cause a problem.
But in general all managed accounts in a SharePoint Farm should be domain accounts. I would still ckeck all the sevice accounts as described in the “Solution” section of this article and update them to use a domain account if required:
https://blog.stefan-gossner.com/2025/09/11/trending-issue-sharepoint-fixes-fail-to-install-after-installation-of-september-2025-cu/
Cheers,
Stefan
Permalink
Nintex installer writes files to the _Layouts directory, After applying the September 2025 CU. Nintex solutions fail to deploy to subfolders under the LAYOUTS directory.
The creation of this directory failed: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Template\LAYOUTS\Nintex\Images.
There are 4 Nintex farm solutions that fail to deploy properly due to this new security update.
Permalink
Hi Stephen,
did you ensure that the SharePoint Farm Service Account is NOT in the local administrators group of the server?
Cheers,
Stefan
Permalink
Yes, I removed the farm account from the local admin group on all 8 servers, Ran the Nintex installer again and still had write errors to the LAYOUTS directory, Ran PSConfig wizard again on the Central Admin server because Central Admin is throwing an HTTP Error 500 after removing the farm account from local admin.
I added the farm service account back to to the Local Admin, Restart IIS and Central Admin is working again. With the farm account removed from the Local Admin on all but the Central Admin server, I tried deploying one of the Nintex solutions again „nintexcommon.wsp“ and it failed with the same issue on all Web Front ends and Application servers:
Error: The creation of this directory failed: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Template\LAYOUTS\Nintex\Images
I am running a mid-size SE farm with duplicate roles Web, Cache, App, and Search, total of 8 servers.
Permalink
Farm account should never be local admin.
And of course farm account must not be used interactively. .
Local system must not be in WSS_WPG.
The error indicates, that the account writing to the directory is in WSS_WPG.
If you need assistance to get this analyzed, please open a ticket with Microsoft support.
Cheers,
Stefan
Permalink
Hello Stefan,
I was able to successfully deploy the solutions using the Nintex Installer. After removing the farm account from the Local Admin and WSS_WPG groups on all farm servers, only then did it deploy successfully.
By default the farm account runs the Central Admin service, when a solution is deployed in CA for a mid-size SharePoint SE farm, it is the Central Admin service account that deploys the files out to the farm servers. However, I was unable to access Central Admin when the farm account was removed from the local admin group on the CA server. To deploy Nintex successfully, I removed the farm account from all Local Administrator and WSS_WPG groups in the farm. Ran the installer, After it successfully completed I had to add the farm account back to the local administrator group on the CA server for the CA site to work properly.
Permalink
Hi Stephen,
the farm account is not required to be a local administrator.
I assume you are using this account for other purposes as well which causes the problem.
The domain account used as SharePoint Farm account should not be used for other purposes in SharePoint.
If you need assistance to resolve this issue I would suggest to open a ticket with Microsoft to get this analyzed.
Cheers,
Stefan
Permalink
The local system account is the default account for the following SharePoint Windows Services if not changed by a SharePoint Administrator:
Claims to Windows Token Service
Document Conversion Launcher Service
-> I have “Document Conversion Load Balancer Service” running under the Local service, does it need to be changed too?
The required permissions account used for the Claims to Windows Token Service can be found in this document:
Claims to Windows Token Service (C2WTS)
(SharePoint Server Subscription Edition no longer uses this service – so no specific permissions are required for this SharePoint Version.)
-> I have SPSE, where can I find permission requirements for “Document Conversion Launcher Service” and “Document Conversion Load Balancer Service” ?
Permalink
Alex, I’m not the expert, but I’ll make an observation: all three services you mentioned (Claims to Windows Token Service, Document Conversion Launcher Service, Document Conversion Load Balancer Service) are Disabled on all of my SharePoint Farms (2019 and Subscription Edition). I’m willing to be these services are Disabled on your farm(s) as well. It may seem non-intuitive, but what Stefan is saying is that it does not matter that the services are not in use, we still are required to change the account that would run them, so to speak. So even though those services almost certainly defaulted to Local System on install and never got changed due to non-use (for most of us), we still have to go and change the running account in Central Admin in order to prevent Local System from being auto-added back into the WSS_WPG group, which will cause issues with future SharePoint patching.
All of this to say, you probably don’t need to worry about the permission requirements etc for the services in question, because in all likelihood you’re not using them anyway.
Permalink
I just finished install the CUs and had none of the issues. SHould I wait to update the Service Accounts or do it now?
Permalink
Hi Kevin,
I would suggest to do it now to ensure that the next CU installs without any problems.
Cheers,
Stefan
Permalink
But when I install updates and remove those 2 accounts from WSS_WPG group after running psconfig they are added back?
Why?
Permalink
Because they are in manged service accounts in SharePoint. You need to remove them there first.
Check the solution section here on how to address this:
https://blog.stefan-gossner.com/2025/09/11/trending-issue-sharepoint-fixes-fail-to-install-after-installation-of-september-2025-cu/
Cheers,
Stefan
Permalink
Hi.
No, I have 2 service accounts used and none of those are local accounts. 100%
Single dev server with all roles.
Permalink
Hi Stefan,
I have the same situation as Gregecslo – the accounts “NT AUTHORITY\LOCAL SERVICE” and “NT AUTHORITY\SYSTEM” got re-added to the group “WSS_WPG” at some stage during or after installation and configuration of September 2026 CU (even though they are not configured as Service Accounts in Central Admin for any services).
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/
Below are the main steps I took as part of the September 2025 CU installation – perhaps they are helpful in troubleshooting:
1) Executed steps described in the article https://blog.stefan-gossner.com/2025/09/11/trending-issue-sharepoint-fixes-fail-to-install-after-installation-of-september-2025-cu/
There were three services which had local accounts specified in Central Admin. They all were disabled and not used. As I understand, SharePoint by default creates them with local accounts. Therefore, I had this situation “by default”.
– Windows Service – Claims to Windows Token Service : NT AUTHORITY\SYSTEM
– Windows Service – Document Conversions Launcher Service : NT AUTHORITY\SYSTEM
– Windows Service – Document Conversions Load Balancer Service : NT AUTHORITY\LOCAL SERVICE
So, I changed accounts in Central Admin for all three services to domain accounts. No other services were using local accounts.
Eventually I removed the accounts “NT AUTHORITY\LOCAL SERVICE” and “NT AUTHORITY\SYSTEM” from the group “WSS_WPG”.
OBSERVATION: Changing the Service Accounts in Central Admin didn’t change the accounts for the actual underlying Windows Services – the Windows Services still had the local accounts specified in “Log on as”. I left it as it was as no additional instructions were mentioned about it in the article.
2) Installed September 2025 CU and run Config for it. It succeeded without issues.
3) Performed verification steps – major and important standard and custom functionality for our solution (Site provisioning, Timer Jobs, Event Receivers, JavaScript, checking Windows Logs, SharePoint Logs etc.). No issues were observed.
Well, the only issue was the new Health report – described here: https://blog.stefan-gossner.com/2025/09/11/trending-issue-sharepoint-health-rule-complains-about-elevated-permissions-for-wss_wpg-group/. But it is a “known issue” post September 2025 CU.
4) I didn’t check immediately if the accounts “NT AUTHORITY\LOCAL SERVICE” and “NT AUTHORITY\SYSTEM” got re-added to the group “WSS_WPG”. But I noticed Gregecslo’s comment and decided to check. And yes – the accounts are re-added.
Service Accounts for the services in Central Admin are still the newly specified domain accounts (not local accounts). However, to repeat – the underlying Windows Services (which are disabled) still display the local accounts in “Log on as”. Perhaps it is somehow related to the issue.
I could remove the local accounts again from the group “WSS_WPG” – so next CU installations succeed. But it would not be an optimal solution if next CU installations would again add them back.
I hope the above information helps to narrow down the potential problem.
Let me know if I can assist in any way.
Permalink
Hi Martins,
thanks a lot for this valuable input!
I have sent you an email to the email address you provided when writing this response with possible next steps.
Cheers,
Stefan
Permalink
I tried changing the accounts for c2wts and Document Launcher / Document Load Balancer services. They are disabled in Servics.msc console
It has created three one-time timer jobs, which aren’t executing
Windows Service “DCLoadBalancer16” Credential Deployment One-time
Windows Service “c2wts” Credential Deployment One-time
Windows Service “DCLauncher16” Credential Deployment One-time
I’ve had this same behaviour in two different farms.
Also another one-time job isn’t running either
Product Version Job on SERVERNAME One-time
Seems there may be some issues with One-time timer jobs?
The farm service account is not local admin on my servers.
Permalink
I am also experiencing the same issue.
I changed all the accounts in “Configure service accounts” section so that none are running under Local System / Local Service. I removed System and Local Service accounts from WSS_WPG and IIS_IUSRS groups. I rebooted the server after that.
I also manually changed the “Disabled” services for c2wts, and the two Document Conversion services to specify a domain account in the Log On As section. The services are still disabled.
After running psconfig wizard, the System account is back in the WSS_WPG group.
Would you please share the “next possible steps” for troubleshooting and resolving this?
Permalink
Maybe I am missing something here but Microsoft official documentation states the following:
The SharePoint Farm service account, which is also referred to as the database access account, is used as the application pool identity for Central Administration and as the process account for the SharePoint Timer Service. The server farm account has the following requirement:
It must have domain user account permissions.
Extra permissions are automatically granted to the SharePoint Farm Service account on SharePoint servers that are joined to a server farm.
After you run Setup, machine-level permissions include:
Membership in the WSS_ADMIN_WPG Windows security group for the SharePoint Timer Service.
Membership in WSS_RESTRICTED_WPG for the Central Administration and Timer service application pools.
Membership in WSS_WPG for the Central Administration application pool. <– this is contradicting the September CU and makes it impossible to deploy a solution to a mini-role farm.
https://learn.microsoft.com/en-us/sharepoint/install/account-permissions-and-security-settings-in-sharepoint-server-2016#sharepoint-farm-administrator-account Are you testing in a single server or mini-role farm? I have seen SharePoint act completely different when it comes to single server and mini-role farms.
Permalink
Hi Stephen,
this is not correct. SharePoint Timer Service does ONLY try to deploy the solutions if the farm account is in the local administrators group – which is not recommended.
If the farm account is NOT in the local administrator group the timer service delegates the work to the SharePoint Administration Service (WSSADMIN.EXE) which runs as local system and can deploy the solutions – at least if the local system account is not a member of the WSS_WPG or IIS_IUSRS group. If the local system account is a member of either of these group, that has to be fixed – otherwise a lot of things will break. E.g. installing future SharePoint hotfixes will fail if the local system account is in one of these two groups.
Cheers,
Stefan
Permalink
To prepare for the Sept CU install on our SharePoint SE non-prod next week, in Configure services accounts, I updated the service accounts on the three services showing Local Service and Local System. None of the three services are enabled. I now see three One-time Credential Deployment Timer jobs that are not clearing out. Do I need to be concerned with the Timer Jobs in this state? I assume this is because the services are not enabled.
TIA
Permalink
Hi Tom,
this did not happen on my machine.
Did you ensure that the farm service account is NOT in the local administrator group?
Cheers,
Stefan
Permalink
Hi Tom, try running through the steps here to get your Timer service back and operational.
I find that it sometimes breaks like this. Couple of references below:
https://learn.microsoft.com/en-us/troubleshoot/sharepoint/administration/administrative-timer-jobs-not-run-after-upgrad
https://joshroark.com/sharepoint-all-about-one-time-timer-jobs/
Permalink
I managed to fix the issue with One-Time scheduled running jobs for setting credentials
You have to start the services for the One-Time jobs to clear.
$appServer1 = Get-SPServer “servername”
Get-SPServiceInstance -Server $appServer1 | where {$.TypeName -eq “Document Conversions Launcher Service”} | Start-SPServiceInstance
Get-SPServiceInstance -Server $appServer1 | where {$.TypeName -eq “Document Conversions Load Balancer Service”} | Start-SPServiceInstance
Get-SPServiceInstance -Server $appServer1 | where {$_.TypeName -eq “Claims to Windows Token Service”} | Start-SPServiceInstance
Note, to start the Document Conversion services, you need the below registry key added before they will start.
https://support.microsoft.com/en-us/topic/some-document-conversion-services-in-sharepoint-server-are-not-secure-when-they-run-in-a-particular-environment-c39cd633-1e6a-18b1-9f2f-d0e7073a26bd
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\16.0\LauncherSettings]
“AcknowledgedRunningOnAppServer”=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\16.0\LoadBalancerSettings]
“AcknowledgedRunningOnAppServer”=dword:00000001
Permalink
Hi Vladimir. What version of SharePoint are you using, 2016, 2019, SPSE? I do not see these timer jobs with 2016. Thehe disabled services still have the local account names.
NOTE: When pasting from this article, the quote marks need to be re-entered.
NOTE: Also, There’s a couple typos in the commands $.TypeName should be $_TypeName.
Permalink
I got the script working with the corrections above and the services now are using the correct account.
Thanks for your post! :0)
Permalink
We’re on SP2016. Apologies about the copy paste issues with the script, not sure how the syntax got messed up in the post. Glad you managed to get it fixed up and working!
Permalink
What about the “Sharepoint Web Services Root” apppool that runs under “LocalService”? Does it need to be changed to use domain user account as identity?
Permalink
No this is not required. The SharePoint Web Services Root application pool is disabled and not configured with a managed service account.
Permalink
During the weekend I set up new SP SE farm on single server.
What I found out:
Here: http://si-sp-dev-se:15394/_admin/FarmCredentialManagement.aspx
I clicked trough every single account and NO LocalSystem or LocalService accounts are used, only managed accounts I registered.
Sharepoint services use this accounts:
https://imgur.com/BLGFNje
If I run psconfig GUI system account is NOT added to group
If I run this:
PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
Both LOCAL service AND SYSTEM are added to WSS_WPG group but NOT to IIS_IUSRS
https://imgur.com/a/gpEbZJt
So next month patch install will fail because SYSTEM is in WSS_WPG?
What am I doing wrong?
Regards,Grega
Permalink
Hi Gregecslo,
thanks for these details!
So there seems to be a difference between executing the GUI and the command line version of the configuration wizard.
I will try to reproduce this on my machine.
As a workaround to install the fixes, please manually remove the local system account from the WSS_WPG group before installing the updates.
Cheers,
Stefan
Permalink
Hello everyone, an update has been added to this article (see yellow box at the end).
We have identified why the config wizard still adds local system to the WSS_WPG windows security group even after fixing the account as discussed in the solution section of this blog post
Permalink
Do you have any info when a fixed update might be made available? I am rather hesitant to install this one on our productive farm.
Installation was planned for this weekend here, but I think I can postpone that?
Permalink
Hi Daniel,
the current plan is to temporarily roll back the restricted permissions for the WSS_WPG group in October CU.
Cheers,
Stefan
Permalink
Moin Stefan,
Thanks for the reply. So I assume all the restrictions/changes that are being put in place now with the September CU, will not have an effect with the upcoming October update(s)?
I know we will have to deal with them but it’s not a thing that HAS to be done in the next ~4wks?
THX,
Daniel
Permalink
Hi Daniel,
no this is not correct. Only the restricted permissions for the WSS_WPG group and the IIS_IUSRS group will be TEMPORARILY reverted as they caused unforeseen side effects.
The other restrictions will still be active.
Cheers,
Stefan
Permalink
I seem to not be able to reply to your last post.
With over a dozen articles/”Trending issues” for the September updates alone, it might be a good idea to a have a single post outlining the changes of this CU, what will be rolled back in October and what will stay after installing this months’ updates.
Either this is ‘slightly’ confusing or it is just me being confused 😀 One way or the other, thanks A LOT for all the updates you provide for us here!!
Permalink
Hi Daniel,
you are stealing my thoughts! 🙂
I started drafting such an article already but did not have time to finish it due to other work.
Will try to get it online later today.
Cheers,
Stefan
Permalink
I agree with Daniel. The issues impacting the September CU has caused me to reconsider applying the patch. It would be helpful to have a post (or update the yellow box above) with a summary of the issues and workarounds. I have attempted to keep up with the workarounds and will be patching non-prod today. Fingers crossed. Production is scheduled for Saturday.
Thanks for your active participation. The past couple of months (since the zero day) have been nuts.
Tom C
Permalink
Stefan,
I’m not sure if you hear this often, but I would like to thank you for all that you are doing to keep us informed and helping us work through these issues month after month. This blog you have created is a God send to us SharePoint architects and admins, its allowed us to look like champions to our employers, end users and colleagues.
Again, Thank you
Permalink
I wholeheartedly agree. Thank you from the bottom of my heart’s service application! (which also is running as SYSTEM 😉 )
Permalink
Thanks, both of you! — I really appreciate your feedback! 🙂
Permalink
My experience after installing the Sept patch in my pre-prod environment and running the Configuration Wizard is that both LOCAL SERVICE and SYSTEM are added back to WSS_WPG group.
Permalink
Correct. This issue is now being investigated.
More exactly, not the fact that they are added (we know exactly why) – but to see if this is really necessary.
Cheers,
Stefan
Permalink
Hi Stefan!
After making these changes on 9/16 & making sure the disabled services have a service account then updating SP on 9/18 and re-configuring then 9/22 re-removed the local accounts it re-added, I’m getting some excessive database login errors on the database server.
The IPs in the error messages for the past 2 days have been 2 of the 4 Search servers, both at 12:36 AM (9/23 12:25:54) AM & 1:16 AM. The errors started on Friday 9/19 12:34 AM. Earlier, 2 of the WFE servers had the same issue. I’m was getting 217 then 165 now 172 errors per day.
SQL Server Alert 20 – Fatal Error in Current Process DESCRIPTION: SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT (IP address)]
The DB SQL server log at the same time has: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [Client (same IP)]
On the Search server, there’s an windows log application error event 5586, “Unknown SQL Exception 18452 occurred. (same info as the SQL server)
Log Name: Application
Source: SharePoint Foundation
Event: 5586
User: NT Authority\IUSR
The crawl jobs seem to be running OK, every 2 minutes with the normal number of errors 25 or 27.
Any ideas on how I can figure out what process is getting these errors? I assume it’s related to this change.
Thanks so much!!
Permalink
Hi Marlene,
in general, ensure to verify all account permissions according to this document:
https://learn.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/plan-for-administrative-and-service-accounts
If this does not resolve the issue my suggestion would be to open a ticket with Microsoft Support to get this investigated.
Cheers,
Stefan
Permalink
Thanks. In IIS on all the servers (APP, Search, WFEs), the “SharePoint Web Services Root” application pool is using LocalService as the Identity. I’m assuming this should be a domain service account. Since I removed the LocalService from the IIS_IUSERS groups, I assume that is what caused the problem and that I need to fix all the servers to use the farm account then stop/start the application pools. Please confirm. Thanks so much!!
Permalink
Hi Marlene,
SharePoint Web Services Root application pool is always disabled and not used at all. The only reason it exists is that IIS does not allow to create a website without adding an application pool to it.
The root of the SharePoint Web Services website does not contain any logic. it is only a container for child web application which each have a different application pool.
So there is no need to modify the identity SharePoint Web Services Root application pool.
Cheers,
Stefan
Permalink
I followed the steps in the beginning of the thread and after removing local and system from on WSS_WPG and IIS_IUSRS Group. After the patches the local and system are added back to WSS_WPG which is mentioned is a known issue.
I want to make sure that it is by design should not be added back to IIS_IUSRS Group
My problem is is per MS support, I should make the services that were local system back to local system but I am not seeing it in the drop down. Was the permanent solution to have local system run any services or have a domain user run the services
Permalink
Hi EJohnson,
this is perfectly expected and your configuration is ok!
Currently there is no need to change service account associations as the relevant change that required it was reverted with October 2025 CU.
Cheers,
Stefan
Permalink
If i never installed the september patch but installed the october patch, will i have this problem if i install the november patch?
Permalink
No you will not experience this issue if you never installed September CU.