Ist PowerShell Direct im „freien“ Hyper-V Server 2019 nur eingeschränkt nutzbar?

[maddinx6 0]

Hallo,

ich bin auf der Suche nach Informationen bezüglich PowerShell Direct auf dem „freien“ Hyper-V Server 2019. Scheinbar ist diese Funktion nur eingeschränkt verfügbar. Ideal wäre eine Quelle von MS.

 

Hintergrund der Frage.

Ich komme vom Veeam Backupserver mittels Enter-PSSession -ComputerName auf den Hyper-V Server und von da aus mit Enter-PSSession -VMName in die VM. Veeam kann aber nicht über PowerShell Direct in die VM „ohne LAN“ schreiben, wen der Hyper-V Host die freie 2019er Version ist. So weit bin ich mit dem Veeam Support gekommen. Mir stellt sich jetzt die Frage, ob das eine Beschränkung Seitens MS.

 

[cj_berlin 1.306]

Moin,

ohne zu wissen, wie Veeam das macht, wäre mir die Beschränkung neu, was nichts heißen soll.

Sanity Check:

1. ist "Guest Services" unter "Integration Services" für diese VM aktiviert?
2. (falls JA zu 1.): kannst Du vom Host aus (RDP, *nicht* PowerShell Remoting) eine PowerShell Direct-Session mit expliziten Credentials zu dieser VM starten?
3. (falls JA zu 2.): kannst Du aus einer PowerShell Remoting-Session zum Host eine PowerShell Direct-Session mit expliziten Credentials zu dieser VM starten?

 

[q617 1]

Warum denn kein Server 2022?

[maddinx6 0]

vor 18 Stunden schrieb cj_berlin:

Moin,

ohne zu wissen, wie Veeam das macht, wäre mir die Beschränkung neu, was nichts heißen soll.

Sanity Check:

1. ist "Guest Services" unter "Integration Services" für diese VM aktiviert?
2. (falls JA zu 1.): kannst Du vom Host aus (RDP, *nicht* PowerShell Remoting) eine PowerShell Direct-Session mit expliziten Credentials zu dieser VM starten?
3. (falls JA zu 2.): kannst Du aus einer PowerShell Remoting-Session zum Host eine PowerShell Direct-Session mit expliziten Credentials zu dieser VM starten?

 

 

Moin,

wenn ich dich richtig verstanden habe, kann ich alle drei Punkte mit ja beantworten.

vor 18 Stunden schrieb maddinx6:

 

Ich komme vom Veeam Backupserver mittels Enter-PSSession -ComputerName auf den Hyper-V Server und von da aus mit Enter-PSSession -VMName in die VM.

Mir ist vorhin der gedackte gekommen das es evtl. einfach an der core ähnlichen Installation liegen könnte. Ich Test jetzt mal ob es mit einem Server std als core installiert läuft.

[cj_berlin 1.306]

vor 1 Minute schrieb maddinx6:

wenn ich dich richtig verstanden habe, kann ich alle drei Punkte mit ja beantworten.

Dann funktioniert ja alles  Mehr Funktionalität geben PowerShell Remoting und PowerShell Direct nicht her. Wenn Veeam versucht, die PowerShell Direct-Verbindung mit *impliziten* Credentials herzustellen, dann gibt es hier gleich zwei Probleme, und keines davon hat mit der Edition des Hosts zu tun.

[maddinx6 0]

vor 17 Stunden schrieb q617:

Warum denn kein Server 2022?

Gibt es jetzt doch einen Hyper-V Server 2022 in der kostenlosen Version? Bisher bin ich davon ausgegangen, dass der Nachfolger azure stack hci „Abo Version“ ist.

Azure Stack HCI 

vor 9 Minuten schrieb cj_berlin:

Dann funktioniert ja alles  Mehr Funktionalität geben PowerShell Remoting und PowerShell Direct nicht her. Wenn Veeam versucht, die PowerShell Direct-Verbindung mit *impliziten* Credentials herzustellen, dann gibt es hier gleich zwei Probleme, und keines davon hat mit der Edition des Hosts zu tun.

 

Im Veeam Log bekomme ich diese Fehlermeldung. Kann es evtl. auch etwas mit dem invoke zu tun haben?

Cannot connect to VM over PSDirect. Guest Login: [demo\administrator].;Failed to invoke func [Connect]: Unknown error 0x80131500. Unknown error 0x80131500. PowerShell 2.0 or later is required

bearbeitet 9. August 2023 von maddinx6

[cj_berlin 1.306]

vor 8 Minuten schrieb maddinx6:

Gibt es jetzt doch einen Hyper-V Server 2022 in der kostenlosen Version? Bisher bin ich davon ausgegangen, dass der Nachfolger azure stack hci „Abo Version“ ist.

Nein, gibt es nicht.

Und nein, Azure Stack HCI ist *nicht* der Nachfolger des Hyper-V Servers, auch wenn es inzwischen eine 1-Box-Version davon gibt.

vor 9 Minuten schrieb maddinx6:

Guest Login: [demo\administrator]

Heißt die VM mit ihrem Windows-Namen "DEMO"? Ohne Netzwerk kann sie ja schwerlich in einer AD-Domäne sein. Und wenn es das gleiche Credential ist, das Du manuell probiert hast, muss Veeam das troubleshooten, denn scheinbar liegt das Problem nicht im Aufruf selbst (denn Du kannst ihn ja tätigen), sondern darin, wie Veeam diesen Aufruf in den eigenen Code verpackt.

