Zugriffsfehler bei einem Scale-Out File Server Cluster – Error 0x80090322
Wir hatten bei einem Kunden vor kurzem eine geplante Neuinstallation der beiden Hardware Server in einem Scale-Out File Server Cluster. Bei diesem Vorgang sollte der erste Server in den Wartungsmodus gesetzt werden, danach mit einem neuen OS ausgestattet werden und letztendlich wieder in das bestehende Cluster aufgenommen werden. Der Wartungsmodus auf dem ersten Server hat problemlos funktioniert, alle Datenträger, der Pool, die Rolle und die Core Cluster-Ressourcen wurden erfolgreich auf den zweiten Server übernommen und die Neuinstallation konnte beginnen.
Nachdem der Server A wieder mit Windows Server 2012 R2 installiert war, begann die Installation der Updates und die Einrichtung von Netzwerk und was sonst noch so alles anfällt. Zum Schluss wurde der Server wieder (erfolgreich) in das Failover Cluster aufgenommen, zuvor wurde ein Test gegen Server B gemacht, allerdings ohne den Speichertest, da dieser die Speicher-Ressourcen temporär offline genommen hätte.
Als nächsten Schritt habe ich nun Server B in den Wartungsmodus gesetzt und kurz gewartet, bis alle Ressourcen verschoben wurden. Dies hat auch problemlos und fehlerfrei funktioniert, allerdings hat nach kurzer Zeit das Monitoring angeschlagen und gemeldet, dass einige VMs nicht mehr erreichbar sind. Nach einem kurzem Blick auf das Hyper-V Cluster zeigte sich, dass dort einige Fehler auftauchten und das einige VMs nicht mehr liefen. Ich habe dann den Storage-Knoten B wieder in den Betriebsmodus genommen und sämtliche Ressourcen wieder auf Server B geschwenkt, danach war ein Zugriff von Hyper-V wieder möglich und die VMs wurden durch das Failover Cluster wieder online geschaltet.
Wir haben danach noch diverse weitere Fehler bekommen bei unterschiedlichen Tätigkeiten. Das anlegen von einem Share zum Beispiel wurde mit dem folgenden Fehler abgeschlossen:
WinRM cannot process the request. The following errir with error code 0x80090322 occured while using Negotiate authentication: An unknown security error occured.
Beim auslesen von den aktuellen Share-Informationen gab es zusätzlich die folgende Fehlermeldung:
Error retrieving SMB share information: WinRM cannot process the request. The following error with error code 0x80090322 occurred while using Negotiate euthentication: An unknown security error occurred.
Im Eventlog traten noch weitere Fehler auf, die in Richtung Kerberos hinweisen:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server Computername$. The target name used was HTTP/computername$. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. (...)
Nach einer Ausgabe und Überprüfung der SPNs im Active Directory des Kunden und einem Vergleich zu unseren SOFS-Objekten gab es keine Unterschiede, ein bisschen komisch ist allerdings der Eintrag, der auf einen fehlenden HTTP-Eintrag verweist. Nach einer kurzen Suche habe ich eine Seite gefunden, die genau diesen Fehler beschreibt:
https://nocentdocent.wordpress.com/2014/12/29/sofs-logical-configuration-reference/
Im unteren Teil des Artikels findet sich unter Known issues die Lösung für unser Problem. In das SOFS-Objekt muss ein neuer SPN eingetragen werden mit dem folgenden Befehl:
Setspn -A http/<<SOFS DistributedNetworkName fqdn>> <<SOFS DistributedNetworkName>>
Beispiel:
setspn -a ldap/sofs.contoso.com sofs
Nach einer Eintragung von diesem Wert war ein Schwenk der Ressourcen von Server B auf Server A wieder problemlos möglich, es gab keinerlei Fehler mehr und die Hyper-V Hosts konnten problemlos auf alle Shares zugreifen. Das anlegen von einem neuem Share war auch problemlos möglich, ebenso der Aufruf von vorhandenen Freigaben.
Interessant finde ich, dass dieser Eintrag bisher in keiner unserer Umgebungen (bzw. in den Kunden-Umgebungen) benötigt wurde und ich auch bei einer Neuinstallation bzw. einem Wechsel der Knoten dieses Problem bisher nie hatte. Ich habe die Neuinstallation bzw. den Austausch von Knoten bisher schon bestimmt zehn Mal oder mehr gemacht, weiterhin ist dieser Weg auch der empfohlene Weg bei einem Upgrade auf Windows Server 2016, Stichwort Rolling Cluster Upgrade. Durch diesen kleinen Eintrag im Computerobjekt der SOFS-Rolle wurde das Problem gelöst, das zählt :)
