Verbindung zu Exchange Online PowerShell herstellen: Schritt-für-Schritt-Anleitung

Von Mirko Peters · 2026-11-12

Mit Connect-ExchangeOnline eine Verbindung zu Exchange Online PowerShell herstellen: Voraussetzungen, interaktive Anmeldung, MFA, Optionen für Partner und unbeaufsichtigte Ausführung sowie Lösungen für Fehler.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Um eine Verbindung zu Exchange Online PowerShell herzustellen, laden Sie das Modul ExchangeOnlineManagement und führen Sie Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com aus. Es öffnet sich ein Anmeldefenster, Sie geben Ihr Kennwort ein und bestätigen die MFA-Abfrage, danach ist die Shell verbunden. Dieser Artikel richtet sich an Exchange- und Microsoft-365-Administratoren, die die genauen Schritte, die Optionen für den Zugriff durch Partner und unbeaufsichtigte Skripte sowie eine kurze Liste von Lösungen für fehlgeschlagene Verbindungen benötigen. Er folgt der aktuellen Microsoft-Dokumentation, daher setzen die Befehle hier moderne Authentifizierung und keine Remote-PowerShell-Sitzung voraus.

Das Wichtigste in Kürze

• Um eine Verbindung zu Exchange Online PowerShell herzustellen, laden Sie das Modul und führen Connect-ExchangeOnline mit Ihrem Administratorkonto im UPN-Format aus.
• Die interaktive Anmeldung funktioniert mit und ohne Multifaktor-Authentifizierung. Sie brauchen also keine separate MFA-Umgehung.
• Die Standardauthentifizierung und die alte Methode New-PSSession werden nicht mehr unterstützt. Skripte, die darauf beruhen, müssen daher neu geschrieben werden.
• Nutzen Sie Get-AcceptedDomain als schnellen Test nach dem Verbinden und beenden Sie die Sitzung immer mit Disconnect-ExchangeOnline.
• Unbeaufsichtigte Skripte sollten App-only-Authentifizierung oder eine verwaltete Identität verwenden, statt ein gespeichertes Kennwort zu hinterlegen.

Was Sie vor der Verbindung benötigen

Der Verbindungsbefehl stammt aus dem Modul, daher muss das Modul zuerst installiert sein. Falls noch nicht geschehen, installieren Sie es über die PowerShell Gallery mit Install-Module -Name ExchangeOnlineManagement. In der Microsoft-Dokumentation heißt das Modul V3-Modul. Microsoft unterstützt sowohl Windows PowerShell 5.1 als auch PowerShell 7. Für PowerShell 7 benötigen Sie Modulversion 2.0.4 oder höher.

Vier weitere Faktoren entscheiden darüber, ob die Verbindung funktioniert:

• Berechtigungen. Die rollenbasierte Zugriffssteuerung legt fest, welche Cmdlets Sie nach der Anmeldung ausführen dürfen. Die Verbindung ist nicht das Schwierige, sondern das Ausführen des richtigen Cmdlets. Microsoft hat eine Seite, auf der Sie die erforderlichen Berechtigungen eines Cmdlets nachschlagen können. Sie lohnt sich als Lesezeichen.
• PowerShell-Zugriff für das Konto. Das Konto muss die Verwendung von Exchange Online PowerShell erlauben. Wenn ein Administrator dies für Ihren Benutzer deaktiviert hat, gelingt die Anmeldung zwar, die Verbindung aber nicht.
• Netzwerk. Zwischen Ihrem Computer und Microsoft 365 muss der TCP-Port 80 geöffnet sein.
• Ein unproblematischer Profilpfad. Laut Microsoft können Verbindungsbefehle fehlschlagen, wenn der Pfad Ihres Benutzerprofils Sonderzeichen enthält, die PowerShell interpretiert, etwa $. Verwenden Sie gegebenenfalls ein anderes Konto, falls Ihres betroffen ist.

An WinRM müssen Sie nichts ändern. Aktuelle Verbindungen verwenden im Hintergrund REST, daher gilt der alte Rat, die Standardauthentifizierung in WinRM zu aktivieren, nicht mehr.

Verbindung zu Exchange Online PowerShell Schritt für Schritt herstellen

Dies ist die Standardmethode für die interaktive Anmeldung. Sie funktioniert in Windows PowerShell 5.1 und PowerShell 7 gleichermaßen, mit oder ohne Multifaktor-Authentifizierung.

