Trending Issue: Distributed Cache problems after applying January 2023 CU

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:

  1. a change in the configuration wizard to update the Distributed Cache Cluster Security Settings
  2. 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.

76 Comments


  1. If we have not installed the January patch, would installing the February patch rout around this entire issue?

    Reply

    1. 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

      Reply

  2. May I please ask if the Feb 2023 updates cover this fix?
    Thanks,

    Reply

    1. Hi Phu, the issue is not addressed in February 2023 CU.

      Reply

  3. Where are the links to the language dependant and language independent?

    Reply

    1. 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

      Reply

  4. 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.

    Reply

    1. Thanks for the confirmation!
      🙂

      Reply

  5. 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!

    Reply

    1. Great – thanks for the confirmation!

      Reply

  6. Just to get things clear:

    We have the jan CU patch installed. Will we still have this issue, after installing the feb patch?

    Reply

    1. Hi Rickard, yes.

      Reply

  7. I suppose that the registry fix is not required for single server farms. Am I right?

    Reply

    1. On a single server farm with DCache enabled you should already have this registry key in place on your server.

      Reply

      1. 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).

        Reply

        1. 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

          Reply

  8. 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

    Reply

    1. Yes, that is expected. You have to apply the other steps on this page as well to resolve the problem.

      Cheers,
      Stefan

      Reply

  9. 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!

    Reply

    1. 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

      Reply

  10. 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

    Reply

    1. 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.

      Reply

      1. Thanks Stefan, in our case the WFE servers also host the distribute cache.

        Reply

        1. 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

          Reply

  11. If I install February 2023 in SP2016, this problem occurs with this patch, right?

    Reply

    1. Yes. it can occur. Does not affect everyone.

      Reply

  12. 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.

    Reply

  13. 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?

    Reply

    1. 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

      Reply

  14. 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.

    Reply

    1. Yes – the issue introduced in January CU also applies to February CU. What intermittend errors do you see in February CU?

      Reply

      1. By intermittent, I mean that sometimes PSConfig will work fine on one distributed cache server and fail on another distributed cache server.

        Reply

  15. 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.

    Reply

    1. 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.

      Reply

  16. 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”?

    Reply

    1. 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

      Reply

  17. Hello Stefan, is this issue still relevant after applying March 2023 CU? Thanks

    Reply

    1. Hi David,
      yes – the issue is not addressed in March 2023 CU.
      Cheers,
      Stefan

      Reply

  18. 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

    Reply

    1. Hi Pablo,
      the fix will not be included in April 2023 CU.
      The same steps apply for a single server farm.
      Cheers,
      Stefan

      Reply

  19. 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

    Reply

    1. Hi Stefano,
      yes, this is correct.
      Cheers,
      Stefan

      Reply

  20. Hello Stefan,
    This regression was introduced in January 2023 CU. Will it be fixed in May 2023 CU/PU?

    Reply

    1. Hi Girish,
      this is the current plan – as always no guarantee as it might slip.
      Cheers,
      Stefan

      Reply

  21. 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

    Reply

  22. Interestingly enough, my distributed cache instances would NOT come back up until I reverted the key back to the old setting of

    Reply

    1. Hi James,
      seems the XML in your response got eliminated when sending your response.
      Can you provide the details again without the tags?

      Reply

      1. securityProperties mode=”None” protectionLevel=”None”

        Reply

        1. 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

          Reply


  23. A fix for this issue has been released with May 2023 CU.

    Reply

  24. 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.

    Reply


  25. 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?

    Reply

  26. 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?

    Reply

    1. 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.

      Reply

      1. Thanks, Stefan for quick clarification!

        Reply

  27. 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.

    Reply

    1. 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

      Reply

  28. 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’

    Reply

  29. 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

    Reply

    1. 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

      Reply

      1. Thanks stefan for your inputs .. Can i ignore the error in case we denote want use the Distributed cache.

        Reply

  30. typo in Previous
    hanks stefan for your inputs .. Can i ignore the error in case we donot want use the Distributed cache.

    Reply

  31. 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

    Reply

    1. 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

      Reply

  32. 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

    Reply

  33. Well, it is not posting the results, the securityProperties section is missing “mode=”None” protectionLevel=”None””.

    Thanks again.

    Reply

    1. That means it is already configured correctly. No need to change the config.

      Reply

  34. Got the issue with the Aug23 CU. Before we had Dec22 CU ad all was fine.

    Reply

  35. 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

    Reply

    1. 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

      Reply

Leave a Reply to Stefan Goßner Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.