Verbinden mit PowerShell in Exchange Online Protection

Das Exchange Online PowerShell V2-Modul (abgekürzt als EXO V2-Modul) verwendet die moderne Authentifizierung und funktioniert mit der mehrstufigen Authentifizierung (Multi-Factor Authentication, MFA) zum Herstellen einer Verbindung mit allen Exchange-bezogenen PowerShell-Umgebungen in Microsoft 365: Exchange Online PowerShell, Security & Compliance PowerShell sowie PowerShell in eigenständigem Exchange Online Protection (EOP). Weitere Informationen zum EXO V2-Modul finden Sie unter Exchange Online PowerShell V2-Modul.

Dieser Artikel enthält Anweisungen zum Herstellen einer Verbindung mit Exchange Online Protection PowerShell mithilfe des EXO V2-Moduls mit oder ohne MFA.

Wenn Sie die älteren, weniger sicheren Anweisungen zur Remote-PowerShell-Verbindung verwenden möchten, die möglicherweise veraltet sind, finden Sie entsprechende Informationen unter Standardauthentifizierung – Verbinden mit PowerShell in Exchange Online Protection.

Was sollten Sie wissen, bevor Sie beginnen?

  • Die Verfahren in diesem Artikel gelten nur für Microsoft 365-Organisationen, die keine Exchange Online-Postfächer haben. So haben Sie beispielsweise ein eigenständiges EOP-Abonnement, das Ihre lokale E-Mail-Umgebung schützt. Wenn Ihr Microsoft 365-Abonnement Exchange Online-Postfächer enthält, können Sie keine Verbindung mit EOP PowerShell herstellen. Stattdessen stellen Sie eine Verbindung mit Exchange Online PowerShell her.

    Wenn Ihre Organisation lokales Exchange verwendet und Sie Exchange Enterprise CAL mit-Dienstlizenzen für EOP haben, sind Ihre EOP PowerShell-Verbindungsanweisungen identisch mit Exchange Online PowerShell. Verwenden Sie (statt der Anweisungen in diesem Artikel) die Anweisungen für die Exchange Online PowerShell-Verbindung in Herstellen einer Verbindung mit Exchange Online PowerShell.

  • Die Anforderungen für die Installation und Verwendung des EXO V2-Moduls sind in Installieren und Verwalten des EXO V2-Moduls beschrieben. Bei den restlichen Anweisungen in diesem Artikel wird davon ausgegangen, dass Sie das Modul bereits installiert haben.

  • Nachdem Sie eine Verbindung hergestellt haben, wird über die rollenbasierte Zugriffssteuerung (RBAC) gesteuert, auf welche Cmdlets und Parameter Sie Zugriff haben bzw. nicht haben. Weitere Informationen finden Sie unter Berechtigungen im eigenständigen EOP.

Tipp

Liegt ein Problem vor? Bitten Sie im Exchange Online Protection-Forum um Hilfe.

Herstellen einer Verbindung mit Exchange Online Protection PowerShell per MFA und moderner Authentifizierung

