Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel enthält Anweisungen zum Herstellen einer Verbindung mit Security & Compliance PowerShell mithilfe des Exchange Online PowerShell-Moduls mit oder ohne mehrstufige Authentifizierung (MFA).
Das Exchange Online PowerShell-Modul verwendet moderne Authentifizierung für die Verbindung mit Exchange Online PowerShell und Security & Compliance PowerShell. Weitere Informationen zum PowerShell-Modul von Exchange Online finden Sie unter Informationen zum PowerShell-Modul von Exchange Online.
Informationen zum Herstellen einer Verbindung mit Security & Compliance PowerShell für die Automatisierung finden Sie unter Nur-App-Authentifizierung für unbeaufsichtigte Skripts.
Was sollten Sie wissen, bevor Sie beginnen?
Die Anforderungen für die Installation und Verwendung des Moduls werden unter Voraussetzungen für das Exchange Online PowerShell-Modul und Unterstützte Betriebssysteme für das Exchange Online PowerShell-Modul beschrieben.
Nach dem Herstellen einer Verbindung steuert die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) die Cmdlets und Parameter, auf die Sie Zugriff haben oder nicht. Weitere Informationen finden Sie unter Berechtigungen im Microsoft Defender-Portal und Berechtigungen im Microsoft Purview-Portal.
Schritt 1: Laden des Exchange Online PowerShell-Moduls
Hinweis
Wenn das Modul bereits installiert ist, können Sie diesen Schritt normalerweise überspringen und Connect-IPPSSession ausführen, ohne es zuerst manuell zu laden.
Nachdem Sie das Modul installiert haben, öffnen Sie ein PowerShell-Fenster, und laden Sie das Modul, indem Sie den folgenden Befehl ausführen:
Import-Module ExchangeOnlineManagement
Schritt 2: Verbinden und authentifizieren
Hinweis
Verbindungsbefehle schlagen wahrscheinlich fehl, wenn der Profilpfad des Kontos, das Sie zum Herstellen der Verbindung verwendet haben,
$PowerShell-Sonderzeichen enthält (z. B. ). Die Problemumgehung besteht darin, eine Verbindung mithilfe eines anderen Kontos herzustellen, das keine Sonderzeichen im Profilpfad enthält.Wenn Sie eDiscovery-Cmdlets (*-ComplianceSearch oder New-ComplianceSearchAction) ausführen möchten, muss die Verbindung die folgenden Anforderungen erfüllen:
Version 3.9.0 (August 2025) oder höher des Exchange Online PowerShell-Moduls.
Der Befehl connect muss den Schalter EnableSearchOnlySession enthalten.
Wenn Ihre PowerShell-Verbindung mit Security & Compliance diese Anforderungen nicht erfüllt, wird beim Versuch, eDiscovery-Cmdlets auszuführen, der folgende Fehler angezeigt:
Please close the current PowerShell session and open a new session using Connect-IPPSSession with the -EnableSearchOnlySession flag. This requires using ExchangeOnlineManagement v3.9.0 or higher.
Die Syntax des Befehls, den Sie ausführen müssen, sieht so aus:
Connect-IPPSSession -UserPrincipalName <UPN> [-ConnectionUri <URL>] [-AzureADAuthorizationEndpointUri <URL>] [-DelegatedOrganization <String>] [-PSSessionOption $ProxyOptions] [-EnableSearchOnlySession]
Ausführliche Informationen zu Syntax und Parametern finden Sie unter Connect-IPPSSession.
<UPN> ist Ihr Konto im Benutzerprinzipalnamensformat (z. B
navin@contoso.onmicrosoft.com. ).Die erforderlichen Werte für "ConnectionUri" und "AzureADAuthorizationEndpointUri" hängen von der Art Ihrer Microsoft 365-Organization ab. Allgemeine Werte werden in der folgenden Liste beschrieben:
-
Microsoft 365 oder Microsoft 365 GCC:
-
ConnectionUri: None. Der erforderliche Wert
https://ps.compliance.protection.outlook.com/powershell-liveid/ist gleichzeitig der Standardwert, sodass Sie den Parameter "ConnectionUri " in Microsoft 365- oder Microsoft 365 GCC-Umgebungen nicht verwenden müssen. -
AzureADAuthorizationEndpointUri: None. Der erforderliche Wert
https://login.microsoftonline.com/organizations, ist jedoch auch der Standardwert, sodass Sie den Parameter AzureADAuthorizationEndpointUri in Microsoft 365- oder Microsoft 365 GCC-Umgebungen nicht verwenden müssen.
-
ConnectionUri: None. Der erforderliche Wert
-
Microsoft 365 GCC Hoch:
-
Verbindungs-URI:
https://ps.compliance.protection.office365.us/powershell-liveid/ -
AzureADAuthorizationEndpointUri:
https://login.microsoftonline.us/organizations*
-
Verbindungs-URI:
-
Microsoft 365 DoD:
-
Verbindungs-URI:
https://l5.ps.compliance.protection.office365.us/powershell-liveid/ -
AzureADAuthorizationEndpointUri:
https://login.microsoftonline.us/organizations*
-
Verbindungs-URI:
-
Office 365, betrieben von 21Vianet:
-
Verbindungs-URI:
https://ps.compliance.protection.partner.outlook.cn/powershell-liveid -
AzureADAuthorizationEndpointUri:
https://login.chinacloudapi.cn/organizations*
-
Verbindungs-URI:
* Der AzureADAuthorizationEndpointUri-Wert , der auf
/organizations"Nur Geschäfts-, Schul- oder Unikonten" endet. Der ältere URI-Wert, der auf/commonFolgendes endet, funktioniert weiterhin, fordert Sie jedoch möglicherweise auf, zwischen einem persönlichen Konto und einem Geschäfts-, Schul- oder Unikonto auszuwählen. Wir empfehlen den/organizationsURI-Wert in Unternehmensszenarien, in denen Heimanwenderkonten ausgeschlossen werden sollen.-
Microsoft 365 oder Microsoft 365 GCC:
Wenn Sie sich hinter einem Proxyserver befinden, können Sie den Parameter PSSessionOption im Verbindungsbefehl verwenden. Führen Sie zunächst den folgenden Befehl aus:
$ProxyOptions = New-PSSessionOption -ProxyAccessType <Value>, wobei Wert <> istIEConfig,WinHttpConfig, oderAutoDetect. Verwenden Sie dann den Wert$ProxyOptionsfür den Parameter PSSessionOption . Weitere Informationen finden Sie unter New-PSSessionOption.Je nach Art Ihrer Organisation können Sie den Parameter UserPrincipalName möglicherweise im nächsten Schritt weglassen. Geben Sie stattdessen den Benutzernamen und das Kennwort ein, oder wählen Sie gespeicherte Anmeldeinformationen aus, nachdem Sie den Befehl Connect-IPPSSession ausgeführt haben. Wenn dies nicht funktioniert, müssen Sie den Parameter UserPrincipalName verwenden.
Wenn keine MFA verwendet wird, kann häufig der Parameter Credential anstelle des Parameters UserPrincipalName verwendet werden. Führen Sie zuerst den Befehl
$Credential = Get-Credentialaus, geben Sie Ihren Benutzernamen und Ihr Kennwort ein, und verwenden Sie dann den Variablennamen für den Credential-Parameter (-Credential $Credential). Wenn dies nicht funktioniert, müssen Sie den Parameter UserPrincipalName verwenden.
Herstellen einer Verbindung mit Security & Compliance PowerShell mit einer interaktiven Anmeldeaufforderung
Die folgenden Beispiele funktionieren in Windows PowerShell 5.1 und PowerShell 7 für Konten mit oder ohne MFA:
In diesem Beispiel wird eine Verbindung zur Security & Compliance PowerShell in einer Microsoft 365- oder Microsoft 365 GCC-Organisation hergestellt:
Connect-IPPSSession -UserPrincipalName navin@contoso.onmicrosoft.comIn diesem Beispiel wird eine Verbindung zur Security & Compliance PowerShell in einer Microsoft GCC High-Organisation hergestellt:
Connect-IPPSSession -UserPrincipalName chris@govt.us -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizationsIn diesem Beispiel wird eine Verbindung zur Security & Compliance PowerShell in einer Microsoft 365 DoD-Organisation hergestellt:
Connect-IPPSSession -UserPrincipalName michelle@govt.mil -ConnectionUri https://l5.ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizationsIn diesem Beispiel wird eine Verbindung zur Security & Compliance PowerShell in einer von 21Vianet betriebenen Office 365-Organisation hergestellt:
Connect-IPPSSession -UserPrincipalName li@fabrikam.cn -ConnectionUri https://ps.compliance.protection.partner.outlook.cn/powershell-liveid -AzureADAuthorizationEndpointUri https://login.chinacloudapi.cn/organizations
Geben Sie im daraufhin geöffneten Anmeldefenster Ihr Kennwort ein, und wählen Sie dann "Anmelden" aus.
Hinweis
In PowerShell 7 wird standardmäßig browserbasiertes einmaliges Anmelden (Single Sign-On, SSO) verwendet, sodass die Anmeldeaufforderung in Ihrem Standardwebbrowser und nicht in einem eigenständigen Dialogfeld geöffnet wird.
Nur MFA: Ein Überprüfungscode wird basierend auf der für Ihr Konto konfigurierten Antwortoption (z. B. eine SMS oder die Microsoft Authenticator-App auf Ihrem Gerät) generiert und übermittelt.
Geben Sie im daraufhin angezeigten Überprüfungsfenster den Prüfcode ein, und wählen Sie dann "Verifizieren" aus.
Herstellen einer Verbindung mit Security & Compliance PowerShell ohne Anmeldeaufforderung (unbeaufsichtigte Skripts)
Vollständige Anweisungen finden Sie unter Nur-App-Authentifizierung für unbeaufsichtigte Skripts in Exchange Online PowerShell und Security & Compliance PowerShell.
Herstellen einer Verbindung mit Security & Compliance PowerShell in Kundenorganisationen
Die Verfahren in diesem Abschnitt erfordern Version 3.0.0 oder höher des Moduls.
In Security & Compliance PowerShell müssen Sie den AzureADAuthorizationEndpointUri mit dem Parameter DelegatedOrganization verwenden.
Weitere Informationen zu Partnern und Kundenorganisationen finden Sie in den folgenden Artikeln:
- Was ist das Cloud Solution Provider (CSP)-Programm?
- Einführung in Granulare delegierte Administratorrechte (GDAP)
Dieses Beispiel stellt in den folgenden Szenarien Verbindungen mit Kundenorganisationen her:
Stellen Sie über ein CSP-Konto eine Verbindung mit einer Kunden-organization her.
Stellen Sie mithilfe eines GDAP eine Verbindung mit einer Kunden-organization her.
Stellen Sie als Gast eine Verbindung mit einer Kunden-organization her.
Connect-IPPSSession -UserPrincipalName navin@contoso.onmicrosoft.com -DelegatedOrganization adatum.onmicrosoft.com -AzureADAuthorizationEndpointUri https://login.microsoftonline.com/adatum.onmicrosoft.com
Schritt 3: Trennen Sie die Verbindung, wenn Sie fertig sind
Stellen Sie sicher, dass Sie die Sitzung trennen, wenn Sie fertig sind. Wenn Sie das PowerShell-Fenster schließen, ohne die Verbindung zu trennen, können Sie alle verfügbaren Sitzungen aufbrauchen und müssen warten, bis die Sitzungen ablaufen. Führen Sie den folgenden Befehl aus, um die Sitzung zu trennen:
Disconnect-ExchangeOnline
Führen Sie den folgenden Befehl aus, um die Verbindung ohne Bestätigungsaufforderung im Hintergrund zu trennen:
Disconnect-ExchangeOnline -Confirm:$false
Hinweis
Der Trennungsbefehl schlägt wahrscheinlich fehl, wenn der Profilpfad des Kontos, das Sie zum Herstellen der Verbindung verwendet haben, $PowerShell-Sonderzeichen enthält (z. B. ). Die Problemumgehung besteht darin, eine Verbindung mithilfe eines anderen Kontos herzustellen, das keine Sonderzeichen im Profilpfad enthält.
Woran erkennen Sie, dass Sie erfolgreich verbunden sind?
Die Security & Compliance PowerShell-Cmdlets werden in Ihre lokale Windows PowerShell-Sitzung importiert, und der Fortschritt wird in der Statusleiste angezeigt. Wenn Sie keine Fehlermeldungen erhalten, wurde die Verbindung erfolgreich hergestellt. Als schnellen Test können Sie ein Security & Compliance PowerShell-Cmdlet ausführen, beispielsweise Get-RetentionCompliancePolicy, und die Ergebnisse überprüfen.
Wenn Sie Fehlermeldungen erhalten, überprüfen Sie die folgenden Anforderungen:
Ein häufig auftretendes Problem ist ein falsches Kennwort. Führen Sie die drei Schritte erneut durch, und achten Sie besonders auf die Eingabe des verwendeten Benutzernamens und Kennworts.
Das Konto, das Sie zum Herstellen der Verbindung verwenden, muss für PowerShell aktiviert sein. Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren des Zugriffs auf Exchange Online PowerShell.
Der TCP-Port 80 muss für den Datenverkehr zwischen Ihrem lokalen Computer und Microsoft 365 geöffnet sein. Er ist wahrscheinlich offen, es kann jedoch vorkommen, dass Ihre Organisation eine eingeschränkte Internetzugriffsrichtlinie verfolgt.
REST-basierte Verbindungen mit Security & Compliance PowerShell erfordern das PowerShellGet-Modul. Aufgrund der Abhängigkeit erfordert das PowerShellGet-Modul das PackageManagement-Modul. Sie erhalten Fehler, wenn Sie versuchen, eine Verbindung herzustellen, ohne beide Module installiert zu haben. Beispielsweise kann der folgende Fehler angezeigt werden:
Der Begriff "Update-ModuleManifest" wird nicht als Name eines Cmdlets, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, überprüfen Sie, ob ein Pfad enthalten war und ob der Pfad korrekt ist, und versuchen Sie es erneut.
Weitere Informationen zu den Modulanforderungen für PowerShellGet und PackageManagement finden Sie unter PowerShellGet für REST-basierte Verbindungen in Windows.
Möglicherweise können Sie keine Verbindung herstellen, wenn sich Ihre Client-IP-Adresse während der Verbindungsanforderung ändert. Der Fehler tritt auf, wenn Ihre organization einen SNAT-Pool (Source Network Address Translation) mit mehreren IP-Adressen verwendet. Der Verbindungsfehler sieht wie folgt aus:
Die Anforderung für die Windows Remote Shell mit der ShellId-ID <> ist fehlgeschlagen, da die Shell auf dem Server nicht gefunden wurde. Mögliche Ursachen sind: Die angegebene Shell-ID ist falsch, oder die Shell ist nicht mehr auf dem Server vorhanden. Stellen Sie die richtige Shell-ID bereit, oder erstellen Sie eine neue Shell, und wiederholen Sie den Vorgang.
Führen Sie einen der folgenden Schritte aus, um das Problem zu beheben:
- Verwenden Sie einen SNAT-Pool, der eine einzelne IP-Adresse enthält.
- Erzwingen Sie die Verwendung einer bestimmten IP-Adresse für Verbindungen mit dem Security & Compliance PowerShell-Endpunkt.