External Email Authentication в SCOM: настройка email-уведомлений

До SCOM 2016 уведомления по почте уходили только через внутренний SMTP-relay без аутентификации — это работало, пока почтовый сервер был внутри периметра. Как только нужно было слать письма через внешний SMTP с логином и паролем, штатных средств не было.

В SCOM 2016 появилась функция External Email Authentication: она позволяет привязать к каналу email-уведомлений учётную запись Run As и проходить аутентификацию на внешнем SMTP-сервере. Настройка состоит из трёх шагов: создать Run As Account, связать его с Run As Profile через Management Pack «Notifications Internal Library», указать профиль при создании email-канала. Способ работает так же в SCOM 2019, 2022 и 2025 — механизм Run As с тех пор не менялся.

Что такое External Email Authentication и когда она нужна

В Operations Manager уведомления по почте всегда отправлялись через SMTP — но до версии 2016 канал умел работать только с relay-сервером, у которого либо аутентификация не нужна вовсе, либо она настроена на уровне сети (IP-разрешения, доверенная зона). Если письма нужно было слать через сервер, который требует логин и пароль — например, корпоративный SMTP за пределами домена или сервис стороннего провайдера — отправка просто не проходила.

External Email Authentication закрывает этот пробел. Канал уведомлений получает возможность подключаться к SMTP-серверу с указанием учётных данных — через привязанный Run As Account. Само название «External» здесь не означает обязательно «облачный» или «сторонний сервис» — речь именно про необходимость аутентификации, а не про расположение сервера.

Функция появилась в SCOM 2016 и с тех пор не менялась — всё, что описано в статье, точно так же работает в SCOM 2019, 2022 и 2025.

Один нюанс, на который стоит обратить внимание заранее: SCOM поддерживает только классическую SMTP-аутентификацию по логину и паролю (Basic Auth), без OAuth2. Если в качестве внешнего сервера планируется Office 365 или Exchange Online, у которых Microsoft отключает Basic Auth для SMTP, схема из этой статьи может не сработать. Что делать в этом случае — разберём в разделе про типичные ошибки.

Создание и настройка Run As Account

Первый шаг — создать учётную запись Run As, через которую SCOM будет авторизовываться на внешнем SMTP-сервере.
Откройте консоль Operations Manager, перейдите на вкладку «Administration» → «Run As Configuration» → «Accounts». В контекстном меню или в панели задач справа выберите «Create Run As Account…». В качестве типа учётной записи укажите «Simple Authentication», задайте отображаемое имя и описание.

На следующем шаге введите имя учётной записи и пароль — те, что использует внешний почтовый сервер для аутентификации отправителя.

В настройках безопасного распространения выберите «More Secure» — это ограничивает использование учётной записи только теми серверами и пулами, которые вы укажете явно на следующем шаге, и нажмите «Create».

Закройте мастер кнопкой «Close».

Учётная запись создана, но без распространения на нужный пул она не будет работать — это частая причина, по которой канал потом не проходит аутентификацию. Откройте свойства созданной учётной записи.

Перейдите на вкладку «Distribution» и нажмите «Add».

Выберите пул Notifications Resource Pool — именно он отвечает за рассылку уведомлений, и без него учётная запись физически не сможет авторизоваться при отправке писем.

Нажмите «Add», затем «OK».

Завершите настройку кнопкой «OK».

Готово — Run As Account создан и распространён на нужный пул. Дальше его нужно связать с Run As Profile.

Создание Run As Profile

Учётная запись сама по себе ничего не делает — её нужно связать с Run As Profile, через который SCOM поймёт, что именно эту запись использовать для аутентификации в канале уведомлений.

Там же, в «Run As Configuration», в контекстном меню или панели задач выберите «Create Run As Profile…».

Задайте отображаемое имя и описание профиля.

Здесь важный момент, на котором часто спотыкаются: в качестве пакета управления (Management Pack), куда будет сохранён профиль, обязательно нужно выбрать Notifications Internal Library. Если выбрать любой другой MP — профиль создастся, но не появится в списке доступных при настройке email-канала.

На следующем шаге нажмите «Add», чтобы привязать к профилю учётную запись.

Из выпадающего списка выберите учётную запись, созданную на предыдущем шаге, и нажмите «OK».

Завершите создание профиля кнопкой «Create».

Закройте мастер кнопкой «Close».

На этом подготовительная часть закончена — есть учётная запись с паролем для внешнего SMTP и профиль, который её использует. Осталось создать сам канал уведомлений и привязать к нему этот профиль.

