Łączenie z Exchange Online PowerShell: przewodnik krok po kroku

By Mirko Peters · 2026-11-12

Połącz się z Exchange Online PowerShell za pomocą Connect-ExchangeOnline: wymagania, logowanie interaktywne, uwierzytelnianie wieloskładnikowe, opcje dla partnerów i tryb bez nadzoru oraz rozwiązania typowych błędów.

Automatically translated with AI from the original post. Read the English original

Aby połączyć się z Exchange Online PowerShell, załaduj moduł ExchangeOnlineManagement i uruchom Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com. Otworzy się okno logowania, w którym podajesz hasło i potwierdzasz monit MFA, po czym powłoka jest połączona. Ten artykuł jest przeznaczony dla administratorów Exchange i Microsoft 365, którzy potrzebują dokładnych kroków, opcji dostępu dla partnerów i w trybie bez nadzoru oraz krótkiej listy rozwiązań, gdy połączenie się nie udaje. Opiera się na aktualnej dokumentacji Microsoft, dlatego opisane tu polecenia zakładają nowoczesne uwierzytelnianie i brak sesji zdalnego programu PowerShell.

Najważniejsze wnioski

• Aby połączyć się z Exchange Online PowerShell, załaduj moduł i uruchom Connect-ExchangeOnline, podając konto administratora w formacie UPN.
• Logowanie interaktywne działa zarówno z uwierzytelnianiem wieloskładnikowym, jak i bez niego, więc nie potrzebujesz osobnego obejścia MFA.
• Uwierzytelnianie podstawowe oraz stara metoda New-PSSession nie są już obsługiwane, więc skrypty, które na nich polegają, wymagają przepisania.
• Po połączeniu użyj Get-AcceptedDomain jako szybkiego testu i zawsze kończ sesję poleceniem Disconnect-ExchangeOnline.
• Skrypty uruchamiane bez nadzoru powinny korzystać z uwierzytelniania tylko aplikacji lub tożsamości zarządzanej zamiast zapisanego hasła.

Czego potrzebujesz przed połączeniem

Polecenie łączenia pochodzi z modułu, więc najpierw trzeba go zainstalować. Jeśli jeszcze tego nie zrobiono, zainstaluj go z PowerShell Gallery poleceniem Install-Module -Name ExchangeOnlineManagement. W dokumentacji Microsoft moduł nazywa się modułem V3. Firma Microsoft obejmuje zarówno Windows PowerShell 5.1, jak i PowerShell 7. W przypadku PowerShell 7 potrzebna jest wersja modułu 2.0.4 lub nowsza.

O tym, czy połączenie zadziała, decydują jeszcze cztery rzeczy:

• Uprawnienia. Kontrola dostępu oparta na rolach decyduje, jakich poleceń cmdlet możesz użyć po połączeniu. Samo połączenie nie stanowi trudności, trudne jest uruchomienie właściwego polecenia cmdlet. Firma Microsoft ma stronę o tym, jak sprawdzić uprawnienia wymagane przez polecenie cmdlet, i warto ją dodać do zakładek.
• Dostęp do PowerShell dla konta. Konto musi mieć zezwolenie na korzystanie z Exchange Online PowerShell. Jeśli administrator wyłączył tę możliwość dla Twojego użytkownika, logowanie się powiedzie, ale połączenie nie.
• Sieć. Między komputerem a usługami Microsoft 365 musi być otwarty port TCP 80.
• Czysta ścieżka profilu. Firma Microsoft zaznacza, że polecenia łączenia mogą się nie powieść, jeśli ścieżka profilu użytkownika zawiera znaki specjalne programu PowerShell, na przykład $. Jeśli Twoje konto ma taką ścieżkę, użyj innego konta.

Nie musisz też niczego zmieniać w WinRM. Aktualne połączenia działają w tle na bazie REST, więc dawna rada, by włączyć uwierzytelnianie podstawowe w WinRM, już nie obowiązuje.

Jak połączyć się z Exchange Online PowerShell krok po kroku

To jest standardowa metoda interaktywna. Działa tak samo w Windows PowerShell 5.1 i PowerShell 7, z uwierzytelnianiem wieloskładnikowym lub bez niego.

