Kontakt zur Powershell Gallery nicht möglich

Auf älteren Windows Systemen kann es vorkommen, dass der Kontakt zur Powershell Gallery nicht möglich ist. Beim Versuch wird ein Fehler zurückgegeben.

Unable to resolve package source ‘https://www.powershellgallery.com/api/v2’

Ursache im TLS

Transport Layer Security (TLS) ist ein Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Seit 2021 gelten die TLS Versionen 1.0 und 1.1 als veraltet und werden daher von vielen Anwendungen nicht mehr akzeptiert. Damit sind TLS 1.2 und 1.3 zum neuen Standard geworden. Auch die Powershell Gallery erfordert Seit 2020 mindestens TLS 1.2 und lehnt ältere Protokolle ab. Ältere Powershell Versionen wie beispielsweise Powershell 5.1 unterstützen diese Konfiguration nicht.

Aktuelles Security Protokoll abfragen

[Net.ServicePointManager]::SecurityProtocol

Als Ergebnis liefert Powershell in der Regel den Wert ‘SystemDefault’ zurück. D.h. Powershell verwendet die systemweiten Einstellungen für TLS.

PS > [Net.ServicePointManager]::SecurityProtocol
SystemDefault

Falls im System eine ältere TLS Version als Standard definiert ist, verwendet Powershell diese als Standard.

TLS 1.2 erzwingen

TLS 1.2 lässt sich in Powershell erzwingen mit dem unten gezeigten Kommando. Allerdings muss dieser Befehl in jeder neuen Powershell Session erneut ausgeführt werden.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Zum Test kann der Befehl aus dem ersten Screenshot erneut ausgeführt werden.

PS > Find-Module -Name VMware.PowerCLI

Es wird nun die Version des Moduls zurückgegeben ohne Fehlermeldung.

Version Name Repository Description
------- ---- ---------- -----------
13.3.0…. VMware.PowerCLI PSGallery This Windows PowerShell module contains VMware.PowerCLI

Nachhaltige Lösung

Das Erzwingen der TLS 1.2 Version kann nur ein kurzfristiger Fix sein. Langfristig sollte die Poweshell Version im OS auf aktuellen Stand gebracht werden. Ältere Systeme, die laut Microsoft ihr End-of-Life (EoL) erreicht haben, sollten nicht mehr eingesetzt werden. Das ist leicht gesagt, aber mir begegnen in der Praxis immer wieder Altsysteme, die aus den unterschiedlichsten Gründen nicht ersetzt werden können.

Kontakt zur Powershell Gallery nicht möglich

Auf älteren Windows Systemen kann es vorkommen, dass der Kontakt zur Powershell Gallery nicht möglich ist. Beim Versuch wird ein Fehler zurückgegeben.

Unable to resolve package source ‘https://www.powershellgallery.com/api/v2’

Ursache im TLS

Transport Layer Security (TLS) ist ein Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Seit 2021 gelten die TLS Versionen 1.0 und 1.1 als veraltet und werden daher von vielen Anwendungen nicht mehr akzeptiert. Damit sind TLS 1.2 und 1.3 zum neuen Standard geworden. Auch die Powershell Gallery erfordert Seit 2020 mindestens TLS 1.2 und lehnt ältere Protokolle ab. Ältere Powershell Versionen wie beispielsweise Powershell 5.1 unterstützen diese Konfiguration nicht.

Aktuelles Security Protokoll abfragen

[Net.ServicePointManager]::SecurityProtocol

Als Ergebnis liefert Powershell in der Regel den Wert ‘SystemDefault’ zurück. D.h. Powershell verwendet die systemweiten Einstellungen für TLS.

PS > [Net.ServicePointManager]::SecurityProtocol
SystemDefault

Falls im System eine ältere TLS Version als Standard definiert ist, verwendet Powershell diese als Standard.

TLS 1.2 erzwingen

TLS 1.2 lässt sich in Powershell erzwingen mit dem unten gezeigten Kommando. Allerdings muss dieser Befehl in jeder neuen Powershell Session erneut ausgeführt werden.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Zum Test kann der Befehl aus dem ersten Screenshot erneut ausgeführt werden.

PS > Find-Module -Name VMware.PowerCLI

Es wird nun die Version des Moduls zurückgegeben ohne Fehlermeldung.

Version Name Repository Description
------- ---- ---------- -----------
13.3.0…. VMware.PowerCLI PSGallery This Windows PowerShell module contains VMware.PowerCLI

Nachhaltige Lösung

Das Erzwingen der TLS 1.2 Version kann nur ein kurzfristiger Fix sein. Langfristig sollte die Poweshell Version im OS auf aktuellen Stand gebracht werden. Ältere Systeme, die laut Microsoft ihr End-of-Life (EoL) erreicht haben, sollten nicht mehr eingesetzt werden. Das ist leicht gesagt, aber mir begegnen in der Praxis immer wieder Altsysteme, die aus den unterschiedlichsten Gründen nicht ersetzt werden können.

ESXi Config-Backup mit PowerCLI benötigt HTTP

Es gibt einen wirklich nützlichen und komfortablen PowerCLI One-Liner zur Sicherung der Hostkonfiguration. Ich verwende ihn seit Jahren und hatte diesen auch in einem alten Blogpost im Detail erklärt.

Get-Cluster -Name myCluster | Get-VMHost | Get-VMHostFirmware -BackupConfiguration -DestinationPath 'C:\myPath'

Im Rahmen meiner VMware Kurse ist dies ein Befehl, den ich meinen Studenten immer mit auf den Weg gebe. Die Sicherung der Host-Konfiguration ist geradezu Pflicht vor Änderungen am Host, Installation von Patches und Treibern, oder Host-Updates. Nur ein paar Sekunden mehr Aufwand, aber diese Konfigurations-Backups haben mir schon mehr als einmal größeren Ärger und viele Stunden Arbeit erspart.

