Der SharePoint Distributed Cache ist ein essentieller Bestandteil einer jeden SharePoint Farm. Allerdings wird der Distributed Cache ziemlich oft einfach vernachlässigt (Regelmäßige Installation von Updates etc.). Bei einer SharePoint 2016 Testinstallation (Single Server) ist nun das Problem aufgetreten, dass der SharePoint Distributed Cache nicht funktionierte. Es gab unzählige Fehlermeldungen in der Ereignisanzeige und ULS Logs. Der zugehörige Windows-Dienst lief immer nur für einen kurzen Moment und beendet sich wieder. Das ganze wiederholte sich in einer endlosen Schleife. Auch die Prüfung des Zustand des Distributed Caches mittels PowerShell bestätigte das Problem:
Use-CacheCluster Get-CacheHost
Hier wurde immer entweder der Status Unknown oder Down zurück geliefert.
Deshalb möchte ich euch heute gerne einmal zeigen, wie man einen fehlerhaften SharePoint Distributed Cache wieder zum laufen bekommt.
Connection String prüfen
Zuerst sollte man den Connection String zur SharePoint Konfigurationsdatenbank überprüfen. Dieser ist in der Datei DistributedCacheService.exe.config hinterlegt. Die Konfigurationsdatei liegt standardmäßig unter dem Pfad C:\Program Files\AppFabric 1.1 for Windows Server. Der interessante Teil liegt am Ende der XML-Datei und sollte so aussehen:
<configuration>
…
<dataCacheConfig cacheHostName="AppFabricCachingService">
…
<clusterConfig provider="SPDistributedCacheClusterProvider" connectionString="Data Source=*SQL-SERVER*;Initial Catalog=*SHAREPOINT-ConfigDB*;Integrated Security=True;Persist Security Info=False;Enlist=False;Pooling=True;Min Pool Size=0;Max Pool Size=100;Asynchronous Processing=False;Connection Reset=True;MultipleActiveResultSets=False;Replication=False;Connect Timeout=15;Encrypt=False;TrustServerCertificate=False;Load Balance Timeout=0;Packet Size=8000;Type System Version=Latest;Application Name=".Net SqlClient Data Provider";User Instance=False;Context Connection=False;Transaction Binding="Implicit Unbind";ApplicationIntent=ReadWrite;MultiSubnetFailover=False;ConnectRetryCount=1;ConnectRetryInterval=10;Column Encryption Setting=Disabled" />
Die beiden Variablen *SQL-SERVER* und *SHAREPOINT-ConfigDB* müssen natürlich an eure Umgebung angepasst werden. Bei *SQL-SERVER* nutzt ihr am besten einen entsprechenden SQL-Alias zu eurer Datenbank. Bei *SHAREPOINT-ConfigDB* muss die SharePoint Konfigurationsdatenbank eingetragen sein.
Service-Account ändern
Danach sollte man prüfen, ob der SharePoint Distributed Cache auch unter dem entsprechenden Service-Account ausgeführt wird. Nach den Best-Practices sollte immer ein Service-Account genutzt werden. Die Änderung funktioniert nicht über die Zentraladministration. Hier gibt es zwar den entsprechenden Punkt. Wenn man versucht eine Änderung vorzunehmen, bekommt man aber die Fehlermeldung, dass eine Änderung nur per PowerShell möglich ist. Danke SharePoint-Team 🙂 . Also machen wir es gleich über die PowerShell mit folgendem Skript:
$Farm=Get-SPFarm
$CacheService=$Farm.Services | Where {$_.Name -eq "AppFabricCachingService"}
$Accnt = Get-SPManagedAccount -Identity contoso\serviceAccount
$CacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$CacheService.ProcessIdentity.ManagedAccount = $Accnt
$CacheService.ProcessIdentity.Update()
In Zeile 3 muss natürlich der zu verwendete Service-Account angepasst werden. Und wunder euch nicht, die Änderung kann durchaus einige Minuten dauern, bis der Service-Account geändert ist.
Instanz neu anlegen
Danach können wir die fehlerhafte SharePoint Distributed Cache Instanz löschen und eine neue erstellen. Auch dies funktioniert am besten per PowerShell:
Remove-SPDistributedCacheServiceInstance Add-SPDistributedCacheServiceInstance
Auch das Hinzufügen der neuen Instanz dauert eine gewisse Zeit, wobei der eigentliche PowerShell Befehl wesentlich schneller ausgeführt ist. Am besten kann man den Vorgang der Erstellung kontrollieren, indem man den Prozess Microsoft(R) Windows(R) Server AppFabric kontrolliert. Während der Neuerstellung verbraucht der Prozess einiges an Arbeitsspeicher. Wenn alles bisher funktioniert hat, sollte der Windows-Dienst AppFabric Caching Service gestoppt sein und der im vorherigen Schritt hinterlegte Servive-Account eingetragen sein.
Cache Cluster Konfiguration prüfen
Von der neu erstellen SharePoint Distributed Cache Instanz sollte im nächsten Schritt nun die Konfiguration des Clusters überprüft werden. Das funktioniert auch wieder per PowerShell:
Use-CacheCluster Export-CacheClusterConfig C:\DistCacheConfig.xml
Der Pfad in Zeile 2 muss natürlich entsprechend der Umgebung angepasst werden. Das Ergebnis ist eine recht umfangreiche XML-Datei:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="dataCache" type="Microsoft.ApplicationServer.Caching.DataCacheSection, Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>
<dataCache size="Small">
<caches partitionCount="32">
<cache consistency="StrongConsistency" name="default" minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedAccessCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedActivityFeedCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedActivityFeedLMTCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="None" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedBouncerCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedDefaultCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedFileLockThrottlerCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedHealthScoreCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedLogonTokenCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedResourceTallyCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedSearchCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedSecurityTrimmingCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedServerToAppServerAccessTokenCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedSharedWithUserCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedUnifiedGroupsCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
<cache consistency="StrongConsistency" name="DistributedViewStateCache_fd19e192-0c52-4b8a-991e-f9746c53577c"
minSecondaries="0">
<policy>
<eviction type="Lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>
</caches>
<hosts>
<host replicationPort="22236" arbitrationPort="22235" clusterPort="22234"
hostId="1961847801" size="819" leadHost="true" account="*SERVICE-ACCOUNT*"
cacheHostName="AppFabricCachingService" name="*SERVERNAME*"
cachePort="22233" />
</hosts>
<advancedProperties>
<partitionStoreConnectionSettings leadHostManagement="false" />
<securityProperties mode="None" protectionLevel="None">
<authorization>
<allow users="WSS_ADMIN_WPG" />
<allow users="WSS_WPG" />
</authorization>
</securityProperties>
</advancedProperties>
<deploymentSettings>
<deploymentMode value="RoutingClient" />
</deploymentSettings>
</dataCache>
</configuration>
In Zeile 6 sollte die Größe auf Small geändert werden. In Zeile 7 die Partitionen auf 32 festlegen. Der Block von Zeile 8 bis 13 muss hinzugefügt werden, weil dieser in unserer Umgebung komplett gefehlt hat. In Zeile 122 sollte ebenfalls noch die Größe auf 819 festgelegt werden. In Zeile 122 und 123 kann ebenfalls noch einmal der Servername und der vorher eingetragene Service-Account geprüft und ggf. korrigiert werden. Und noch eine kleine Anmerkung zur angehängten GUID fd19e192-0c52-4b8a-991e-f9746c53577c. Diese ist bei euch natürlich eine andere, weil es sich hierbei um die SharePoint Farm ID handelt. Also sollte sich eure Farm ID von der aufgeführten ID unterscheiden, sollte man diese natürlich auch entsprechend korrigieren.
Nun müssen wir die angepasst Konfiguration nur noch wieder „einspielen“. Das funktioniert ähnlich zum Vorgehen des Exportierens:
Use-CacheCluster Import-CacheClusterConfig C:\DistCacheConfig.xml -Confirm:$false
Sollte der Import mit dem Fehler ErrorCode<ERRCAdmin001>:SubStatus<ES0001>:Hosts are already running in the cluster fehlschlagen, liegt es daran, dass der Windows-Dienst AppFabric Caching Service gerade mal wieder gestartet ist. Dann muss man einfach kurz warten, bis sich dieser wieder von selbst beendet.
Starten und Validieren
Ist die neue Konfiguration erfolgreich importiert, kann das Cache Cluster gestartet werden. Auch dies funktioniert wieder über die PowerShell:
Use-CacheCluster Start-CacheCluster
Nun muss man wie so häufig ein paar Minuten warten, danach sollte der SharePoint Distributed Cache aber wieder fehlerfrei funktionieren. Das kann man auch über die folgenden Befehle prüfen:
Use-CacheCluster Get-CacheClusterHealth Get-Cache
Ich hoffe, mit dieser Anleitung konntet ihr den SharePoint Distributed Cache wieder zum laufen bewegen. Wenn nicht, nutzt einfach die Kommentarfunktion.
In diesem Sinne, Happy SharePointing 🙂
Wie ist das Vorgehen bei einer Farm mit mehreren SP Servern?
Das Vorgehen ist eigentlich analog zu einem Server. Die XML-Konfiguration ist dann etwas umfangreicher, weil mehrere Server dort aufgeführt sind.
Hat alles wunderbar funktioniert und läuft auch noch 😀
Musste den User für DitributedCache auf 2 Server ändern
Vielen Dank
ein zufriedener (SP)Admin