M365Con 2027 – безкоштовна онлайн-конференція · 11–22 Jan 2027 · 120 sessions→ m365con.net

Блог · Mirko Peters

Підключення до Exchange Online PowerShell: покрокова інструкція

By ·

Як підключитися до Exchange Online PowerShell за допомогою Connect-ExchangeOnline: вимоги, інтерактивний вхід, MFA, варіанти для партнерів і безнадзорного режиму, а також способи усунення помилок.

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

Щоб підключитися до Exchange Online PowerShell, завантажте модуль ExchangeOnlineManagement і виконайте Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com. Відкриється вікно входу, ви введете пароль і підтвердите запит MFA, після чого оболонка буде підключена. Ця стаття призначена для адміністраторів Exchange і Microsoft 365, яким потрібні точні кроки, варіанти безпечного доступу для партнерів і безнадзорного режиму, а також короткий перелік рішень, якщо підключення не вдається. Вона відповідає поточній документації Microsoft, тому команди тут припускають сучасну автентифікацію та відсутність віддаленого сеансу PowerShell.

Головне

  • Щоб підключитися до Exchange Online PowerShell, завантажте модуль і виконайте Connect-ExchangeOnline, вказавши обліковий запис адміністратора у форматі UPN.
  • Інтерактивний вхід працює як з багатофакторною автентифікацією, так і без неї, тож окремий обхідний шлях для MFA не потрібен.
  • Базова автентифікація та старий метод New-PSSession більше не підтримуються, тому скрипти, які від них залежать, потрібно переписати.
  • Після підключення використовуйте Get-AcceptedDomain для швидкої перевірки і завжди завершуйте сеанс командою Disconnect-ExchangeOnline.
  • Для безнадзорних скриптів використовуйте автентифікацію лише для застосунку або керовану ідентичність замість збереженого пароля.

Що потрібно перед підключенням

Команда підключення належить до модуля, тож спочатку його потрібно встановити. Якщо ви ще цього не зробили, встановіть його з PowerShell Gallery командою Install-Module -Name ExchangeOnlineManagement. У документації Microsoft цей модуль називається модулем V3. Microsoft описує роботу як у Windows PowerShell 5.1, так і в PowerShell 7. Для PowerShell 7 потрібна версія модуля 2.0.4 або новіша.

Чотири інші фактори визначають, чи вдасться підключення:

  • Дозволи. Керування доступом на основі ролей визначає, які командлети ви можете виконувати після підключення. Саме підключення не є складною частиною, складно виконати потрібний командлет. Microsoft має сторінку про те, як знайти дозволи, потрібні командлету, і її варто зберегти в закладках.
  • Доступ до PowerShell для облікового запису. Обліковий запис повинен мати дозвіл на використання Exchange Online PowerShell. Якщо адміністратор вимкнув це для вашого користувача, вхід пройде успішно, але підключення не відбудеться.
  • Мережа. Між вашим комп'ютером і Microsoft 365 має бути відкритий TCP-порт 80.
  • Чистий шлях до профілю. Microsoft зазначає, що команди підключення можуть не працювати, якщо шлях до профілю користувача містить спеціальні символи PowerShell, наприклад $. Використайте інший обліковий запис, якщо у вас є такий.

Налаштовувати WinRM також не потрібно. Поточні підключення працюють через REST, тож стара порада увімкнути базову автентифікацію в WinRM більше не актуальна.

Покрокове підключення до Exchange Online PowerShell

Це стандартний інтерактивний метод. Він працює однаково в Windows PowerShell 5.1 і PowerShell 7, з багатофакторною автентифікацією або без неї.

  1. Відкрийте нове вікно PowerShell. Нове вікно дозволяє уникнути конфліктів збірок з іншими модулями, які ви могли завантажити раніше в цій сесії.
  2. Завантажте модуль командою Import-Module ExchangeOnlineManagement. Якщо модуль уже встановлено, Microsoft зазначає, що цей крок зазвичай можна пропустити і одразу перейти до команди підключення, адже PowerShell завантажує модуль автоматично.
  3. Виконайте Connect-ExchangeOnline -UserPrincipalName admin@contoso.com, але замість прикладу вкажіть свій обліковий запис у форматі UPN. В деяких організаціях можна опустити -UserPrincipalName, і тоді система запитає його сама. Якщо це не спрацювало, додайте параметр.
  4. Введіть пароль у вікні входу та натисніть Sign in.
  5. Якщо для вашого облікового запису ввімкнено MFA, введіть код підтвердження та натисніть Verify. Код надсилається відповідним для вас способом, наприклад текстовим повідомленням або через Microsoft Authenticator. У PowerShell 7 вхід за замовчуванням відбувається через браузер.
  6. Дочекайтеся банера. Відсутність помилок означає, що підключення успішне.

Це все. Та сама команда підключає до сесій PowerShell для Microsoft 365 GCC без додаткових параметрів. Лише для інших хмар потрібне налаштування, про яке йдеться далі.

