The product group released the December 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 December 2024 CU will be available at the following Location in a couple of hours:
- KB 5002657 – December 2024 Update for SharePoint Server 2019 (language independent)
This is also a security update! - KB 5002664 – December 2024 Update for SharePoint Server 2019 (language dependent)
This is also a security update!
The downloads for December 2024 CU are available through the following links:
- Download December 2024 Update for SharePoint Server 2019 (language independent)
This is also a security update! - Download December 2024 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 December 2024 CU Build Number:
Language independent fix: 16.0.10416.20026
Language dependent fix: 16.0.10416.20026
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
Is it fine to install the cumulative/security update, does it cover the previous month security updates as well.
Permalink
Hi Vivekanand,
yes – December CU includes all previously released fixes.
Cheers,
Stefan
Permalink
Since this update, our Nintex workflows are becoming stuck when they encounter a “Pause Until” or “Pause For” action.
We have not been able to solve the problem so far and are currently waiting for support from Nintex.
More information:
We have replicated the issue in another farm, so we are almost sure this update triggered this issue.
Workflows without pause actions are handled well.
We know from experience that Nintex Workflows are initially handled by processes on the web frontends. In the event that a pause action is reached, the workflow should be picked up by processes on the application server. All processes on both types of servers are running and we cannot find error in our logs.
Permalink
Since today we are working closely with Nintex to resolve this issue, but haven’t yet identified the root cause. Our investigation so far includes:
– A comprehensive investigation in the logfiles (in which we not yet find a clue)
– Verification of Webconfig and related settings (in which we don’t find any abnormality yet)
We’ll continue our investigation and provide further updates as soon as we have new information. In the meantime, we welcome any insights or observations you may have.
Permalink
https://community.nintex.com/nintex-for-sharepoint-67/workflows-with-a-pause-action-fail-to-run-or-do-not-progress-after-applying-december-2022-sharepoint-cumulative-update-31735
Fixes the issue for newly started Workflows. As far as I recall, back in 2022 (also december 🤔) we weren’t able to fix it for Workflows that already got stuck, but working on that now with Nintex.
Permalink
Thank you for sharing the link. (I also obtained it from Nintex support.) By following the article’s instructions, I successfully restored workflows. The specific action that encountered issues was the ‘Change State’ action. While newly initiated workflows are functioning properly, existing workflows failed to restart following the changes implemented. If you happen to receive any updates or information from Nintex regarding this matter, please share that information. It would be helpful for those of us facing similar challenges with existing workflows after the recent adjustments.
Permalink
For us the problem has been solved; please note it took up to 9 hours+ for some workflows to pick up from the pause. Newly started workflows just run as expected.
@Walter, it seems we luckily had no Change State actions in the time we faced the problem. Hope you find a solution. Best wishes!
Permalink
Emil, this fixed our issues with Nintex that started after the December 2024 CU was applied. Thank you for your help.
Permalink
I agree with Emiel regarding issues with Nintex workflows getting stuck. In my case, the workflow stops progressing when it reaches a ‘Change State’ action. I have already verified that all required entries are present in the web.config and owstimer.config files, as suggested. Additionally, I have opened a case with Nintex support and am awaiting their response. Once I have a resolution, I will be sure to share it here.