Wie sich mit PowerShell Direct VMs Remote verwalten lassen

Mit PowerShell Direct beginnen

PowerShell Direct erfordert Windows PowerShell 5.1 oder höher. Es gibt eine Reihe weiterer Bedingungen, um PowerShell Direct zur Verwaltung von VMs auf einem Hyper-V-Host zu verwenden:

• Auf dem Hyper-V-Host muss Windows Server 2016 oder neuer oder Windows 10 (Creators Edition oder höher) ausgeführt werden.
• Man muss am Hyper-V-Host als Hyper-V-Administrator angemeldet sein.
• Die VM muss entweder Windows 10 (Creators Edition oder höher) oder Windows Server 2016 oder höher sein.
• PowerShell muss 5.1 oder höher sein.
• PowerShell muss mit erhöhten Berechtigungen ausgeführt werden.
• Die zu verwaltende virtuelle Maschine (VM) muss sich auf dem lokalen Hyper-V-Host befinden und ausgeführt werden.
• Man benötigt die Anmeldeinformationen auf der VM.

PowerShell Direct ist nicht für die Verbindung mit Linux-VMs verfügbar, aber man kann hvc.exe verwenden, um eine Verbindung mit einer Linux-VM über SSH über den VMBus herzustellen.

Wenn man über ein Cluster von Hyper-V-Hosts verfügt, kann man sich nur mit PowerShell Direct auf dem Host, an dem man angemeldet ist, mit VMs verbinden. Wenn eine VM auf einem anderen Host ausgeführt wird, muss man WSMan-basiertes PowerShell Remoting in Windows PowerShell 5.1 und PowerShell Core 6.0 und höher, SSH-basiertes Remoting in PowerShell Core 6.0 und höher verwenden oder die VM auf den Host verschieben, auf dem man sich befindet.

So arbeitet man mit PowerShell Direct

Bei einer Standard WSMan-basierten PowerShell-Remoting-Sitzung gibt man den Computernamen an, mit dem man sich verbinden möchte. In PowerShell Direct verwendet man den Namen der VM oder die VMId:

Get-VM W16AS01 | Format-List VMname, VMId

VMName : W16AS01

VMId : 2a1eabc2-e3cd-495c-a91f-51a1ad43104c

Die VMId ist eine GUID. Diese erfordert mehr Arbeit für die richtige Eingabe als der VM-Name. Wenn der Name der VM nicht mit dem Namen der Maschine innerhalb der VM übereinstimmt, sollte man sicherstellen, dass man den VM-Namen und nicht den Computernamen verwendet.

Die folgenden Befehle erstellen eine Remote-Sitzung für eine virtuelle Maschine:

$cred = Get-Credential -Credential manticore\richard

$s = New-PSSession -VMName W16AS01 -Credential $cred

$s1 = New-PSSession -VMId '2a1eabc2-e3cd-495c-a91f-51a1ad43104c' -Credential $cred

$s2 = New-PSSession -VMGuid '2a1eabc2-e3cd-495c-a91f-51a1ad43104c' -Credential $cred

Wenn man keine Anmeldeinformationen angibt, wird man aufgefordert, diese einzugeben. VMGuid ist ein Parameter-Alias für VMId.

Nach dem Einrichten einer Sitzung kann man folgende Verwaltungsaufgaben ausführen:

Invoke-Command -Session $s -ScriptBlock {Get-Process}

Die folgenden Cmdlets haben einen -VMname- und einen -VMid-Parameter: Enter-PSSession, Get-PSSession, Invoke-Command, New-PSSession und Remove-PSSession.

Sie können den Invoke-Command direkt für die VM verwenden, ohne eine Remote-Sitzung zu erstellen:

Invoke-Command -VMName W16AS01 -ScriptBlock {$env:COMPUTERNAME} -Credential $cred W16AS01

Man muss beachten, die Anmeldeinformationen für den Computer bei jeder Verwendung des Invoke-Command anzugeben, wenn man keine Remote-Sitzung erstellt hat.

Ein Punkt, auf den viele neue PowerShell-Anwender treffen, ist das zweite Hop-Problem (Double Hop) bei PowerShell Remoting. Folgender Befehl hilft hierbei:

Invoke-Command -ComputerName W16AS01 -ScriptBlock {Invoke-Command -ComputerName W16DC01 -ScriptBlock {$env:COMPUTERNAME}}

