With January 2023 CU for SharePoint Server 2016, 2019 and Subscription Edition we released a security fix which increased the transport security for communications between the SharePoint applications and the distributed cache cluster.
A fix for this issue has been released with May 2023 CU for SharePoint Server 2016, 2019 and Subscription Edition.
The change was implemented in two parts:
- a change in the configuration wizard to update the Distributed Cache Cluster Security Settings
- a change in the client logic (the code that connects the SharePoint worker processes to the Distributed Cache Server) to identify if the security of the server has been updated
For some customers these changes were not applied correctly which caused connections to the Distributed Cache server to fail with the following ULS log messages:
w3wp.exe (0xXXXX) 0xXXXX SharePoint Foundation DistributedCache 837o4 Unexpected Unexpected error while executing ExportCacheClusterConfig with parameters provider: 'SPDistributedCacheClusterProvider' , connectionString: '...
and
w3wp.exe (0xXXXX) 0xXXXX SharePoint Foundation DistributedCache 4y50r Unexpected Unexpected Exception in getting cache cluster security config - Exception 'System.Management.Automation.CmdletInvocationException: ErrorCode<ERRCAdmin040>:SubStatus<ES0001>:Failed to connect to hosts in the cluster ---> Microsoft.SharePoint.Internal.Caching.DataCacheException: ErrorCode<ERRCAdmin040>:SubStatus<ES0001>:Failed to connect to hosts in the cluster at ...'
and
w3wp.exe (0x285C) 0x2DA4 SharePoint Foundation DistributedCache ah24w Unexpected Unexpected Exception in SPDistributedCachePointerWrapper::InitializeDataCacheFactory for usage 'DistributedLogonTokenCache' - Exception 'Microsoft.SharePoint.Internal.Caching.DataCacheException: ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry later. ...'
To resolve these problems please follow the steps below.
Important: The PowerShell commands used below are slightly different for SharePoint Server Subscription Edition compared to SharePoint Server 2016/2019 as AppFabric got integrated into SharePoint Server Subscription Edition and the PowerShell CmdLets were updated with this integration.
Verifying the Distributed Cache configuration
To verify if the Distributed Cache configuration is correct you can use the following commands in a SharePoint Management Shell:
SharePoint Server 2016 and 2019
Use-CacheCluster Export-CacheClusterConfig -Path c:\temp\clusterconfig.xml
SharePoint Server Subscription Edition
Export-SPCacheClusterConfig -Path c:\temp\clusterconfig.xml
Open the exported clusterconfig.xml file and scroll to the end of the file and verify the advancedProperties section.
The correct configuration after applying January 2023 CU or later looks like this:
...
<advancedProperties>
<partitionStoreConnectionSettings leadHostManagement="false" />
<securityProperties>
<authorization>
<allow users="WSS_ADMIN_WPG" />
<allow users="WSS_WPG" />
</authorization>
</securityProperties>
</advancedProperties>
...
This is how the configuration looked like before applying January 2023 CU – if this still looks like this after installing the CU and running the config wizard then the configuration is incorrect and needs to be updated:
...
<advancedProperties>
<partitionStoreConnectionSettings leadHostManagement="false" />
<securityProperties mode="None" protectionLevel="None">
<authorization>
<allow users="WSS_ADMIN_WPG" />
<allow users="WSS_WPG" />
</authorization>
</securityProperties>
</advancedProperties>
...
You will notice the additional mode and protectionLevel attributes in the above incorrect configuration.
Fixing the Distributed Cache configuration
To resolve the issue execute the following PowerShell commands:
SharePoint Server 2016 and 2019
Stop-CacheCluster Set-CacheClusterSecurity -SecurityMode Transport -ProtectionLevel EncryptAndSign Start-CacheCluster
SharePoint Server Subscription Edition
Stop-SPCacheCluster Set-SPCacheClusterSecurity -SecurityMode Transport -ProtectionLevel EncryptAndSign Start-SPCacheCluster
Be aware that the Set-SPCacheClusterSecurity command has been added in January 2023 CU for SharePoint Server Subscription Edition and is not available in older builds.
The commands above will stop the cache cluster, update the cache cluster configuration (this will only work if the cache cluster has been stopped before – otherwise you will get an error) and start the cluster again.
Ensure that the client logic is able identify the security configuration of the distributed cache server
Required change on SharePoint servers NOT hosting the Distributed Cache service
To ensure that the SharePoint worker processes on servers which do not host the Distributed Cache service can read the Distributed Cache Configuration a custom provider has to be registered in the registry.
Copy the text below AS IS into a file with extension reg (e.g. DistributedCacheProvider.reg) and apply it on each server in your farm which does not host the Distributed Cache Service.
Best ist to hover over the text below and use the “Copy to Clipboard Function” to ensure that you copy the exact text you need.
SharePoint Server 2016 and 2019
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppFabric\V1.0\Providers\AppFabricCaching\SPDistributedCacheClusterProvider] "DisplayName"="Microsoft SharePoint AppFabric Caching Service Configuration Store Provider" "Type"="Microsoft.SharePoint.DistributedCaching.Utilities.SPDistributedCacheClusterCustomProvider, Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
SharePoint Server Subscription Edition
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\16.0\Caching\Providers\SPDistributedCacheClusterProvider] "DisplayName"="Microsoft SharePoint AppFabric Caching Service Configuration Store Provider" "Type"="Microsoft.SharePoint.DistributedCaching.Utilities.SPDistributedCacheClusterCustomProvider, Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
Required change on servers hosting the Distributed Cache service
There is one final step that needs to be completed: the worker process needs to be able to access the registry on the Distributed Cache servers to read the Distributed Cache registry key. To ensure that this works grant read access to the WSS_WPG group on the following registry key on all servers hosting the Distributed Cache service:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg
After this step is completed ensure to restart IIS on your Web Frontend Servers to ensure that the SharePoint worker processes try to reconnect to the SharePoint Distributed Cache Cluster.
In case you still get the ah24w message in the ULS log after this change verify if the application pool account of the affected web application is a member of the WSS_WPG group on the distributed cache server. SharePoint adds the account to this group on all machines when a new application pool is provisioned but if this step failed then the WSS_WPG group might miss the relevant account and it has to be added manually to this group to ensure that the account has access to the registry.
Credits
Thanks a lot to my colleague Dan Cristureanu from Romania whos analysis on several support cases was a significant contribution to this blog post.
Permalink
If we have not installed the January patch, would installing the February patch rout around this entire issue?
Permalink
Hi Charles,
unfortunately not.
I will update this thread as soon as I have further information if and when it will be addressed.
Cheers,
Stefan
Permalink
May I please ask if the Feb 2023 updates cover this fix?
Thanks,
Permalink
Hi Phu, the issue is not addressed in February 2023 CU.
Permalink
Where are the links to the language dependant and language independent?
Permalink
Hi Peter,
please check my other blog posts about CU releases.
This post is not a CU release post – it talks about a specific problem.
Thanks,
Stefan
Permalink
That seems to have fixed my issues on my two 2016 test farms, thanks Stefan (and Dan!) for the instructions and details on the issue. I’d been seeing the feed cache repopulation jobs fail and they’re both running properly after the fix. The Distcache seems happy & healthy.
Permalink
Thanks for the confirmation!
🙂
Permalink
These steps fixed my issues as well in SP 2019 test farm 🙂 Our configuration was correct but the last registry update did the trick. Thank you!
Permalink
Great – thanks for the confirmation!
Permalink
Just to get things clear:
We have the jan CU patch installed. Will we still have this issue, after installing the feb patch?
Permalink
Hi Rickard, yes.
Permalink
I suppose that the registry fix is not required for single server farms. Am I right?
Permalink
On a single server farm with DCache enabled you should already have this registry key in place on your server.
Permalink
Does it apply also for Permissions for winreg? In other words: is it required to grant read perm on mentioned registry key for WSS_WPG group on single server scenarios? Sorry Stefan, I am asking because when I added my initial post/question there was not yet published last step of resolution (registry perms modification).
Permalink
Hi eLKey,
I don’t have such a server to test.
If you see the ah24w ULS log entries then you should set this permission.
Cheers,
Stefan
Permalink
Hello Stefan, we are getting these unexpected errors in our logs after applying the January patch “Unexpected error while executing ExportCacheClusterConfig with parameters provider” and “Unexpected Exception in getting cache cluster security config” but when we check the config file it looks correct and if we run the powershell to set “-SecurityMode Transport -ProtectionLevel EncryptAndSign” it tells us no change required.
Just curious if anyone else has this issue where we are getting the errors but the config file is set correctly?
Thanks
Permalink
Yes, that is expected. You have to apply the other steps on this page as well to resolve the problem.
Cheers,
Stefan
Permalink
Hello Stefan,
We are on SP 2019.
What are the day to day usability impacts of this issue?
I have 3 farms on the Jan 2023 CU since January. All passed testing and seem to be functioning as expected.
I confirmed our cluster config on all servers/farms are correct and I don’t find the error messages in the ULS logs of any server. I searched a full day’s worth of ULS logs from each server; is that enough?
Our Dev farm is missing the registry entries for the non-DC servers, but QA and Prod have the registry entries.
None of the DC servers have the registry permission for WSS_WPG.
All farms appear to function as expected, but none meet all of the conditions of the fix instructions. Dev is particularly out of spec.
If I were to apply all of the fix items will the Feb 2023 CU possibly put servers back into a problem state?
Thanks so much!
Permalink
Hi GB,
that depends. Distributed Cache is used in various different places in SharePoint and if content cannot be served from the Cache a variety of issues can occur including
– frequent authentication prompts and logouts
– performance problems
– problems with Office Online Server
– …
These are just a view examples.
If the ULS log entries I listed are not in the ULS logs of the WebFrontEnd servers, then there should not be an issue.
Feb CU is already available and you can apply it.
Cheers,
Stefan
Permalink
Thank you, Stefan.
Permalink
Hi Stefan,
We are on SP 2016. I have applied the fixes above but the servers hosting the distributed cache are still logging the ah24w errors. There are also distributed cache related exceptions being logged to the window event log. The issues on the distributed cache client servers has been resolved.
Thanks,
Pete
Permalink
Hi Pete, that looks like a different issue. For the issue we have seen the ah24w shows up on servers with the wfe role. For you it happens on the dcache servers. I would recommend to open a ticket with Microsoft support to get this analyzed.
Permalink
Thanks Stefan, in our case the WFE servers also host the distribute cache.
Permalink
Hi Pete,
thanks for the confirmation. I think that cases requires deeper analysis if the steps in this article did not help.
Might be other things going wrong when communicating with the distributed cache servers.
I would recommend to open a support ticket with Microsoft to get this analyzed.
Cheers,
Stefan
Permalink
If I install February 2023 in SP2016, this problem occurs with this patch, right?
Permalink
Yes. it can occur. Does not affect everyone.
Permalink
After this fix, we continued to get ‘ah24w’ errors on our WFE servers. When I added our Web App service account to the WSS_WPG security group on our dedicated Distributed Cache server, we no longer received the error. The service app account was already a member, but not the account running the web application.
Permalink
Nice fix.
Permalink
Thanks, Stefan – We’re applying the fix to a 2019 farm with custom role servers that have Dist Cache and Front End services running on the same servers.
The errors stopped on the APP servers that do not run DC, and the UPS Proxy – Feed Cache Full Repopulation Job no longer fails to execute, which is great. The UPS Proxy – Feed Cache Repopulation Job executing on one of the FE/DC servers continues to fail, however, throwing the same error in the log.
I’m thinking that it may be necessary to add the custom provider reg key to the FE/DC host servers in this farm config, but since doing the wrong thing to Distributed Cache can cause major issues in a farm, I’m apprehensive to just give it a try, even on our DEV/TEST farms. Your thoughts?
Permalink
Hi Brett,
on a server hosting a DCache instance that registry key should always exit. Thats why we only import it into servers which do not host the DCache service. But to be sure please double check if it is missing.
FYI: the ULS log entry with 837o4 message indicates that the export of the cache cluster config failed – which could be an indicator that the above listed reg key is missing – or that the permission on the remote registry key do not allow remote registry access to the registry of the DCache server (…\winreg above). Same for the 4y50r message.
If the 837o4 and the 4y50r ULS log entries do not occur, then the cache cluster config was correctly exported. Then this registry key is there and works correct. It is also an indicator that the permission on the remote registry key is correct (…\winreg) as this is also required to successfully communicate with the DCache service.
We have seen one case where only the 4y50r message occurred but we are still troubleshooting it. In this case the inner exceptions in this message indicate a WCF layer communication problem between the WFE and the DCache server and not missing registry keys or registry permissions.
Please let me know which of these ULS log entries you get.
Cheers,
Stefan
Permalink
I’m still seeing intermittent issues with the February update as well. Note that I’d skipped the January update in this dev environment. PSConfig produced the following error.
An exception of type Microsoft.SharePoint.Upgrade.SPUpgradeException was thrown. Additional exception information:
Failed updating SecurityMode and ProtectionLevel in cluster. [Exception=System.Management.Automation.ParameterBindingException: A parameter cannot be found that matches parameter name ‘Path’.] (EventID:0)
Running Set-CacheClusterSecurity -SecurityMode Transport -ProtectionLevel EncryptAndSign fixed the issue and I was able to complete the upgrade.
I also saw instances where the registry key SPDistributedCacheClusterProvider was missing. Add the key and values manually fixed the issue.
Permalink
Yes – the issue introduced in January CU also applies to February CU. What intermittend errors do you see in February CU?
Permalink
By intermittent, I mean that sometimes PSConfig will work fine on one distributed cache server and fail on another distributed cache server.
Permalink
Successful February 2023 patch applied (SharePoint 2016):
I just wanted to report that I was able to apply the February 2023 patch successfully in my SharePoint 2016 environment. I ensured that I gracefully stopped Distribution Cache before running PSCONFIG on my WFE/Cache servers. When I checked, both had the correct configuration, and did not see the issue associated with the January 2023 patch (which we had skipped). I applied no remediation steps to the farm.
Permalink
Update: False assumption of success above.
Checking the registry on all the other servers in the farm aside from the WFE/Cache servers revealed that 4/6 did not have the correct values. We updated the reg on these servers, and granted read permissions for the key specified on the WFE/Cache servers.
Permalink
Would either an Office Online Server, or the SQL Server hosting the SP database, be considered a member of the farm that falls under “Required change on servers NOT hosting the Distributed Cache service”?
Permalink
Hi Keenan,
no – this is only required on Server which have SharePoint installed.
Let me update the wording to make it more clear.
Cheers,
Stefan
Permalink
Hello Stefan, is this issue still relevant after applying March 2023 CU? Thanks
Permalink
Hi David,
yes – the issue is not addressed in March 2023 CU.
Cheers,
Stefan
Permalink
Hi Stefan, do you know if this will be resolved on April 2023 CU? What are the steps on this fix for a single server farm? Thanks
Permalink
Hi Pablo,
the fix will not be included in April 2023 CU.
The same steps apply for a single server farm.
Cheers,
Stefan
Permalink
Hey Stefan,
in your article you mentioned “For some customers these changes were not applied correctly”.
So do I understand correctly then that this is not a general error that will occur with every installation?
So if I install this patch in our Dev SharePoint farm, then I might not get the error in PROD it might show up then unfortunately?
Regards,
Stefano
Permalink
Hi Stefano,
yes, this is correct.
Cheers,
Stefan
Permalink
Hello Stefan,
This regression was introduced in January 2023 CU. Will it be fixed in May 2023 CU/PU?
Permalink
Hi Girish,
this is the current plan – as always no guarantee as it might slip.
Cheers,
Stefan
Permalink
Hi Stefan,
Thank you for this fix.
I was able to correct this in our DEV/TEST environment and currently awaiting change management approval to apply to prod.
I ran into some issues that may be encountered by some other admins so I am adding them :
Distributed Cache Process Account was a least priviliged account and that caused issues when reseting distributed cache values
User profile service had an separate assigned account which was not in WSS_WPG so LMT Repopulation and Feed cache errors persisted until an explicit Grant-CacheAllowedClientAccount -Account “domain\account” was performed. At which point it appeared in the config segment securityProperties->Allow and the error went away. This was also reported in the eventviewer as needing to be granted (Server channel security authorization failed for client {UserProfSync-SVC}. To grant access, use Grant-CacheAllowedClientAccount command
Permalink
Interestingly enough, my distributed cache instances would NOT come back up until I reverted the key back to the old setting of
Permalink
Hi James,
seems the XML in your response got eliminated when sending your response.
Can you provide the details again without the tags?
Permalink
securityProperties mode=”None” protectionLevel=”None”
Permalink
Hi James,
that is unexpected. The DCache servers should be able to run with the new and the old configuration. I would recommend to open a support ticket with Microsoft to get this analyzed.
Cheers,
Stefan
Permalink
Permalink
A fix for this issue has been released with May 2023 CU.
Permalink
Just wanted to feedback the following. One SharePoint 2019 farm (pre-production) I support was affected by this issue when applying the April 2023 CU. The manual fixes described above were applied, but I could not get the distributed cache back up, the status would either be unknown or starting, before returning to down. I was also still seeing ‘ah24w’ event log errors. As this was late April, I decided to wait for the May CU. After applying the May 2023 CU successfully the cache still failed to restart (not a huge surprise given this edge case). Further analysis led me to clear the config cache on all servers, which resolved this issue. I then verified the cache config and health were good.
Permalink
Permalink
Stefan, for SharePoint 2016, if we apply the May 2023 CU, will that be enough or are we still need to apply the fixes above you mentioned?
Permalink
Hi Raj, it will be enough except for specific conditions as discussed here: https://blog.stefan-gossner.com/2023/05/25/trending-issue-additional-flavor-of-the-distributed-cache-problem-introduced-with-january-2023-cu/
Permalink
Hi Stefan, I’ve applied the march 2023 CU on a small SP2019 farm (1 Frontend with Distributed Cache, 1 Application with Search, 1 Office Online Server and 1 AddIn Server). The Distributed Cache configuration looks ok. In the ULS logs I don’t have ah24w messages or other unexpected messages regarding distributed cache. But I see some messages like “Successfully executed… SPDistributedCacheClusterCustomProvider:: BeginTransaction” (ahlcr) or “Calling… SPDistributedCacheClusterCustomProvider:: GetValue(object transactionContext, string type, string key).” (ahlc2). So everything looked fine for me and because I didn’t find some unexpected messages regarding distributed cache, I didn’t apply the fix (also not the two fixes for the registry, one for the frontend server and one for the application server). But since we’ve applied this CU our customer is facing some performance issues during peak hours (e.g. in the morning, when all the employee starting their intranet) and of course he’s assuming that there is a relation to this issue. How can I make sure, that the farm is not affected by this issue?
Permalink
Hi Reto, if the ULS events listed in the article above are not showing up on the relevant WFE or Distributed Cache servers, then the issue is not present.
Permalink
Thanks, Stefan for quick clarification!
Permalink
My WFE with Distrubuted Cache server failed . I tried to bring up a new server and add the same role. As i added the server into the farm i had cache host null. I was able to correct the cache host null issue and now my page is showing error 503. When i checked the UL Logs indicated error regarding distrubuted errors:
The error code ERRCA0017 with SubStatus ES0006 indicates a temporary failure in the Distributed Cache service in SharePoint. The error message suggests that one or more specified cache servers are unavailable, which could be due to a busy network or server-related issues.
Permalink
Hi Tekola,
did you ensure that your farm and the new server are patched with at least May 2023 CU?
This should ensure that the Jan CU issue does not happen.
If thats the case and the issue still occurs and you need assistance to get it resolve I would recommend to open a case with Microsoft Support.
Cheers,
Stefan
Permalink
Hi Stefan,
We have applied July 2023 CU(sharepoint 2019), but Distibuted cache isse not resolved.
Tried all above suggestion which are mention in this blog.
Deleted Distributed cache, created again but no success
1- Use-CacheCluster
2- Get-CacheHost
3- Add-SPDistributedCacheServiceInstance
getting error –
add-spdistributedcacheserviceinstance : a parameter cannot be found that matches parameter name ‘path’
Permalink
HI Stefan
In Our Environment we have not configured the Distributed cached even though we are getting same error during patch installation of AUG23 .Could you please help me on this
Permalink
Hi Praveen,
the error occurs when the distributed cache server cannot be reached from the w3wp process.
If you did not configure a distributed cache server in your farm, then it of course cannot be reached.
To resolve it you need to configure a distributed cache server in your farm.
Cheers,
Stefan
Permalink
Thanks stefan for your inputs .. Can i ignore the error in case we denote want use the Distributed cache.
Permalink
typo in Previous
hanks stefan for your inputs .. Can i ignore the error in case we donot want use the Distributed cache.
Permalink
Stefan,
We have the January patches installed (SP 2016 16.0.5378.1000)and ran into a failure while trying to install the July CU. I had snapshots in place and rolled back to the January CU to see if this issue existed then. When I run the first command to export I am seeing the following:
When I attempt to run the fix I get the following message:
Set-CacheClusterSecurity -SecurityMode Transport -ProtectionLevel EncryptAndSign
WARNING: Configuration will not be updated. No new values were provided.
Also, it appears I can only run these from the WFE01 server as the cach cluster is not available from WFE02, even though both are in an up status after I Start-CacheCluster. Any recommendations?
Thanks,
Joe
Permalink
Hi Joseph,
sorry screenshots are not supported in comments – so I do not see the error.
As the issue is fixed with May 2023 CU and later I would recommend to focus on getting any of the newer fixes installed.
Cheers,
Stefan
Permalink
Stefan,
Thanks for the quick response. I was trying to post the results of the export:
As you can see it is missing the updated configuration.
We were trying to update to the July CU from the January CU when the update failed on WFE02. The error message led me to this fix. When I run this part of the fix: “Set-CacheClusterSecurity -SecurityMode Transport -ProtectionLevel EncryptAndSign”
WARNING: Configuration will not be updated. No new values were provided.
I was thinking that I may need to rebuild the Distributed Cache. Your thoughts would be appreciated.
Thanks,
Joe
Permalink
Permalink
Well, it is not posting the results, the securityProperties section is missing “mode=”None” protectionLevel=”None””.
Thanks again.
Permalink
That means it is already configured correctly. No need to change the config.
Permalink
Got the issue with the Aug23 CU. Before we had Dec22 CU ad all was fine.
Permalink
Hello Stefan,
I have two plateforms Sharepoint 2019 on Windows Server 2016 (farms with one server) : one with CU 10/2023, the other with CU 02/2023. I have exactly the same issue but if i try to apply your solution, the command “Set-CacheClusterSecurity -SecurityMode Transport -ProtectionLevel EncryptAndSign” fails with the error :
Set-CacheClusterSecurity : Object reference not set to an instance of an object.
At line:1 char:1
+ Set-CacheClusterSecurity -SecurityMode Transport -ProtectionLevel Enc …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Set-AFCacheClusterSecurity], NullReferenceException
+ FullyQualifiedErrorId : System.NullReferenceException,Microsoft.ApplicationServer.Caching.Commands.SetAFCacheClusterSecurityCommand
command ‘use-cachecluster’ fails : “ErrorCode:SubStatus:Failed to connect to hosts in the cluster”
command ‘get-cachehost’ succeeds and one host is UP
command ‘stop-cachecluster’ fails with timeout. Finally, the windows service is stopped but the distributed Cache service instance is still online
command ‘set-cachecluster security … ‘ fails with message ‘Set-CacheClusterSecurity : Object reference not set to an instance of an object’
command ‘start-cachecluster’ succeeds
Any idea about this problem ?
Kind regards
Christophe
Permalink
Hi Christophe,
I haven’t seen this and would recommend to open a ticket with Microsoft Support to get this analyzed in more detail.
Cheers,
Stefan
Permalink
Hi Stefan,
Regarding the registry rights on HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg of group WSS_WPG, we see that the two keys below that key (AllowedExactPaths and AllowedPath) do not get the rights inherited so on those two keys, there is no READ right for the group WSS_WPG. Sould we simply establish the inheritance again or assign also the READ rights. What is the default here?
Let me know if I should open a support request to get this answered, thanks.
Cheers von ZRH nach MUC,
Richard
Permalink
Hi Richard,
please open a ticket to get this clarified.
Cheers,
Stefan
Permalink
Hi stefan,
I faced the same issue when installing cu april 2024, originally i had rtm version.
I just executed the powershell command and the upgrade was successful.
Is it required to do the registry changes in this case as i see it is already there?
Permalink
Hi Najwan, if the registry entries are there you don’t have to manually add them.