Windows Server: iSCSI-Verbindungsproblem dank Windows Update

Heute noch ein kurzer Blog-Beitrag in Sachen Windows Server. Scheinbar laufen Nutzer in ein iSCSI-Verbindungsproblem und in der Ereignisanzeige taucht die Event ID 4231 auf. Im dümmsten Fall geht dann auf dem Server nichts mehr. Ursache scheinen ein verunglücktes Update und eine Fehlkonfigurierung der Portbelegung zu sein.

Der Hinweis stammt von Blog-Leser Stefan F. – Stefan lief auf ein Problem, welches er in einer Mail folgendermaßen umschreibt:

… dass wenn eine iSCSI Anbindung auf „Versuche zu Verbinden" steht, ich nach einer Weile keinen Zugriff mehr hatte auf einen Server. Microsoft hatte ja in dem Beitrag bestätigt, dass ein Patch auf sich warten lässt. Habe auch ein paar Kollegen die genau dasselbe hatten, aber nicht so genau wussten woran es lag.

Eine kurze Erklärung: Er versucht unter Windows Server auf iSCSI-Geräte zuzugreifen. Steht die Meldung Versuche zu Verbinden an, scheitert der Zugriff auf dieses Gerät irgendwann. Und es scheint kein Einzelfall zu sein.

Fehlerdetails im Technet-Forum

Stefan lieferte diesen Link zum Technet Forenbeitrag Ephemeral port exhaustion – Event ID 4231 in der E-Mail mit. Dort thematisiert ein Benutzer den Fehler, der sich mit dem Ereigniseintrag mit der ID 4231 bemerkbar macht.

"A request to allocate an ephemeral port number from the global TCP port space has failed due to all such ports being in use."

Im betreffenden Fall traf dies bei ihm auf mehreren Servern zu. So funktionierte plötzlich ein Veeam Backup nicht mehr, weil kein Zugriff auf das Gerät möglich war. Drucker konnten auf Windows Server 2012 R2 nicht mehr angesprochen werden, RDP zum Server scheitert irgendwann und so weiter.

Ein Neustart bringt zwar Abhilfe – bei einem Server nicht immer möglich – und der Fehler tauchte nach Angaben des Benutzers nach 2 Tage im Mittel wieder auf. Es wird gemeldet, dass die freien Ports ausgegangen wären. Andere Benutzer hatten die Fehler nach 15 Minuten und einige berichteten, dass sich der Server irgendwann ganz aufhängt und nicht mehr bedienbar sei.

Erklärung der Ursache im Technet-Forum

Im gleichen Technet-Beitrag wird auch die Ursache benannt. Das Problem tritt wohl unter Windows Server 2012 R2 und Windows Server 2016 in Clustern auf. In einem Log kristallisierte sich heraus, dass möglicherweise ein Port von mehreren Prozessen belegt wird.

Emmanuel Paré führt aus, dass der Server einen Verbindungsversuch durchführt und ephemeral Ports (dynamische Ports) durchprobiert. Die Verbindungsversuche werden mehrfach durchgeführt, bis alle Ports belegt sind – dann wird das Ereignis ausgelöst.

Ich habe in diesem Technet-Thread von 2014 ebenfalls den Hinweis gefunden, dass bei Windows Server 2012 R2 dynamische Ports ausgehen, obwohl dies nicht passieren dürfte. Und dieser Technet-Beitrag befasst sich mit der Erkennung von Port-Exhaustion. Nur als Zusatzinformation.

Die Leute um Emmanuel Parè konnten das Problem im Labor nachstellen. Er erwähnt, dass Microsoft das Problem kennt und an einem Fix arbeite. Er vermutet, dass das konkrete Problem wohl durch einen 'April-Patch' hervorgehoben werden könnte.

Der Ursprungsposter bestätigte dann auch, dass redundante Pfade zu iSCSI-Geräten für das Problem verantwortlich seien. Durch Entfernen der redundanten Pfade werde das Problem behoben.

Ein Fix kommt, schmutziges Workaround

Benutzer Dave Hallwas hat, in Zusammenarbeit mit dem Microsoft-Support, einige Details im Forenthread gepostet.

• Microsoft arbeitet an einem Fix, der aber wohl nicht vor dem July Update Preview (3. Juli-Woche) freigegeben wird.
• Bis dahin gibt es nur einen 'schmutzigen' Workaround, indem alle zuletzt installierten kumulativen Updates und Update Rollups bis zum März 2017 wieder deinstalliert werden.

Im konkreten Fall für ein Cluster aus Windows Server 2016 Maschinen konnte er Update KB4022715 identifizieren. Allerdings löste die Deinstallation des Updates auf einer Maschinen sofort einen Blue Screen aus. Insgesamt also eine etwas unschöne Situation. Vielleicht hilft es dem einen oder anderen Betroffenen aber als erster Ankerpunkt weiter. Mein Dank gilt Blog-Leser Stefan F. (auch danke für den Link).