Wenn Ihr Konto die mehrstufige Authentifizierung verwendet, führen Sie die Schritte in diesem Abschnitt aus. Andernfalls wechseln Sie zum Abschnitt Herstellen einer Verbindung mit Exchange Online Protection PowerShell per moderner Authentifizierung.

  1. Laden Sie in einem Windows PowerShell-Fenster das EXO V2-Modul, indem Sie den folgenden Befehl ausführen:

    Import-Module ExchangeOnlineManagement
    

    Hinweis

    Wenn Sie das EXO V2-Modul bereits installiert haben, funktioniert der vorherige Befehl wie beschrieben.

  2. Die Syntax des Befehls, den Sie ausführen müssen, sieht so aus:

    Connect-IPPSSession -UserPrincipalName <UPN> [-ConnectionUri <URL>] [-AzureADAuthorizationEndPointUri <URL>] [-PSSessionOption $ProxyOptions]
    
    • <UPN> ist Ihr Konto im Benutzerprinzipalnamen-Format (z. B. navin@contoso.com).
    • Die erforderlichen Werte für ConnectionUri und AzureADAuthorizationEndPointUrl sind abhängig von der Art Ihrer Microsoft 365-Organisation. Weitere Informationen finden Sie unter den Parameterbeschreibungen in Connect-IPPSSession.
    • Wenn Sie sich hinter einem Proxyserver befinden, führen Sie zuerst diesen Befehl aus: $ProxyOptions = New-PSSessionOption -ProxyAccessType <Value>, wobei <Value> den Wert IEConfig, WinHttpConfig oder AutoDetect annehmen kann. Verwenden Sie dann den PSSessionOption-Parameter mit dem Wert $ProxyOptions. Weitere Informationen finden Sie unter New-PSSessionOption.

    In diesem Beispiel wird eine Verbindung mit Exchange Online Protection PowerShell in einer Microsoft 365-Organisation hergestellt:

    Connect-IPPSSession -UserPrincipalName navin@contoso.com -ConnectionUri https://ps.protection.outlook.com/powershell-liveid/
    

Ausführliche Informationen zu Syntax und Parametern finden Sie unter Connect-IPPSSession.

Hinweis

Stellen Sie sicher, dass die Remote-PowerShell-Sitzung getrennt wird, wenn Sie alle Aufgaben ausgeführt haben. Wenn Sie das Windows PowerShell-Fenster schließen, ohne die Sitzung zu trennen, verbrauchen Sie möglicherweise alle Remote-PowerShell-Sitzungen, die Ihnen zur Verfügung stehen, und müssen darauf warten, dass die Sitzungen ablaufen. Führen Sie den folgenden Befehl aus, um die Remote-PowerShell-Sitzung zu trennen.

Disconnect-ExchangeOnline

Herstellen einer Verbindung mit Exchange Online Protection PowerShell per moderner Authentifizierung

Wenn Ihr Konto nicht die mehrstufige Authentifizierung verwendet, führen Sie die Schritte in diesem Abschnitt aus.

  1. Laden Sie in einem Windows PowerShell-Fenster das EXO V2-Modul, indem Sie den folgenden Befehl ausführen:

    Import-Module ExchangeOnlineManagement
    

    Hinweis

    Wenn Sie das EXO V2-Modul bereits installiert haben, funktioniert der vorherige Befehl wie beschrieben.

  2. Führen Sie den folgenden Befehl aus:

    Hinweis

    Sie können diesen Schritt überspringen und den Parameter Credential im nächsten Schritt weglassen, um nach der Ausführung des Befehls Connect-IPPSSession zur Eingabe des Benutzernamens und des Kennworts aufgefordert zu werden. Wenn Sie den Parameter Credential weglassen und im nächsten Schritt den Parameter UserPrincipalName einfügen, werden Sie nach Ausführung des Befehls Connect-IPPSSession nur zur Eingabe des Kennworts aufgefordert.

    $UserCredential = Get-Credential
    

    Geben Sie im angezeigten Dialogfeld Bei Windows PowerShell anmelden Ihr Geschäfts-, Schul- oder Unikonto und das Kennwort ein, und klicken Sie dann auf OK.

  3. Die Syntax des letzten Befehls, den Sie ausführen müssen, sieht so aus:

    Connect-IPPSSession [-Credential $UserCredential] -ConnectionUri <URL> [-PSSessionOption $ProxyOptions]
    
    • Der erforderliche Wert für ConnectionUri ist abhängig von der Art Ihrer Microsoft 365-Organisation. Weitere Informationen finden Sie unter der Parameterbeschreibung in Connect-IPPSSession.
    • Wenn Sie sich hinter einem Proxyserver befinden, speichern Sie die Ausgabe des Cmdlets New-PSSessionOption in einer Variablen (z. B. $ProxyOptions = New-PSSessionOption -ProxyAccessType <Value> [-ProxyAuthentication <Value>] [-ProxyCredential <Value>]). Verwenden Sie die Variable ($ProxyOptions) dann als Wert für den Parameter PSSessionOption.

    In diesem Beispiel wird eine Verbindung mit Exchange Online Protection PowerShell in einer Microsoft 365-Organisation hergestellt:

    Connect-IPPSSession -Credential $UserCredential -ConnectionUri https://ps.protection.outlook.com/powershell-liveid/
    