In diesem Fall verbindet sich der Administrator mit einer entfernten Maschine und versucht dann, einen Befehl für eine andere Remote-Maschine auszuführen, also einen Double Hop. Das Problem ist, dass Active-Directory-Domänen Kerberos zur Verwaltung der Authentifizierung verwenden, und Kerberos es nicht zulässt, dass Anmeldeinformationen an den ersten Remote-Computer delegiert werden, um sie für den Zugriff auf den zweiten Computer zu verwenden.

Der Anmeldeversuch schlägt fehl. Man kann dies lösen, indem man Credential Security Support Provider verwendet, um die Anmeldeinformationen zu delegieren. Ein besserer Ansatz ist allerdings, vorausschauend zu planen, um einen Double Hop zu vermeiden.

PowerShell Direct erlaubt den Double Hop, da es nicht den WSMan-Kerberos-Ansatz verwendet, der das Delegationsproblem vermeidet.

Invoke-Command -Session $s -ScriptBlock {Invoke-Command -ComputerName W16DC01 -ScriptBlock {$env:COMPUTERNAME}}

W16DC01

Invoke-Command -Session $s -ScriptBlock {Get-ADuser -Identity Richard}

PSComputerName  : W16AS01

RunspaceId    : 8351563d-57f6-4af6-aa77-ba00aa48490d

DistinguishedName : CN=Richard,CN=Users,DC=Manticore,DC=org

Enabled      : True

GivenName     : Richard

Name       : Richard

ObjectClass    : user

ObjectGUID    : 9b2b7185-15d2-4014-bc2c-41b04f5f6198

SamAccountName  : Richard

SID        : S-1-5-21-759617655-3516038109-1479587680-1104

Surname      :

UserPrincipalName : [email protected]

Man kann sich auch über eine PowerShell-Direct-Verbindung mit einer VM verbinden und Remote arbeiten. Für dieses Tutorial wird PowerShell Core 6.0.1. verwendet.

Als erstes muss man Anmeldeinformationen abrufen, die man für den Remote-Computer benötigt. PowerShell Core enthält nicht das Hyper-V-Modul, so dass man es in die PowerShell-Sitzung importieren muss. Das Hyper-V-Modul wird in PowerShell Core ausgeführt.

Die Standardkonfiguration von PowerShell Core 6.0 enthält die Windows-PowerShell-5.1-Module nicht auf dem Modulpfad, so dass automatisches Laden aktiviert ist. Benutzer hatten seit der Veröffentlichung von PowerShell Core 6.1 im September 2018 sechs Monate Zeit, um von PowerShell Core 6.0 aufzurüsten, um weiterhin Support zu erhalten.

Als nächstes erstellt man die Sitzung auf dem Remote-Computer. Wenn man bereits eine bestehende Sitzung hat, kann man diese eingeben. Zum Beispiel:

Enter-PSSession -Session $s

[W16AS01]: PS C:\Users\Richard\Documents>

In beiden Fällen ändert sich die Eingabeaufforderung, um den VM-Namen aufzunehmen. Man kann dann interaktiv arbeiten, als wäre man an der entfernten Maschine angemeldet. Über Exit-PSSession kann man die PowerShell-Remote-Sitzung verlassen.

Auf die Versionen von PowerShell Core achten

Wenn man PowerShell Direct verwendet, verbindet man sich standardmäßig mit der Windows-PowerShell-5.1-Instanz auf der VM. Dies geschieht, wenn man eine Verbindung von einer Windows-PowerShell-5.1- oder einer PowerShell-Core 6.0-Instanz auf dem Hyper-V-Host herstellt.

Dieses Verhalten hat sich in PowerShell Core 6.1 verändert. Wenn man Windows PowerShell 5.1 und PowerShell Core 6.1 auf dem Host und nur Windows PowerShell 5.1 auf der VM hat, verbindet man sich wie bisher mit der Windows-PowerShell-5.1-Instanz der VM.

Wenn man Windows PowerShell 5.1 und PowerShell Core 6.1 auf dem Host und auf der VM hat, versucht PowerShell Direct zuerst, eine Verbindung mit PowerShell Core 6.1 (unter Verwendung der ausführbaren Datei pwsh.exe) herzustellen. Wenn die Verbindung nicht hergestellt werden kann, wird auf Windows PowerShell 5.1 (unter Verwendung der ausführbaren Datei PowerShell.exe) zurückgegriffen. Das bedeutet, dass man über die PowerShell-Funktionalität auf der VM nachdenken und prüfen muss, ob sie unter PowerShell Core 6.1 ausgeführt wird.

Man sollte die PowerShell im Auge behalten, um über Änderungen informiert zu sein. Es ist immer eine gute Idee, die $PSVersionTable auf der VM zu testen, um die Version von PowerShell zu überprüfen.