1. Öffnen Sie ein neues PowerShell-Fenster. Ein frisches Fenster vermeidet Assembly-Konflikte mit anderen Modulen, die Sie zuvor in der Sitzung geladen haben.
2. Laden Sie das Modul mit Import-Module ExchangeOnlineManagement. Ist das Modul bereits installiert, können Sie laut Microsoft meist diesen Schritt überspringen und direkt zum Connect-Befehl gehen, da PowerShell das Modul automatisch lädt.
3. Führen Sie Connect-ExchangeOnline -UserPrincipalName admin@contoso.com aus, allerdings mit Ihrem eigenen Konto im UPN-Format. In manchen Organisationen können Sie -UserPrincipalName weglassen, dann werden Sie stattdessen zur Eingabe aufgefordert. Schlägt das fehl, fügen Sie den Parameter hinzu.
4. Geben Sie Ihr Kennwort im Anmeldefenster ein und wählen Sie Anmelden.
5. Verwendet Ihr Konto MFA, geben Sie den Bestätigungscode ein und wählen Sie Überprüfen. Der Code wird über Ihre konfigurierte Methode übermittelt, zum Beispiel per SMS oder über Microsoft Authenticator. In PowerShell 7 erfolgt die Anmeldung standardmäßig über Ihren Browser.
6. Warten Sie auf das Banner. Ohne Fehlermeldung sind Sie verbunden.

Das war alles. Derselbe Cmdlet-Aufruf verbindet Sie ohne zusätzliche Parameter auch mit PowerShell-Sitzungen für Microsoft 365 GCC. Nur für die anderen Clouds ist eine Einstellung erforderlich, die als Nächstes folgt.

Wenn Sie das Willkommensbanner nicht im Skriptprotokoll haben möchten, fügen Sie -ShowBanner:$false hinzu. Wenn Get-Help Hilfe für Exchange Online-Cmdlets anzeigen soll, fügen Sie -LoadCmdletHelp hinzu. Seit Modulversion 3.7.0 wird diese Hilfe nicht mehr standardmäßig geladen. Das überrascht viele, die das Modul aktualisieren und danach feststellen, dass Get-Help nahezu nichts zurückgibt.

Weitere Verbindungsmöglichkeiten: PowerShell 7, Partner und Clouds

Die Dokumentation beschreibt mehrere Varianten. Wählen Sie die passende für Ihre Situation.

PowerShell 7 ohne Browser. Führen Sie Connect-ExchangeOnline -Device aus. Der Befehl gibt eine Meldung aus, die Sie auffordert, https://microsoft.com/devicelogin zu öffnen und einen Code einzugeben. Das erledigen Sie auf einem anderen Gerät, melden sich an und bestätigen. Danach schließt die ursprüngliche Sitzung die Verbindung ab. Das funktioniert mit und ohne MFA und ist nützlich auf Servern oder Linux-Rechnern ohne Desktop.

PowerShell 7 mit Anmeldeinformationen in der Befehlszeile. Connect-ExchangeOnline -UserPrincipalName admin@contoso.com -InlineCredential funktioniert für Konten ohne MFA. Da die meisten Organisationen MFA für Administratoren vorschreiben, werden Sie diese Variante selten nutzen.

Windows PowerShell 5.1 mit einem Anmeldeobjekt. Für Konten ohne MFA können Sie zuerst $Credential = Get-Credential ausführen und danach Connect-ExchangeOnline -Credential $Credential. Microsoft weist darauf hin, dass Sie bei einem Fehler stattdessen -UserPrincipalName verwenden sollten.

Kundenmandanten als Partner. Partner im Cloud Solution Provider-Programm und Gastadministratoren fügen -DelegatedOrganization hinzu, zum Beispiel Connect-ExchangeOnline -UserPrincipalName admin@contoso.onmicrosoft.com -DelegatedOrganization adatum.onmicrosoft.com. Die Microsoft-Seite verweist für die Berechtigungsseite auf das Cloud Solution Provider-Programm und granulare delegierte Administratorberechtigungen (GDAP).

Regierungs- und regionale Clouds. -ExchangeEnvironmentName wählt die Umgebung aus. Der Standardwert ist O365Default, der Microsoft 365 und GCC abdeckt. Die dokumentierten Werte für die übrigen sind O365USGovGCCHigh, O365USGovDoD, O365GermanyCloud und O365China.

