For more details check this article: Trending Issue: SharePoint fixes fail to install after installation of September 2025 CU
The product group released the October 2025 Cumulative Update for SharePoint Server 2019 product family. SharePoint Server 2019 is patched with a language dependent and a language independent fix.
The KB article for October 2025 CU will be available at the following Location in a couple of hours:
- KB 5002796 – October 2025 Update for SharePoint Server 2019 (language independent)
This is also a security update! - KB 5002798 – October 2025 Update for SharePoint Server 2019 (language dependent)
This is also a security update!
The downloads for October 2025 CU are available through the following links:
- Download October 2025 Update for SharePoint Server 2019 (language independent)
This is also a security update! - Download October 2025 Update for SharePoint Server 2019 (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 2019 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.
Please ensure to have a look at the SharePoint Patching Best Practices before applying new fixes.
SharePoint 2019 October 2025 CU Build Number:
Language independent fix: 16.0.10417.20059
Language dependent fix: 16.0.10417.20059
Related Links:
- Technet: Updated Product Servicing Policy for SharePoint Server 2019
- Blog: SharePoint Patching Best Practices
- 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 Zero-Downtime Patching Demystified (applies also to SharePoint Server 2019)
- Blog: SharePoint does not have a build version. Full Stop.
Permalink
Just a note that Microsoft SharePoint updates’ site listed 5002797 as the language patch for 2019 Server instead of 5002798
Permalink
Hi JL,
5002797 is the Office Online Server fix – seems to be a small glitch on this page.
Cheers,
Stefan
Permalink
Hello,
I have just applied the Oct CU patch to a single server Development farm, having removed the NT Authority\system account from the required groups.
After running PSConfig, I now have the following:
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.
Is this expected as a fallout from the Sept 2025 CU
Permalink
Hi Scott,
please double check if the deny ACE for the WSS_WPG and IIS_IUSR group still exists on the LAYOUTS directory.
The upgrade action when running the configuration wizard should have removed it.
If they still exist, remove the deny ACEs manually.
Also confirm whether you used all of the following parameters when executing PSCONFIG:
PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
Cheers,
Stefan
Permalink
Thanks Stefan,
That has worked. Is it always advisable to run the PSConfig script as opposed to just running the Configuration wizard, as I would normally do
Thank you
Scott
Permalink
Hi Scott,
not really. The configuration wizard should do all required operations. The command line version with a options just forces all operations to be reapplied – independent if SharePoint thinks it is necessary or not.
Cheers,
Stefan
Permalink
Thank you Stefan,
I will continue to use the PSConfig going forward.
I can also confirm that carrying out the steps for Sept CU do work
Regards
Scott
Permalink
We noticed that patching keeps adding the Local Service and System accounts back to the WSS_WPG group on the server we are running the Config wizard from. Currently not able to complete the patch, it is stuck on configuration task 9 of 10… “The farm is being upgraded in the timer service process. The task is 10.00% completed.”
Update: We were able to finish patching with running PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install instead of config wizard. We’re currently wondering if only the system account should be removed or the Local Service account as well, since patching kept adding both back.
Permalink
Hi Jenne,
after October CU is installed removing these accounts is no longer necessary as the relevant code was reverted in this fix.
Cheers,
Stefan
Permalink
Hi Stefan,
Thank you for your reply! Just to verify… On my QAS farm, this left me with IIS_IUSRS with no system and local service and a WSS_WPG that does contain both. Is this the current best practice?
Permalink
Hi Stefan,
for the first time with the October update, we are seeing the following error for all content databases in the upgrade error logs:
PSCONFIG (0x1DA0) 0x03F8 SharePoint Foundation Upgrade PDEUpgraderAction_17_0_312_0 (17.0.312.0) 7045 INFO SPContentDatabase Name=***** 00000000-0000-0000-0000-000000000000
PSCONFIG (0x1DA0) 0x03F8 SharePoint Foundation Upgrade PDEUpgraderAction_17_0_312_0 (17.0.312.0) 7045 WARNING Sql Telemetry : Index IX_MSP_PROJECTS_BY_WRES on pjver.MSP_PROJECTS does not exists and cannot be dropped 00000000-0000-0000-0000-000000000000
Is this something we should be concerned about? The upgrade still appears to complete successfully.
Thank you in advance!
Regards, Thoren.
Permalink
Hi Thoren,
this is a project server related database element. Unfortunately Project Server support is provided by a different team.
I and my team only support the core SharePoint product.
My recommendation would be to open a support case with Microsoft to get this investigated.
Cheers,
Stefan
Permalink
Hi Stefan,
Thank you for your response. That’s what I suspected. The only strange thing is that we never consciously used Project Server, and I can’t find a database with the name pjver. Perhaps SharePoint offers an internal function similar to Project that causes the updater to miss the database.
I’ll contact support when I get a chance. Thanks again 🙂
Regards,
Thoren.
Permalink
Hi Thoren,
there is not a separate database. This is in the SharePoint content database. And you don’t have to use it to have it installed. pjver is a schema not a database name – similar to dbo.
The good thing is – if you are not using project server functionality, then the problem will most likely not cause any trouble for you.
Cheers,
Stefan
Permalink
Hi Stefan,
Back in CU September, I managed to patch it successfully with a new farm account that is excluded in both WSS_WPG and IIS_IUSRS group.
But in CU October, i kept on facing the issue:
“Error writing to file: C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\BIN\onetnative.dll. Verify that you have access to that directory.
Before “onetnative.dll”, i hit a few, but managed to overcome by modifying the permission from “DENY” to “ALLOW” on the WRITE permission.
Permalink
Hi Pen,
my suggestion would be to edit the permission on the 16\template\layouts and the 14\template\layouts directory and remove the “Deny” access control entry for WSS_WPG and IIS_IUSRS.
This is the same operation the SharePoint configuration wizard will perform after successfully installing October CU.
If these ACE caused the problem this will avoid them.
Cheers,
Stefan
Permalink
Hi Stefan,
Thanks for the tips. However, I’m still encountering the same error — “Error writing to file”
I’ve already removed the DENY access control entries from the 16\TEMPLATE\LAYOUTS and 14\TEMPLATE\LAYOUTS directories, but this didn’t resolve the issue for the directory Web Server Extensions\16\BIN, which doesn’t have any DENY entries for WSS_WPG or IIS_IUSRS.
I noticed that most people encounter the issue with 16\TEMPLATE\LAYOUTS\accessrequestscontrol.debug.js. In my case, after fixing that, I encountered this error related to 16\BIN\onetnative.dll.
Permalink
Hi Pen,
this is most likely a sharing violation and not an access denied issue.
SharePoint stops all its own services and processes before installing the fix – but it might be that there is still a SharePoint Management Shell open which loaded this dll or it could be that you did not exclude the recommended directories from your virus scanner and the virus scanner blocks access to the file while it is being written.
Ensure to close all running applications which might keep the file in use and also ensure that the correct exclusions are configured for your virus scanner:
https://support.microsoft.com/en-us/office/certain-folders-may-have-to-be-excluded-from-antivirus-scanning-when-you-use-file-level-antivirus-software-in-sharepoint-01cbc532-a24e-4bba-8d67-0b1ed733a3d9
Cheers,
Stefan
Permalink
Hi Stefan.
We went from the July hotfix directly to the October CU. After having patched 2 developer 2019 farms, we see this error occur a lot in the Event Viewer:
After a while Just-In-Time Debugger pops up with an unhandled win32 exception in w3wp.exe, and we get an error in Event Viewer with Event ID 1000, and Source: Application Error:
Faulting application name: w3wp.exe, version: 10.0.17763.1, time stamp: 0xcfdb13d8
Faulting module name: KERNELBASE.dll, version: 10.0.17763.7553, time stamp: 0x296284f5
Exception code: 0xe0434352
Fault offset: 0x0000000000041b39
Faulting process id: 0x2e28
Faulting application start time: 0x01dc4d7e7a8a1bf3
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 3a7a4585-25a4-468f-9d4f-19e34e4c5cc3
Faulting package full name:
Faulting package-relative application ID:
We got this after applying the October cu. Any ideas of how we should proceed with fixing this error?
I have researched a lot, and many things point towards that IIS Worker Process crashes with AMSI.dll, and disabling AMSI did slow down the ratio of error loging, but could not make it disappear.
Please advice 🙂
Permalink
Hi Adeel,
with October CU AMSI is permanently enabled and option to disable has been removed.
The error code 0xe0434352 indicates a problem in a COM component.
More details an be found in a user dump.
My suggestion would be to open a ticket with Microsoft support to identify which component is causing the exception.
It could be AMSI but it can also be something completely different.
Cheers,
Stefan
Permalink
Hi Stefan,
We installed October updates in our SharePoint farms(Test and PRD). It has been little less than a month when the installations were done and we had no issues up until today. However, today we saw ‘SharePoint’ app pool automatically got stopped and we are seeing several errors in Event Viewer like:
A process serving application pool ‘SharePoint’ suffered a fatal communication error with the Windows Process activation service.
and several errors like:
Faulting application name: w3wp.exe, version: 10.0.17763.1, time stamp: 0xcfdb13d8 Faulting module name: KERNELBASE.dll, version: 10.0.17763.7553, time stamp: 0x296284f5 Exception code: 0xc06d007e Fault offset: 0x0000000000041b39 Faulting process id: 0x40a8 Faulting application start time: 0x01dc52efd21de4a1 Faulting application path: c:\windows\system32\inetsrv\w3wp.exe Faulting module path: C:\Windows\System32\KERNELBASE.dll
On looking up more about it, I am seeing recommendations to disable AMSI if AMSI is causing instability:
Set-SPAntivirusSettings -EnableAMSI $false
Would you recommend following this approach. Have you seen this with any of your systems after October 2025 Updates? What is your recommendation on this?
Permalink
Hi Raman,
a couple of things:
– since September 2025 CU AMSI is permanently enabled and the option to disable it has been deactivated as AMSI is an important security feature of SharePoint
– The command you listed “Set-SPAntiVirusSettings” does not exist
– If enabling AMSI is really causing the issue, then the problem is not in SharePoint but in the AV solution and you either need to work with your AV vendor to get a fixed version or need to switch to a different AV solution.
The exception code 0xc06d007e was an unknown exception to me. When searching in my favorite search the internet I see references to problems with AV solutions. So the AMSI feature of the AV solution you installed might indeed cause this problem.
If you need confirmation, my recommendation would be to open a ticket with Microsoft support to get this analyzed.
Cheers,
Stefan