Jetzt testen

Einführung in die neuen Exchange Online V2 Cmdlets

Inhaltsverzeichnis

Post Featured Image

Der neue Satz von Cmdlets im Exchange Online V2-Modul erweist sich gleichermaßen als Segen und etwas als Fluch für diejenigen, die Postfächer nach Exchange Online verschieben oder Exchange Online im Allgemeinen verwalten.

They are a boon because the nine new cmdlets are simply more robust and faster than their predecessors. They are also a bane because they will require script re-coding as well as learning the new methodologies (PropertySets and Properties) that are now present in these cmdlets.

Overall Microsoft has sought to balance use, speed and compatibility with the previous PowerShell module for Exchange Online.

In order to use the new Exchange Online V2 Module, we need to make sure that we meet certain prerequisites. Let’s dive into that first.

 

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:

Screenshot of a system message containing the following:

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:$False

Wenn 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").InstallationPolicy

Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted

Anschließend können wir die Änderung verifizieren:
(Get-PSRepository -Name "PSGallery").InstallationPolicy

Tipp: Verifizieren Sie die Änderung immer, um zukünftige Fehler zu vermeiden, insbesondere bei abhängigen Prozessen.

 


PackageManagement

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.5

Wenn PackageManagement nicht installiert ist, erhalten wir eine Fehlermeldung wie diese:

Screenshot of an error message that states

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 -SkipPublisherCheck

Wenn wir dann die Installation überprüfen, sehen wir dies:

Screenshot: The output of

Fig. 3: Since PackageManagement is installed, we can verify it via PowerShell

Beachten Sie, dass die „Quelle“ für dieses Paket die PowerShell-Galerie ist, die wir zuvor zugelassen haben.

 

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:
[int32]((Get-Module PowerShellGet).Version).Major

Auf neuen Computern sollte dies als Standard angezeigt werden:
 
Screenshot: The output of the command

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 -SkipPublisherCheck

Wenn alles nach Plan läuft, können wir unsere neue Version verifizieren und sehen dies:

Screenshot: The output of the command

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
Screenshot: The output of 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:

Screenshot: Removing the old PowerShellGet version via PowerShell and Importing the new version

Abb. 7: Nach dem Entfernen und erneuten Importieren von PowerShellGet zeigt unsere Eingabeaufforderung die richtige Version an

Wir sehen nun, dass 2.x von PowerShellGet geladen und für uns bereit ist. Nun zum Herunterladen des Moduls:

 


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 ExchangeOnlineManagement
Überprüfen Sie, ob es installiert ist:
Get-InstalledModule ExchangeOnlineManagement
Screenshot: The output of Get-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:

the Screenshot of the ExchangeOnlineManagement version history shows that new versions of the package are being released every 1 to 2 months

Abb. 9: Versionsverlauf von ExchangeOnlineManagement in der PowerShell-Galerie

 

 

Exchange Online V2 Cmdlets

Nachdem wir nun die Voraussetzungen aus dem Weg geräumt und das neue Modul installiert haben, was bringt uns das? Verbinden wir uns zunächst und schauen, was sich laut Microsoft geändert hat:

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:

 
Screenshot: Connect-ExchangeOnline delivers a wrap-up of old and new cmdlets in the module

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

Screenshot: Output of Get-Module

Abb. 11: Get-Module gibt uns einen Überblick über die verfügbaren Module und die darin enthaltenen Cmdlets

 

download-3

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.

Kostenlos auf GitHub >

 

 

Warum sollte man Exchange Online V2 cmdlets verwenden?

  1. 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.
  2. PropertySets: Gruppierte Sätze von Daten, die von PowerShell-Cmdlets zurückgegeben werden können.
  3. 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, *quota

Neue 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'} | ft

 

Beispiel Properties:

Get-EXOMailbox -Properties Name,Alias,PrimarySMTPAddress, IsResource, IssueWarningQuota,ProhibitSendQuota, ProhibitSendReceiveQuota | Where {$_.IsResource -eq 'True'} | ft

Dies 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:


Tab. 1: List of all property sets for Get-ExoMailbox
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
Screenshot: Output of

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
Screenshot: Full list of properties put out by

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):

       

      Screenshot: Execution time for Get-Mailbox

      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.
      Screenshot: Execution time for Get-ExOMailbox

      Abb. 15: Ausführungszeit mit Get-EXOMailbox


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.

 

Über den Autor: