Distributed Cache not working on a renamed SharePoint SE server

Question

Distributed Cache not working on a renamed SharePoint SE server

Keith Vollero 101

We renamed our SharePoint SE WFE server. It's a small farm, just a WFE server and SQL server backend. The system is working, but the Distributed Cache service will not start.

It throws the error: 'cacheHostInfo is null'.

User's image

Checking the ClusterConfig.xml file, I see that the old server name is still there in the <hosts> section.

I've tried the 'Remove-SPDistributedCacheServiceInstance' / 'Add-SPDistributedCacheServiceInstance', but No Joy.

How can I correct the Cluster Config file?

Also, in case anyone knows the answer to this: I do not have the AppFabric Caching service available in my Services. Is SharePoint SE supposed to have that service? My installation does not.

0 comments

3 answers

Your answer

Answer 1

Vergil-V 14,765 Microsoft External Staff Moderator

Hi Keith Vollero

Based on my research, the behavior where the AppFabric Caching service is no longer visible is expected by design.

Reference: Manage the Distributed Cache service in SharePoint Server - SharePoint Server | Microsoft Learn

With that in mind, I would not recommend manually editing the ClusterConfig.xml file, as this may lead to further inconsistencies.

Additionally, may I clarify one point: did you run the Rename-SPServer command as part of the renaming process?

If not, you may consider the following steps to help narrow down and verify the current state:

1/ Verify what the farm recognizes as the server name

Get-SPServer | Select Name, Role

Also check the cache host status:

Get-SPCacheHost

2/ Run the Rename-SPServer command

Rename-SPServer -Identity "OLDSERVERNAME" -Name "NEWSERVERNAME"

After running this, execute Get-SPServer again to confirm that the new name is updated correctly.

3/ Force remove any stale cache service instance

# Find and delete the orphaned/stale instance 
$instanceName = "SPDistributedCacheService Name=SPCache" 
$serviceInstance = Get-SPServiceInstance | Where-Object { 
    ($_.service.tostring()) -eq $instanceName -and 
    ($_.server.name) -eq $env:computername 
} 
  
# Inspect it first 
$serviceInstance | Select Server, Status, Id 
  
# Then delete it 
$serviceInstance.Unprovision() 
$serviceInstance.Delete()

4/ Re-add the cache service

Add-SPDistributedCacheServiceInstance

Then verify again:

Get-SPCacheHost 
Get-SPServiceInstance | Where-Object { $_.TypeName -eq "Distributed Cache" }

I hope this provides additional direction.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Keith Vollero 101 Reputation points

2026-06-01T15:53:44.1233333+00:00

Hello Vergil-V,

I did run the Rename-SPserver command when doing the renaming. That was the very first step.

I've confirmed that with the get-server command. Watson is the name of this WFE server, (renamed from Edison)

As shown, the Distributed Cache service is disabled.
Vergil-V 14,765 Reputation points Microsoft External Staff Moderator

2026-06-02T08:52:13.1933333+00:00

Please note that Q&A forum is a public platform, and moderators will modify the question to hide personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi Keith Vollero
I suspect that the Distributed Cache may still be referencing server names, even if they are no longer valid. ~~In this case, you may consider removing any invalid entries using the script below:~~

~~# Remove all Invalid ghost servers~~

~~Get-SPServer | Where-Object { $_.Role -eq "Invalid" } | ForEach-Object {~~

~~Write-Host "Removing: $($_.Name)" -ForegroundColor Yellow~~

~~Remove-SPServer -Identity $_.Name -Confirm:$false~~

}

~~# Confirm only Watson remains~~

~~Get-SPServer | Select Name, Role~~

After that, you may rerun the steps to remove and then re-add the cache service to check whether it works as expected.

If you have any updates, please feel free to share them.
Keith Vollero 101 Reputation points

2026-06-02T13:03:23.7033333+00:00

Hi Vergil,

This sounds like the right track. DC is almost certainly referencing an invalid server name, the original name is still embedded in the ClusterConfig.xml file. Your script looks to be the correct start to a solution, except now I've hit a bizarre problem. Even though I'm running PowerShell with Administration privileges, and have definitely added the SharePoint snapin, "Remove-SPServer" doesn't seem to be among my PowerShell SharePoint commands?

It throws a 'not recognized' error when running the command,

Even more strange, it doesn't appear in the Command list in Powershell ISE.

What the heck?
Vergil-V 14,765 Reputation points Microsoft External Staff Moderator

2026-06-02T14:13:58.76+00:00

Hi Keith Vollero
Thank you for sharing your findings.

I have double-checked and realized that I made a mistake earlier, as the Remove-SPServer command does exist. I sincerely apologize for the confusion.

