Installation Exchange Online PowerShell V2

Microsoft entwickelt für Exchange Online eine neue PowerShell, die sich schon bei der Installation von bisherigen PowerShell-Erweiterungen unterscheidet.

Es gibt keinen manuellen Download mehr von einer Microsoft Download-Seite.

Stattdessen muss zuerst das Modul „PowerShellGet“ installiert werden, wenn noch nicht vorhanden.

Install-Module PowershellGet

Dazu wird der NuGet Paketmanager benötigt, welcher gleich mitinstalliert werden will:

Der NuGet-Anbieter ist erforderlich, um den Vorgang fortzusetzen.
PowerShellGet erfordert die NuGet-Anbieterversion 2.8.5.201 oder höher für die Interaktion mit NuGet-basierten
Repositorys. Der NuGet-Anbieter muss in "C:\Program Files\PackageManagement\ProviderAssemblies" oder
"C:\Users\administrator\AppData\Local\PackageManagement\ProviderAssemblies" verfügbar sein. Sie können den
NuGet-Anbieter auch durch Ausführen von 'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'
installieren. Möchten Sie den NuGet-Anbieter jetzt durch PowerShellGet installieren und importieren lassen?
[J] Ja  [N] Nein  [H] Anhalten  [?] Hilfe (Standard ist "J"):

Schlägt die Installation fehl, könnte dieser Artikel den Fehler beheben:

Die nächste Abfrage bestätigen…

Nicht vertrauenswürdiges Repository
Sie installieren die Module aus einem nicht vertrauenswürdigen Repository. Wenn Sie diesem Repos
 Sie dessen InstallationPolicy-Wert, indem Sie das Set-PSRepository-Cmdlet ausführen. Möchten Si
'PSGallery' wirklich installieren?
[J] Ja  [A] Ja, alle  [N] Nein  [K] Nein, keine  [H] Anhalten  [?] Hilfe (Standard ist "N"):

Bei mir ist das Modul in einer älteren Version schon installiert:

WARNUNG: Version 1.0.0.1 des Moduls "PowerShellGet" ist bereits auf "C:\Program
Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1" installiert. Um Version 2.2.5 zu installieren, führen Sie
Install-Module aus und fügen den -Force-Parameter hinzu. Durch diesen Befehl werden Version 2.2.5 und Version 1.0.0.1
parallel installiert.

Also machen wir weiter und installieren im zweiten Schritt das ExchangeOnlineManagement-Modul:

Install-Module -Name ExchangeOnlineManagement

Die Abfrage (siehe oben) wieder bestätigen und das Modul ist installiert.

Es hat sich bewährt die PowerShell im Anschluss zu schließen und neu zu öffnen, damit die neuen Module auch mit eingebunden werden.

In der neu geöffneten PowerShell lässt sich nun das ExchangeOnlineManagement aufrufen

Connect-ExchangeOnline

Es werden hier noch die alten und neuen Befehle gegenübergestellt.

Außerdem öffnet sich die Microsoft 365 Anmeldemaske, welche auch MFA unterstützt:

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

Unsere ESXi-Hosts zeigen seit kurzem 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.

Was aber ist die Isolationsadresse? Wofür wird sie benötigt?

In vSphere nutzt die HA-Funktion die Isolationsadresse als eine Art „Witness“. Das bedeutet, wenn ein Mitglied eines HA Clusters nicht mehr mit einem anderen Mitglied des HA Clusters kommunizieren kann, kann dieses mit der Isolationsadresse feststellen, ob das Problem an ihm selbst oder an dem nicht erreichten Host liegt.

Im Standard wird die Isolationsadresse mit dem konfigurierten Standardgateway vorbelegt.

Wie die Isolationsadresse geändert wird, ist in diesem Artikel beschrieben:

VMware ESXi Isolationsadresse des vSphere HA Cluster ändern

In unserem Fall war die Standard Isolationsadresse das Standard Gateway – die Firewall. Und in dieser wurde die Konfiguration dahingehend geändert, dass sie nicht mehr auf Ping-Anfragen (ICMP vom Typ Ping) antwortet.