Якщо ви не хочете, щоб вітальний банер потрапляв у журнал скрипта, додайте -ShowBanner:$false. Якщо хочете, щоб Get-Help показував довідку для командлетів Exchange Online, додайте -LoadCmdletHelp. Починаючи з версії модуля 3.7.0, ця довідка більше не завантажується за замовчуванням, тож ті, хто оновлює модуль, можуть здивуватися, побачивши, що Get-Help повертає майже нічого.

Інші способи підключення: PowerShell 7, партнери та хмари

У документації наведено кілька варіантів. Оберіть той, що відповідає вашій ситуації.

PowerShell 7 без браузера. Виконайте Connect-ExchangeOnline -Device. Команда виведе повідомлення з вказівкою відкрити https://microsoft.com/devicelogin і ввести код. Це робиться на будь-якому іншому пристрої: ви входите, підтверджуєте, і початкова сесія завершує підключення. Спосіб працює з MFA і без нього та зручний на серверах або машинах з Linux без графічного інтерфейсу.

PowerShell 7 з вбудованими обліковими даними. Connect-ExchangeOnline -UserPrincipalName admin@contoso.com -InlineCredential працює для облікових записів без MFA. Більшість організацій вимагає MFA для адміністраторів, тож цим способом ви користуватиметеся рідко.

Windows PowerShell 5.1 з об'єктом облікових даних. Для облікових записів без MFA спершу виконайте $Credential = Get-Credential, а потім Connect-ExchangeOnline -Credential $Credential. Microsoft зазначає, що якщо це не спрацює, слід використати -UserPrincipalName.

Клієнти-партнерам. Партнери програми Cloud Solution Provider і гостьові адміністратори додають -DelegatedOrganization, наприклад Connect-ExchangeOnline -UserPrincipalName admin@contoso.onmicrosoft.com -DelegatedOrganization adatum.onmicrosoft.com. Сторінка Microsoft посилається на програму Cloud Solution Provider і гранулярні делеговані привілеї адміністрування (GDAP) щодо дозволів.

Урядові та регіональні хмари. Середовище вибирається параметром -ExchangeEnvironmentName. За замовчуванням використовується O365Default, яке охоплює Microsoft 365 і GCC. Задокументовані значення для інших хмар: O365USGovGCCHigh, O365USGovDoD, O365GermanyCloud і O365China.

Скрипти без участі користувача. Не зберігайте пароль адміністратора в скрипті. Microsoft рекомендує два кращі варіанти. Керована identity, наприклад Connect-ExchangeOnline -ManagedIdentity -Organization "contoso.onmicrosoft.com", підходить для скриптів, які працюють в Azure. Автентифікація лише для застосунку з сертифікатом підходить для всього іншого. Параметр відбитка сертифіката підтримується лише у Windows. Для налаштування потрібні реєстрація застосунку в Microsoft Entra ID, дозвіл застосунку Exchange.ManageAsApp з адміністративною згодою, сертифікат і підтримувана роль, наприклад Exchange Administrator, для застосунку. Microsoft рекомендує принцип найменших привілеїв, тож не надавайте застосунку роль Global Administrator, якщо без цього не обійтися. Скористайтеся окремою статтею Microsoft про автентифікацію лише для застосунку, а не скороченою версією.

У службі Windows додайте -SkipLoadingFormatData, щоб уникнути помилок. Якщо з'являються помилки, що згадують Web Account Manager, для цього є перемикач -DisableWAM у версіях модуля 3.7.2 і новіших.

Тримайте скрипти легкими: обмежуйте те, що імпортуєте

Підключення зазвичай імпортує командлети Exchange Online, які вам дозволено використовувати. Для швидкого перегляду поштової скриньки це нормально, але скрипту, якому потрібні три команди, не потрібні всі. Сторінка модуля Microsoft дає конкретну пораду. Часті виклики Connect-ExchangeOnline і Disconnect-ExchangeOnline в одному сеансі можуть призвести до витоку пам'яті. Рішення: підключатися один раз для кожного скрипту та використовувати параметр -CommandName, щоб імпортувати лише потрібні командлети.

Скрипт, який лише читає статистику поштових скриньок, наприклад, потребує лише однієї команди. Назвіть кілька потрібних команд, підключіться один раз на початку, виконайте роботу й відключіться один раз у кінці. Скрипти, написані так, легше перевіряти, адже рядок підключення показує читачеві, які команди використовує скрипт.

Ще дві звички допомагають у командних середовищах. По-перше, тримайте рядок підключення в одному місці, наприклад у невеликій функції, щоб зміна методу автентифікації відбувалася один раз, а не в двадцяти скриптах. По-друге, журналюйте обліковий запис або назву застосунку, який запустив скрипт, але ніколи не його секрет. Коли в поштовій скриньці щось несподівано змінюється, такий рядок журналу заощаджує години роботи.

