The product group released the May 2023 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 May 2023 CU will be available at the following Location in a couple of hours:
- KB 5002389 – May 2023 Update for SharePoint Server 2019 (language independent)
This is also a security update!
- KB 5002374 – May 2023 Update for SharePoint Server 2019 (language dependent)
The downloads for May 2023 CU are available through the following links:
- Download May 2023 Update for SharePoint Server 2019 (language independent)
This is also a security update!
- Download May 2023 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 May 2023 CU Build Number:
Language independent fix: 16.0.10398.20000
Language dependent fix: 16.0.10398.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.
Is Distributed cache issue has resolved on this May 2023 Patches?
see this post by Stefan – https://blog.stefan-gossner.com/2023/05/10/resolved-trending-issue-distributed-cache-problems-after-applying-january-2023-cu/
After installing this CU on my development environment, I noticed that retracting a solution takes longer than before. Before installing the CU, It usually took 30 to 60 seconds. Now, it takes 3 to 5 minutes for a single solution.
I tried using Central Administration, Remove-SPSolution with PowerShell and SPSolution.Retract from a C# console application, but it all behaves the same way. It seems like the timer job that retracts the solution is slowed down.
I noticed this right after installing the CU. Could this behavior be caused by the CU?
Hi Miroslav, please check here:
With respect to the fix applied in the May CU… I have installed the May CU in a 2016 and 2019 test environment. Both gave me an error that follows when running configuration wizard on the first server.
Failed updating SecurityMode and ProtectionLevel in cluster. [Exception=System.Management.Automation.CmdletInvocationException: Cannot start service AppFabricCachingService on computer ‘wps-spsrch-t05.corp.wpsic.com’. —> System.InvalidOperationException: Cannot start service AppFabricCachingService on computer ‘wps-spsrch-t05.corp.wpsic.com’. —> System.ComponentModel.Win32Exception: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it — End of inner exception stack trace — at System.ServiceProcess.ServiceController.Start(String args) at Microsoft.ApplicationServer.Caching.AdminApi.CacheAdmin.StartHostHelper(IHostConfiguration hostConfig, Boolean clusterCommand, Int32 hostTimeout) at Microsoft.ApplicationServer.Caching.AdminApi.CacheAdmin.StartExternalManagedCluster(IClusterConfigurationReader reader, ProgressDelegate progressDelegate, WriteErrorDelegate writeError, Int32 hostTimeout) at Microsoft.ApplicationServer.Caching.AdminApi.CacheAdmin.StartCluster(ProgressDelegate progressDelegate, WriteErrorDelegate writeError, Nullable
1 quorumTimeout, Nullable1 hostTimeout) at Microsoft.ApplicationServer.Caching.Commands.StartAFCacheClusterCommand.BeginProcessing() at System.Management.Automation.Cmdlet.DoBeginProcessing() at System.Management.Automation.CommandProcessorBase.DoBegin() — End of inner exception stack trace — at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input) at Microsoft.SharePoint.DistributedCaching.Utilities.SPVelocityPowerShellWrapper.StartCacheCluster(String provider, String connectionString) at Microsoft.SharePoint.Upgrade.UpdateClusterConfigurationInSPDistributedCache.Upgrade()]
I dumped the cluster configuration and it appears to be correct per the article posted.
<allow users="WSS_ADMIN_WPG" />
<allow users="WSS_WPG" />
The AppFabricCachingService was disabled on this server. Why would this service be disabled and since the cluster configuration is correct, do I need to worry about this?
RSS Web part seems broken in SP2019 environments. Any reported issues? Below is the error message from ULS log.
RssWebPart: Exception handed to HandleRuntimeException.HandleException System.Xml.XmlException: Root element is missing. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.ParseDocumentContent() at System.Xml.XmlCharCheckingReader.Read() at Microsoft.SharePoint.WebControls.XmlUrlDataSource.FetchData(String requestUrl) at Microsoft.SharePoint.WebControls.BaseXmlDataSource.Execute(String request) at Microsoft.SharePoint.WebControls.BaseXmlDataSource.GetXmlDocument() at Microsoft.SharePoint.WebControls.SingleDataSource.GetXPathNavigatorInternal() at Microsoft.SharePoint.WebControls.SingleDataSource.GetXPathNavigator() at Microsoft.SharePoint.WebPartPages.DataFormWebPart.GetXPathNavigator(String viewPath) at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform(Boolean bDeferExecuteTransform)
I have not heard about this..
RSS web part is working fine for us after the May CU in SP19.