Kürzlich war ich in einem größeren Datacenter mit der Sicherung der Host-Konfigurationen beschäftigt. Überraschenderweise funktionierte der Befehl auf einigen der vCenter-Instanzen nicht und brach mit einer Fehlermeldung ab.

Get-VMHostFirmware : 18.08.2023 12:05:49 Get-VMHostFirmware An error occurred while sending the request.
At line:1 char:28
+… et-VMHost | Get-VMHostFirmware -BackupConfiguration -DestinationPath …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-VMHostFirmware], ViError
+ FullyQualifiedErrorId : Client20_SystemManagementServiceImpl_BackupVmHostFirmware_DownloadError,VMware.VimAutomation.ViCore.Cmdlets.Commands.Host.GetVMHostFirmware

Um den Fehler zu verstehen muss man zunächst verstehen, wie das PowerCLI Kommando arbeitet. Zunächst wird über vCenter auf dem Host ein Backup der Host-Konfiguration getriggert. Diese legt der Host lokal als gezipptes TAR Archiv (.tgz) ab. Der Name lautet configBundle-HostFQDN.tgz (Beispiel: configBundle-esx01.lab.local.tgz). Das Archiv wird dann in einem zweiten Schritt vom Host geladen. Die URL hierfür lautet:

http://[HostFQDN]/downloads/[Host-UUID]/configBundle-HostFQDN.tgz

Liest man die obige Fehlermeldung, gab es ganz offensichtlich ein Problem beim Download des TGZ-Files. Mit Hilfe der Netzwerk Admins wurde schnell klar, was hier passierte. Meine Arbeitsstation, von der ich den PowerCLI Befehl absendete, versuchte erfolglos eine HTTP Verbindung zum ESXi-Host aufzubauen. Dies wurde jedoch durch eine Firewall Regel geblockt.

Ich fragte mich, warum der Transfer über unverschlüsseltes HTTP abgewickelt wird. Im Log der Firewall sieht man einen Verbindungsversuch zum ESXi-Host mit HTTP und HTTPS.

Gibt es eine Möglichkeit, den Transfer über HTTPS zu erzwingen?

Der erste Gedanke war, dass es vielleicht einen Parameter zum Kommando gibt, der das HTTPS Protokoll erzwingt. Eine Anfrage im VMTN-Forum brachte leider Ernüchterung.

Es ist etwas erstaunlich, dass VMware für diese durchaus sensitiven Daten ein unverschlüsseltes Protokoll verwendet. Umso mehr da die PowerCLI Session zum vCenter ohnehin schon über HTTPS läuft. Die plausibelste Erklärung wäre, dass schlicht ‘vergessen’ wurde bei diesem doch recht alten Befehl, den Transfer über SSL abzusichern.

Es bleibt derzeit also keine andere Wahl, als eine Firewall-Regel zu erzeugen, die den Download über HTTP erlaubt.

vSAN Cluster Live-Migration in ein neues vCenter

Was kann man tun, wenn die produktive vCenter Server Appliance beschädigt ist und man einen vSAN-Cluster auf eine neue vCenter Appliance übertragen muss?

Im heutigen Beitrag werde ich zeigen, wie man einen laufenden vSAN-Cluster unter vollen Segeln von einer vCenter-Instanz auf ein neues vCenter übertragen kann.

Bei jedem der mit vSAN arbeitet, wird sich bei diesem Gedanken ein flaues Gefühl in der Magengegend verbreiten. Warum sollte man so etwas tun? Wäre es nicht besser, den Cluster komplett in den Wartungsmodus zu fahren? – Prinzipiell, ja. In der Praxis treffen wir aber immer wieder auf Einschränkungen, die in absehbarer Zeit kein Wartungsfenster erlauben.

Normalerweise sind vCenter Server Appliances robuste und wartungsarme Einheiten. Entweder sie funktionieren, oder sie sind völlig zerstört. In letzterem Fall könnte eine neue Appliance bereitgestellt und vom Backup ein Konfiguration-Restore eingespielt werden. Nichts davon traf auf ein kürzlich durchgeführtes Projekt zu. Die VCSA 6.7 funktionierte noch halbwegs, jedoch waren wichtige vSAN-Funktionalitäten im UI nicht mehr verfügbar. Eine erste Idee, das Problem mit einem Upgrade auf vCenter v7 und somit auf eine neue Appliance zu beseitigen scheiterte. Auch eine Cross-vCenter Migration der VMs (XVM) auf einen neuen vSAN-Cluster war nicht möglich, da erstens dieses Feature erst mit Version 7.0 Update 1c integriert wurde und zweitens auch nur zwei neue Ersatzhosts zur Verfügung standen. Zu wenig für einen neuen vSAN-Cluster. Zu allem Überfluss war auch der Quellcluster an seiner Kapazitätsgrenze.

Es gab nur einen Ausweg: Den Cluster stabilisieren und unter voller Last auf ein neues vCenter übertragen.

Zu diesem Thema gibt es einen alten, aber immer noch wertvollen Beitrag von William Lam. Damit, und mit dem VMware KB 2151610 Artikel konnte ich eine Strategie entwickeln, die ich hier skizzieren möchte.

Das Verfahren funktioniert, da ein vSAN-Cluster nach Einrichtung und Konfiguration autonom vom vCenter arbeiten kann. Das vCenter wird lediglich für Monitoring und Konfigurationsänderungen benötigt.

„vSAN Cluster Live-Migration in ein neues vCenter“ weiterlesen