Создание email-канала с External Email Authentication

Теперь нужно создать канал уведомлений и указать в нём созданный Run As Profile.

В консоли Operations Manager перейдите на вкладку «Administration» → «Notifications» → «Channels». В контекстном меню или панели задач справа выберите «New» → «E-Mail (SMTP)».

Задайте имя канала и описание.

Кнопкой «Add» добавьте внешний SMTP-сервер, через который будут уходить уведомления.

Во всплывающем окне укажите FQDN или IP-адрес сервера и порт, если он отличается от стандартного 25 (например, 587 для SMTP с авторизацией — уточните у провайдера или администратора почтового сервера, какой порт у него открыт под аутентифицированную отправку). Здесь же выберите метод аутентификации External Email Authentication и Run As Profile, созданный на предыдущем шаге.

Если профиль в списке не появляется — вернитесь и проверьте, что он создан именно в Management Pack «Notifications Internal Library» (см. раздел 4), это самая частая причина.

Укажите обратный email-адрес — тот, что получатели увидят в поле «От кого».

При необходимости отредактируйте формат сообщения — тему, текст, важность и кодировку — и завершите создание канала кнопкой «Finish».

Закройте мастер.

Канал появится в общем списке — на этом этапе можно сразу нажать «Send Test E-Mail», чтобы проверить, что письмо реально доходит, не дожидаясь первой настоящей подписки.

Канал с External Email Authentication готов. Дальше остаётся обычная часть — создать получателей (Subscribers) и подписки (Subscriptions), указав в них этот канал.

Создание Subscriber и Subscription

Канал сам по себе ничего не отправляет — нужна подписка, которая определяет, какие правила и группы мониторинга порождают уведомление, и получатель, которому это уведомление придёт.

В той же вкладке «Notifications» откройте «Subscribers» → «New» и укажите email-адрес получателя в его контактной информации (Contact information → Channel → E-Mail). Затем перейдите в «Subscriptions» → «New», выберите критерии — по каким алертам или группам должна срабатывать подписка, — и на шаге выбора каналов укажите тот, что был создан с External Email Authentication.

Если в списке каналов на этом шаге канал не отображается — обычно дело в правах: подписка видит только те каналы, на которые есть доступ у учётной записи, под которой настраивается подписка, либо канал ещё не успел реплицироваться между management-серверами (обычно это занимает не больше пары минут).

После создания подписки имеет смысл сразу спровоцировать тестовый алерт (например, вручную перевести правило в критическое состояние) и убедиться, что письмо реально дошло — это быстрее, чем ждать первого настоящего инцидента.

Если правила мониторинга ещё не настроены, начать стоит с настройки мониторинга служб Windows в SCOM — оттуда и будут приходить алерты, на которые рассчитана подписка.

Возможные ошибки и как их найти

Письмо не уходит, хотя канал и подписка настроены

Первым делом смотрите Operations Manager Event Log на сервере, который входит в Notifications Resource Pool (Event Viewer → Application and Services Logs → Operations Manager). Ошибки отправки уведомлений там фиксируются с конкретным кодом события и текстом — обычно этого достаточно, чтобы понять, на каком этапе обрыв: не нашёл Run As Profile, не смог подключиться к серверу, отказ в аутентификации.

Authentication failed / 535 5.7.8 Error: authentication failed

Чаще всего это значит, что пароль в Run As Account не совпадает с тем, что ждёт SMTP-сервер, либо учётная запись на стороне почтового сервера заблокирована или требует смены пароля. Стоит также проверить — иногда сервер ожидает имя пользователя в формате domain\user или полный email-адрес, а не короткое имя.

Канал создан, но Run As Profile не появляется в списке при выборе

Почти всегда причина в том, что профиль сохранён не в Management Pack «Notifications Internal Library» — другой MP в этом списке просто не отображается, даже если профиль создан корректно во всех остальных смыслах. Решение — пересоздать профиль с правильным MP.

Учётная запись создана и привязана к профилю, но письма всё равно не уходят

Проверьте Distribution учётной записи — она должна быть явно распространена на Notifications Resource Pool. Без этого Run As Account существует в системе, но фактически не может быть использована тем сервером, который реально отправляет почту.

Office 365 / Exchange Online — Basic Auth отключён

