Windows Failover Cluster Service: Fehler beim Aktualisieren einer SMB-Freigabe

Dieser Beitrag erschien zuerst auf Bents Blog.

Mit Hilfe eines Windows Failover Clusters können unterschiedliche Dienste bzw. Rollen hochverfügbar angeboten werden. Mit jeder Windows Version wurden dabei die Funktionen und technischen Möglichkeiten verbessert. Bei einem Kunden hatte ich die Aufgabe einen bestehenden Windows Cluster für Dateifreigaben (SMB) basierend auf Windows Server 2003 durch einen aktuellen Windows Server 2012 R2 Failover Cluster abzulösen. Da die Dateifreigaben für Benutzer-Profilverzeichnisse und andere Daten bereitgestellt werden sollte, kam die bekannte Dateifreigabe ohne horizontale Skalierung in Frage, da keine virtuellen Maschinen auf den Freigaben gespeichert werden sollten und die Ressourcen-Manager für Dateiserver für das Quota-Management zum Einsatz kommen sollte.

Nicht zuletzt durch eine großzügige Planung und genaue Vorbereitung verliefen die Installation der Cluster-Knoten, die Anbindung des Speichersystems, die Einrichtung des Clusters und die Einrichtung der ersten Dateifreigabe problemlos. Alle anschließenden Tests waren erwartungsgemäß erfolgreich.

Problem

Etwa zwei Wochen später meldete der Kunde, dass er an dem Cluster keine weiteren Freigaben erstellen und die Eigenschaften der bestehenden Freigabe nicht mehr verändern konnte. Der Wizard meldete bei der Erstellung einer neuen Freigabe den folgenden Fehler:

Fehler beim Aktualisieren einer SMB-Freigabe: Für diesen Vorgang müssen sich die Ressourcen in demselben Knoten im Onlinemodus befinden.

Bei einem weiteren Versuch, den Wizard für die Erstellung einer neuen Freigabe aufzurufen, wurde der folgende Fehler bei der Ermittlung der Serverkonfiguration gemeldet:

WinRM kann die Anforderung nicht verarbeiten. Bei der Verwendung der Negotiate-Authentifizierung ist der folgende Fehler mit dem Fehlercode 0x8009030e aufgetreten: Eine angegebene Anmeldesitzung ist nicht vorhanden. Sie wurde gegebenenfalls bereits beendet.

Da ich vor Ort nach intensiver Untersuchung zu keinem Ergebnis kam, entschloss ich mich, die Umgebung in unserem Labor virtualisiert nachzustellen.

Ursache

Glücklicherweise konnte ich das Verhalten in meiner virtuellen Testumgebung exakt nachstellen. Genau wie bei der Installation beim Kunden aktivierte ich nach Fertigstellung des Clusters die Funktion Cluster Aware Updating (CAU), die seit dem Windows Server 2012 für eine automatisierte Installation der Windows Updates sorgt und dabei die geschützten Cluster-Ressourcen automatisch auf den jeweils verbleibenden, aktiven Clusterknoten verschiebt.

Genau wie beim Kunden musste ich für den Internetzugriff einen Proxy-Server verwenden. Da der CAU-Prozess als System ausgeführt wird, muss die Proxy-Konfiguration auf allen Clusterknoten auf Kommandozeile mit folgendem Befehl erfolgen:

netsh winhttp set proxy <proxy-server:port> “<local>”

Diese Konfiguration erfolgte nach den Best Practices von Microsoft, daher hatte ich beim Kunden keinerlei Gedanken in diese Richtung verschwendet. Nach dieser Einstellung, allen installierten Windows Updates und den Neustarts der Clusterknoten verhielt sich mein Cluster allerdings genauso merkwürdig wie der des Kunden, ich erhielt dieselben Fehlermeldungen.

Lösung

Nach kurzer Untersuchung hatte ich letztlich die Ursache identifiziert. Der Failover-Cluster nutzt für verschiedenste Konfigurations- und Prüfungsvorgänge das Windows Remote Management (WinRM). Da die Aufrufe über HTTP (bzw. HTTPS) erfolgen, kommt hier natürlich die Proxy-Einstellung zum Zuge. In der obigen Einstellung werden lokale Adressen (<local>) zwar von der Proxy-Nutzung ausgeschlossen, allerdings wirkte erst der folgende expliziete Ausschluss für lokale Adressen und die Clusterknoten:

netsh winhttp set proxy <proxy-server:port> “<local>;*.kundendomain.tld;<clusternode1>;<clusternode2>”

Im Anschluss funktionerte die Erstellung einer neuen SMB-Freigabe fehlerfrei und der Cluster verhielt sich wieder normal und wie erwartet.