Microsoft разрешила администраторам временно отменить отключение EWS в Exchange Online, если после 1 октября перестали работать корпоративные почтовые приложения. Это даёт компаниям короткую передышку до окончательного отключения API 1 апреля 2027 года — и особенно важно для организаций, где старые интеграции с почтой до сих пор являются частью бизнес-процессов, сообщает BleepingComputer.
Exchange Web Services, или EWS, — API для работы с письмами, календарями, контактами и другими объектами почтового ящика. Его используют не только самописные интеграции: от него могут зависеть старые версии Outlook для Windows, надстройки Outlook, Apple Mail и Calendar в macOS, а также внутренние сервисы, которые читают входящие письма, создают встречи или синхронизируют контакты. После отключения API пользователи могут увидеть сообщение о недоступности протокола либо бесконечные запросы логина и пароля — симптомы, которые легко принять за сбой учётной записи или MFA.
Вернуть EWS можно двумя способами. В Microsoft 365 администратору нужно открыть настройки базового режима безопасности и снять флажок, запрещающий всей организации использовать EWS. Второй вариант — Exchange Online PowerShell: команда Set-OrganizationConfig -EWSEnabled $true. Microsoft предупреждает, что применение настройки может занять до четырёх часов. Это не исправление приложения, а временное восстановление доступа к устаревшему интерфейсу.
Компания начала блокировать EWS по умолчанию 1 октября 2026 года. В феврале Microsoft сообщала, что на переходный период доступ можно будет сохранять через список разрешённых приложений. Сейчас она уточнила: первый этап ещё позволяет включить API обратно, но в апреле 2027 года такой возможности не останется. Для Exchange Server, развернутого в собственной инфраструктуре, этот график не действует: EWS там продолжит работать.
Почему проблема всплыла именно сейчас
Для Microsoft это не внезапный разворот, а финальная стадия давно объявленного вывода технологии из эксплуатации. Ещё в 2018 году компания прекратила развивать EWS функционально. В октябре 2021-го она объявила устаревшими 25 наименее используемых методов EWS для Exchange Online, а в марте 2022 года убрала их из сервиса по соображениям безопасности. Затем в сентябре 2023 года появился план начать отключение API в октябре 2026-го.
Проблема в том, что почтовые интеграции редко живут в центре внимания разработки. Сервис обработки заявок мог быть написан несколько лет назад, иметь одного ушедшего автора и исправно разбирать письма через EWS каждую минуту. Аналогично устроены архиваторы, CRM-коннекторы, боты для бронирования переговорных, HR-автоматизация и внутренние надстройки Outlook. Пока интерфейс доступен, у таких систем обычно нет приоритета в бэклоге. Отключение EWS превращает технический долг в инцидент с понятным сроком эскалации.
Microsoft называет долгосрочное решение прямо: обновить приложение до версии без EWS или переписать собственный код на Microsoft Graph API. Для большинства сценариев Graph уже имеет почти полный функциональный паритет с EWS. Вендорское ПО нужно обновлять после проверки совместимости; самописные решения — инвентаризировать, определить используемые операции и отдельно проверить разрешения, модель авторизации и поведение при ограничениях API. Простая замена конечной точки здесь маловероятна: Graph и EWS отличаются объектной моделью, подходом к запросам и набором доступных операций.
Что делать ИТ-командам до апреля 2027 года
Включать EWS обратно имеет смысл только после быстрой диагностики: подтвердить, какое приложение обращается к сервису, кто владелец кода или контракта с поставщиком, и можно ли перейти на поддерживаемую версию. Затем стоит зафиксировать временное исключение с датой закрытия. Массовое возвращение EWS для всего тенанта может быстро убрать пользовательские ошибки, но заодно замаскирует перечень зависимостей, который всё равно придётся разобрать до дедлайна.
Для разработчиков это хороший повод не ограничиваться миграцией «чтобы снова заработало». Нужно проверить, какие почтовые данные и действия действительно необходимы приложению, сократить избыточные разрешения и протестировать сценарии с календарём, вложениями, общими ящиками и обработкой ошибок. Для ИТ-директора задача ещё прозаичнее: назначить владельцев всех EWS-зависимостей и поставить дату миграции раньше апреля 2027-го. Временное включение — это аварийный рубильник, а не продление поддержки.
Следующие месяцы покажут, сколько корпоративных почтовых процессов всё ещё привязано к интерфейсу, который Microsoft перестала развивать восемь лет назад. После апреля 2027 года спор будет уже не о том, оставлять ли EWS включённым, а о том, какие незамеченные процессы не пережили окончательное отключение EWS.