After further research, you may consider reviewing the steps below for the removal approach through Central Administration.

This approach is suitable for orphaned servers, which appears closely related to your current scenario.

Reference: Remove a server from a farm in SharePoint Servers 2016, 2019, and Subscription Edition - SharePoint…

I hope this provides additional insight.
Vergil-V 14,765 Reputation points Microsoft External Staff Moderator

2026-06-03T10:31:39.3033333+00:00

Hi Keith Vollero
Hope you're having a good day.

May I ask if there have been any updates since our last exchange?

Have you had a chance to review the responses shared so far?

I’d appreciate any updates you can provide, and please let me know if there’s anything further I can do to assist.
Keith Vollero 101 Reputation points

2026-06-03T12:38:10.77+00:00

Hello Virgil,

Apologies for being MIA yesterday. I was swamped with HelpDesk tickets.

I've removed the orphan server via Central Admin, and now that information is in sync with the information PowerShell is giving me. Have been getting errors when trying the script to remove the stale ServiceInstance, so I played around with the commands a bit to see where the issue is. Managed to make some headway, and I feel like we're getting closer.

Running this: "$serviceInstance = Get-SPServiceInstance | Where-Object{($_.service.tostring()) -eq "SPDistributedCacheService Name=SPCache" }" returns this:

However, the ".Unprovision()" command fails with the same error, "cachehostinfo is null"

I'm guessing that the fact that it's disabled is why it can't be unprovisioned, so am tempted to skip the 'Unprovision' line and simply try the .Delete.

Good idea, or maybe not?
Vergil-V 14,765 Reputation points Microsoft External Staff Moderator

2026-06-03T14:55:03.0166667+00:00

Hi Keith Vollero
I would like to be transparent that I do not have dedicated testing to replicate this scenario or provide confirmed insights.

However, I did notice in the following documentation: SPServiceInstance methods (Microsoft.SharePoint.Administration) | Microsoft Learn

It states that:

+The Unprovision method is used to stop the service instance on the server.

+The Delete method is used to remove the object entirely.

Based on your intention, you may consider trying the Delete method directly, since the SharePoint server is already in a disabled state, to observe how it behaves in your scenario.

I hope this provides some additional context and helps guide your next steps.
Keith Vollero 101 Reputation points

2026-06-03T16:57:10.13+00:00

Hello Vergil -

At this point, I feel like I should at least buy you lunch for your efforts.

For now, things are getting interesting...

With the 'Get-SPServiceInstance' command, I'm able to get the GUID for the Distributed Cache service, which has a status of "disabled".

With the GUID, I then get that specific service instance and can delete it. I know it's deleted because it no longer shows up in the Service Instance list.

I then run 'Add-SPDistributedCacheServiceInstance', and a new service is created. I know it's a new one because it has a different GUID.

However, it's still disabled.

Attempting to start the Distributed cache service from Central Admin still throws the same error, "cachehostinfo is null".

Running Remove-SPDistributedCacheServiceInstance also throws the same error, "cachehostinfo is null".

This all comes back to the problem that the old server name is embedded in the ClusterConfig.xml file. And Microsoft is Very Adamant about not messing with that file.

Copilot has some thoughts on the matter, but the very first step is stopping service named "ClusSvc" which doesn't appear to be in the list of services.

And that's where I am today.
Vergil-V 14,765 Reputation points Microsoft External Staff Moderator

2026-06-04T13:49:45.29+00:00
Hi Keith Vollero

Thank you for your kind words.

You are correct that the ClusterConfig.xml file should not be edited directly.

However, based on my research, the PowerShell cmdlets for the Distributed Cache service do support exporting and importing the ClusterConfig file.

With that said, you could consider exporting the current ClusterConfig.xml file, creating a copy, then updating the SharePoint Server name in the copied file. After that, you can import the updated copy back, while keeping the original file available as a backup.

Reference:

Manage the Distributed Cache service in SharePoint Server - SharePoint Server | Microsoft Learn

Export-SPCacheClusterConfig (SharePointServer) | Microsoft Learn

Import-SPCacheClusterConfig (SharePointServer) | Microsoft Learn

I hope this provides another useful direction.
Keith Vollero 101 Reputation points

2026-06-04T18:44:11.9433333+00:00

Hello Vergil,

Well, Export/Import sounded so promising...

After a bit of trial and error, I got the Export to run. It was originally failing with a "failing to connect with the host" message. After getting the service GUID, I was able to successfully export the .xml file. I modified that file and tried the Import. The Import command fails, however, with "Object reference not set to an instance..." What this is saying, I think, is that the Import command needs a working, provisioned, DC service to connect to. Which I do not have.

