The product group released the October 2024 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 2024 CU will be available at the following Location in a couple of hours:
- KB 5002647 – October 2024 Update for SharePoint Server 2019 (language independent)
This is also a security update! - There was no language dependent fix released this month.
The most recent language dependent fix is KB 5002597 from August 2024 CU.
If this is not yet installed on your Farm, you need to install it together with the language independent fix.
The downloads for October 2024 CU are available through the following links:
- Download October 2024 Update for SharePoint Server 2019 (language independent)
This is also a security update! - There was no language dependent fix released this month.
The most recent language dependent fix is KB 5002597 from August 2024 CU.
If this is not yet installed on your Farm, you need to install it together with the language independent fix.
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 2024 CU Build Number:
Language independent fix: 16.0.10415.20001
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
Hi Stefan,
Does this security update address the following issues reported in previous KBs?
Trending Issue: Certain PowerShell operations failing after installing the July 2024 CU for SharePoint 2016/2019.
Trending Issue: Problems with Workflows after applying the September 2024 CU for SharePoint 2016/2019/SE.
Could you please confirm if this patch is stable enough for production deployment?
BR,
Prashant Kumar
Permalink
Hi Prashant,
the issue with PowerShell operations has been addressed already in September PU.
The second issue is not something that needs to be addressed. It is the expected outcome of a security fix and the blog post and the referenced KB article outlines how to address it.
About “stable enough for a production deployment”: each environment is different and it is technically impossible to identify the impact of code changes included in a CU on all possible topologies and configurations. Our recommendation is to evaluate each CU in a test environment against all business critical functions before applying in production.
Cheers,
Stefan
Permalink
Hi Stefan,
Thank you for your prompt response.
Regarding the second issue, we applied the fix in the web.config file but still encountered workflow problems in the lower environment. We then reverted the September patch and installed the August security updates, which resolved the workflow issue but led to a site creation issue using PowerShell.
We are wondering if the October update will fix the workflow issue without requiring manual intervention in the web.config file.
Do we still need to make changes to the web.config file for the workflow fix if we apply the October security update in the lower environment?
BR,
Prashant Kumar
Permalink
Hi Prashant,
there is currently no plan to change the implementation. Means all future fixes will expose the same issues. My recommendation: if the web.config change did not help, open a ticket with Microsoft Support to get this investigated in more detail.
Cheers,
Stefan
Permalink
Hi Stefan,
“The second issue is not something that needs to be addressed. It is the expected outcome of a security fix and the blog post and the referenced KB article outlines how to address it.”
Is this not a contradiction?
Permalink
Hi John,
I see why this confuses you.
What I mean is that there will not be a fix from Microsoft side to revert this change.
Customers have to evaluate their workflows and implement the workaround themselves.
Cheers,
Stefan
Permalink
Hi Stefan.
First of all, I would like to say thank for your great work and keeping up to date your blog and answering to the user community.
Now, I do have a question related to last month CU and in particular with Workflow issues. After I installed the CU I notified that any workflow in my farm could not start (either scheduled or manual) and then I applied the workaround you mentioned.
<System.Workflow.ComponentModel.WorkflowCompiler>
After that, workflow started to run again.
However, I do have a problem with triggered workflows (when an item is changed/created). Sometimes (a lot of times) they fail to start. This behavior started after SEP 24 CU and I don’t have a fix yet.
Do I have to whitelist something else or? I’ve checked ULS logs, I don’t find anything related to authorized types or any other error type related to workflows.
When I manually start the workflow, it runs normally with no errors. The problem occurs only when workflows are triggered by a change of state of an item from the list.
Permalink
Hi Catalin,
I have not seen this issue and would recommend to open a support case with Microsoft to get this investigated.
If the workflow starts when manually starting it is not about missing allow listing of namespaces.
Cheers,
Stefan
Permalink
Stefan,
Thank you for your quick reply.
Before getting a ticket with MS, do you recommend any location to look around for more information related to the errors? Other than looking on WFE ULS logs.
The environment we use is isolated from internet, so any interaction with Microsoft would be difficult.
Thanks.
Permalink
Hi Catalin,
for SP2010 workflows the workflow history list and ULS log are the main place to look for issues.
But if the workflow really does not start I assume there is nothing in the workflow history list.
Cheers,
Stefan
Permalink
In past there were problem with Nintex WF and running workflows in Timer. So you had to edit OWSTIMER config. You can check it, if you have problem to run automated workflows.
Location should be like: C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\BIN\OWSTIMER.EXE.CONFIG
otherwise you can post US logs and error messages from WF history.
Permalink
you also have to add exceptions to the Timer Service web.config, when using triggered Workflows:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\BIN\OWSTIMER.EXE.config
Permalink
Hi Martin,
Thanks for your reply.
I haven’t done this in the past, do you mind telling me how it should look the exception for OWSTIMER?
Should I add the entire code from Stefan’s post for fixing workflows? In my OWSTIMER there is not entry for authorized types, probably is the config is the default one.
Also i have 2 WFE and 2APP+Search servers (APP2 is hosting also WFM). The exception for OWSTIMER is only for both WFE or foll all SP servers from my farm?
Thank you.
Permalink
we have installed october 2024 in SPSE and seeing too slow response from sites. Verified the resources RAM and CPU everything looks good. any one observed the same behavior?
Permalink
Hi Stefan,
first of all I have to thank you for providing such detailed information on every CU not only for SharePoint! I’ve been consulting your blog for over 5 years now. SharePoint runs like a breeze, most excellent!
I tried to find an answer to my following question, but couldn’t find anything in your blog…
We are currently at July 2024 CU.
Do I have to install the language independent AND dependent version of August 2024 beforehand or is it OK to just take the August language dependent CU and install it along with October language independent CU?
What is best practice here?
Thanks in advance!
Thomas
Permalink
Hi Thomas,
it is always sufficient to install the most recent package for each piece as they are cumulative.
So if you would like to upgrade from July 2024 CU to October CU you only have to apply the language independent fix from October (KB5002647) and the language dependent fix from August (KB5002597).
There is NO need to install the language independent fix from August CU.
Cheers,
Stefan
Permalink
Hello together,
after handling the September CU with the entries in the web.config without problems, the October CU broke it again in our Test Environment and neither fix works. The web.config change and the change to the farm with powershell dont help me to get a basic test workflow published now which i took last time. Anyone experienced the same behavior?
Greetings Simon
Permalink
Hi Simon,
please open a support ticket with Microsoft to get this analyzed.
Cheers,
Stefan
Permalink
Hi Simon,
Indeed, the September CU fixed the issue with web.config, however after applying October CU, web.config file is broken again. Do you have any information from Microsoft ? Thanks.
Kr,
Joseph
Permalink
Did you get this resolved? I’m about to deploy the OCT 2024 update and a little nervous now …
Permalink
Hi Joseph,
Sorry for the delay. We didnt open a call as the old fix worked again anday and reboot after the initial installation. Sorry no further actions at the moment. But we will update the test environment tomorrow, and have a look at it.
Kind regards
Permalink
HI. Stefan.
I have a sharepoint 2019 installed version is 16.0.10389.20000 August 2022 core and langpack.
I want to update. can i install only core 16.0.10415.20001 October 2024 and last langpack 16.0.10413.20000 August 2024?
or i shoud instal core and langpack 16.0.10413.20000 before, and after core 16.0.10415.20001?
Permalink
Hi Stas,
yes, you can directly go to October 2024 lang independent and August 2024 language dependent and run the config wizard afterwards.
No need to install any intermediate fixes.
Cheers,
Stefan