The product group released the October 2022 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 2022 CU will be available at the following Location in a couple of hours:
- KB 5002278 – October 2022 Update for SharePoint Server 2019 (language independent)
This is also a security update!
- KB 5002277 – October 2022 Update for SharePoint Server 2019 (language dependent)
The downloads for October 2022 CU are available through the following links:
- Download October 2022 Update for SharePoint Server 2019 (language independent)
This is also a security update!
- Download October 2022 Update for SharePoint Server 2019 (language dependent)
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 2022 CU Build Number:
Language independent fix: 16.0.10391.20000
Language dependent fix: 16.0.10391.20000
- 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.
In the C:\Windows\Installer folder, I noticed that there are about 12 GBs of patch installers for Microsoft SharePoint Server 2019. It looks to be a cumulation of patches from January of 2019 to today. It seems like when a patch is applied for SharePoint, it stores the patch installer into this directory to be used just in case if you need to uninstall it. The problem is that over time, this starts to get huge.
Is there a way to cleanup C:\Windows\Installer folder?
you should not touch this directory. Removing elements can lead to a situation where you are no longer able to apply further patches.
Post installing the Oct 2022 SP 2019 Patch , After the latest patch we have noticed that some of out SharePoint Designer workflows have started to fail and throw the following error in ULS Logs :
Message=Scope ‘/SharePoint/default/1412b875-e1f4-4829-b8c4-248635a4bbd2/67a41b16-64eb-43cd-a678-9bd00db33785’ was not found. HTTP headers received from the server – ActivityId: 4a114c79-e50a-4a67-b89a-f92a27044ec7. NodeId: 04ADC15301. Scope: /SharePoint/default/1412b875-e1f4-4829-b8c4-248635a4bbd2/67a41b16-64eb-43cd-a678-9bd00db33785. Client ActivityId : b90b6ea0-a05d-e095-c20d-a64be0dbb44e.
at Microsoft.Workflow.Client.ClientHelpers.SendRequest[T](HttpWebRequest request, T content)
at Microsoft.Workflow.Client.WorkflowManager.StartInternal(String workflowName, WorkflowStartParameters startParameters)
at Microsoft.SharePoint.WorkflowServices.FabricWorkflowManagementClient.StartInstance(String serviceGroupName, String workflowName, String monitoringParam, String activationKey, IDictionary
2 payload)2 payload)
at Microsoft.SharePoint.WorkflowServices.FabricWorkflowInstanceProvider.StartWorkflow(WorkflowSubscription subscription, IDictionary
at Microsoft.SharePoint.WorkflowServices.FabricWorkflowInstanceProvider.StartWorkflowOnListItem(WorkflowSubscription subscription, Int32 itemId, IDictionary`2 payload)
It sounds to me as if the workflow manager registration on this farm is no longer valid.
The scope “SharePoint” seems to be missing.
You can reestablish it using the command below (ensure to fill in the missing parts)
-WorkflowHostUri -ScopeName “SharePoint” -Force
See below for details:
If this does not help I would suggest to open a support case with Microsoft to get this analyzed in more details.
Hi Stefan, we wanted to know the steps to identify and address .xoml file encoding known issue reported in the 2016 & 2019 KB’s (KB5002278 & KB5002287) . The below mentioned blog doesn’t contain any details on how to address it and we don’t have any resolution from our end . Could you please guide us ?
if you need assistance for this I would recommend to open a support ticket with Microsoft.
Do we have to apply the fixes mentioned in September 2022 CU after installing October 2022 CU if we are directly going from June 2022 CU?
SharePoint fixes are cumulative. If you install both fixes from October CU they include all fixes from September CU as well.
Stefan, after applying the October 2022 CU to our On-Prem SharePoint 2019 dev farm, we are now seeing errors when trying to use “Share” or “Shared with” on list items: “Sharing context retrieval failed: SyntaxError: Unexpected end of JSON input”. However, when we examine the actual web calls being made, we see a 404 Not Found for “https://CONTOSO.com/sites/CONTOSO/_api/SP.Web.GetObjectSharingSettings”, whereas that same call works without issues in our production site, which has not had the October 2022 CU applied yet. Have you seen this problem reported yet?
I haven’t heard about such an issue. If you need assistance to resolve it I would recommend to open a ticket with Microsoft Support.
did you fix this issue? I need help
Be aware there is also an issue that was introduced soem time between Jan21 and Oct22 that causes RDB refresh to fail and leave the RDB schema out of sync with PWA. We are running an incident on this, and it is seen on OCT22CU and NOV22CU (though could have been introduced earlier)