Если внешний SMTP — это Office 365 или Exchange Online, есть риск, что отправка не пройдёт вообще, независимо от правильности настройки канала: Microsoft поэтапно отключает Basic Auth (логин/пароль) для SMTP AUTH, а External Email Authentication в SCOM именно его и использует — поддержки OAuth2 здесь нет. В этом случае варианты такие:

• использовать внутренний SMTP-relay без аутентификации (если он есть в инфраструктуре и доверен почтовым сервером);
• настроить отдельный shared mailbox с разрешённым SMTP AUTH через exception в политике организации (если это всё ещё допускается администратором Exchange Online);
• перейти на сторонний транзакционный SMTP-сервис (SendGrid, Mailgun и подобные), который поддерживает Basic Auth по логину и API-ключу;
• рассмотреть альтернативный канал оповещений — например, через webhook в Teams или Command-канал — если email как таковой не обязателен.

Письмо доходит, но видно только при тестовой отправке, а не от реальных алертов

Это обычно не проблема канала, а проблема подписки — либо критерии подписки (Criteria) слишком узкие и не покрывают нужные алерты, либо получатель не привязан к расписанию (Schedule) подписки. Стоит перепроверить именно настройки Subscription, а не повторно лезть в канал.

Настройка через PowerShell

Все три сущности — Run As Account, Run As Profile и канал уведомлений — можно создать командами модуля OperationsManager, без консоли. Это удобно, если нужно повторить настройку на нескольких management group или внести её в скрипт развёртывания.
Перед тем как запускать, подключитесь к management group:

Import-Module OperationsManager
New-SCOMManagementGroupConnection -ComputerName "<имя сервера управления>"

Создание Run As Account (Simple Authentication):

$password = ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force

$account = New-SCOMRunAsAccount -Simple `
    -Name "External SMTP Account" `
    -Description "Учётная запись для аутентификации на внешнем SMTP" `
    -Username "notify@example.com" `
    -Password $password

Распространение на Notifications Resource Pool:

$pool = Get-SCOMResourcePool -DisplayName "Notifications Resource Pool"
Set-SCOMRunAsDistribution -RunAsAccount $account -SecureDistribution $false -ResourcePool $pool

Создание Run As Profile в нужном Management Pack:

$mp = Get-SCOMManagementPack -DisplayName "Notifications Internal Library"
$profile = New-SCOMRunAsProfile -Name "External.Email.Profile" `
    -DisplayName "External Email Run As Profile" `
    -Description "Профиль для аутентификации в email-канале" `
    -ManagementPack $mp
Set-SCOMRunAsProfile -Action Add -Profile $profile -Account $account

Создание email-канала:

Тут готового «единого» cmdlet под все версии SCOM нет — синтаксис New-SCOMEmailNotificationChannel и его параметры (SMTP-сервер, порт, метод аутентификации, ссылка на Run As Profile) немного отличаются между билдами 2016/2019/2022/2025. Рабочий шаблон:

New-SCOMEmailNotificationChannel -Name "External SMTP Channel" `
    -Description "Канал с External Email Authentication" `
    -PrimaryServer @{ServerName="smtp.example.com"; PortNumber=587; AuthenticationType="ExternalAuthentication"} `
    -ReturnAddress "scom-alerts@example.com" `
    -RunAsProfile $profile

Перед использованием в проде стоит проверить точное имя параметров для своей версии:

Get-Command -Module OperationsManager -Name "*EmailNotificationChannel*" | Get-Help -Full

— это надёжнее, чем ориентироваться на пример из статьи, потому что Microsoft время от времени меняет состав параметров между cumulative update’ами.

Заключение

External Email Authentication закрывает конкретный пробел в SCOM — возможность слать оповещения через SMTP-сервер, который требует логин и пароль. Настройка не сложная: один Run As Account, один Run As Profile в правильном Management Pack и канал, который на этот профиль ссылается. Большая часть проблем на практике сводится к одной из двух вещей — профиль создан не в том MP, либо учётная запись не распространена на Notifications Resource Pool.

Отдельно стоит держать в голове ограничение по Basic Auth: если внешний сервер — Office 365 или Exchange Online, схема может не заработать вообще, и тут поможет либо relay, либо сторонний SMTP-сервис, либо канал другого типа.

Когда email-канал настроен и проверен, имеет смысл не останавливаться на одной подписке — посмотреть в сторону эскалации (несколько подписчиков с разным приоритетом), notification schedule с дежурствами, либо параллельных каналов — например, в Teams через webhook для критичных алертов, чтобы не зависеть от одной только почты.

FAQ