Installation von NuGet in der PowerShell schlägt fehl – Es kann kein Download von URI durchgeführt werden

Bei der Installation des ExchangeOnlineManagement-Moduls (und wahrscheinlich jedem anderen Modul) in der PowerShell wird der NuGet Paketmanager benötigt. Dieses kann direkt mitinstalliert werden.

Dabei bin ich dann auf das folgende Problem gestossen :

Die Fehlermeldung lautet:

WARNUNG: Es kann kein Download von URI "https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409" nach ""
durchgeführt werden.
WARNUNG: Die Liste der verfügbaren Anbieter kann nicht heruntergeladen werden. Überprüfen Sie Ihre Internetverbindung.
PackageManagement\Install-PackageProvider : Für die angegebenen Suchkriterien für Anbieter "NuGet" wurde keine
Übereinstimmung gefunden. Der Paketanbieter erfordert das PackageManagement- und Provider-Tag. Überprüfen Sie, ob das
angegebene Paket über die Tags verfügt.
In C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7405 Zeichen:21
+ ...     $null = PackageManagement\Install-PackageProvider -Name $script:N ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac
   kageProvider], Exception
    + FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro
   vider

PackageManagement\Import-PackageProvider : Für die angegebenen Suchkriterien und den Anbieternamen "NuGet" wurde keine
Übereinstimmung gefunden. Führen Sie "Get-PackageProvider -ListAvailable" aus, um festzustellen, ob der Anbieter im
System vorhanden ist.
In C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7411 Zeichen:21
+ ...     $null = PackageManagement\Import-PackageProvider -Name $script:Nu ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (NuGet:String) [Import-PackageProvider], Exception
    + FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.ImportPackageProv
   ider

Da eine Internetverbindung vorhanden war, musste der Fehler eine andere Ursache haben.

Nach kurzer Recherche im Netz bin ich auf den folgenden Artikel von ugg.li gestossen (vielen Dank dafür):

Das Problem scheint wohl an TLS zu liegen. Seit April 2020 lässt der Endpunkt nur noch Verbindungen mit mindestens TLS 1.2 zu.

Allerdings spricht die PowerShell im Default-Zustand nur TLS 1.1.

Der nachfolgende Befehl stell die PowerShell auf TLS 1.2 um:

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

Und siehe da, der Installer funktioniert wieder und die eigentliche Installation kann weiter gehen.

Der vSphere HA-Agent auf diesem Host konnte die Isolationsadresse nicht erreichen

Seit kurzem zeigen unsere ESXi-Hosts die Fehlermeldung:

„Der vSphere HA-Agent auf diesem Host konnte die Isolationsadresse nicht erreichen: IP-Adresse.“

Fehlermeldung in VMware ESXi vSphere: Der vSphere HA-Agent auf diesem Host konnte die Isolationsadresse nicht erreichen: IP-Adresse.

Dies wirft jedoch die Frage auf: Was ist die Isolationsadresse und warum ist sie wichtig?

In vSphere dient die Isolationsadresse als eine Art „Witness“ für die High Availability (HA)-Funktion. Das bedeutet, wenn ein Mitglied eines HA-Clusters nicht mehr mit einem anderen Mitglied des Clusters kommunizieren kann, kann es mithilfe der Isolationsadresse feststellen, ob das Problem an ihm selbst oder am nicht erreichbaren Host liegt. Die Isolationsadresse spielt somit eine entscheidende Rolle bei der Erkennung von Kommunikationsproblemen innerhalb des Clusters.

Standardmäßig wird die Isolationsadresse mit dem konfigurierten Standardgateway vorbelegt. Dieses Standardgateway fungiert als Referenzpunkt für die Überwachung der Kommunikation zwischen den Cluster-Mitgliedern. Es ist jedoch wichtig zu beachten, dass eine benutzerdefinierte Konfiguration der Isolationsadresse je nach Umgebung und Anforderungen vorgenommen werden kann.

In einem spezifischen Fall war die Standard-Isolationsadresse das Standardgateway, sprich die Firewall. Eine Änderung in der Firewall-Konfiguration führte dazu, dass sie nicht mehr auf Ping-Anfragen (ICMP vom Typ Ping) antwortete. Dies wiederum löste die Fehlermeldung aus, da die Kommunikation über die Isolationsadresse beeinträchtigt war.

Um solche Probleme zu beheben, ist es entscheidend zu verstehen, wie die Isolationsadresse funktioniert und wie sie an die individuellen Anforderungen der Umgebung angepasst werden kann.

Der folgende detaillierte Artikel, der die Schritte zur Änderung der Isolationsadresse bei VMware ESXi beschreibt, kann hilfreich sein, um sicherzustellen, dass die HA-Funktion reibungslos und zuverlässig arbeitet:

VMware ESXi Isolationsadresse des vSphere HA Cluster ändern

VMware ESXi – Isolationsadresse des vSphere HA Cluster ändern

Die Hochverfügbarkeitsfunktion (HA) in vSphere bedient sich der Isolationsadresse als eine Art „Witness“ bzw. „Zeugen“. Sollte ein Mitglied eines HA-Clusters nicht mehr mit einem anderen kommunizieren können, dient die Isolationsadresse dazu zu ermitteln, ob das Problem am betroffenen Mitglied selbst liegt oder am nicht erreichbaren Host.

Standardmäßig wird die Isolationsadresse mit dem konfigurierten Standardgateway vorbelegt. Wenn jedoch die Isolationsadresse angepasst werden soll, sind einige Einträge in den erweiterten Optionen des HA-Clusters erforderlich.

Ändern kann man die Isolationsadresse in den Erweiterten Optionen des HA-Clusters.

Um die Isolationsadresse zu ändern, müssen die folgenden Einträge über die Schaltfläche „Hinzufügen“ ergänzt werden:

  • das.isolationaddress1: IP-Adresse
  • das.isolationaddress2: IP-Adresse
  • das.usedefaultisolationaddress: false

Durch den Eintrag „das.usedefaultisolationaddress“ wird der HA-Cluster angewiesen, nicht länger die Standardisolationsadresse abzufragen.

In den erweiterten Optionen des HA-Clusters werden die alternativen Isolations-Adressen eingetragen.

Allerdings sollte nun mindestens eine Alternativ-Adresse angegeben werden. Diese Adresse sollte von einem physischen Server stammen, der kontinuierlich erreichbar ist. Ein virtueller Server, der auf einem der Hosts im HA-Cluster gehostet wird, ist in diesem Fall nicht sinnvoll.

Sobald die Einträge im HA-Cluster hinzugefügt wurden, müssen die Konfigurationen auf jedem Host übernommen werden. Hierfür wählt man über das Aktionen-Menü den Punkt „Für vSphere HA neu konfigurieren“ aus.

Dadurch werden die Änderungen auf alle beteiligten Hosts angewendet, was entscheidend ist, um sicherzustellen, dass das HA-Cluster einwandfrei funktioniert und die Hochverfügbarkeit der virtuellen Maschinen gewährleistet ist. Diese sorgfältige Vorgehensweise ist von wesentlicher Bedeutung für die Stabilität und Leistungsfähigkeit des Clusters und somit für die Geschäftskontinuität.

Die neue Konfiguration muss noch auf den Hosts aktiviert werden.
1 5 6 7 8 9 31