1. Otwórz nowe okno PowerShell. Świeże okno pozwala uniknąć konfliktów zestawów z innymi modułami, które mogłeś wcześniej załadować w tej sesji.
2. Załaduj moduł poleceniem Import-Module ExchangeOnlineManagement. Jeśli moduł jest już zainstalowany, według Microsoftu zwykle można pominąć ten krok i przejść od razu do polecenia połączenia, ponieważ PowerShell załaduje moduł automatycznie.
3. Uruchom polecenie Connect-ExchangeOnline -UserPrincipalName admin@contoso.com, ale z własnym kontem w formacie UPN. W niektórych organizacjach można pominąć parametr -UserPrincipalName i zostaniesz poproszony o podanie danych. Jeśli to nie zadziała, dodaj ten parametr.
4. Wpisz hasło w oknie logowania i wybierz przycisk Zaloguj się.
5. Jeśli na Twoim koncie wymagane jest uwierzytelnianie wieloskładnikowe (MFA), wpisz kod weryfikacyjny i wybierz przycisk Zweryfikuj. Kod jest dostarczany skonfigurowaną metodą, na przykład wiadomością tekstową lub aplikacją Microsoft Authenticator. W programie PowerShell 7 logowanie domyślnie odbywa się w przeglądarce.
6. Poczekaj na baner. Brak błędu oznacza, że połączenie zostało nawiązane.

To wszystko. To samo polecenie łączy sesje PowerShell dla usługi Microsoft 365 GCC bez dodatkowych parametrów. Tylko w przypadku pozostałych chmur potrzebne jest jedno ustawienie, o którym piszę za chwilę.

Jeśli nie chcesz, aby baner powitalny trafiał do logu skryptu, dodaj -ShowBanner:$false. Jeśli chcesz, aby Get-Help wyświetlało pomoc dla poleceń cmdlet programu Exchange Online, dodaj -LoadCmdletHelp. Od wersji modułu 3.7.0 pomoc ta nie jest już ładowana domyślnie, co zaskakuje osoby, które zaktualizowały moduł, a potem zauważyły, że Get-Help zwraca prawie nic.

Inne sposoby połączenia: PowerShell 7, partnerzy i chmury

Dokumentacja opisuje kilka wariantów. Wybierz ten, który odpowiada Twojej sytuacji.

PowerShell 7 bez przeglądarki. Uruchom Connect-ExchangeOnline -Device. Polecenie wyświetli komunikat z poleceniem otwarcia https://microsoft.com/devicelogin i wpisania kodu. Robisz to na innym urządzeniu, logujesz się, potwierdzasz, a pierwotna sesja kończy połączenie. Działa to z MFA i bez niego, a przydaje się na serwerach lub maszynach z systemem Linux bez środowiska graficznego.

PowerShell 7 z poświadczeniami podanymi w poleceniu. Connect-ExchangeOnline -UserPrincipalName admin@contoso.com -InlineCredential działa w przypadku kont bez MFA. Większość organizacji wymaga MFA dla administratorów, więc ten wariant będziesz używać rzadko.

Windows PowerShell 5.1 z obiektem poświadczeń. W przypadku kont bez MFA możesz najpierw uruchomić $Credential = Get-Credential, a następnie Connect-ExchangeOnline -Credential $Credential. Microsoft zaznacza, że jeśli to nie zadziała, należy zamiast tego użyć -UserPrincipalName.

Dzierżawy klientów jako partner. Partnerzy programu Cloud Solution Provider oraz goście z rolą administratora dodają parametr -DelegatedOrganization, na przykład Connect-ExchangeOnline -UserPrincipalName admin@contoso.onmicrosoft.com -DelegatedOrganization adatum.onmicrosoft.com. Strona Microsoftu odwołuje się do programu Cloud Solution Provider oraz szczegółowych uprawnień administracji delegowanej (GDAP) w kwestii uprawnień.

Chmury rządowe i regionalne. Środowisko wybierasz parametrem -ExchangeEnvironmentName. Domyślną wartością jest O365Default, która obejmuje Microsoft 365 i GCC. Udokumentowane wartości dla pozostałych chmur to O365USGovGCCHigh, O365USGovDoD, O365GermanyCloud i O365China.