Ausführliche Informationen zu Syntax und Parametern finden Sie unter Connect-IPPSSession.

Hinweis

Stellen Sie sicher, dass die Remote-PowerShell-Sitzung getrennt wird, wenn Sie alle Aufgaben ausgeführt haben. Wenn Sie das Windows PowerShell-Fenster schließen, ohne die Sitzung zu trennen, verbrauchen Sie möglicherweise alle Remote-PowerShell-Sitzungen, die Ihnen zur Verfügung stehen, und Sie müssen darauf warten, dass die Sitzungen ablaufen. Führen Sie den folgenden Befehl aus, um die Remote-PowerShell-Sitzung zu trennen:

Disconnect-ExchangeOnline

Woher wissen Sie, dass dieses Verfahren erfolgreich war?

Die Exchange Online Protection-Cmdlets werden in Ihre lokale Windows PowerShell-Sitzung importiert und der Fortschritt des Importvorgangs wird in einer Statusanzeige dargestellt. Wenn Sie keine Fehlermeldungen erhalten, wurde die Verbindung erfolgreich hergestellt. Ein schneller Test ist die Ausführung eines Exchange Online Protection-Cmdlets, z. B. von Get-TransportRule, und die Betrachtung der Ergebnisse.

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 aus, und achten Sie besonders auf den Benutzernamen und das Kennwort, das Sie verwenden.

  • Um die Abwehr von DoS-Angriffen (Denial of Service) zu unterstützen, ist die Anzahl der offenen PowerShell-Remoteverbindungen mit Exchange Online Protection auf fünf beschränkt.

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

  • Das Konto, das Sie zum Herstellen einer Verbindung mit Exchange Online Protection PowerShell verwenden, muss als E-Mail-Benutzer in EOP (manuell oder durch Verzeichnissynchronisierung erstellt) vorhanden sein. Wenn das Konto im Exchange Admin Center (EAC) nicht als E-Mail-Benutzer unter Empfänger > Kontakte angezeigt wird, wird beim Versuch, eine Verbindung herzustellen, die folgende Fehlermeldung angezeigt:

    Import-PSSession: In Remotesitzung ausgeführter Befehl Get-Command meldet den folgenden Fehler: Beim Ausführen von Daten für einen Remotebefehl ist folgender Fehler aufgetreten: Fehler bei der Anforderung für die Windows-Remoteshell mit der Shell-ID <GUID>, weil die Shell nicht auf dem Server 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.

  • Möglicherweise können Sie keine Verbindung herstellen, wenn sich Ihre Client-IP-Adresse während der Verbindungsanforderung ändert. Dies kann vorkommen, wenn in Ihrer Organisation ein SNAT-Pool (Source Network Address Translation, Quell-Netzwerkadressenübersetzung) verwendet wird, der mehrere IP-Adressen enthält. Der Verbindungsfehler sieht wie folgt aus:

    Fehler bei der Anforderung für die Windows-Remoteshell mit der Shell-ID <ID>, weil die Shell nicht auf dem Server 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.

    Um das Problem zu beheben, verwenden Sie einen SNAT-Pool mit einer einzelnen IP-Adresse, oder erzwingen Sie die Verwendung einer bestimmten IP-Adresse für Verbindungen mit dem PowerShell-Endpunkt von Exchange Online Protection.