The product group released the October 2023 Cumulative Update for SharePoint Server Subscription Edition.
Monthly SharePoint Server Subscription edition updates are released as a single unified “uber” package containing both the language independent and language dependent fixes. Language independent and language dependent fixes will no longer be released separately. This is similar to the full server packages released for SharePoint 2013.
The KB article for October 2023 CU will be available at the following location in a couple of hours:
- KB 5002506 – October 2023 Update for SharePoint Server Subscription Edition
The download for October 2023 CU is available through the following link:
It is irrelevant which language you pick on the drop down in download center. It will always download the same package.
After installing the fix you need to run the SharePoint 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 Server Subscription Edition October 2023 CU Build Number: 16.0.16731.20252
Related Links:
- Technet: 23H2 Feature Update for SharePoint Server Subscription Edition
- Technet: Updated Product Servicing Policy for SharePoint Server Subscription Edition
- Technet: FAQs for SharePoint Server Subscription Edition product servicing policy
- 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
Hello Stefan,
I hope you are doing okay!
We have noticed the same as the below commentator, that patching SPSE takes a very long time compared to older farms (SP2019, SP2016). Do you have any guidance on this topic?
https://blog.stefan-gossner.com/2023/05/10/may-2023-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-19943
Thanks
Permalink
This issue occurs since June or July on some of our servers too and every patchday the affected servers are changing.
If you look into the event viewer on an affected machine you will see that the “RestartManager” (Source) is spamming entries with event id “10010”. The Description says something like this “Application ‘C:\Windows\System32\inetsrv\w3wp.exe’ cannot be restarted – Application SID does not match Conductor SID..”
Sometimes i think the patches are installing faster and the occurrence of this issue is minimized when installing the update via CMD/PowerShell (as Administrator), but sometimes there is no difference and the issue occurs nonetheless.
We also have not found an solution for this issue.
Permalink
Hey Daniel,
I have exactly the same events spamming. I will keep looking…
Thanks
Permalink
Hello, i was able to speed up process by killing the pid in Task Manager > Details. Refreshing the Eventviewer to see all the pid, killing them one after another. it seems the installerar can process faster.
Permalink
Hi David,
thank you very much for the information.
I wonder when the affected process is getting killed, does it really install the patch successfully?
I’m asking that because we are having an phenomenon after installing the september uber package. We had the long update issue on one server and after some hours an error occured, that the update could not be installed. We restarted the machine, tried again and it was installing then.
Now after some weeks(!) in our Central Administration one server says “Upgrade required”, but i don’t remember if it was the one who took so long and failed first (should have written that down).
We ran the Config Wizard after each update and there were no errors thrown when using it. Also under CA –> Upgrade Status there is no error to be seen, but in “Manage servers in this farm” an upgrade is required on one server.
Could you please check if you have the same issue in your environment? I can’t reproduce this here.
Permalink
Hello,
Well I obviously wouldnt recommend killing the pid to install patch other than for “fun” right now until we hear back from Microsoft how to best fix this issue.
I did not see any issues with the one farm I used the above method for. It was however a small test farm without complex services.
Regards
Permalink
Hi David,
from what I can see we did not receive a support case for this topic.
In order to start investigating this we need a support case from a customer reporting this problem.
Cheers,
Stefan
Permalink
Hi Stefan,
I’ve opened a support case on tuesday because we see that the installation of cu for spse needs signifantly more time than cu installation for SPS2016/SPS2019 (TrackingID#2310100050004393).
My colleague Christoph mentioned this already in your Blog.
We see the same entries described by David.
The installation of cu september 2023 (for example) took ~ 60 minutes. The sts-x-none_MSPLOG.LOG is about 158.755 KB (1725130 rows).
In the log file the time for assembly installation took 51 minutes. During this time the log is full of entries like “Assembly Install: Failing with hr=80070005 at RemoveDirectoryAndChildren” (50327).
In this time slot (the last 23 minutes of assembly installation) we see mor than 80000 entries of “Application ‘C:\Windows\System32\inetsrv\w3wp.exe’ (pid 9564) cannot be restarted – Application SID does not match Conductor SID..” in eventlog.
Permalink
Thanks for the info Sybille – I will take ownership of the case and investigate it.
Permalink
Hi Stefan
We’re facing the issue with long running installers (and thousands of events “(pid xxxx) cannot be restarted…” in the eventlog on all of our SPSE farms since mid of this year.
Is there any outcome from that case Sybille opened, which could be shared with us? What would be the best approach to avoid such long running operations? Disabling Search Services, etc. prior to the installation as we used to do it in good old SP2013 times? https://blog.russmax.com/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install/
Many thanks for your feedback
Andy
Permalink
Hi Andy,
we did not finish the analysis in a previous case as the problem did no longer occur.
I would recommend to open a support ticket to get this analyzed.
Cheers,
Stefan
Permalink
i Stefan, hi Andy,
I wanted to wait for our experiences with cu december 2023 before reopening my case.
We’ve just applied cu november 2023 (kb5002527) in our production environments.
I’ve just compared our installation times for cu october 2023 and cu november 2023 for one production environment (4 servers).
I’ve additional informations from another brand new spse farm (14 servers).
What I see is that the installation time depends on sharepoint server roles.
We see the longest installation times on all servers with search index-role.
example:
server 1 (with index role – 10 cores 32 gb ram):
cu october 2023: 20 minutes
cu november 2023: 82 minutes
server 2 (with index role – 10 cores 32 ram):
cu october 2023: 20 minutes
cu november 2023: 80 minutes
server 3 (only index role – 16 cores – 64 gb ram):
cu november 2023: 75 minutes
@Stefan: shall i already reopen the case now? what do you recommend?
Regards
Sybille
Permalink
Hi Sybille, hi Stefan
Many thanks for your answers and sharing these valuable insights.
I also suspect, that search plays a role in these long running operations:
– When I installed Nov23 CU on our single server (custom role, 16cpu, 64gb), I cancelled the installer after 45min and rebooted the server (apart from the restart manager warnings, nothing happened)
– I then restarted the installer and got asked to stop the search service during the installation. – After confirming that, the binaries installation was finished after 15min
-> I will next time try to stop/pause the search before applying the CU and see what happens.
Regards
Andy
Permalink
Hi Stefan,
I have installed a SharePoint Subscription Edition, with September CU.
All was OK except “Site contents” that doesn’t work.
But software updates for SharePoint Server Subscription Edition are packaged starting with the March 2023 public update, which introduces SharePoint Server Subscription Edition Version 23H1. Starting with this software update, Microsoft will no longer release separate core and language pack software updates each month. Instead, Microsoft will release a single software update each month that will contain all of the changes that previously would have been included in those two separate updates.
So I don’t think my problem comes from that… Do you have any idea please ?
Permalink
Hi David,
I haven’t seen this issue and would recommend to open a ticket with Microsoft support to get this investigated.
The packaging change does not introduce any issues – it only guarantees that language dependent and language independent fixes are installed together to guarantee a consistent patch level.
Cheers,
Stefan
Permalink
Hi Stefan,
After make the wizard in Powershell mode rather than GUI, it seems to work.
Thank you for your response.
Can you hide my last name from the last comment please ?
Permalink
Sure – done.
Permalink
Short update for the community concerning our support case because of long installation times of CU for SPSE:
The support case ist closed again.
While installing CU october 2023 we’ve experienced for the first time installation times of the package similar to those for SPS2019 (without changing anything on our part).
Permalink
Anyone else facing a search indexing issue with legacy MS Office file formats after October CU deployment?
I have following errors in search indexing logs for 2 different environments and this applies for .doc, .xls and.ppt
The docfile has been corrupted. ( Error parsing document ssic://15554. Error initializing IFilter for extension ‘.ppt’ (Error code is 0x80030109). The function encountered an unknown error.; ; SearchID = 34F436D1-B680-4ED7-AB43-1507D8B0B030 )
In Subscription Edition environments having September CU or older patch level indexing legacy formats is working correctly.
Permalink
Yes, I am having the same issue with Search Indexing of the legacy office formats!
Permalink
I am also experiencing the Search indexing issues since this CU was installed and after a full crawl was done.
Permalink
Hi Stefan,
We’re also having this issue with September 2023 CU.
Will there be a fix in a following CU or do we have to install the ifiltter packs for Office mentioned by Janet here under ?
Best.
Patrick
Permalink
Hi Patrick,
the issue is currently under investigation by the product group.
We do not have further info as of now.
If this is an important issue for you I would recommend to open a support ticket with Microsoft to raise awareness.
Cheers,
Stefan
Permalink
We were able to reinstall the Ifilter packs for Office and that resolved the issue with search.
Permalink
Hi Janet
Did you use the old FilterPack64bit.exe from Microsoft download published 12/20/2019 ?
Using Windows 2022 and SharePoint SE?
Where are all worldwide consultant send invoices to Microsoft to troubleshoot and bring solutions to customers 🙂
Permalink
Hi Johnny,
Yes, just checked with my SP admin. That is what he installed. It did not resolve the PowerPoint files, but the .doc files cleared up.
Good Luck :)!
Permalink
Hello, following the installation of the CU in the following days we noticed that the MSS_UsageAndHealth database had increased by 150 GB, it’s a bit surprising and I can’t find a cause for this, do you have the same case?