Skripte ohne Benutzerinteraktion. Hinterlegen Sie kein Administratorkennwort in einem Skript. Microsoft beschreibt zwei bessere Optionen. Eine verwaltete Identität, zum Beispiel Connect-ExchangeOnline -ManagedIdentity -Organization "contoso.onmicrosoft.com", eignet sich für Skripte, die in Azure laufen. Die appbasierte Authentifizierung mit einem Zertifikat eignet sich für alle übrigen Fälle. Der Parameter für den Zertifikat-Fingerprint wird nur unter Windows unterstützt. Die Einrichtung umfasst eine App-Registrierung in Microsoft Entra ID, die Anwendungsberechtigung Exchange.ManageAsApp mit Administratorzustimmung, ein Zertifikat und eine unterstützte Rolle, etwa Exchange-Administrator, für die App. Microsoft empfiehlt das Prinzip der minimalen Berechtigungen. Weisen Sie der App daher nicht die Rolle Globaler Administrator zu, solange sich das nicht vermeiden lässt. Halten Sie sich an Microsofts eigenen Artikel zur appbasierten Authentifizierung und nicht an eine verkürzte Fassung davon.

Fügen Sie in einem Windows-Dienst -SkipLoadingFormatData hinzu, um Fehler zu vermeiden. Wenn Fehler auftreten, die auf den Web Account Manager verweisen, bietet die Modulversion 3.7.2 oder neuer dafür den Schalter -DisableWAM.

Halten Sie Skripte schlank und begrenzen Sie, was Sie importieren.

Eine Verbindung importiert normalerweise alle Exchange-Online-Cmdlets, die Sie verwenden dürfen. Für einen schnellen Blick in ein Postfach ist das in Ordnung. Ein Skript, das drei Befehle benötigt, braucht aber nicht alle. Die Modulseite von Microsoft gibt dazu einen konkreten Tipp. Häufige Aufrufe von Connect-ExchangeOnline und Disconnect-ExchangeOnline in derselben Sitzung können zu einem Speicherleck führen. Die Lösung: Stellen Sie pro Skript nur einmal eine Verbindung her und verwenden Sie den Parameter -CommandName, um nur die benötigten Cmdlets zu importieren.

Ein Skript, das zum Beispiel nur Postfachstatistiken abruft, benötigt nur diesen einen Befehl. Nennen Sie die wenigen benötigten Befehle, stellen Sie oben einmal die Verbindung her, erledigen Sie die Arbeit und trennen Sie die Verbindung unten einmal. So geschriebene Skripte lassen sich leichter prüfen, weil die Verbindungszeile zeigt, welche Befehle das Skript verwendet.

Zwei weitere Gewohnheiten helfen in Teamumgebungen. Erstens: Halten Sie die Verbindungszeile an einer zentralen Stelle, etwa in einer kleinen Funktion. So müssen Sie eine Änderung der Authentifizierungsmethode nur einmal vornehmen und nicht in zwanzig Skripten. Zweitens: Protokollieren Sie das Konto oder den App-Namen, das bzw. der das Skript ausgeführt hat, aber niemals dessen Geheimnis. Wenn sich in einem Postfach unerwartet etwas ändert, spart Ihnen diese Protokollzeile oft Stunden.

Verbindung prüfen und sauber trennen

Eine Verbindung ohne Fehlermeldung ist ein gutes Zeichen. Testen Sie sie dennoch mit einem harmlosen Lesebefehl. Get-AcceptedDomain listet die Domänen Ihrer Organisation auf und ist in einer Sekunde ausgeführt. Wenn Domänen erscheinen, funktioniert Ihre Sitzung und Ihr Konto hat mindestens Leserechte.

Für Details zu Ihren Verbindungen verwenden Sie Get-ConnectionInformation. Die Modulseite von Microsoft weist darauf hin, dass Get-PSSession bei diesen REST-basierten Verbindungen nichts Brauchbares zurückgibt. Ältere Skripte, die Get-PSSession prüfen, müssen daher angepasst werden.

Führen Sie nach getaner Arbeit Disconnect-ExchangeOnline aus. In Skripten fügen Sie -Confirm:$false hinzu, um die Rückfrage zu unterdrücken. Microsoft warnt in seinem Artikel zur Verbindungsherstellung, dass das Schließen des Fensters ohne Trennung die verfügbaren Sitzungen aufbrauchen kann. Dann müssen Sie warten, bis sie ablaufen.

Die häufigsten Verbindungsfehler beheben

Die meisten Fehler haben eine kleine Zahl von Ursachen. Gehen Sie sie von oben nach unten durch.

