Hyper-V-Hosts und VMs mit Skripten starten

Patch-Management unter Hyper-V mit PowerShell Direct

| Autor / Redakteur: Thomas Joos / Peter Schmitz

Mit PowerShell Direct können Admins auf VMs zuzugreifen und so zum Beispiel effizient Windows-Updates installieren.
Mit PowerShell Direct können Admins auf VMs zuzugreifen und so zum Beispiel effizient Windows-Updates installieren. (© Weissblick, Marima - stock.adobe.com)

Microsoft hat in Windows Server 2016 die PowerShell erweitert. Mit der PowerShell Direct können Admins aus einer PowerShell-Sitzung heraus auf VMs zuzugreifen und Befehle auszuführen. Der Vorteil dabei besteht darin, dass sich in der PowerShell sehr schnell Admin-Aufgaben auf Host und VMs durchführen lassen. Zum Beispiel lassen sich so Windows-Updates installieren.

PowerShell Direct ermöglicht es Administratoren auf Hyper-V-Hosts in der PowerShell Befehle auf VMs auszuführen. Im Gegensatz zu den Netzwerkfunktionen der PowerShell wird die PowerShell Direct vom Host auf die lokalen VMs umgeleitet. Die Verbindung funktioniert allerdings nur dann, wenn auf dem Host Windows Server 2016 oder Windows Server 1709 ausgeführt wird. Das gilt auch für die VMs. PowerShell Direct setzt den Betrieb von Windows Server 2016, Windows 10 oder Windows Server 1709 auf der VM voraus.

So funktioniert PowerShell Direct

Es gibt zwei Möglichkeiten um vom Hyper-V-Host aus Befehle in einer VM auszuführen. Der einfachste Weg besteht darin eine Sitzung vom Host aus in der VM zu öffnen:

Enter-PSSession -VMName <Name der VM im Hyper-V-Manager>

Als Name wird nicht der Computername verwendet, sondern die Bezeichnung der VM im Hyper-V-Manager. Die Namen der VMs werden in der PowerShell zum Beispiel mit get-vm angezeigt. Sobald die Sitzung geöffnet ist, werden alle Befehle der Sitzung in der jeweiligen VM durchgeführt. Für den Verbindungsaufbau ist noch eine Authentifizierung notwendig. Nach der Authentifizierung wird im vorderen Bereich der jeweiligen Befehlszeile der Name der VM angezeigt. Beim Befehl kann auch gleich der Anmeldenamen an der VM mitgegeben werden:

Enter-PSSession -VMName <Computer> -Credential <Benutzer>

Sitzungen pausieren und wieder aufnehmen

Neben PowerShell Direct lassen sich natürlich auch über das Netzwerk Sitzungen zu VMs aufbauen. Allerdings funktioniert das nur für CMDlets, die diese Funktion unterstützen. Sollen von einer lokalen PowerShell-Sitzung über das Netzwerk Programme auf einem Remotecomputer starten, wird der folgende Befehl verwendet:

Invoke-Command -ComputerName <Ziel-Computer> -ScriptBlock { <Befehl> } -credential <Benutzername>

Im Gegensatz zu PowerShell Direct wird hier aber der Computername verwendet, nicht der Name der VM in Hyper-V. Die beiden Namen müssen nicht zwingend identisch sein. Sind die Namen identisch macht das den Wechsel zwischen PowerShell Direct und PowerShell Remote einfacher. Außerdem muss bei der Verwendung von PowerShell Remote mit New-PSSession erst eine Sitzung erstellt werden. Mit enter-pssession <Nummer> wird eine Verbindung aufgebaut.

Für die Authentifizierung muss dem Computer vertraut werden. Am einfachsten ist das, wenn sich der Computer in der gleichen Active Directory-Gesamtstruktur befindet.

Funktioniert der Befehl, öffnet sich ein Authentifizierungsfenster und Sie müssen das Kennwort für den Benutzer eingeben. Mit dem CMDlet Test-WsMan <Computername> wird der Zugriff getestet. Erscheint keine Fehlermeldung, sondern eine Statusanzeige, funktioniert der Zugriff vom Quell-Computer auf den Ziel-Computer.

Sitzungen lassen sich über das Netzwerk jederzeit trennen und wieder erneut aufbauen. Dazu gibt es die beiden CMDlets Disconnect-PSSession und Connect-PSSession. Getrennte Sitzungen bleiben auf der VM gestartet und führen die Befehle in der Sitzung weiter durch.

In Remote-PowerShell-Sitzungen über PowerShell Direct verwenden die gleichen CMDlets wie auf den lokalen Computern verwendet. Das gilt auch für die Verbindung der PowerShell über das Netzwerk.

PowerShell und das Netzwerk

Allerdings erlauben nicht alle CMDlets eine Remoteverwaltung über das Netzwerk. Mit PowerShell Direct funktionieren die meisten Befehle dagegen recht problemlos. Administratoren sehen die kompatiblen CMDlets am schnellsten, indem sie überprüfen, ob das Cmdlet die Option „-ComputerName“ unterstützt. Mit dem Befehl Get-Help * -Parameter ComputerName wird eine Liste aller dieser CMDlets angezeigt. Soll von einer lokalen PowerShell-Sitzung über das Netzwerk Programme auf einem Remotecomputer starten, wird der folgende Befehl verwendet:

Invoke-Command -ComputerName <Ziel-Computer> -ScriptBlock { <Befehl> } -credential <Benutzername>

Funktioniert der Befehl, öffnet sich ein Authentifizierungsfenster und Sie müssen das Kennwort für den Benutzer eingeben. Mit dem CMDlet Test-WsMan <Computername> wird der Zugriff getestet. Erscheint keine Fehlermeldung, sondern eine Statusanzeige, funktioniert der Zugriff vom Quell-Computer auf den Ziel-Computer.

Microsoft hat Funktionen der Windows Workflow Foundation (WWF) in die PowerShell integriert. Diese Technik erlaubt auch das parallele Ausführen von mehreren Befehlen. Aktionen lassen sich in Abhängigkeit voneinander setzen und mit Bedingungen konfigurieren.

Mit der PowerShell Direct Patches installieren

Damit Patches mit PowerShell Direct installiert werden können, müssen diese über das Netzwerk erst auf die Rechner verteilt werden. Alternativ speichern Administratoren die Patches in einer Netzwerkfreigabe und starten von den einzelnen PowerShell Direct-Sitzungen die Installation des Patches. Idealerweise sollten die Patches auf die Server kopiert werden. In den meisten Fällen werden dazu MSU-Dateien verwendet. MSU-Dateien lassen sich mit dem Befehlszeilentool „wusa.exe“ installieren:

Wusa.exe <MSU-Datei des Patches> /quiet /norestart

Um die installierten Patches anzuzeigen wird get-hotfix verwendet. Der Befehl funktioniert über das Netzwerk mit der Option -computername.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45146607 / Cloud und Virtualisierung)