Skrypty bez nadzoru. Nie przechowuj hasła administratora w skrypcie. Microsoft opisuje dwie lepsze opcje. Tożsamość zarządzana, na przykład Connect-ExchangeOnline -ManagedIdentity -Organization "contoso.onmicrosoft.com", sprawdza się w skryptach uruchamianych w usłudze Azure. Uwierzytelnianie aplikacji (app-only) z certyfikatem sprawdza się we wszystkich pozostałych przypadkach. Parametr odcisku certyfikatu jest obsługiwany wyłącznie w systemie Windows. Konfiguracja obejmuje rejestrację aplikacji w usłudze Microsoft Entra ID, uprawnienie aplikacji Exchange.ManageAsApp z zgodą administratora, certyfikat oraz obsługiwaną rolę, na przykład Administrator Exchange, przypisaną aplikacji. Microsoft zaleca zasadę najmniejszych uprawnień, więc nie przydzielaj aplikacji roli Administrator globalny, chyba że nie ma innego wyjścia. Postępuj zgodnie z osobnym artykułem Microsoft o uwierzytelnianiu aplikacji, a nie z jego skróconą wersją.

W usłudze Windows w tle dodaj -SkipLoadingFormatData, aby uniknąć błędów. Jeśli widzisz błędy dotyczące Web Account Manager, moduł w wersji 3.7.2 lub nowszej ma do tego przełącznik -DisableWAM.

Utrzymuj skrypty w prostej formie: ogranicz importowane polecenia

Połączenie zazwyczaj importuje wszystkie polecenia cmdlet programu Exchange Online, do których masz dostęp. Jest to wygodne przy szybkim sprawdzeniu skrzynki, ale skrypt, który potrzebuje trzech poleceń, nie potrzebuje wszystkich. Strona modułu Microsoft zawiera tutaj konkretną wskazówkę. Częste wywoływanie Connect-ExchangeOnline i Disconnect-ExchangeOnline w tej samej sesji może spowodować wyciek pamięci. Rozwiązaniem jest połączenie się raz na skrypt oraz użycie parametru -CommandName, aby zaimportować tylko potrzebne polecenia.

Skrypt, który jedynie odczytuje statystyki skrzynki, potrzebuje na przykład tylko jednego polecenia. Nazwij kilka poleceń, połącz się raz na początku, wykonaj pracę i rozłącz się raz na końcu. Skrypty napisane w ten sposób łatwiej sprawdzić, ponieważ wiersz połączenia pokazuje czytelnikowi, z których poleceń korzysta skrypt.

Dwa kolejne nawyki pomagają w środowiskach zespołowych. Po pierwsze, trzymaj wiersz połączenia w jednym miejscu, na przykład w małej funkcji, dzięki czemu zmiana metody uwierzytelniania wykonuje się raz, a nie w dwudziestu skryptach. Po drugie, zapisuj w dzienniku nazwę konta lub aplikacji, która uruchomiła skrypt, nigdy jej sekretu. Kiedy w skrzynce zmieni się coś nieoczekiwanego, ten wpis w dzienniku oszczędzi ci wielu godzin.

Sprawdź poprawność połączenia i czysto się rozłącz

Połączenie bez błędu to dobry znak, ale przetestuj je prostym poleceniem odczytu. Get-AcceptedDomain wyświetla domeny Twojej organizacji i wykonuje się w ciągu sekundy. Jeśli pojawią się domeny, sesja działa, a Twoje konto ma co najmniej uprawnienia do odczytu.

Aby zobaczyć szczegóły swoich połączeń, użyj polecenia Get-ConnectionInformation. Strona modułu Microsoft zwraca uwagę, że Get-PSSession nie zwraca niczego przydatnego dla tych połączeń opartych na REST, więc starsze skrypty sprawdzające Get-PSSession wymagają zmian.

Po zakończeniu uruchom Disconnect-ExchangeOnline. W skryptach dodaj -Confirm:$false, aby pominąć monit. Artykuł Microsoft o połączeniach ostrzega, że zamknięcie okna bez rozłączenia może wyczerpać dostępne sesje, a wtedy trzeba czekać, aż wygasną.

Napraw najczęstsze błędy połączenia

Większość błędów wynika z krótkiej listy przyczyn. Sprawdzaj je od góry do dołu.

