Hyper-V Replica schlägt mit 0x00002EFD fehl

Kürzlich hatte ich ein ärgerliches Problem mit einem Setup für Hyper-V Replica. Eigentlich kann man bei dem Feature fast nichts falsch machen. Darum nervte mich das Problem auch besonders.

Wie immer, wenn man der Meinung ist, dass man das System eigentlich gut kennt, stößt man selbst natürlich auf die Situationen, in denen es nicht mal ordentliche Fehlermeldungen gibt. So auch hier: Beim Versuch, die Replikation für eine VM einzuschalten, meldete Hyper-V ganz am Ende (aber sofort nach dem Klick auf “Fertig stellen”):

Fehler beim Aktivieren der Replikation für den virtuellen Computer „MSC-Blanko“: Die Serververbindung konnte nicht hergestellt werden. (0x00002EFD). (ID des virtuellen Computers: 8CCFC631-4A0C-4454-8315-xxxyyyzzz)

Mit dem angegebenen Replikatserver „msc-hvreplica01.MSC.Demo“ kann keine Verbindung hergestellt werden. Fehler: Die Serververbindung konnte nicht hergestellt werden. (0x00002EFD). Vergewissern Sie sich, dass der angegebene Server als Replikatserver konfiguriert ist, dass eingehende Verbindungen am Port „80“ zugelassen werden und dass das gleiche Authentifizierungsschema unterstützt wird.

Wie sich herausstellte, gibt es zu der Fehlernummer 0x00002EFD nicht nur keine brauchbaren Fundstellen im Web. Nein, tatsächlich handelt es sich um einen Fehlercode, der allgemeiner kaum sein kann – er sagt nicht viel mehr aus als “ich kann keine Verbindung zur anderen Seite aufbauen und weiß nicht warum”.

Die Firewall war nicht Schuld. Tatsächlich hätte das die Ursache sein können, aber Hyper-V weist schon beim Einrichten der Replica-Server darauf hin, dass man eine entsprechende Ausnahme setzen muss. In der Windows-Firewall ist das dann auch sehr einfach, denn es gibt zwei fertige Regeln, die schon “Hyper-V Replikation” im Namen tragen und die man nur anschalten muss. Diese Regeln tun auch nichts weiter, als eingehenden TCP-Traffic auf Port 80 bzw. 443 zuzulassen – auch bekannt als HTTP bzw. HTTPS. Nur um sicherzugehen, schaltete ich die Firewall testweise ganz ab, das Problem blieb. OK, also Firewall wieder an.

Auch die Authentifizierung war nicht das Problem: Beide Hosts gehören derselben Domäne an, ich war auch auf beiden mit demselben Adminkonto angemeldet, um die Replikationsbeziehung einzurichten. Das AD arbeitete, wie es soll, IP-Adressen und DNS-Namensauflösung waren korrekt. Ein Zugriff per Telnet auf Port 80 auf dem “empfangenden” Host ergab, dass dieser antwortet und auch (anscheinend korrekte) HTTP-Antworten gibt.

Nur zur Vorsicht alle Server nacheinander neu gestartet (und wo nötig gleich fehlende Updates installiert) – keine Änderung.

Gut. Oder vielmehr: Nicht gut. Ich versuchte, dem System Genaueres zu entlocken. Dazu schaltete ich auf beiden Seiten das Analytic Log für den Hyper-V-Managementdienst ein. Das geht so:

• Ereignisanzeige starten.
• Im Menü “Ansicht” einschalten: “Analytische und Debugprotokolle einblenden”.
• Navigieren zum Zweig: Anwendungs- und Dienstprotokolle / Microsoft / Windows / Hyper-V VMMS. Dort gibt es nun ein Protokoll namens “Analytic”. Hierauf rechtsklicken und auswählen: “Protokoll aktivieren”.