• Falscher Benutzername oder falsches Kennwort. Wiederholen Sie die Schritte und prüfen Sie beide Angaben. Das klingt banal, aber prüfen Sie zuerst das Format des UPN.
• PowerShell-Zugriff ist für das Konto deaktiviert. Ein Administrator kann ihn aktivieren. Microsoft hat einen eigenen Artikel zum Aktivieren und Deaktivieren des Zugriffs auf Exchange Online PowerShell.
• Port 80 ist blockiert. Bitten Sie Ihr Netzwerkteam, TCP-Port 80 zu Microsoft 365 freizugeben.
• Föderiertes Konto mit nicht erreichbarem Identitätsanbieter. Wenn Ihr IDP oder STS nicht öffentlich erreichbar ist, empfiehlt Microsoft, für die Verbindung ein nicht föderiertes Konto in Microsoft 365 zu verwenden.
• „Der Begriff ‚Update-ModuleManifest‘ wurde nicht erkannt“. Die Verbindung benötigt PowerShellGet und dessen Abhängigkeit PackageManagement. Aktualisieren Sie beide und starten Sie PowerShell neu.
• "Could not load file or assembly 'System.IdentityModel.Tokens.Jwt'". Das Modul steht in Konflikt mit einem anderen Modul in derselben Sitzung. Stellen Sie die Verbindung in einem neuen Windows-PowerShell-Fenster her, bevor Sie etwas anderes importieren.
• Fehler in einem Fenster, das von einem Dienst oder einer geplanten Aufgabe geöffnet wurde. Versuchen Sie es mit -SkipLoadingFormatData.

Wenn keiner dieser Punkte zutrifft, ist die Modulversion der nächste Verdächtige. Führen Sie Update-Module -Name ExchangeOnlineManagement im selben Bereich aus, mit dem Sie das Modul installiert haben, und versuchen Sie es dann erneut in einem neuen Fenster.

Häufige Fehler

• Verwendung von Basic Authentication oder New-PSSession. Microsoft führt diese nur noch als historische Referenz auf und erklärt, dass sie nicht mehr unterstützt werden. Ein Skript, das noch auf diese Weise eine Sitzung aufbaut, muss auf Connect-ExchangeOnline umgestellt werden.
• Fenster schließen, statt die Verbindung zu trennen. Dadurch können Ihre Sitzungen erschöpft werden. Machen Sie Disconnect-ExchangeOnline zur letzten Zeile jedes Skripts.
• Ein Kennwort im Klartext in ein Skript schreiben. Verwenden Sie stattdessen eine verwaltete Identität oder ein Zertifikat.
• Andere Module vorab importieren. Ein Konflikt mit einem anderen Modul kann die Anmeldung unterbrechen. Stellen Sie zuerst die Verbindung zu Exchange Online her oder verwenden Sie ein neues Fenster.
• Verbindung mit Berechtigung gleichsetzen. Wenn ein Cmdlet nach dem Verbinden als „nicht erkannt“ gemeldet wird, enthält Ihre Rolle es nicht. Das ist eine Frage der RBAC und kein Verbindungsproblem.

Verwandte Themen zum Vertiefen

• Modul installieren und aktualisieren: Die Verbindung hängt vom passenden Modul und der passenden PowerShell-Version ab. Lesen Sie daher die Voraussetzungen des Exchange Online PowerShell-Moduls, bevor Sie es in einem Team ausrollen.
• Berechtigungen für ein Cmdlet ermitteln: Microsoft erklärt, wie Sie nachschlagen, welche Rolle ein bestimmtes Exchange-Cmdlet benötigt.
• Verbindung mit Security & Compliance PowerShell herstellen: Dasselbe Modul bietet Connect-IPPSSession, das in PowerShell 7 unter Linux oder macOS nicht verfügbar ist.
• Unbeaufsichtigte Automatisierung: App-only-Authentifizierung und verwaltete Identitäten sind der sichere Weg, geplante Exchange-Skripte auszuführen.
• Große Massenvorgänge: REST-basierte Cmdlets haben ein Timeout von 15 Minuten. Teilen Sie umfangreiche Mitgliederaktualisierungen daher in Batches auf.

Nächster Schritt

Um zuverlässig eine Verbindung mit Exchange Online PowerShell herzustellen, beginnen Sie mit einem neuen Fenster, führen Connect-ExchangeOnline -UserPrincipalName mit Ihrem Administratorkonto aus, testen mit Get-AcceptedDomain und trennen die Verbindung am Ende. Planen Sie Ihre unbeaufsichtigten Skripte anschließend rund um eine verwaltete Identität oder ein Zertifikat, damit niemand ein Kennwort eingeben oder speichern muss.