Der neue Satz von Cmdlets (neun an der Zahl) im Exchange Online V2-Modul erweist sich gleichermaßen als Segen und als Fluch für diejenigen, die Postfächer nach Exchange Online verschieben oder Exchange Online im Allgemeinen verwalten.
Sie sind ein Segen, weil die neun Cmdlets einfach robuster und schneller sind als ihre Vorgänger. Sie sind aber auch ein Fluch, denn sie erfordern eine Neukodierung der Skripte sowie das Erlernen der neuen Methoden (PropertySets und Eigenschaften/Properties), die jetzt in diesen Cmdlets enthalten sind.
Insgesamt hat Microsoft versucht, ein Gleichgewicht zwischen Nutzung, Geschwindigkeit und Kompatibilität mit dem vorherigen PowerShell-Modul für Exchange Online herzustellen.
Um das neue Exchange Online V2-Modul verwenden zu können, müssen wir sicherstellen, dass wir bestimmte Voraussetzungen erfüllen. Lassen Sie uns zuerst in diese eintauchen.
Voraussetzungen
Es gibt vier Voraussetzungen, die erfüllt sein müssen, bevor das neue Exchange Online V2-Modul überhaupt installiert werden kann. Diese Voraussetzungen werden möglicherweise bereits von Ihrer Jumpbox oder Ihrer regulären Workstation erfüllt. Wenn dies jedoch nicht der Fall ist, müssen sie möglicherweise installiert werden. Keine dieser Voraussetzungen ist ungewöhnlich, aber alle sorgen für eine bessere PowerShell-Erfahrung für den Administrator, der das neue PowerShell-Modul verwendet. Die vier Voraussetzungen sind wie folgt:
- NuGet – Version 2.8.5 oder neuer
- PsGallery – Vertrauenswürdiges PS-Repository
- PackageManagement – muss v.x sein
- PowerShell Get – sollte v.x oder höher sein
Lassen Sie uns die Installation für jede dieser Komponenten aufschlüsseln.
NuGet
NuGet ist einfach ein Paketmanager, auf den sich das Exchange Online V2 PowerShell-Modul stützt. Er ermöglicht Microsoft die Freigabe von Code und Admins den Download der neuen Module. Wenn dieser Paketmanager auf unserer Workstation nicht vorhanden ist, werden wir bei dem Versuch ExchangeOnlineManagement zu installieren etwas Ähnliches wie in Abbildung 1 angezeigt bekommen:
Abb. 1: Diese Meldung zeigt, dass NuGet nicht auf dem System installiert ist
Eine einfache Installation würde etwa so aussehen:
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force -Confirm:$FalseWenn wir überprüfen wollen, ob NuGet installiert werden muss, können wir auch die installierte Version überprüfen oder ob überhaupt eine Version installiert ist, etwa so:
$PackageProviders = (Get-PackageProvider -ListAvailable).Name
If ($PackageProviders -NotContains 'NuGet') {write-host 'NuGet is missing.'}Wenn nun NuGet fehlt, führen wir den obigen Installationscode aus, wenn jedoch NuGet installiert ist, können wir so oder so eine Installation der richtigen, minimalen Version mit dem vorherigen Cmdlet erzwingen.
Beachten Sie, dass die Build-Nummern bis zu 2.12.1 reichen, wir aber nur 2.8.3 oder höher benötigen.
PSGallery – Vertrauenswürdige Repositories
PowerShell Galleries sind Repositorys, in denen Scripte, Module und DSC-Ressourcen gespeichert werden, die zum Herunterladen verfügbar sind. Microsoft hostet ein Repository namens „PSGallery“, das ihre PowerShell-Ressourcen für Admins enthält, die ihre Produkte unterstützen.
Im Fall des Microsoft Exchange Online PowerShell V2-Moduls benötigen wir Zugriff auf dieses Repository, um das Modul herunterladen zu können. Standardmäßig ist dieses Repository möglicherweise nicht als vertrauenswürdig eingestuft und daher müssen wir sicherstellen, dass es vertrauenswürdig eingestuft wird.
Überprüfen wir zunächst von unserer Workstation aus, ob es vertrauenswürdig ist oder nicht:
(Get-PSRepository -Name "PSGallery").InstallationPolicySet-PSRepository -Name "PSGallery" -InstallationPolicy TrustedAnschließend können wir die Änderung verifizieren:
(Get-PSRepository -Name "PSGallery").InstallationPolicyTipp: Verifizieren Sie die Änderung immer, um zukünftige Fehler zu vermeiden, insbesondere bei abhängigen Prozessen.
Zusätzlich zur richtigen Version von NuGet müssen wir auch sicherstellen, dass PackageManagement ebenfalls in der richtigen Version vorliegt. PaketPackageManagement stellt ein einheitliches Paketverwaltungssystem für Windows-Betriebssysteme bereit. Als solches arbeitet es zusammen mit NuGet, das wir zuvor aktualisiert haben. Beachten Sie auch, dass NuGet zuerst installiert wurde und PackageManagement als Nächstes folgt, da dies die Reihenfolge des Upgrades ist, die wir einhalten müssen.
Für PackageManagement müssen wir sicherstellen, dass wir mindestens die Version 1.4.5 haben. Überprüfen wir dies mit der PowerShell:
Get-Package PackageManagement -MinimumVersion 1.4.5Wenn PackageManagement nicht installiert ist, erhalten wir eine Fehlermeldung wie diese:
Fig. 2: The error message states that PackageManagement is not installed
Um PackageManagement richtig zu installieren, müssen wir eventuell etwas herumjonglieren. Das liegt daran, dass es Abhängigkeiten gibt, die den Upgrade-Prozess zum Stolpern bringen können.
Wenn jedoch alles gut geht, ist dies die einzige Zeile, die wir brauchen, um PackageManagement zu installieren:
Install-Module PackageManagement -Force -SkipPublisherCheckWenn wir dann die Installation überprüfen, sehen wir dies:
PowerShell Get
Zusätzlich zur vorherigen Paketverwaltungssoftware haben wir auch ein Modul, das es Admins ermöglicht, PowerShell-Module, DSC-Ressourcen, Skripte und mehr zu erkennen, zu installieren und zu aktualisieren. Dies ist die letzte Voraussetzung für die Installation des EXO V2-Moduls.
Wie installieren wir es? Erstens: Haben wir es installiert?
Wir benötigen nur Version 2 oder höher, also überprüfen wir, ob wir ein Modul installiert haben, dessen Major-Version 2 ist:
Wie installieren wir es? Erstens: Haben wir es installiert?
Wir benötigen nur Version 2 oder höher, also überprüfen wir, ob wir ein Modul installiert haben, dessen Major-Version 2 ist:
[int32]((Get-Module PowerShellGet).Version).MajorAuf neuen Computern sollte dies als Standard angezeigt werden:
Abb. 4: Die Ausgabe besagt, dass die Major-Version des installierten Cmdlets „1“ ist
Nun wollen wir dies auf mindestens 2.0 aktualisieren.
Install-module PowerShellGet -MinimumVersion 2.0.0.0 -Force -Confirm:$False -SkipPublisherCheckWenn alles nach Plan läuft, können wir unsere neue Version verifizieren und sehen dies:
Abb. 5: Die Ausgabe besagt immer noch, dass die Hauptversion „1“ ist
Warten Sie. Was ist das? Das sollte doch jetzt „2“ sein. Was ist passiert? Ist das Paket jetzt auf unserem Rechner aktualisiert?
Get-Package PowerShellGet
Abb. 6: Die Ausgabe von Get-Package zeigt, dass die aktuelle Version 2.2.5 ist
OK. Wir haben also die richtige Version, warum wurde bei unserer Prüfung dann eine 1 angezeigt? Das liegt daran, dass das Modul, das geladen wird, das alte ist.
Nun, das lässt sich leicht beheben:
Download EXO V2 Module
Nachdem wir unsere vier Voraussetzungen installiert haben, können wir nun das neue Modul mit der gleichen Methode wie jedes andere Modul für PowerShell herunterladen:
Install-Module ExchangeOnlineManagementGet-InstalledModule ExchangeOnlineManagement
Abb. 8: Die Ausgabe von „Get-InstalledModule“ zeigt, dass das neue EXO V2-Modul installiert ist
Hinweis: Es kann sein, dass Ihre Version eine andere ist, wenn Sie dies lesen, da 2.0.4 die aktuelle Version zum Zeitpunkt der Erstellung dieses Artikels ist.
In den letzten Jahren hat sich diese Version jedoch mehrfach geändert, wie dieser Screenshot des Versionsverlaufs zeigt:
Connect-ExchangeOnline
Wir werden wie bei anderen Modulen für Office 365 zu MFA oder zumindest Modern Auth aufgefordert. Vor dem Verbinden sehen wir diese Information:
Abb. 10: Connect-ExchangeOnline liefert eine Übersicht über alte und neue Cmdlets im Modul
Das Modul bietet Ersatz für neun Cmdlets, stellt aber auch weiterhin die anderen 700+ Original-Cmdlets aus dem ursprünglichen Exchange Online-Modul zur Verfügung, die wir seit vielen Jahren verwenden.
Wenn wir unsere geladenen Module überprüfen, sehen wir das neue ganz oben in der Liste, aber wir sehen auch die ursprünglichen Cmdlets, die im letzten Modul aufgeführt sind
Abb. 11: Get-Module gibt uns einen Überblick über die verfügbaren Module und die darin enthaltenen Cmdlets
Kostenlose PowerShell-Scripte
ActionPack für Microsoft Exchange Online
Sichern Sie sich unsere kostenlose PowerShell Script-Sammlung zur Verwaltung von Verteilergruppen, Postfächern, Ressourcen und Diensten mit Exchange Online.
Warum sollte man Exchange Online V2 cmdlets verwenden?
- Datenreduzierung: Traditionelle PowerShell-Cmdlets geben alle Daten aus, auch wenn nicht alle Daten angezeigt werden. Die EXO V2-Cmdlets geben nur eine Teilmenge der Daten zurück, was für einen Administrator eine Herausforderung sein kann, um festzustellen, was er benötigt.
- PropertySets: Gruppierte Sätze von Daten, die von PowerShell-Cmdlets zurückgegeben werden können.
- Geschwindigkeit: Zusammen mit den beiden vorherigen Beispielen bieten die neun neuen Cmdlets mehr Geschwindigkeit und Zuverlässigkeit.
Diese Cmdlets wurden aus zwei Gründen ausgewählt – sie werden am ehesten verwendet, sind aber auch am wahrscheinlichsten langsam oder schlagen aufgrund der zurückgegebenen Datenmenge und der Belastung der Exchange Online-Server fehl.
Änderung in der Bedienung
Beim Einsatz dieser Cmdlets ist es wichtig zu beachten, dass wir in der Tat auf die Syntax und die richtige Verwendung der neuen Parameter achten müssen, um die richtigen Daten in Exchange Online zu erhalten.
Beispiel für PropertySets:
Alte Methode
Get-Mailbox | Where {$_.IsResource -eq 'True'} | Ft Name, Alias, PrimarySMTPAddress, *quotaNeue EXO V2-Methode
Mit den neuen Cmdlets müssen wir entweder auf PropertySets zurückgreifen wie hier:
Get-EXOMailbox -PropertySets Minimum, Resource, Quota | Where {$_.IsResource -eq 'True'} | ftBeispiel Properties:
Get-EXOMailbox -Properties Name,Alias,PrimarySMTPAddress, IsResource, IssueWarningQuota,ProhibitSendQuota, ProhibitSendReceiveQuota | Where {$_.IsResource -eq 'True'} | ftDies liefert zwar die gleichen Ergebnisse, wird aber schon recht unhandlich. Die Wahl zwischen Properties und PropertySets sollte sich also danach richten, wie viele Attribute man anzeigen möchte.
Woher wissen wir, welche Parameter/Eigenschaften mit einem PropertySet verwendbar sind? Das ist weder in der Get-Help noch in der Online-Hilfe von Microsoft Docs dokumentiert. Nehmen wir zum Beispiel Get-EXOMailbox aus dem vorherigen Beispiel. Wir sehen die Liste aller Property Sets, die in Get-Help für das Cmdlet aufgeführt sind:
| Minimum | AddressList | Audit |
| Archive | Audit | Custom |
| Delivery | Hold | Moderation |
| Move | Policy | PublicFolder |
| Quota | Resource | Retention |
| SCL | SoftDelete | StatisticsSeed |
Wenn wir nach allen Quota-Attributen suchen, sehen wir, dass es eine Quota-Property gibt. Mit dieser lassen sich viele Eigenschaften für ein Konto ermitteln:
Get-EXOMailbox Ted -PropertySets Quota
Abb. 12: Die Verwendung der Eigenschaft „Quota“ offenbart weitere Details zu einem bestimmten Konto
Beachten Sie, dass es einige Eigenschaften gibt, die sich nicht auf die Quota beziehen, sondern stattdessen Bezeichner für das Postfach sind – UserPrincipalName,PrimarySMTPAddress und Identity. Was sind die minimal gemeldeten Eigenschaften? Sehen wir uns das folgende Beispiel an, da die Standardeinstellung (keine PropertySets definiert) „Minimum“ ist:
Get-EXOMailbox Ted
Abb. 13: Ungefilterte Liste der Eigenschaften
Praxiserfahrung mit EXO V2 cmdlets
In der kurzen Zeit, in der diese Cmdlets öffentlich verfügbar sind, habe ich Folgendes festgestellt:
- Weniger Timeouts – bei einem Datensatz mit 7.000 Postfächern konnten die neuen EXO V2-Cmdlets alle Postfächer abfragen, jeden Ordner untersuchen und eine große Anzahl von Elementen in Ordnern (100k+) finden, ohne dass es zu Timeouts kam. Mit den älteren Cmdlets wäre dies nicht möglich gewesen.
- Geschwindigkeit – Die EXO v2-Cmdlets laufen viel schneller. Zur Verdeutlichung haben wir eine Abfrage sowohl mit Get-Mailbox als auch mit Get-EXOMailbox durchgeführt:
- Get-Mailbox (vollständiger Durchlauf, unbegrenzte Ergebnisse, 7.600+ Postfächer):
Abb. 14: Ausführungszeit mit Get-Mailbox
- Get-EXOMailbox (vollständiger Durchlauf, unbegrenzte Ergebnisse, 7.600+ Postfächer):
Beachten Sie, dass das EXO V2-Cmdlet etwa doppelt so schnell ist wie das reguläre Cmdlet. Ihre persönlichen Ergebnisse hängen von Ihrer Umgebung ab, aber im Allgemeinen sollte es viel schneller und reaktionsschneller sein.
Abb. 15: Ausführungszeit mit Get-EXOMailbox
- Get-Mailbox (vollständiger Durchlauf, unbegrenzte Ergebnisse, 7.600+ Postfächer):
Fazit
Während die Vorbereitungsarbeiten für die ExchangeOnlineManagement-PowerShell-Cmdlets ein wenig einschüchternd erscheinen mögen, wird dieses Script dazu beitragen, jegliche Installationsprobleme zu lindern.
Nach der Installation haben Sie nun Zugriff auf einen robusten Satz von PowerShell-Cmdlets. Als begeisterter PowerShell-Anwender ist der Autor zwar der Meinung, dass diese Cmdlets noch einige Schwachstellen aufweisen, aber in puncto Zuverlässigkeit und Leistung sind sie sicherlich in mancher Hinsicht besser. Außerdem investiert Microsoft ständig in die Verbesserung der PowerShell-Leistung der Administratoren, und wir sollten in den nächsten ein oder zwei Jahren sicherlich einige davon sehen.
Zusammenhängende Posts
Über den Autor:
Damian Scoles ist ein zehnfacher Microsoft MVP mit Spezialisierung auf Exchange, Office 365 und PowerShell, der über 25 Jahre Erfahrung in der IT-Branche mitbringt. Er ist im Großraum Chicago ansässig und begann mit der Verwaltung von Exchange 5.5 und Windows NT. Im Laufe der Jahre hat er mit Office 365 seit BPOS gearbeitet und darüber hinaus Erfahrung mit Azure AD, Security and Compliance Admin Centers und Exchange Online. Zu seinem Engagement in der Community gehören Beiträge in TechNet-Foren, die Erstellung von PowerShell-Skripten, die in seinen Blogs zu finden sind, das Schreiben von ausführlichen PowerShell/Office365/Exchange-Blogartikeln, Tweets und die Erstellung von PowerShell-Videos auf YouTube. Er hat fünf PowerShell-Bücher geschrieben und arbeitet außerdem aktiv an dem Buch "Microsoft 365 Security for IT Pros".