I have received several reports from users that after installing September 2025 CU for SharePoint Server 2016, 2019 or Subscription Edition the SharePoint configuration wizard failed with the following error message:
System.InvalidOperationException was thrown. Additional exception information: An internal error occurred. The program cannot continue to run. The program stopped because of the following: Copy SideBySide files for In Place Upgrade failed.
This will happen if the account being used to execute the configuration wizard is a member of the WSS_WPG or the IIS_IUSRS windows security group.
The WSS_WPG group and the IIS_IUSRS group include all SharePoint managed service accounts including the SharePoint Farm Service Account, SharePoint Windows Service Accounts and SharePoint Application Pool Accounts.
It might be convenient to use the farm service account for administrative purposes but it is unsupported.
Please review this article for details:
Using any account that is a member of the WSS_WPG or the IIS_IUSRS group interactively can lead to issues when executing specific SharePoint PowerShell commands that perform write operations in the _LAYOUTS directory – such as deploying custom solutions or running Copy-SPSideBySideFiles.
Solution
To avoid this problem ensure to run the configurationn wizard using a farm administrator account which is not a member of the WSS_WPG or the IIS_IUSRS group.
Permalink
Hi,
I have found an issue in PowerShell with latest CU
Add-SPServerScaleOutDatabase -ServiceApplication $ssa -DatabaseName SP2022_SA_Search_AnalyticsReportingStore_1″
Add-SPServerScaleOutDatabase : Value cannot be null.
Parameter name: Host Name In Certificate
also, on 2 separate occassions in two different unrelated environments, I had an issue on Windows Server 2025 that SpAdminV4 does not run with the error in event log
Error in event logs
Faulting application name: WSSADMIN.EXE, version: 16.0.19127.20100, time stamp: 0xcb8febdd
Faulting module name: PayloadRestrictions.dll, version: 10.0.26100.1150, time stamp: 0x19def02b
After disabling IAF, EAF and StackPivot in Defender Exploit protection, it started working. Are there any known issues?
Permalink
Hi Robi,
not that I’m aware of.
Best would be to open a ticket with Microsoft Support for this.
Cheers,
Stefan
Permalink
I just deployed new development version of SP SE.
I can confirm that Robi is right and same thing happens to me.
Server 2025 SEP CU
Sharepoint SE SEP CU
Permalink
Hi Gregecslo, please ensure that local system account is not in the WSS_WPG group.
Permalink
It is not, 100%
Permalink
HI Stefan and Gregecslo
I would assume this relates to
also, on 2 separate occassions in two different unrelated environments, I had an issue on Windows Server 2025 that SpAdminV4 does not run with the error in event log
Error in event logs
Faulting application name: WSSADMIN.EXE, version: 16.0.19127.20100, time stamp: 0xcb8febdd
Faulting module name: PayloadRestrictions.dll, version: 10.0.26100.1150, time stamp: 0x19def02b
?
Permalink
Please open a ticket with Microsoft support for this. It seems Windows Defender Realtime protection causes a problem here.
Cheers,
Stefan
Permalink
Yes, my post relates to defender blocking wssadmin service.
Permalink
Hi Robi,
did you open a support case with Microsoft on this topic?
Cheers,
Stefan
Permalink
Hi Stefan,
I have not. There are actually two issues.
First one relates to PowerShell cmdlet, where “Add-SPServerScaleOutDatabase” require you to enter “DatabaseServerCertificateHostName”, even though database encryption is optional
Add-SPServerScaleOutDatabase -ServiceApplication $ssa -DatabaseName SP2022_SA_Search_AnalyticsReportingStore_1″
Add-SPServerScaleOutDatabase : Value cannot be null.
Parameter name: Host Name In Certificate
Second issue relates to WSSAdmin
Faulting application name: WSSADMIN.EXE, version: 16.0.19127.20100, time stamp: 0xcb8febdd
Faulting module name: PayloadRestrictions.dll, version: 10.0.26100.1150, time stamp: 0x19def02b
After disabling IAF, EAF and StackPivot in Defender Exploit protection, it started working
Permalink
Hi Robi,
unfortunately without a support case there is no option for us to follow up on these issues with our product group. So far we have not received a case for these two issues.
Cheers,
Stefan
Permalink
Hi Stefan,
If I open two support tickets, may I then forward you the SR numbers?
BR
Robi
Permalink
Hi Robi,
of course.
I cannot guarantee that I will be able to handle them myself but if I have bandwidth I will take ownership of the cases.
Cheers,
Stefan
Permalink
Hey Stefan hope you’re doing well. i have this warning after the update.
“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.”
I checked the permissions and everything seems correct. Any Idea?
Permalink
Hi Landry,
where do you get this message?
In a Health analyzer rule?
Permalink
Hi Stefan,
Yes !
Permalink
Hi Stefan,
One more I noticed today after installing September CU, is that owstimer.exe account (farm service account) gets access denied for creating a folder in 16/Template/layouts if it is in local admin group, so solution deployment does not work.
Once removed from local admin group, solution deployment works again.
Permalink
I can definitely confirm that.
Another account with the same permissions
but not in any group.
And the CU update runs smoothly.
Logic?
I can’t explain it.
Permalink
Hi Mike,
this is expected. WSS_WPG group has now a deny rule to prevent similar exploits as fixed in July 21st out of band update.
You can find a note about this in the KB article for September CU:
To strengthen security in SharePoint Server, users in the WSS_WPG group are now restricted from running administrative processes, such as the SharePoint Products Configuration Wizard (Psconfig). For more information, see Account permissions and security settings in SharePoint Servers.
Cheers,
Stefan
Permalink
Hi Robi, Stefan,
I’ve tried to use your solution bij removing the farm service account from the local admin group.
But then I’m not able to start the Configuration Wizard.
Removed the farm service account from the WSS_Admin_WPG group. same error, and the account is placed back.
Any other suggestions?
Permalink
Hi Dennis,
the SharePoint Configuration Wizard must not be executed in context of the farm service account but by a farm administrator account.
The farm service account should not and is not required to be a local administrator.
Cheers,
Stefan
Permalink
Hi Dennis,
just to add: WSS_Admin_WPG is not problematic – it has full control on the layouts directory.
Only the WSS_WPG has been retricted.
Cheers,
Stefan
Permalink
Hi Stefan,
Thanks for the help, I have found an account that did the trick, update now error.
Unfortunately some other issue has come up. The central admin is not responding on the web app address. But I think that is an other issue that is not related to this topic.
Thanks again, Dennis
Permalink
We are still receiving this error after removing our SharePoint admin account from the WSS_WPG group. Are there any other ids local or otherwise that should not be in this group?
09/11/2025 08:14:26 1 ERR Failed to complete the SharePoint Products configuration.
An exception of type System.InvalidOperationException was thrown. Additional exception information: An internal error occurred. The program cannot continue to run. The program stopped because of the following: Copy SideBySide files for In Place Upgrade failed.
System.InvalidOperationException: An internal error occurred. The program cannot continue to run. The program stopped because of the following: Copy SideBySide files for In Place Upgrade failed.
at Microsoft.SharePoint.PostSetupConfiguration.Common.ThrowNewInvalidOperationException(String exceptionData)
at Microsoft.SharePoint.PostSetupConfiguration.FinalizeTask.Run()
at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()
Permalink
Hi Dave,
the user executing the SharePoint Configuration Wizard needs to be removed from WSS_WPG for this step to succeed.
But it might be that this is an unrelated problem. My suggestion would be to use process monitor from sysinternals to monitor the write operations. It should tell you why the write operations fail.
If you need assistance to resolve the issue my suggestion is to open a support case with Microsoft.
Cheers,
Stefan
Permalink
Unable to deploy wsp packages in Central Administration after patch.
Solution properties from CA: Access to the path ‘C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\xxx\xxx’ is denied.
Farm service account is in both WSS_Admin_WPG, WSS_WPG and IIS_IUSRS.
Farm service account is running SharePoint timer service.
After patch ….\TEMPLATE\LAYOUTS folder has Deny Write for IIS_IUSRS and WSS_WPG.
Get-acl “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Template\layouts” | fl
BUILTIN\IIS_IUSRS Deny Write
xx\WSS_WPG Deny Write
SharePoint timer service cant create wsp package folders in \TEMPLATE\LAYOUTS as WSS_WPG and IIS_IUSRS has deny write on the folder.
Br,
Bo
Permalink
Hi Bo,
ensure that your SharePoint Farm Service account is not in the local administrators group.
If it is not in the local admin group the SPAdmin service will do the write which has permission.
(The SharePoint Farm Service Account should never be in the local administrators group)
Cheers,
Stefan
Permalink
Thank you
Permalink
Hey Stefan,
I’d like to add a few things to this issue. What I’ve noticed is that while having the farm account in the local admins group (yes, it’s also in WSS_WPG), running the Config Wizard with the farm account gets stuck at the last step (starts hanging at step 10 of 10). Associated behaviors are:
CopySideBySideFiles_xxxx.log shows the endless repetition of this error: “\16\TEMPLATE\LAYOUTS\accessrequestcontrol.debug.js Access is denied. Waiting 30 seconds… Retrying…”.
The “Upgrade Status” page on CA, however, shows the green status “Succeeded”.
Hitting the Cancel or X button on the Config Wizard won’t close the GUI. Had to kill it in Task Manager.
Using the farm admin user account to run the Wizard while having the farm account in the local admins group gives no issue (I understand that the farm account still needs to be removed from the local admins group)
Best,
Permalink
Hi SL
Using the farm service account to run the configuration wizard is unsupported.
Cheers,
Stefan
Permalink
hello Stefan,
customer has same account for both service account and farm account
how can work here ?
Permalink
Hi Anuradha,
sorry – the wording is not clear. What do you mean by service account and farm account?
There is a farm administrator account used to setup SharePoint, run the SharePoint configuration wizard and perform administrative actions in PowerShell and farm service account which is used as application pool account for the central administration website and is the account to run the SharePoint Timer Service and there are additional accounts for other SharePoint windows services and application pools.
Please clarify which account you mean.
Cheers,
Stefan
Permalink
We have been using farm account to install CU. Now we need to make a new account for future use installing CU, What is the permissions the account need for this? (Database, server, central administration)
Permalink
Hi Aarohi,
the account permissions for a Farm Administrator User Account are explained in detail here:
https://learn.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/plan-for-administrative-and-service-accounts
Cheers,
Stefan
Permalink
Interesting, I am running PSConfig command using installer account, not a farm account and no service is running under this account.
After the first failuare, i removed installer account (non-farm account) from WSS_WPG group, it failed with same error.
I then removed it from WSS_ADMIN_WPG group for fun, it failed again.
How ever on the upgrade status page in central admin it is showing as ” Successful” each time. So I am not really sure whats the reall solution for this is but if you go and check the upgrade status on the page its green.
Thank you for replying to each question here, it seems like the only solution is to remove account should not be in the WSS_WPG group but it’s possible there is more than that that need to be changed.
Permalink
Hi Umr,
after updating the group you also have to sign-out and sign-in again with the account as the process token of the current session is created during login. Updating the group without sign/out and sign/in will not resolve the issue as the token does only get recreated with a new login.
About your Successful message in Central Administration: this is related to the database upgrade operations. But It does not cover the file system operations on the individual server. So in your case the database upgrade succeeded but the flile system operation for copy-side-by-side might still have failed.
Cheers,
Stefan
Permalink
Hi Umr,
if it is SharePoint SE with Windows Server 2025 and it fails after step 8, you should check if “SharePoint Administration” is running. If PSConfig was unable to start the service it throws an error, but upgrade shows as complete.
Permalink
Hi Stefan,
I’d like to get a bit of clarification here. I understand that the farm service account must not be used interactively for running psconfig/psconfigui. For creating a new content database though, if the farm admin user account is used in powershell, the user account, not the farm service account, will become the owner of the content db (db properties > General > Database > Owner). Wouldn’t this cause an issue down the road?
Also, according to this article – https://learn.microsoft.com/en-us/sharepoint/administration/add-a-content-database#to-add-a-content-database-to-a-web-application-by-using-powershell – the farm admin user has to verify the “db_owner fixed database role on all databases that are to be updated” prior to creating the new content db. However, the screenshot you posted above, the farm admin user account “must be a member of the db_owner fixed database role for the database OR a member of the sysadmin fixed server role on SQL”. If the user account has the sysadmin fixed server role on SQL, the verification of the db_owner can be ignored, correct? Furthermore, which databases are “to be updated” when creating the new content db?
Thanks,
Permalink
Hi SL,
to answer this in detail this would require some research. Please open a ticket with Microsoft Support to get assistance.
Cheers,
Stefan
Permalink
No worries, Stefan. Thanks for looking into this.
Just bit a history here. I have not used my farm user account for database operations in powershell for many years due to complexities regarding how permissions are intermingled in different areas. I had to temporarily add the farm service account to the local admins group, perform the db operations, and then remove it from the group to ensure the reliable operations. Since the interactivity of the farm service account seems to be strictly enforced now, I’d like to get to the bottom of this 🙂
Permalink
MS did this in 2007 and it caused a mess, they need to let us run the Farms and not try to think for us..
Permalink
Hello Stefan, thank you for this post. We’re migrating to SE, we have an admin account and a service account, but the admin account is in both WSS_WPG and IIS_IUSRS on a single-server install this month. Why?
Permalink
Hi Daniel,
the why is not something I can answer. 🙂
Depends what you used this account for in the past.
I would recommend to check all Application pool accounts in IIS manager and Windows Service accounts for SharePoint Services.
Also check the service accounts configured in “Security” – “Configure Service Accounts” in the SharePoint central administration website.
Cheers,
Stefan