• Błędna nazwa użytkownika lub hasło. Wykonaj kroki ponownie i sprawdź oba. Brzmi banalnie, ale najpierw sprawdź format UPN.
• Dostęp do PowerShell dla konta jest wyłączony. Administrator może go włączyć. Microsoft ma osobny artykuł o włączaniu i wyłączaniu dostępu do programu Exchange Online PowerShell.
• Port 80 jest zablokowany. Poproś zespół sieciowy o zezwolenie na ruch TCP na porcie 80 do usługi Microsoft 365.
• Konto federacyjne z niedostępnym dostawcą tożsamości. Jeśli Twój dostawca tożsamości IDP lub STS nie jest dostępny publicznie, Microsoft sugeruje do połączenia użycie konta niefederacyjnego w usłudze Microsoft 365.
• "Nie rozpoznano terminu „Update-ModuleManifest”". Połączenie wymaga modułu PowerShellGet oraz jego zależności PackageManagement. Zaktualizuj oba i uruchom ponownie PowerShell.
• „Could not load file or assembly 'System.IdentityModel.Tokens.Jwt'”. Moduł koliduje z innym modułem w tej samej sesji. Połącz się w nowym oknie programu Windows PowerShell, zanim zaimportujesz cokolwiek innego.
• Błędy w oknie otwartym przez usługę lub zadanie zaplanowane. Spróbuj użyć parametru -SkipLoadingFormatData.

Jeśli żadna z tych przyczyn nie dotyczy Twojej sytuacji, kolejnym podejrzanym jest wersja modułu. Uruchom polecenie Update-Module -Name ExchangeOnlineManagement w tym samym zakresie, w którym instalowałeś moduł, i spróbuj ponownie w nowym oknie.

Częste błędy

• Używanie uwierzytelniania podstawowego (Basic) lub polecenia New-PSSession. Firma Microsoft podaje je wyłącznie jako odniesienie historyczne i informuje, że nie są już obsługiwane. Skrypt, który nadal tworzy sesję w ten sposób, trzeba przenieść na Connect-ExchangeOnline.
• Zamykanie okna zamiast rozłączania. Może to wyczerpać dostępne sesje. Ustaw Disconnect-ExchangeOnline jako ostatni wiersz każdego skryptu.
• Umieszczanie hasła w postaci jawnego tekstu w skrypcie. Zamiast tego użyj tożsamości zarządzanej lub certyfikatu.
• Importowanie innych modułów przed połączeniem. Konflikt z innym modułem może przerwać logowanie. Najpierw połącz się z usługą Exchange Online albo użyj nowego okna.
• Zakładanie, że połączenie oznacza uprawnienia. Jeśli po połączeniu polecenie zgłasza „not recognized”, oznacza to, że Twoja rola go nie obejmuje. To kwestia RBAC, a nie problem z połączeniem.

Powiązane tematy warte poznania

• Instalacja i aktualizacja modułu: połączenie zależy od właściwego modułu i wersji programu PowerShell, dlatego przed wdrożeniem w zespole zapoznaj się z wymaganiami dotyczącymi modułu Exchange Online PowerShell.
• Sprawdzanie uprawnień dla polecenia: firma Microsoft wyjaśnia, jak ustalić, która rola jest potrzebna do konkretnego polecenia Exchange.
• Połączenie z Security & Compliance PowerShell: ten sam moduł udostępnia polecenie Connect-IPPSSession, które nie jest dostępne w PowerShell 7 w systemach Linux i macOS.
• Automatyzacja bez nadzoru: uwierzytelnianie aplikacji (app-only) i tożsamości zarządzane to bezpieczny sposób uruchamiania zaplanowanych skryptów Exchange.
• Duże zadania zbiorcze: polecenia oparte na REST mają limit czasu wynoszący 15 minut, dlatego duże aktualizacje członków warto podzielić na partie.

Następny krok

Aby niezawodnie połączyć się z Exchange Online PowerShell, zacznij od nowego okna, uruchom Connect-ExchangeOnline -UserPrincipalName z kontem administratora, przetestuj połączenie poleceniem Get-AcceptedDomain i na koniec się rozłącz. Następnie zaplanuj skrypty bez nadzoru z wykorzystaniem tożsamości zarządzanej lub certyfikatu, aby nikt nie musiał wpisywać ani przechowywać hasła.