[maddinx6 0]

Ich habe mir zusätzlich eine kleine Testumgebung aufgebaut. Die Domain dieser heißt demo 😉

 

Hintergrund des ganzen ist ein meines Erachtens gravierender Fehler im File Level Restore (FLR) von Veeam. Ich versuche das mal zu beschreiben.

 

Gesichert wird VM1 auf Host1. Diese wird anschließend auf Host2 zurück gesichert. Das klappt so weit. Die VM1 hat keine verbundene LAN-Schnittstelle auf Host2 zugewiesen bekommen.
Wenn ich jetzt ein FLR-Job einer Datei aus dem Backup von VM1 in die VM1 Kopie auf Host2 mache, beginnt der Spaß.

 

In der Veeam Konsole wird der Job als erfolgreich abgeschlossen dargestellt. Datei xyz in VM1 auf Host2 wiederhergestellt. Die Datei wird aber in VM1 auf Host1 geschrieben!
Das liegt daran das Veeam beim Restore grundsätzlich immer erst versucht die Datei über Lan direkt in die VM zu schreiben. Wenn jetzt, wie im meinem Fall VM1 auf Host1 antwortet wird in diese zurückgesichert, ohne zu beachten das mein FLR-Job auf Host2 verweist…

 

Wenn VM1 auf Host1 ebenfalls nicht über LAN erreichbar ist, wird er Job wie angegeben abgearbeitet. Hierfür wird dann PowerShell Direct benutzt. Man kann mittels Reg-Key Veeam dazu nötigen PowerShell Direct bevorzugt zu nutzen, um das Fehlverhalten zu umgehen. Leider klappt der Restore via PowerShell Direct grundsätzlich nicht wenn das Host2 OS Hyper-V Server 2019 ist. 

 

[cj_berlin 1.306]

Von Deiner langen Ausführung abgesehen: ein Domain Member ohne Netz wird die Verbindung mit einem Domain-Konto nicht authentifizieren können.

[Dukel 451]

Nach einer Google Suche kann es sein, dass man Powershell v2.0 nachinstallieren muss.

[maddinx6 0]

vor einer Stunde schrieb cj_berlin:

Von Deiner langen Ausführung abgesehen: ein Domain Member ohne Netz wird die Verbindung mit einem Domain-Konto nicht authentifizieren können.

Ist etwas länger geworden. Aber hoffentlich verständlich 😉

Hmm, ich habe mich aber mit genau diesem Konto angemeldet via Enter-PSSession -VMName angemeldet?

bearbeitet 9. August 2023 von maddinx6

[cj_berlin 1.306]

Gerade eben schrieb maddinx6:

Hmm, ich habe mich aber mit genau diesem Konto angemeldet via Enter-PSSession -VMName angemeldet?

 

Mag sein, dann war das lokale Admin-Kennwort entweder dasselbe, oder dieser User war dort schon angemeldet und Credentials wirden zwischengespeichert. Beides aus Security-Sicht schlecht.

 

Aber ich denke, wir haben hinreichend gut festgestellt, dass der Fehler bei Veeam liegen muss und damit in deren fähige Hände gehört  

[maddinx6 0]

vor 8 Minuten schrieb cj_berlin:

Mag sein, dann war das lokale Admin-Kennwort entweder dasselbe, oder dieser User war dort schon angemeldet und Credentials wirden zwischengespeichert. Beides aus Security-Sicht schlecht.

 

Aber ich denke, wir haben hinreichend gut festgestellt, dass der Fehler bei Veeam liegen muss und damit in deren fähige Hände gehört  

Ist halt eine Testumgebung. Quick and dirty

Dieser Meinung bin ich auch. Aber die wollen sich diesem Thema nicht so recht annehmen. Ich bin da schon seit über einer Woche dran mit denen…
Mit dem geht nicht auf Hyper-V Server 2019 könnte ich leben. Aber das der Restore einfach in einer anderen VM auf einem anderen Host landet geht meiner Meinung nach gar nicht.

 

Vielen Dank für dein Unterstützung.

vor 54 Minuten schrieb Dukel:

Nach einer Google Suche kann es sein, dass man Powershell v2.0 nachinstallieren muss.

 

Das klingt fast zu einfach. Muss ich mir mal anschauen. Ich bin davon ausgegangen das 5.1 passt wegen des Log Eintrags „PowerShell 2.0 or later is required“

[maddinx6 0]

Moin,
Dukels Tipp war die Lösung des Problems. Vielen Dank nochmal dafür.
Ich bin aufgrund des Logeintrags „PowerShell 2.0 or later is required“ davon ausgegangen das die installierte 5.1 ausreicht.

 

Merkwürdig ist allerdings das Powershell 2.0 nur beim Hyper-V Server 2019 benötigt wird. Standard und Datacenter mit und ohne Desktopdarstellung benötigen das nicht.

bearbeitet 10. August 2023 von maddinx6

[cj_berlin 1.306]

Nein, der Tip war die Verschlimmerung des Problems. PowerShell 2.0 sollte 2023 nicht mehr betrieben werden, Veeam muss das dringend lösen, bevor die Leute anfangen PS 2.0 auf modernen Systemen zu aktivieren.

bearbeitet 10. August 2023 von cj_berlin