Probably the same issue with 'Use-spcachecluster', which fails with the "the pipeline does not contain a command" error. Presumably, because there isn't a working, valid, cache cluster. It can't run unless the DC service is running.

So where does this leave me? I can remove/delete the DC service. I can even run the 'Add-SPDistributedCacheServiceInstance' and recreate one. But the hangup seems to be that any new service instance created still has the Old Server name embedded in the cluster configuration file. I wonder where it's getting that name from?

It's possible that re-running the Configuration Wizard would fix this, but this is my Production environment and I'd prefer not to take chances on a guess. The system is currently functional. Users are not experiencing any problems.

Unless there's a way to get the Import to work, I think the next step is to wait until my next maintenance window when I install the monthly CU. I'll take snapshots of the WFE and database servers in case the Config Wizard blows up, and then run the Wizard as part of the monthly update.
Vergil-V 14,765 Reputation points Microsoft External Staff Moderator

2026-06-05T09:37:56.42+00:00

Hi Keith Vollero
Thank you for sharing this update.

Based on your description, re‑running the Configuration Wizard does seem to be the most suitable approach at this stage, especially considering your environment is running in production, and the available references I found mainly apply to older SharePoint versions, which have already been mentioned and tried.

With that said, I am sorry that I was not able to find additional insight beyond the option you mentioned regarding re‑running the Configuration Wizard.

If you do proceed with this approach and notice any new findings, your update would be very valuable for others facing a similar situation. Please feel free to share it here.

Thank you again for your time and effort.
Keith Vollero 101 Reputation points

2026-06-05T11:10:20.92+00:00

Vergil -

I will keep banging away at this, and eventually I'll either fix it, or break it so badly that I'll have to rebuild the farm. Either way, the problem will get solved. I very much appreciate all the work you put in to helping me with this.

Thank you, and I will post updates as the situation changes.
Vergil-V 14,765 Reputation points Microsoft External Staff Moderator

2026-06-05T13:58:41.7333333+00:00

Hi Keith Vollero
Thank you for sharing.
I truly appreciate it.
For additional support, since you are using SharePoint Server SE which is still within the support lifecycle, you may consider reaching out through the following channel: https://engagecenter.microsoft.com/auth/login/

Please note that this is a paid support option, which means it requires an active support plan or a one‑time support purchase. However, the benefit of using this channel is that your request will be routed directly to the Microsoft engineering team responsible for the specific service or feature.

This team includes engineers and developers who work on the product itself, so they are best positioned to provide accurate, in‑depth, and authoritative guidance, especially for more complex or advanced scenarios that may go beyond publicly available documentation or community knowledge.

Answer 2

Keith Vollero 101

No luck following this procedure. The 'Add-SPDistributedCacheServiceInstance' command threw the following error:

"No such host is known"

User's image

0 comments

Answer 3

Renaming the SharePoint server leaves the old cache host registration in the farm, which causes the cacheHostInfo is null error. The ClusterConfig.xml file is generated from the farm configuration; it is not edited directly. The cache host must be removed and re‑added in SharePoint so that the configuration (and ClusterConfig.xml) is rebuilt with the new server name.

Use the supported repair sequence for a non‑functioning Distributed Cache host:

On the renamed SharePoint SE server, open SharePoint Management Shell as Farm Administrator.

Remove the Distributed Cache service instance:

   Remove-SPDistributedCacheServiceInstance

If this fails (common when the host name changed), manually delete the service instance and then re‑add it: For SharePoint Server Subscription Edition

   $instanceName = "SPDistributedCacheService Name=SPCache"
   
   $serviceInstance = Get-SPServiceInstance | ? { ($_.Service.ToString()) -eq $instanceName -and ($_.Server.Name) -eq $env:COMPUTERNAME }
   
   if ($serviceInstance -ne $null)
   {
       $serviceInstance.Delete()
   }

After this manual deletion completes, run again:

   Add-SPDistributedCacheServiceInstance

Verify in Central Administration → Application Management → Manage services on server that Distributed Cache is listed and its status is Started.

This process updates the farm’s cache configuration (including ClusterConfig.xml) to use the new server name; no direct editing of ClusterConfig.xml is required or supported.

Regarding AppFabric: in SharePoint Subscription Edition, the Distributed Cache implementation is different from SharePoint 2013–2019, so the legacy AppFabric Caching Service entry is not expected in Services. Management is done only through the SharePoint Distributed Cache cmdlets such as Add-SPDistributedCacheServiceInstance and Remove-SPDistributedCacheServiceInstance.

References:

Share via

Distributed Cache not working on a renamed SharePoint SE server

3 answers

Your answer