12 min read
Erste Schritte mit PowerShell-Funktionen
PowerShell-Funktionen sind wichtige Tools, mit denen Du Code zur Wiederverwendung kapseln kannst, wodurch Ihre Skripts...
ScriptRunner Blog
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.
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:
Lassen Sie uns die Installation für jede dieser Komponenten aufschlüsseln.
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:
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.
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
(Get-PSRepository -Name "PSGallery").InstallationPolicy
Tipp: 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.5
Wenn PackageManagement nicht installiert ist, erhalten wir eine Fehlermeldung wie diese:
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
[int32]((Get-Module PowerShellGet).Version).Major
Nun wollen wir dies auf mindestens 2.0 aktualisieren.
Install-module PowerShellGet -MinimumVersion 2.0.0.0 -Force -Confirm:$False -SkipPublisherCheck
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
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:
Install-Module ExchangeOnlineManagement
Überprüfen Sie, ob es installiert ist: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:
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
Sichern Sie sich unsere kostenlose PowerShell Script-Sammlung zur Verwaltung von Verteilergruppen, Postfächern, Ressourcen und Diensten mit Exchange Online.
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.
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.
Get-Mailbox | Where {$_.IsResource -eq 'True'} | Ft Name, Alias, PrimarySMTPAddress, *quota
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
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:
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
In der kurzen Zeit, in der diese Cmdlets öffentlich verfügbar sind, habe ich Folgendes festgestellt:
Abb. 14: Ausführungszeit mit Get-Mailbox
Abb. 15: Ausführungszeit mit Get-EXOMailbox
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.
Apr 1, 2025 by Stéphane van Gulick
PowerShell-Funktionen sind wichtige Tools, mit denen Du Code zur Wiederverwendung kapseln kannst, wodurch Ihre Skripts...
Feb 25, 2025 by Heiko Brenn
Die neueste ScriptRunner Version bringt drei interessante Neuerungen, die die IT-Automatisierung in Unternehmen...
Dez 19, 2024 by Jeffery Hicks
Steigere die IT-Effizienz mit Winget und PowerShell! Lies, wie du Installationen, Updates und die Verwaltung von...
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".