Перевіряйте підключення та коректно відключайтеся

Підключення без помилок — добрий знак, але перевірте його безпечною командою читання. Get-AcceptedDomain показує домени вашої організації і виконується за секунду. Якщо домени з'являються, ваш сеанс працює, а обліковий запис має принаймні доступ на читання.

Щоб переглянути відомості про підключення, використовуйте Get-ConnectionInformation. Сторінка модуля Microsoft зазначає, що Get-PSSession не повертає нічого корисного для цих підключень на основі REST, тож старим скриптам, які перевіряють Get-PSSession, потрібні зміни.

Коли закінчите, виконайте Disconnect-ExchangeOnline. У скриптах додайте -Confirm:$false, щоб пропустити запит підтвердження. У статті Microsoft про підключення попереджається, що закриття вікна без відключення може вичерпати доступні сеанси, і тоді доведеться чекати, доки вони завершаться.

Усуньте найпоширеніші помилки підключення

Більшість збоїв мають невеликий перелік причин. Перевіряйте їх по порядку, зверху вниз.

  • Неправильне ім'я користувача або пароль. Повторіть кроки та перевірте обидва. Це звучить банально, але спершу перевірте формат UPN.
  • Доступ до PowerShell для облікового запису вимкнено. Адміністратор може його увімкнути. У Microsoft є окрема стаття про увімкнення та вимкнення доступу до Exchange Online PowerShell.
  • Порт 80 заблоковано. Попросіть мережевих фахівців дозволити TCP-порт 80 до Microsoft 365.
  • Федеративний обліковий запис із недоступним постачальником ідентифікації. Якщо ваш IDP або STS недоступний публічно, Microsoft радить для підключення використовувати нефедеративний обліковий запис у Microsoft 365.
  • "Термін 'Update-ModuleManifest' не розпізнано". Для підключення потрібні PowerShellGet та його залежність PackageManagement. Оновіть обидва модулі та перезапустіть PowerShell.
  • «Could not load file or assembly 'System.IdentityModel.Tokens.Jwt'». Модуль конфліктує з іншим модулем у тій самій сесії. Підключіться у новому вікні Windows PowerShell, перш ніж імпортувати будь-що інше.
  • Помилки у вікні, відкритому службою або запланованим завданням. Спробуйте -SkipLoadingFormatData.

Якщо жодне з цього не стосується вашої ситуації, наступна підозра – версія модуля. Виконайте Update-Module -Name ExchangeOnlineManagement в тій самій області, в якій ви встановлювали модуль, і повторіть спробу в новому вікні.

Типові помилки

  • Використання базової автентифікації або New-PSSession. Microsoft наводить ці способи лише як історичну довідку та зазначає, що вони більше не підтримуються. Скрипт, який досі створює сесію таким чином, потрібно перевести на Connect-ExchangeOnline.
  • Закриття вікна замість відключення. Це може вичерпати ваші сесії. Зробіть Disconnect-ExchangeOnline останнім рядком кожного скрипта.
  • Збереження пароля у скрипті у вигляді відкритого тексту. Натомість використовуйте керовану ідентичність або сертифікат.
  • Імпорт інших модулів перед підключенням. Конфлікт з іншим модулем може зламати вхід. Спершу підключіться до Exchange Online або скористайтеся новим вікном.
  • Припущення, що підключення означає наявність дозволів. Якщо після підключення командлет виводить «not recognized», ваша роль не включає його. Це питання RBAC, а не проблема підключення.

Пов’язані теми для вивчення

  • Встановлення та оновлення модуля: підключення залежить від правильного модуля та версії PowerShell, тож перед впровадженням у команді ознайомтеся з вимогами до модуля Exchange Online PowerShell.
  • Перевірка дозволів для командлета: Microsoft пояснює, як дізнатися, яка роль потрібна для конкретного командлета Exchange.
  • Підключення до PowerShell Security & Compliance: той самий модуль пропонує Connect-IPPSSession, який недоступний у PowerShell 7 на Linux або macOS.
  • Автоматизація без участі користувача: автентифікація лише для застосунку та керовані ідентичності – це безпечний спосіб запускати заплановані скрипти Exchange.
  • Великі масові завдання: командлети на основі REST мають тайм-аут 15 хвилин, тож великі оновлення складу груп розбивайте на пакети.

Наступний крок

Щоб надійно підключатися до Exchange Online PowerShell, почніть з нового вікна, виконайте Connect-ExchangeOnline -UserPrincipalName з вашим обліковим записом адміністратора, перевірте підключення командлетом Get-AcceptedDomain і відключіться після завершення роботи. Далі плануйте автоматизовані скрипти з використанням керованої ідентичності або сертифіката, щоб ніхто не мусив вводити чи зберігати пароль.

Entities in this article

Exchange Online PowerShell PowerShell

Related articles

RSS