Informationen zum Exchange Online PowerShell-Moduls
Das Exchange Online PowerShell-Modul verwendet moderne Authentifizierung und funktioniert mit oder ohne mehrstufige Authentifizierung (Multi-Factor Authentication, MFA), um eine Verbindung mit allen Exchange-bezogenen PowerShell-Umgebungen in Microsoft 365 herzustellen: Exchange Online PowerShell, Security & Compliance PowerShell und eigenständige Exchange Online Protection (EOP) PowerShell.
Verbindungsanweisungen zum Verwenden des Moduls finden Sie in den folgenden Artikeln:
- Herstellen einer Verbindung mit Exchange Online PowerShell
- Verbinden Sie sich mit Security & Compliance PowerShell
- Verbinden mit PowerShell in Exchange Online Protection
- Reine App-Authentifizierung für unbeaufsichtigte Skripts in Exchange Online PowerShell und Security & Compliance PowerShell
- Verwenden von verwalteten Azure-Identitäten zum Herstellen einer Verbindung mit Exchange Online PowerShell
- Herstellen einer Verbindung mit Exchange Online PowerShell mithilfe von C#
In Rest dieses Artikels werden die Funktionsweise des Moduls, seine Installation und Wartung sowie die im Modul verfügbaren optimierten Exchange Online-Cmdlets beschrieben.
Tipp
Version 3.0.0 und höher (2022) wird als Exchange Online PowerShell V3-Modul (abgekürzt als EXO V3-Modul) bezeichnet. Version 2.0.5 und früher (2021) wurde als Exchange Online PowerShell V2-Modul (abgekürzt als EXO V2-Modul) bezeichnet.
REST-API-Verbindungen im EXO V3-Modul
Exchange Online PowerShell und Security & Compliance powerShell verwendet jetzt REST-API-Verbindungen für alle Cmdlets:
- Exchange Online PowerShell: EXO V3-Modul v3.0.0 oder höher.
- Security & Compliance PowerShell: EXO V3-Modul v3.2.0 oder höher.
REST-API-Verbindungen erfordern die Module PowerShellGet und PackageManagement. Weitere Informationen finden Sie unter PowerShellGet für REST-basierte Verbindungen in Windows.
Cmdlets in REST-API-Verbindungen haben die folgenden Vorteile gegenüber ihren historischen Gegenstücken:
- Sicherer: Integrierte Unterstützung für moderne Authentifizierung und keine Abhängigkeit von der PowerShell-Remotesitzung. PowerShell auf Ihrem Clientcomputer benötigt keine Standardauthentifizierung in WinRM.
-
Zuverlässiger: Vorübergehende Fehler verwenden integrierte Wiederholungen, sodass Fehler oder Verzögerungen minimiert werden. Zum Beispiel:
- Fehler aufgrund von Netzwerkverzögerungen.
- Verzögerungen aufgrund großer Abfragen, deren Abschluss sehr lange dauert.
- Bessere Leistung: REST-API-Verbindungen vermeiden das Einrichten eines PowerShell-Runspaces.
Die Vorteile von Cmdlets in REST-API-Verbindungen werden in der folgenden Tabelle beschrieben:
PowerShell-Remote-Cmdlets | Get-EXO*-Cmdlets | REST-API-Cmdlets | |
---|---|---|---|
Sicherheit | Am wenigsten sicher | Hohe Sicherheit | Hohe Sicherheit |
Leistung | Geringe Leistung | Hohe Leistung | Mittlere Leistung |
Zuverlässigkeit | Am wenigsten zuverlässig | Hohe Zuverlässigkeit | Hohe Zuverlässigkeit |
Funktionalität | Alle Parameter und Ausgabeeigenschaften verfügbar | Eingeschränkte Parameter und Ausgabeeigenschaften verfügbar | Alle Parameter und Ausgabeeigenschaften verfügbar |
REST-API-Cmdlets haben die gleichen Cmdlet-Namen und funktionieren genau wie ihre PowerShell-Remote-Entsprechungen, sodass Sie Cmdlet-Namen oder -Parameter in älteren Skripts nicht aktualisieren müssen.
Tipp
Das Cmdlet Invoke-Command funktioniert nicht in REST-API-Verbindungen. Alternativen finden Sie unter Problemumgehungen für Invoke-Command Szenarien in REST-API-Verbindungen.
Standardauthentifizierungsverbindungen (Remote-PowerShell) sind in Exchange Online PowerShell und Security & Compliance PowerShell veraltet. Weitere Informationen finden Sie hier und hier.
Einige Cmdlets in Exchange Online PowerShell wurden mit dem experimentellen UseCustomRouting-Switch in REST-API-Verbindungen aktualisiert. Dieser Schalter wird den Befehl direkt an den erforderlichen Postfachserver weiterleiten, und die Gesamtleistung kann verbessert werden. Verwenden Sie den UseCustomRouting-Schalter experimentell.
Wenn Sie den UseCustomRouting-Schalter verwenden, müssen Sie für die Identität des Postfachs die folgenden Werte verwenden:
- Benutzerprinzipalname (User Principal Name, UPN)
- E-Mail-Adresse
- Postfach-GUID
Der UseCustomRouting-Schalter ist nur für die folgenden Exchange Online PowerShell-Cmdlets in REST-API-Verbindungen verfügbar:
- Get-Clutter
- Get-FocusedInbox
- Get-InboxRule
- Get-MailboxAutoReplyConfiguration
- Get-MailboxCalendarFolder
- Get-MailboxFolderPermission
- Get-MailboxFolderStatistics
- Get-MailboxMessageConfiguration
- Get-MailboxPermission
- Get-MailboxRegionalConfiguration
- Get-MailboxStatistics
- Get-MobileDeviceStatistics
- Get-UserPhoto
- Remove-CalendarEvents
- Set-Clutter
- Set-FocusedInbox
- Set-MailboxRegionalConfiguration
- Set-UserPhoto
Verwenden Sie das Cmdlet Get-ConnectionInformation, um Informationen zu REST-API-Verbindungen mit Exchange Online PowerShell und Security & Compliance PowerShell abzurufen. Dieses Cmdlet ist erforderlich, da das Cmdlet Get-PSSession in Windows PowerShell keine Informationen für REST-API-Verbindungen zurückgibt.
Szenarien, in denen Sie Get-ConnectionInformation verwenden können, werden in der folgenden Tabelle beschrieben:
Szenario Erwartete Ausgabe Führen Sie nach den Befehlen Connect-ExchangeOnline oder Connect-IPPSSession für REST-API-Verbindungen aus. Gibt ein Verbindungsinformationsobjekt zurück. Führen Sie nach mehreren Befehlen Connect-ExchangeOnline oder Connect-IPPSSession für REST-API-Verbindungen aus. Gibt eine Auflistung von Verbindungsinformationsobjekten zurück. Verwenden Sie den Schalter SkipLoadingFormatData im Cmdlet Connect-ExchangeOnline , um das Laden von Formatdaten zu vermeiden und Connect-ExchangeOnline-Befehle schneller auszuführen.
Cmdlets, die von der REST-API unterstützt werden, weisen ein Timeout von 15 Minuten auf, das sich auf Massenvorgänge auswirken kann. Für den folgenden Befehl Update-DistributionGroupMember zum Aktualisieren von 10.000 Mitgliedern einer Verteilergruppe kann beispielsweise ein Timeout auftreten:
$Members = @("member1","member2",...,"member10000") Update-DistributionGroupMember -Identity DG01 -Members $Members
Verwenden Sie stattdessen den Befehl Update-DistributionGroupMember , um weniger Mitglieder zu aktualisieren, und fügen Sie dann die verbleibenden Mitglieder einzeln mithilfe eines Add-DistributionGroupMember-Befehls hinzu. Zum Beispiel:
Update-DistributionGroupMember -Identity DG01 -Members $Members[0..4999] $Remaining = $Members[-5000..-1] foreach ($Member in $Remaining) { Add-DistributionGroupMember -Identity DG01 -Member $Member }
Weitere Informationen zu den Neuerungen im EXO V3-Modul finden Sie weiter unten in diesem Artikel im Abschnitt Versionshinweise .
Melden von Fehlern und Problemen für Vorschauversionen des Exchange Online PowerShell-Moduls
Tipp
Verwenden Sie für allgemein verfügbare Versionen des Moduls nicht die folgende E-Mail-Adresse, um Probleme zu melden. Meldungen zu allgemein verfügbaren Versionen des Moduls werden nicht beantwortet. Erstellen Sie stattdessen ein Supportticket.
Verwenden Sie exocmdletpreview[at]service[dot]microsoft[dot]com
für Vorschauversionen des Moduls, um probleme zu melden, die möglicherweise auftreten. Stellen Sie sicher, dass Sie die Protokolldateien in Ihre E-Mail-Nachricht einschließen. Um die Protokolldateien zu generieren, ersetzen Sie <Path> durch einen Ausgabeordner, und führen Sie dann den folgenden Befehl aus:
Connect-ExchangeOnline -EnableErrorReporting -LogDirectoryPath <Path> -LogLevel All
Cmdlets im Exchange Online PowerShell-Modul
Das EXO-Modul enthält neun exklusive Get-EXO*-Cmdlets, die für die Geschwindigkeit in Massenabrufszenarien (Tausende von Objekten) in Exchange Online PowerShell optimiert sind. Die verbesserten Cmdlets im Modul sind in der folgenden Tabelle aufgeführt:
Tipp
Wenn Sie mehrere Verbindungen mit Exchange Online PowerShell im selben Fenster öffnen, werden die Get-EXO*-Cmdlets immer der letzten (aktuellen) Exchange Online PowerShell-Verbindung zugeordnet. Führen Sie den folgenden Befehl aus, um die REST-API-Sitzung zu suchen, in der die Get-EXO*- Cmdlets ausgeführt werden: Get-ConnectionInformation | Where-Object {$_.ConnectionUsedForInbuiltCmdlets -eq $true}
.
Die verbindungsbezogenen Cmdlets im Modul sind in der folgenden Tabelle aufgeführt:
EXO-Modul-Cmdlet | Älteres verwandtes Cmdlet | Kommentare |
---|---|---|
Connect-ExchangeOnline |
Connect-EXOPSSession in V1 des Moduls oder New-PSSession |
|
Connect-IPPSSession | Connect-IPPSSession in V1 des Moduls | |
Disconnect-ExchangeOnline | Remove-PSSession | |
Get-ConnectionInformation | Get-PSSession | Verfügbar in Version 3.0.0 oder höher. |
Tipp
Die häufige Verwendung der Cmdlets Connect-ExchangeOnline und Disconnect-ExchangeOnline in einer einzelnen PowerShell-Sitzung oder einem einzelnen Skript kann zu einem Speicherverlust führen. Die beste Möglichkeit, dieses Problem zu vermeiden, besteht darin, den Parameter CommandName im Connect-ExchangeOnline-Cmdlet zu verwenden, um die in der Sitzung verwendeten Cmdlets einzuschränken.
Verschiedene Exchange Online Cmdlets, die sich im Modul befinden, sind in der folgenden Tabelle aufgeführt:
Cmdlet | Kommentare |
---|---|
Get-DefaultTenantBriefingConfig | Verfügbar in Version 3.2.0 oder höher. |
Set-DefaultTenantBriefingConfig | Verfügbar in Version 3.2.0 oder höher. |
Get-DefaultTenantMyAnalyticsFeatureConfig | Verfügbar in Version 3.2.0 oder höher. |
Set-DefaultTenantMyAnalyticsFeatureConfig | Verfügbar in Version 3.2.0 oder höher. |
Get-MyAnalyticsFeatureConfig | Verfügbar in Version 2.0.4 oder höher. |
Set-MyAnalyticsFeatureConfig | Verfügbar in Version 2.0.4 oder höher. |
Get-UserBriefingConfig | Ersetzt durch Get-MyAnalyticsFeatureConfig. |
Set-UserBriefingConfig | Ersetzt durch Set-MyAnalyticsFeatureConfig. |
Get-VivaInsightsSettings | Verfügbar in v2.0.5 oder höher. |
Set-VivaInsightsSettings | Verfügbar in v2.0.5 oder höher. |
Get-VivaModuleFeature | Verfügbar in Version 3.2.0 oder höher. |
Get-VivaModuleFeatureEnablement | Verfügbar in Version 3.2.0 oder höher. |
Add-VivaModuleFeaturePolicy | Verfügbar in Version 3.2.0 oder höher. |
Get-VivaModuleFeaturePolicy | Verfügbar in Version 3.2.0 oder höher. |
Remove-VivaModuleFeaturePolicy | Verfügbar in Version 3.2.0 oder höher. |
Update-VivaModuleFeaturePolicy | Verfügbar in Version 3.2.0 oder höher. |
Add-VivaOrgInsightsDelegatedRole | Verfügbar in v3.7.0-Preview1 oder höher. |
Get-VivaOrgInsightsDelegatedRole | Verfügbar in v3.7.0-Preview1 oder höher. |
Remove-VivaOrgInsightsDelegatedRole | Verfügbar in v3.7.0-Preview1 oder höher. |
Installieren und Verwalten des Exchange Online PowerShell-Moduls
Sie laden das Modul aus dem PowerShell-Katalog unter https://www.powershellgallery.com/packages/ExchangeOnlineManagement/herunter.
In den Verfahren in diesem Abschnitt wird erläutert, wie Das Modul installiert, aktualisiert und deinstalliert wird.
Unterstützte Betriebssysteme für das Exchange Online PowerShell-Modul
Die neuesten Versionen des Moduls werden offiziell in PowerShell 7 unter Windows, Linux und Apple macOS unterstützt.
Insbesondere Version 2.0.4 oder höher wird in PowerShell 7.0.3 oder höher unterstützt.
Weitere Informationen zu PowerShell 7 finden Sie unter Ankündigung von PowerShell 7.0.
Apple macOS
Das Modul wird in den folgenden Versionen von macOS unterstützt:
- macOS 11 Big Sur oder höher
- macOS 10.15 Catalina
- macOS 10.14 Mojave
Anweisungen zur Installation von PowerShell 7 auf macOS finden Sie unter Installieren von PowerShell auf macOS.
Wie im Installationsartikel beschrieben, müssen Sie OpenSSL installieren, da dies für WSMan erforderlich ist.
Führen Sie nach der Installation von PowerShell 7 und OpenSSL die folgenden Schritte aus:
PowerShell als Superuser ausführen:
sudo pwsh
Führen Sie in der PowerShell-Superusersitzung die folgenden Befehle aus:
Install-Module -Name PSWSMan Install-WSMan
Wenn Sie dazu aufgefordert werden, akzeptieren Sie PSGallery als Quelle für die Cmdlets.
Jetzt können Sie die regulären PowerShell-Voraussetzungen erfüllen und das Exchange Online PowerShell-Modul installieren.
Linux
Das Modul wird offiziell in den folgenden Linux-Distributionen unterstützt:
- Ubuntu 24.04 LTS
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Anweisungen zur Installation von PowerShell 7 auf Linux finden Sie unter Installieren von PowerShell auf Linux.
Führen Sie nach der Installation von PowerShell 7 die folgenden Schritte aus:
PowerShell als Superuser ausführen:
sudo pwsh
Führen Sie in der PowerShell-Superusersitzung die folgenden Befehle aus:
Install-Module -Name PSWSMan Install-WSMan
Wenn Sie dazu aufgefordert werden, akzeptieren Sie PSGallery als Quelle für die Cmdlets.
Jetzt können Sie die regulären PowerShell-Voraussetzungen erfüllen und das Exchange Online PowerShell-Modul installieren.
Hinweis
Wenn Sie über ein Netzwerk hinter einem Proxyserver eine Verbindung mit Exchange Online PowerShell herstellen, funktioniert das EXO V2-Modul (Version 2.0.5 oder früher) unter Linux nicht. Sie müssen das EXO V3-Modul (v3.0.0 oder höher) unter Linux verwenden, um eine Verbindung aus einem Netzwerk herzustellen, das sich hinter einem Proxyserver befindet.
Windows
Alle Versionen des Moduls werden in Windows PowerShell 5.1 unterstützt.
PowerShell 7 unter Windows erfordert Version 2.0.4 oder höher.
Version 2.0.5 oder höher des Moduls erfordert die Verbindung mit dem Microsoft .NET Framework 4.7.2 oder höher. Andernfalls erhalten Sie einen System.Runtime.InteropServices.OSPlatform
Fehler. Diese Anforderung sollte in aktuellen Versionen von Windows kein Problem sein. Weitere Informationen zu Windows-Versionen, die die .NET Framework 4.7.2 unterstützen, finden Sie in diesem Artikel.
Windows PowerShell Anforderungen und Modulunterstützung in älteren Versionen von Windows werden in der folgenden Liste beschrieben:
Windows 8.1¹
Windows Server 2012 oder Windows Server 2012 R2¹
Windows 7 Service Pack 1 (SP1)² ¹ ⁴
Windows Server 2008 R2 SP1² ¹ ⁴
¹ PowerShell 7 für diese Version von Windows erfordert die Windows 10 Universelle C-Runtime (CRT).
² Der Support für diese Version von Windows wurde eingestellt und wird jetzt nur auf virtuellen Azure-Computern unterstützt.
¹ Diese Version von Windows unterstützt nur v2.0.3 oder frühere Versionen des Moduls.
⁴ Windows PowerShell 5.1 für diese Version von Windows erfordert die .NET Framework 4.5 oder höher und die Windows Management Framework 5.1. Weitere Informationen finden Sie unter Windows Management Framework 5.1.
Voraussetzungen für das Exchange Online PowerShell-Modul
Legen Sie die PowerShell-Ausführungsrichtlinie auf RemoteSigned fest.
Tipp
Die Einstellungen in diesem Abschnitt gelten für alle Versionen von PowerShell auf allen Betriebssystemen.
PowerShell muss zum Ausführen von Skripts konfiguriert werden. Standardmäßig ist dies nicht der Fall. Wenn Sie versuchen, eine Verbindung herzustellen, wird die folgende Fehlermeldung angezeigt:
Dateien können nicht geladen werden, weil das Ausführen von Skripts auf diesem System deaktiviert ist. Stellen Sie ein gültiges Zertifikat bereit, mit dem die Dateien signiert werden sollen.
Um festzulegen, dass alle PowerShell-Skripts, die Sie aus dem Internet herunterladen, von einem vertrauenswürdigen Herausgeber signiert sein müssen, müssen Sie den folgenden Befehl in einem PowerShell-Fenster mit erhöhten Rechten ausführen (ein PowerShell-Fenster, das Sie durch Auswahl von Als Administrator ausführen geöffnet haben):
Set-ExecutionPolicy RemoteSigned
Mehr zu Ausführungsrichtlinien finden Sie unter Ausführungsrichtlinien.
Aktivieren der Standardauthentifizierung in WinRM
Wichtig
REST-API-Verbindungen erfordern keine Standardauthentifizierung in WinRM, wie in diesem Abschnitt beschrieben. Wie weiter oben in diesem Artikel beschrieben, sind der Zugriff der Standardauthentifizierung (Remote-PowerShell) auf Exchange Online PowerShell und Security & Compliance PowerShell veraltet. Die Informationen in diesem Abschnitt werden zu historischen Zwecken verwaltet.
Für PowerShell-Remoteverbindungen, die die REST-API nicht verwenden (die jetzt nicht mehr möglich sind), muss WinRM die Standardauthentifizierung zulassen. Die Kombination aus Benutzername und Kennwort wird nicht gesendet. Der Standardauthentifizierungsheader ist erforderlich, um das OAuth-Token der Sitzung zu senden, da die clientseitige Implementierung von WinRM OAuth nicht unterstützt.
Um zu überprüfen, ob die Standardauthentifizierung für WinRM aktiviert ist, führen Sie den folgenden Befehl in der Eingabeaufforderung oder Windows PowerShell aus:
Hinweis
Die folgenden Befehle erfordern, dass WinRM aktiviert ist. Führen Sie den folgenden Befehl aus, um WinRM zu aktivieren: winrm quickconfig
.
winrm get winrm/config/client/auth
Wenn der Wert Basic = true
nicht angezeigt wird, müssen Sie einen der folgenden Befehle ausführen, um die Standardauthentifizierung für WinRM zu aktivieren:
In der Eingabeaufforderung:
winrm set winrm/config/client/auth @{Basic="true"}
In Windows PowerShell:
winrm set winrm/config/client/auth '@{Basic="true"}'
In Windows PowerShell zum Ändern der Registrierung:
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WinRM\Client' -Name 'AllowBasic' -Type DWord -Value '1'
Wenn die Standardauthentifizierung für WinRM deaktiviert ist, erhalten Sie einen der folgenden Fehler, wenn Sie versuchen, eine Verbindung über eine Standardauthentifizierung (Remote-PowerShell)-Verbindung herzustellen:
Die Anforderung kann vom WinRM-Client nicht verarbeitet werden. Die Standardauthentifizierung ist in der Clientkonfiguration zurzeit deaktiviert. Ändern Sie die Clientkonfiguration, und versuchen Sie es erneut.
Erstellen der PowerShell-Sitzung ist mit OAuth fehlgeschlagen.
PowerShellGet für REST-API-Verbindungen in Windows
REST-API-Verbindungen in Windows erfordern das PowerShellGet-Modul und abhängig das PackageManagement-Modul. Diese Module sind mehr für PowerShell 5.1 als für PowerShell 7 zu berücksichtigen, aber alle Versionen von PowerShell profitieren von der Installation der neuesten Versionen der Module. Installations- und Updateanweisungen finden Sie unter Installieren von PowerShellGet unter Windows.
Tipp
Betaversionen des PackageManagement- oder PowerShellGet-Moduls können Verbindungsprobleme verursachen. Wenn Verbindungsprobleme auftreten, vergewissern Sie sich, dass keine Betaversionen der Module installiert sind, indem Sie den folgenden Befehl ausführen: Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions
.
Wenn PowerShellGet nicht installiert ist, wenn Sie versuchen, eine REST-API-Verbindung zu erstellen, erhalten Sie beim Versuch, eine Verbindung herzustellen, die folgende Fehlermeldung:
Cmdlet Update-Manifest nicht gefunden
Installieren des Exchange Online PowerShell-Moduls
Führen Sie die folgenden Schritte aus, um das Modul zum ersten Mal zu installieren:
Installieren oder aktualisieren Sie das PowerShellGet-Modul wie unter Installieren von PowerShellGet beschrieben.
Schließen Sie das Windows PowerShell-Fenster und öffnen Sie es erneut.
Jetzt können Sie das Cmdlet Install-Module verwenden, um das Modul aus dem PowerShell-Katalog zu installieren. In der Regel möchten Sie die neueste öffentliche Version des Moduls, aber Sie können auch eine Vorschauversion installieren, falls verfügbar.
Führen Sie einen der folgenden Befehle aus, um die neueste öffentliche Version des Moduls zu installieren:
In einem PowerShell-Fenster mit erhöhten Rechten (alle Benutzer):
Install-Module -Name ExchangeOnlineManagement
Nur für das aktuelle Benutzerkonto:
Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser
Führen Sie den folgenden Befehl aus, um die verfügbaren Vorschauversionen des Moduls anzuzeigen:
Find-Module ExchangeOnlineManagement -AllVersions -AllowPrerelease
Führen Sie einen der folgenden Befehle aus, um die neueste verfügbare Vorschauversion des Moduls zu installieren:
In einem PowerShell-Fenster mit erhöhten Rechten (alle Benutzer):
Install-Module -Name ExchangeOnlineManagement -AllowPrerelease
Nur für das aktuelle Benutzerkonto:
Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser -AllowPrerelease
Um eine bestimmte Vorschauversion des Moduls zu installieren, ersetzen Sie <PreviewVersion> durch den erforderlichen Wert, und führen Sie einen der folgenden Befehle aus:
In einem PowerShell-Fenster mit erhöhten Rechten (alle Benutzer):
Install-Module -Name ExchangeOnlineManagement -RequiredVersion <PreviewVersion> -AllowPrerelease
Nur für das aktuelle Benutzerkonto:
Install-Module -Name ExchangeOnlineManagement -RequiredVersion <PreviewVersion> -AllowPrerelease -Scope CurrentUser
Wenn Sie fertig sind, geben Sie Y ein, um den Lizenzvertrag anzunehmen.
Ausführliche Informationen zu Syntax und Parametern finden Sie unter Install-Module.
Aktualisieren des Exchange Online PowerShell-Moduls
Wenn das Modul bereits auf Ihrem Computer installiert ist, können Sie die Verfahren in diesem Abschnitt verwenden, um das Modul zu aktualisieren.
Führen Sie den folgenden Befehl aus, um die Version des moduls anzuzeigen, das derzeit installiert ist und wo es installiert ist:
Get-InstalledModule ExchangeOnlineManagement | Format-List Name,Version,InstalledLocation
Wenn das Modul unter C:\Programme\WindowsPowerShell\Modules installiert ist, wird es für alle Benutzer installiert. Wenn das Modul im Ordner Dokumente installiert ist, wird es nur für das aktuelle Benutzerkonto installiert.
Sie können das Cmdlet Update-Module verwenden, um das Modul aus dem PowerShell-Katalog zu aktualisieren. In der Regel möchten Sie die neueste öffentliche Version des Moduls, aber Sie können auch ein Upgrade auf eine Vorschauversion durchführen, falls diese verfügbar ist.
Um ein Upgrade auf die neueste öffentliche Version des Moduls durchzuführen, führen Sie einen der folgenden Befehle aus, je nachdem, wie Sie das Modul ursprünglich installiert haben (alle Benutzer und nur für das aktuelle Benutzerkonto):
In einem PowerShell-Fenster mit erhöhten Rechten (alle Benutzer):
Update-Module -Name ExchangeOnlineManagement
Nur für das aktuelle Benutzerkonto:
Update-Module -Name ExchangeOnlineManagement -Scope CurrentUser
Um ein Upgrade auf eine Vorschauversion des Moduls durchzuführen, können Sie ein Upgrade auf die neueste verfügbare Vorschauversion durchführen oder den RequiredVersion-Parameter verwenden, um ein Upgrade auf eine bestimmte Vorschauversion durchzuführen.
Führen Sie den folgenden Befehl aus, um die verfügbaren Vorschauversionen des Moduls anzuzeigen:
Find-Module ExchangeOnlineManagement -AllVersions -AllowPrerelease
Führen Sie einen der folgenden Befehle aus, um ein Upgrade auf die neueste verfügbare Vorschauversion des Moduls durchzuführen:
In einem PowerShell-Fenster mit erhöhten Rechten (alle Benutzer):
Update-Module -Name ExchangeOnlineManagement -AllowPrerelease
Nur für das aktuelle Benutzerkonto:
Update-Module -Name ExchangeOnlineManagement -Scope CurrentUser -AllowPrerelease
Um auf eine bestimmte Vorschauversion des Moduls zu aktualisieren, ersetzen Sie <PreviewVersion> durch den erforderlichen Wert, und führen Sie einen der folgenden Befehle aus:
In einem PowerShell-Fenster mit erhöhten Rechten (alle Benutzer):
Update-Module -Name ExchangeOnlineManagement -RequiredVersion <PreviewVersion> -AllowPrerelease
Nur für das aktuelle Benutzerkonto:
Update-Module -Name ExchangeOnlineManagement -Scope CurrentUser -RequiredVersion <PreviewVersion> -AllowPrerelease
Wenn Sie fertig sind, geben Sie Y ein, um den Lizenzvertrag anzunehmen.
Um zu bestätigen, dass das Update erfolgreich war, führen Sie die folgenden Befehle aus, um die Versionsinformationen des installierten Moduls zu überprüfen:
Import-Module ExchangeOnlineManagement; Get-Module ExchangeOnlineManagement
Ausführliche Informationen zu Syntax und Parametern finden Sie unter Update-Module.
Problembehandlung bei der Installation des Exchange Online PowerShell-Moduls
Sie erhalten einen der folgenden Fehler:
Das angegebene Modul "ExchangeOnlineManagement" mit PowerShellGetFormatVersion "<version>" wird von der aktuellen Version von PowerShellGet nicht unterstützt. Rufen Sie die neueste Version des PowerShellGet-Moduls zum Installieren dieses Moduls, "ExchangeOnlineManagement", ab.
WARNUNG: Vom URI kann nicht heruntergeladen werden.https://go.microsoft.com/fwlink/?LinkID=627338& clcid=0x409" bis "".
WARNUNG: Die Liste der verfügbaren Anbieter kann nicht heruntergeladen werden. Überprüfen Sie Ihre Internetverbindung.
Aktualisieren Sie die Installation des PowerShellGet-Moduls auf die neueste Version, wie unter Installieren von PowerShellGet beschrieben. Schließen Sie unbedingt das PowerShell-Fenster, und öffnen Sie es erneut, bevor Sie noch einmal versuchen, das ExchangeOnlineManagement-Modul zu aktualisieren.
Sie erhalten den folgenden Fehler:
Für die angegebenen Suchkriterien und den Modulnamen „ExchangeOnlineManagement“ wurde keine Übereinstimmung gefunden. Versuchen Sie,
Get-PSRepository
auszuführen, um alle verfügbaren registrierten Modulrepositorys anzuzeigen.Das Standardrepository für PowerShell-Module ist nicht auf PSGallery festgelegt. Führen Sie den folgenden Befehl aus, um diesen Fehler zu beheben:
Register-PSRepository -Default
Ab April 2020 unterstützt der PowerShell-Katalog nur noch Verbindungen mit TLS 1.2 oder höher. Weitere Informationen finden Sie unter PowerShell-Katalog: TLS-Unterstützung.
Um Ihre aktuellen Einstellungen im Microsoft .NET Framework zu überprüfen, führen Sie den folgenden Befehl in Windows PowerShell aus:
[Net.ServicePointManager]::SecurityProtocol
Wie im Artikel „PowerShell-Katalog: TLS-Unterstützung“ beschrieben, führen Sie zum Installieren der Module „PowerShellGet“ oder „ExchangeOnlineManagement“ den folgenden Befehl in Windows PowerShell aus, um das Sicherheitsprotokoll vorübergehend auf TLS 1.2 zu ändern, bevor Sie das Modul installieren:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Um die starke Kryptografie im Microsoft .NET Framework ab Version 4.x dauerhaft zu aktivieren, führen Sie einen der folgenden Befehle aus, je nach Ihrer Windows-Architektur:
x64:
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Type DWord -Value '1'
x86:
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Type DWord -Value '1'
Weitere Informationen finden Sie unter SchUseStrongCrypto.
Deinstallieren des Exchange Online PowerShell-Moduls
Führen Sie den folgenden Befehl aus, um die Version des moduls anzuzeigen, das derzeit installiert ist und wo es installiert ist:
Get-InstalledModule ExchangeOnlineManagement | Format-List Name,Version,InstalledLocation
Wenn das Modul unter C:\Programme\WindowsPowerShell\Modules installiert ist, wurde es für alle Benutzer installiert. Wenn das Modul im Ordner Dokumente installiert ist, wurde es nur für das aktuelle Benutzerkonto installiert.
Führen Sie zum Deinstallieren des Moduls den folgenden Befehl in einer der folgenden Umgebungen aus, je nachdem, wie Sie das Modul ursprünglich installiert haben (alle Benutzer und nur für das aktuelle Benutzerkonto):
In einem PowerShell-Fenster mit erhöhten Rechten (alle Benutzer).
In einem normalen PowerShell-Fenster (nur für das aktuelle Benutzerkonto).
Uninstall-Module -Name ExchangeOnlineManagement
Ausführliche Informationen zu Syntax und Parametern finden Sie unter Uninstall-Module.
Eigenschaften und Eigenschaftensätze im Exchange Online PowerShell-Modul
Herkömmliche Exchange Online Cmdlets geben alle möglichen Objekteigenschaften zurück, einschließlich vieler leerer oder uninteressanter Eigenschaften. Dieses Verhalten führt zu einer verminderten Leistung (mehr Serverrechenaufwand und zusätzliche Netzwerklast). Nur selten (wenn überhaupt) benötigen Sie die gesamten Eigenschaften in der Cmdlet-Ausgabe.
Die Get-EXO*- Cmdlets im Modul verfügen über kategorisierte Ausgabeeigenschaften. Anstatt allen Eigenschaften die gleiche Wichtigkeit zuzuweisen und sie in allen Szenarien zurückzugeben, haben wir bestimmte verwandte Eigenschaften in Eigenschaftensätze kategorisiert. Diese Eigenschaftensätze sind Buckets mit mindestens zwei verwandten Eigenschaften für das Cmdlet.
Die größten und am häufigsten verwendeten Get-EXO*- Cmdlets verwenden Eigenschaftensätze:
In diesen Cmdlets werden Eigenschaftengruppen durch folgende Parameter gesteuert:
- PropertySets: Dieser Parameter akzeptiert einen oder mehrere verfügbare, durch Kommas getrennte Eigenschaftensatznamen. Die verfügbaren Eigenschaftensätze werden unter Eigenschaftensätze in Exchange Online PowerShell-Modul-Cmdlets beschrieben.
- Properties: Dieser Parameter akzeptiert einen oder mehrere, durch Kommas getrennte Eigenschaftennamen.
Sie können die Parameter PropertySets und Properties zusammen im selben Befehl verwenden.
Wir haben auch einen Minimum-Eigenschaftssatz eingeschlossen, der einen minimalen Satz erforderlicher Eigenschaften für die Cmdlet-Ausgabe enthält (z. B. Identitätseigenschaften). Die Eigenschaften in den Minimum-Eigenschaftssätzen werden auch unter Eigenschaftensätze in Exchange Online PowerShell-Modul-Cmdlets beschrieben.
- Wenn Sie die PropertySets- oder Properties-Parameter nicht verwenden, erhalten Sie automatisch die Eigenschaften im Minimum-Eigenschaftensatz.
- Wenn Sie die PropertySets- oder Properties-Parameter verwenden, erhalten Sie die angegebenen Eigenschaften und die Eigenschaften im Minimum-Eigenschaftensatz.
In beiden Richtungen enthält die Cmdlet-Ausgabe weit weniger Eigenschaften, und die Ergebnisse werden viel schneller zurückgegeben.
Nachdem Sie beispielsweise eine Verbindung mit Exchange Online PowerShell hergestellt haben, gibt das folgende Beispiel nur die Eigenschaften im Minimum-Eigenschaftssatz für die ersten 10 Postfächer zurück.
Get-EXOMailbox -ResultSize 10
Im Gegensatz dazu würde die Ausgabe desselben Get-Mailbox-Befehls mindestens 230 Eigenschaften für jedes der ersten 10 Postfächer zurückgeben.
Hinweis
Auch wenn der Parameter PropertySets den Wert "All" akzeptiert, raten wir dringend davon ab, mit diesem Wert alle Eigenschaften zurückzugeben, da dadurch der Befehl verlangsamt und die Zuverlässigkeit verringert wird. Verwenden Sie immer die PropertySets- und Properties-Parameter, um die Mindestanzahl von Eigenschaften abzurufen, die in Ihrem Szenario benötigt werden.
Weitere Informationen zum Filtern im Modul finden Sie unter Filter im Exchange Online PowerShell-Modul.
Versionshinweise
Sofern nicht anders angegeben, enthält die aktuelle Version des Exchange Online PowerShell-Moduls alle Features früherer Versionen.
Aktuelles Release
Version 3.6.0
- Get-VivaModuleFeature gibt jetzt Informationen zu den Arten von Identitäten zurück, für die das Feature Richtlinien erstellt (z. B. Benutzer, Gruppen oder der gesamte Mandant).
- Cmdlets für Viva Featurezugriffsverwaltung bewältigen jetzt Herausforderungen bei der fortlaufenden Zugriffsauswertung (Continuous Access Evaluation, CAE).
- Korrektur für Kompatibilitätsproblem mit dem Microsoft.Graph-Modul hinzugefügt.
Frühere Releases
Version 3.5.1
- Fehlerbehebungen in Get-EXOMailboxPermission und Get-EXOMailbox.
- Das Modul wurde für die Ausführung unter .NET 8 aktualisiert und ersetzt die vorherige Version, die auf .NET 6 basiert.
- Verbesserungen in Add-VivaModuleFeaturePolicy.
Version 3.5.0
- Neues Cmdlet Get-VivaFeatureCategory .
- Unterstützung für Richtlinienvorgänge auf Kategorieebene in Viva Featurezugriffsverwaltung (VFAM) hinzugefügt.
- Neue IsFeatureEnabledByDefault-Eigenschaft in der Ausgabe von Get-VivaModuleFeaturePolicy. Der Wert dieser Eigenschaft zeigt den Standardaktivierungsstatus für Benutzer im Mandanten an, wenn keine Mandanten- oder Benutzer-/Gruppenrichtlinien erstellt wurden.
Version 3.4.0
- Fehlerbehebungen in Connect-ExchangeOnline, Get-EXORecipientPermission und Get-EXOMailboxFolderPermission.
- Der Parameter SigningCertificate in Connect-ExchangeOnline unterstützt jetzt den eingeschränkten Sprachmodus (CLM).
Version 3.3.0
- SkipLoadingCmdletHelp-Parameter in Connect-ExchangeOnline , um das Überspringen des Ladens von Cmdlet-Hilfedateien zu unterstützen.
- Die globale Variable
EXO_LastExecutionStatus
ist verfügbar, um die status des zuletzt ausgeführten Cmdlets zu überprüfen. - Fehlerbehebungen in Connect-ExchangeOnline und Connect-IPPSSession.
- IsUserControlEnabled-Parameter für Add-VivaModuleFeaturePolicy und Update-VivaModuleFeaturePolicy zur Unterstützung der Aktivierung von Benutzersteuerelementen per Richtlinie für Features, die in Viva Featurezugriffsverwaltung integriert sind.
Version 3.2.0
- Neue Cmdlets:
- Get-DefaultTenantBriefingConfig und Set-DefaultTenantBriefingConfig.
- Get-DefaultTenantMyAnalyticsFeatureConfig und Set-DefaultTenantMyAnalyticsFeatureConfig.
- Get-VivaModuleFeature, Get-VivaModuleFeatureEnablement, Add-VivaModuleFeaturePolicy, Get-VivaModuleFeaturePolicy, Remove-VivaModuleFeaturePolicy und Update-VivaModuleFeaturePolicy.
- REST-API-Verbindungsunterstützung für Security & Compliance PowerShell.
-
ConnectionId-Parameter für Get-ConnectionInformation und Disconnect-ExchangeOnline:
- Ruft Verbindungsinformationen für bestimmte REST-API-Verbindungen ab.
- Selektive Trennung für REST-API-Verbindungen.
- Mit dem Parameter "SigningCertificate" auf Connect-ExchangeOnline können Sie die Formatdateien (* signieren. Format.ps1xml) oder Skriptmoduldateien (.psm1) im temporären Modul, das Connect-ExchangeOnline mit einem Clientzertifikat erstellt, das in allen PowerShell-Ausführungsrichtlinien verwendet werden kann.
- Fehlerbehebungen in Connect-ExchangeOnline.
Version 3.1.0
- AccessToken-Parameter in Connect-ExchangeOnline verfügbar.
- Fehlerbehebungen in Connect-ExchangeOnline und Get-ConnectionInformation.
- Fehlerbehebung in Connect-IPPSSession für das Herstellen einer Verbindung mit Security & Compliance PowerShell mithilfe von CertificateThumbprint.
Version 3.0.0 (Vorschauversionen, bekannt als v2.0.6-PreviewX)
- Features, die bereits in den REST-API-Verbindungen im Abschnitt EXO V3-Modul beschrieben sind:
- Zertifikatbasierte Authentifizierung für Security & Compliance PowerShell (Version 2.0.6-Preview5 oder höher).
- Das Cmdlet Get-ConnectionInformation für REST-basierte Verbindungen (Version 2.0.6-Preview7 oder höher).
- Der SkipLoadingFormatData-Schalter im Cmdlet Connect-ExchangeOnline für REST-basierte Verbindungen (Version 2.0.6-Preview8 oder höher).
- Der Parameter DelegatedOrganization funktioniert im Cmdlet Connect-IPPSSession , solange Sie auch den Parameter AzureADAuthorizationEndpointUri im Befehl verwenden.
- Bestimmte Cmdlets, die verwendet wurden, um in bestimmten Szenarien zur Bestätigung aufzufordern, tun dies nicht mehr. Standardmäßig wird das Cmdlet bis zum Abschluss ausgeführt.
- Das Format des Fehlers, der bei der fehlgeschlagenen Cmdletausführung zurückgegeben wird, wurde geringfügig geändert. Die Ausnahme enthält jetzt mehr Daten (z. B. den Ausnahmetyp), und der
FullyQualifiedErrorId
enthältFailureCategory
nicht . Das Format des Fehlers kann noch geändert werden.
Version 2.0.5
Neue Cmdlets Get-OwnerlessGroupPolicy und Set-OwnerlessGroupPolicy zum Verwalten besitzerloser Microsoft 365-Gruppen.
Hinweis
Obwohl die Cmdlets im Modul verfügbar sind, ist das Feature nur für Mitglieder einer privaten Vorschau verfügbar.
Neue Cmdlets Get-VivaInsightsSettings und Set-VivaInsightsSettings zum Steuern des Benutzerzugriffs auf Headspace-Features in Viva Insights.
Version 2.0.4
PowerShell 7 wird offiziell unter Windows, Linux und Apple macOS unterstützt, wie im Abschnitt Voraussetzungen für das Exchange Online PowerShell-Modul in diesem Artikel beschrieben.
Das Modul in PowerShell 7 unterstützt browserbasiertes einmaliges Anmelden (Single Sign-On, SSO) und andere Anmeldemethoden. Weitere Informationen finden Sie unter Exklusive Verbindungsmethoden für PowerShell 7.
Die Cmdlets Get-UserAnalyticsConfig und Set-UserAnalyticsConfig wurden durch Get-MyAnalyticsConfig und Set-MyAnalyticsConfig ersetzt. Darüber hinaus können Sie den Zugriff auf Featureebene konfigurieren. Weitere Informationen finden Sie unter Konfigurieren von MyAnalytics.
Richtlinien- und Sicherheitsdurchsetzung in Echtzeit bei allen benutzerbasierten Authentifizierungen. Die fortlaufende Zugriffsevaluierung (Continuous Access Evaluation, CAE) ist im Modul aktiviert. Weitere Informationen zu CAE finden Sie hier.
Die Eigenschaften LastUserActionTime und LastInteractionTime sind jetzt in der Ausgabe des Cmdlets Get-EXOMailboxStatistics verfügbar.
Der interaktive Anmeldeprozess verwendet jetzt eine sicherere Methode zum Abrufen von Zugriffstoken unter Verwendung sicherer Antwort-URLs.
Version 2.0.3
- Allgemeine Verfügbarkeit der zertifikatbasierten Authentifizierung (CBA), die die Verwendung von moderner Authentifizierung bei unbeaufsichtigten Skripting- oder Hintergrundautomatisierungsszenarios ermöglicht. Die verfügbaren Zertifikatspeicherorte sind:
- Remote im Parameter „Azure Key Value“ (das Zertifikat). Mit dieser Option wird die Sicherheit verbessert, da das Zertifikat nur zur Laufzeit abgerufen wird.
- Lokal im CurrentUser- oder LocalMachine-Zertifikatspeicher (der CertificateThumbprint-Parameter).
- Lokal in einer exportierten Zertifikatdatei (der CertificateFilePath- und der CertificatePassword-Parameter). Weitere Informationen finden Sie in den Parameterbeschreibungen unter Connect-ExchangeOnline und reine App-Authentifizierung für unbeaufsichtigte Skripts im Exchange Online PowerShell-Modul.
- Verbinden Sie sich in einem einzigen PowerShell-Fenster gleichzeitig mit Exchange Online PowerShell und Security & Compliance PowerShell.
- Der neue CommandName-Parameter ermöglicht es Ihnen, die in einer Sitzung importierten Exchange Online PowerShell-Cmdlets anzugeben und einzuschränken. Diese Option verringert den Speicherbedarf für PowerShell-Anwendungen mit hoher Auslastung.
- Get-EXOMailboxFolderPermission unterstützt jetzt ExternalDirectoryObjectID im Parameter Identity.
- Die optimierte Latenz des ersten V2-Cmdlet-Aufrufs. Laborergebnisse zeigen, dass die erste Aufrufwartezeit von 8 Sekunden auf ungefähr 1 Sekunde reduziert wurde. Die tatsächlichen Ergebnisse hängen von der Größe des Cmdlet-Ergebnisses und der Mandantenumgebung ab.
Version 1.0.1
- GA-Version (allgemeine Verfügbarkeit) des EXO PowerShell V2-Moduls. Es ist stabil und bereit für den Einsatz in Produktionsumgebungen.
- Das Cmdlet Get-EXOMobileDeviceStatistics unterstützt nun den Parameter Identity.
- Erhöhte Zuverlässigkeit der automatischen Wiederbindung von Sitzungen in bestimmten Fällen, in denen ein Skript für ~50 Minuten ausgeführt wurde und aufgrund eines Fehlers in der Logik für die automatische Wiederverbindung eine Fehlermeldung vom Typ "Cmdlet nicht gefunden" angezeigt wurde.
- Datentypfehler bei zwei häufig verwendeten "User" und "MailboxFolderUser"-Attributen zur einfachen Migration von Skripts behoben.
- Verbesserte Unterstützung von Filtern, da jetzt vier weitere Operatoren unterstützt werden: EndsWith, Contains, Not und NotLike support. Überprüfen Sie filter im Exchange Online PowerShell-Modul auf Attribute, die in Filtern nicht unterstützt werden.
Version 0.4578.0
- Unterstützung für die Konfiguration von Briefing-E-Mails für Ihre Organisation auf Benutzerebene mit Set-UserBriefingConfig- und Get-UserBriefingConfig-Cmdlets hinzugefügt.
- Unterstützung für die Sitzungsbereinigung mithilfe des Disconnect-ExchangeOnline-Cmdlets. Bei diesem Cmdlet handelt es sich um das V2-Äquivalent von
Get-PSSession | Remove-PSSession
. Zusätzlich zum Löschen von Sitzungsobjekten und lokalen Dateien wird auch das Zugriffstoken aus dem Cache entfernt, das für die Authentifizierung bei V2-Cmdlets verwendet wird. - Sie können
FolderId
jetzt als Identitätsparameter in Get-EXOMailboxFolderPermission verwenden. Sie können denFolderId
-Wert mithilfe von Get-MailboxFolder abrufen. Zum Beispiel:Get-MailboxFolderPermission -Identity <UPN>:<Folder-Path>
Get-MailboxFolderPermission -Identity <UPN>:\<Folder-Id>
- Verbesserte Zuverlässigkeit von Get-EXOMailboxStatistics , da bestimmte Anforderungsroutingfehler, die zu Fehlern geführt haben, behoben wurden.
- Optimierte Speicherauslastung, wenn eine Sitzung durch erneutes Verwenden eines vorhandenen Moduls mit einer neuen Sitzung erstellt wird, anstatt jedes Mal, wenn eine Sitzung importiert wird, ein neues Modul zu erstellen.
Version 0.4368.1
- Unterstützung für Security & Compliance PowerShell-Cmdlets mit dem Connect-IPPSSession Cmdlet hinzugefügt.
- Das Ankündigungsbanner kann mit dem Schalter ShowBanner (
-ShowBanner:$false
) ausgeblendet werden. - Beenden Sie die Ausführung des Cmdlets für Client-Ausnahmen.
- Remote-PowerShell enthielt verschiedene komplexe Datentypen, die in EXO-Cmdlets absichtlich nicht unterstützt wurden, um die Leistung zu verbessern. Unterschiede bei nicht komplexen Datentypen zwischen Remote-PowerShell-Cmdlets und V2-Cmdlets wurden behoben, um eine nahtlose Migration von Verwaltungsskripts zu ermöglichen.
Version 0.3582.0
- Unterstützung für Präfixe während der Sitzungserstellung:
- Sie können jeweils nur eine Sitzung erstellen, die Cmdlets mit Präfix enthält.
- EXO V2-Cmdlets haben kein Präfix, da sie bereits über das Präfix EXO verfügen. Verwenden Sie
EXO
daher nicht als Präfix.
- Verwenden Sie EXO V2-Cmdlets, auch wenn die WinRM-Standardauthentifizierung auf dem Clientcomputer deaktiviert ist. Remote-PowerShell-Verbindungen erfordern WinRM Basic-Authentifizierung, und PowerShell-Remote-Cmdlets sind nicht verfügbar, wenn die Standardauthentifizierung in WinRM deaktiviert ist.
- Der Identitätsparameter für V2-Cmdlets unterstützt jetzt Name und Alias. Die Verwendung von Alias oder Name verlangsamt die Leistung von V2-Cmdlets, daher wird davon abgeraten, sie zu verwenden.
- Ein Problem wurde behoben, bei dem sich der Datentyp der vom V2-Cmdlet zurückgegebenen Attribute von jenem von Remote-PowerShell-Cmdlets unterschied. Wir verfügen immer noch über wenige Attribute mit unterschiedlichen Datentypen, und wir planen, diese in den kommenden Monaten zu verarbeiten.
- Fehler behoben: Häufiges Verbindungsproblem bei sitzungen, wenn Connect-ExchangeOnline mit Anmeldeinformationen oder UserPrincipalName aufgerufen wurde
Version 0.3555.1
- Ein Fehler wurde behoben, bei dem mittels Pipeline übertragene Cmdlets aufgrund eines Authentifizierungsproblems mit folgendem Fehler fehlschlugen:
Die Pipeline kann nicht aufgerufen werden, da sich der Runspace nicht im Zustand Geöffnet befindet. Der aktuelle Status des Runspace ist "geschlossen".
Version 0.3527.4
- Aktualisierte Get-Help-Inhalte.
- Es wurde ein Problem in Get-Help behoben, bei dem der Online-Parameter zu einer nicht vorhandenen Seite mit dem Fehlercode 400 umgeleitet wurde.
Version 0.3527.3
- Unterstützung für die Verwaltung von Exchange für einen anderen Mandanten mittels Delegierungsfluss hinzugefügt.
- Funktioniert zusammen mit anderen PowerShell-Modulen in einem einzelnen PowerShell-Fenster.
- Unterstützung für Positionsparameter wurde hinzugefügt.
- Das Feld "Datum/Uhrzeit" unterstützt jetzt das Clientgebietsschema.
- Bug behoben: PSCredential leer, wenn während Connect-ExchangeOnline übergeben.
- Bug behoben: Client-Modulfehler, wenn Filter $null enthielt.
- Sitzungen, die im EXO V2-Modul erstellt wurden, weisen nun Namen auf (Benennungsmuster: ExchangeOnlineInternalSession_%SomeNumber%).
- Fehlerbehebung: Remote-PowerShell-Cmdlets treten aufgrund des Zeitunterschieds zwischen Tokenablauf und Sitzungsablauf im Leerlauf zeitweilig fehl.
- Größeres Sicherheitsupdate.
- Bugfixes und Verbesserungen.