Wichtig: Die Analytic and Debug Logs arbeiten anders als die normalen Eventlogs. Sie sammeln nur Daten, wenn man sie aktiviert, zeigen währenddessen aber nichts an. Erst wenn man sie deaktiviert, sieht man die gesammelten Daten. Das liegt daran, dass diese Logs schnell sehr viele Daten produzieren, sodass man sie nur sammeln lässt, wenn man konkrete Tests ausführt. Niemals “einfach so” aktiviert lassen!

• Dasselbe auf dem anderen Server wiederholen.
• Nun den fehlerhaften Vorgang ausführen, hier also: Versuchen, die Replikation für eine VM einzurichten.
• Nachdem der Fehler aufgetreten ist: Auf beiden Seiten Rechtsklick auf das Protokoll “Analytic” und auswählen “Protokoll deaktivieren”.
• Nun sollte das Protokoll seine Daten anzeigen. Zeigt es nichts, dann gab es nichts zu sammeln. In meinem Fall sah ich auf dem “sendenden” Host einige Einträge, auf dem “empfangenden” keine. Schon hier also ein Beleg, dass beim Empfänger überhaupt nichts ankommt.

In den ausführlichen Protokollen fand ich gleich zu Beginn interessante Einträge:

[FrnHttpClient::SetupConnection (frnhttpclient.cpp:247)] Send Request (GET) failed: unknown error (0x80072efd)

Das klingt, als würde tatsächlich schon der erste Versuch fehlschlagen, per HTTP eine Verbindung zur Gegenseite aufzubauen. Zur Überprüfung schlug ich den Fehlercode 0x80072efd nach – hier hilft das kleine Tool err.exe, das sich bei Microsoft herunterladen lässt (es nennt sich zwar “Exchange Server Error Code Look-up”, hat aber eigentlich mit Exchange nichts zu tun):

[Download Microsoft Exchange Server Error Code Look-up from Official Microsoft Download Center]
https://www.microsoft.com/en-us/download/details.aspx?id=985

Der Aufruf “err.exe 0x80072efd” ergab allerdings nichts wirklich Neues: “ERROR_INTERNET_CANNOT_CONNECT” – gut, das wusste ich mittlerweile.

Wenn aber die Netzwerkverbindung funktioniert, die Anmeldung auch, und sogar per Telnet der angefragte Port anscheinend korrekt erreichbar ist – was könnte dann noch dazwischenfunken?

Auf so eine Frage gibt es immer einen Generalverdächtigen: Der Virenscanner. Tatsächlich lief auf beiden Seiten ein solcher, das konkrete Produkt tut hier nichts zur Sache.

Also den Virenscanner auf der “Empfangsseite” abgeschaltet (naja, in Wirklichkeit: abgeschossen, denn auf dem normalen Weg wollte er sich nicht abschalten lassen). Ergebnis: Geht immer noch nicht.

Eigentlich nur noch versuchshalber den Virenscanner auch auf der “Senderseite” abgeschossen: Siehe da, plötzlich ging’s, und die Replikation ließ sich einrichten.

Fazit

Am Ende bleibt die Erkenntnis: Wenn man einen Virenscanner auf einem Server einsetzt, dann muss man ihn auch richtig konfigurieren. Und man muss auf die Idee kommen, dass der Virenscanner überhaupt beteiligt sein könnte. Was auch immer das Ding getan hat – zum Zeitpunkt des Fehlers waren keine Dateien beteiligt, sondern es schlug ein Client-HTTP-Zugriff fehl. Anscheinend hielt der Scanner es für eine gute Idee, dort einzugreifen – war aber keine gute Idee.

Daneben habe ich hier einige Hilfsmittel gezeigt, unspezifischen Fehlern doch noch auf die Spur zu kommen.

Und, ganz wichtig: Wenn man eine Änderung versucht hat und diese nichts bringt, dann sollte man diese wieder rückgängig machen (in meinem Beispiel etwa: die abgeschaltete Firewall wieder einschalten) – es sei denn, man ist sich sicher, dass man diese Änderung beibehalten will und dokumentiert dies auch.