Отказ от EWS в Exchange Online: как не потерять синхронизацию почты и календарей с CRM

Что нужно успеть сделать ИТ-службе и разработчикам интеграций до апреля 2027 года

Microsoft поэтапно отключает Exchange Web Services (EWS) в Exchange Online: с октября 2026 года протокол начинает блокироваться по умолчанию для тех, кто не настроил доступ явно, а с 1 апреля 2027 года EWS отключат полностью и для всех [1][2]. Это касается именно Exchange Online — облачной версии сервиса; на EWS локально развёрнутого Exchange Server изменение не распространяется [3]. Риск для компании обычно скрывается не в почтовом клиенте сотрудников, а в фоновых интеграциях — CRM, календарных синхронизациях, сервисах контроля общих и делегированных ящиков, ботах для встреч, — которые вызывают EWS в фоне и о которых ИТ-служба может не знать. Единственная официальная замена — Microsoft Graph API, и переход не сводится к смене адреса эндпоинта: меняются модель прав доступа, механизм уведомлений об изменениях и часть возможностей, для которых у Graph пока нет полного аналога [2][4].

Почему это должно оказаться в списке дел ИТ-службы, а не только вендора CRM

Компания обычно узнаёт об отказе от EWS из письма от разработчика её CRM, коннектора для 1С или сервиса аналитики почты — если разработчик вообще успел предупредить заранее. Реальная же зависимость от EWS часто шире, чем думает ИТ-отдел: это может быть коннектор синхронизации почты в CRM, модуль автоматического создания встреч из карточки сделки, сервис контроля общих ящиков поддержки, старый скрипт выгрузки календаря в BI-отчёт или интеграция с 1С:ЗУП, которая читает статус отсутствия сотрудника. Часть таких приложений могла быть настроена несколько лет назад и с тех пор не привлекала внимания — до момента, когда она перестанет работать.

Проблема усиливается тем, что срок отключения не единый и не одномоментный: Microsoft начинает переводить тенанты на блокировку по умолчанию с октября 2026 года постепенно, а не всем сразу в один день, и окончательно закрывает протокол 1 апреля 2027 года [1][2]. Это значит, что интеграция может продолжать работать в ноябре 2026 года и внезапно отказать в январе 2027-го — просто потому, что очередь автоматического отключения дошла до конкретного тенанта.

Для российских компаний есть дополнительный слой сложности: часть организаций уже работает с Exchange Online в условиях ограниченного доступа к оплате и поддержке Microsoft из-за санкционных ограничений [5], и решение о судьбе интеграций с CRM нередко принимается одновременно с более широким вопросом — стоит ли вообще продолжать зависеть от облачного Exchange или пора мигрировать почту на российскую платформу. Материал ниже касается ситуации, когда компания продолжает пользоваться Exchange Online и должна успеть перенести интеграции до отключения EWS.

Что такое EWS и почему Microsoft его закрывает

Exchange Web Services — это SOAP-протокол почти двадцатилетней давности, через который внешние приложения читают и изменяют письма, вложения, календари, контакты и настройки почтовых ящиков Exchange. Много лет это был основной способ построить интеграцию с почтой Microsoft: CRM синхронизировала переписку по сделке, календарный модуль создавал встречи, а сервис контроля SLA следил за письмами в общем ящике поддержки.

Функциональные обновления EWS прекратились ещё в 2018 году, а в 2023-м Microsoft объявила дату начала отключения — октябрь 2026 года [3]. Ускорил процесс инцидент с группировкой Midnight Blizzard в январе 2024 года: атака была связана с EWS, после чего Microsoft расширила задачу — теперь от протокола отказываются не только сторонние приложения, но и собственные продукты компании, включая Outlook, Teams и Dynamics 365 [2]. Официальная и единственная замена — Microsoft Graph, единый REST API для доступа к сервисам Microsoft 365, который использует современную авторизацию через Microsoft Entra ID вместо модели «сервисный аккаунт видит всё» [4].

Как устроено отключение: сроки и переключатели

Отключение управляется двумя настройками на уровне тенанта.

EWSEnabled. У этого параметра три состояния — True, False и Null (значение по умолчанию до сих пор у большинства организаций). Начиная с 1 октября 2026 года Microsoft начинает переводить тенанты со значением Null в False — это заблокирует EWS для всех приложений тенанта [1]. Если компании EWS ещё нужен, до конца сентября 2026 года требуется явно выставить EWSEnabled = True; Microsoft подтверждает, что заранее установленное значение True не будет автоматически изменено при развёртывании [1].

EWSAllowedAppIDs. Начиная с осени 2026 года одного EWSEnabled = True уже не хватает: доступ к EWS дополнительно ограничивается списком разрешённых идентификаторов приложений Microsoft Entra ID. Приложение, которого нет в списке, получит отказ, даже если EWS в тенанте включён [1][6]. Для организаций, которые не успели создать список сами, Microsoft предварительно заполнит его на основе фактического использования EWS в тенанте [1] — но полагаться на это стоит только как на временную меру, а не как на постоянное решение, потому что автоматически собранный список отражает прошлое поведение, а не то, что администратор осознанно разрешил.

Даты, которые стоит зафиксировать в проектном плане:

• до конца сентября 2026 года — включить EWSEnabled = True и настроить собственный EWSAllowedAppIDs, чтобы не попасть под автоматический перевод в False [1];
• с 1 октября 2026 года — начинается поэтапное, а не одномоментное отключение EWS по всем тенантам [1][2];
• 1 апреля 2027 года — EWS отключается окончательно и без исключений [2].

Отдельно стоит отличать EWSAllowedAppIDs от старой настройки EwsAllowList/EwsApplicationAccessPolicy: последняя определяет доступ по строке User-Agent и существовала задолго до текущей волны изменений — она не защищает от отключения EWS сама по себе и работает по другому принципу, чем допуск по идентификатору приложения [1][7].

Российская специфика: что уточнить до начала работ

Тема технически глобальная, но для российских компаний есть контекст, который стоит учитывать до начала миграции.

Доступность и оплата Microsoft 365. С 2022 года Microsoft ограничила продажу новых лицензий и приём платежей от компаний из России; действующие подписки для многих организаций продолжают работать, но обновление, продление и обращение в официальную поддержку зависят от статуса конкретного договора и платёжного профиля [5]. Это значит, что часть компаний может столкнуться с EWS-миграцией в условиях, когда обычные каналы поддержки Microsoft недоступны или ограничены — стоит заранее понять, на какую поддержку можно рассчитывать, и не откладывать миграцию до последнего момента в расчёте на индивидуальную помощь вендора.

Персональные данные и место хранения. Смена EWS на Graph не переносит почтовые данные в другую страну. До миграции составьте карту мест хранения писем, вложений и копий в CRM, а применимость требований локализации и трансграничной передачи проверьте с ответственным за персональные данные. Нельзя сводить такую проверку к одной настройке API или считать согласие на доступ приложения правовым основанием обработки.

Российские CRM. Если письма синхронизируются не с зарубежной CRM вроде Dynamics 365 или Salesforce, а с Битрикс24, amoCRM, retailCRM или похожей системой, миграция EWS → Graph, как правило, ложится не на саму CRM, а на промежуточный коннектор или собственный модуль интеграции — именно там нужно менять протокол вызовов и модель авторизации. Разработчик коннектора может быть штатным сотрудником, подрядчиком или уже не поддерживающим решение бывшим исполнителем — это стоит выяснить как можно раньше, а не в момент, когда интеграция уже перестала работать.

Шаг 1. Найти все приложения и учётные записи, которые вызывают EWS

Прежде чем что-либо мигрировать, нужно узнать, что вообще использует EWS в тенанте — включая забытые фоновые задания, о которых никто не вспоминал годами.

Отчёты об использовании EWS. В административном центре Microsoft 365 есть отдельный отчёт «EWS Usage»: он показывает, какие приложения (по идентификатору App ID) вызывали EWS за последние 7, 30 или 90 дней, какие именно SOAP-операции они выполняли и с каким объёмом успешных вызовов [11][12][13]. Отчёт агрегируется по неделям, а не по дням, поэтому редкие, но критичные фоновые задания (например, ночная синхронизация раз в сутки) стоит смотреть на максимальном горизонте в 90 дней, чтобы не пропустить их [13].

Уведомления в Message Center. Microsoft с конца декабря 2025 года рассылает тенантам сообщения с темой вроде «Update active Exchange Web Services Applications» — если такого сообщения в Message Center нет, скорее всего, тенант не имеет заметного использования EWS [14]. Это не заменяет отчёт об использовании, но помогает быстро понять, стоит ли вообще тема на повестке конкретной компании.

Сопоставление App ID с реальными приложениями. Отчёт показывает GUID приложения, а не человекочитаемое название. Если это не приложение из списка первичных сервисов Microsoft, идентификатор нужно найти среди корпоративных приложений Microsoft Entra ID — там же видно, кто и когда предоставил ему согласие на доступ, какие разрешения выданы и когда приложение последний раз проходило вход [15][14]. Отдельные open-source утилиты автоматизируют это сопоставление и заодно проверяют активность по журналам входа и аудита [16][14].

Забытые фоновые задания. Отдельно стоит проверить: сервисные учётные записи с давно не менявшимся паролем и широкими правами на доступ к чужим ящикам; cron-задачи и запланированные задания на серверах компании, которые обращаются к Exchange напрямую по SOAP; расширения и надстройки для 1С, Excel или устаревших порталов самообслуживания, написанные штатными разработчиками много лет назад; резервное копирование почты через сторонние решения (некоторые продукты для бэкапа Exchange Online до сих пор используют EWS и уже публично предупреждают клиентов о необходимости перехода на Graph [17][18]).

Реестр зависимостей от EWS: что в нём фиксировать

Каждую найденную зависимость стоит сразу заносить в единый реестр, а не держать в голове или в разрозненных заметках. По каждому приложению нужно зафиксировать:

1. приложение или App ID — что это за интеграция и по какому идентификатору она видна в отчётах;
2. что делает — какие операции выполняет (например: чтение писем и вложений, отправка от имени менеджера; создание, изменение и отмена встреч; экспорт писем при резервном копировании);
3. тип доступа — делегированный доступ или олицетворение (impersonation) сервисного аккаунта;
4. ящик или ресурс — к чему именно обращается приложение: личные ящики отдела продаж, ящик конкретного менеджера, все ящики тенанта;
5. периодичность — работает непрерывно (вебхук или постоянный опрос), по событию или, например, еженедельно;
6. критичность процесса — что произойдёт с бизнесом, если операция перестанет работать: например, CRM-коннектор почты остановит приём заявок (высокая критичность), а разовый экспорт для бэкапа обычно можно отложить на несколько дней (средняя);
7. ответственный — кто может внести изменения: внутренний разработчик, разработчик коннектора или внешний вендор.

Такой реестр — рабочий артефакт, а не разовая справка: его стоит обновлять по мере миграции каждого приложения и использовать как основу для приоритизации на этапе переключения.

Шаг 2. Составить перечень операций, которые интеграция выполняет через EWS

Когда список приложений собран, для каждого нужно понять не «использует ли оно EWS», а что именно оно делает — это определит, какие права и какая модель Graph понадобятся при переносе. Перечень стоит вести по операциям, сгруппированным по типу данных:

• письма — чтение входящих, отправка от имени пользователя или сервисного аккаунта, перемещение между папками, отметка прочитанным;
• вложения — чтение, добавление и скачивание вложений писем;
• календари и встречи — создание, изменение и отмена встреч, чтение свободного/занятого времени;
• приглашения — отправка приглашений на встречу и обработка ответов участников (принял/отклонил/под вопросом);
• общие и делегированные ящики — доступ к почте отдела продаж, поддержки или бухгалтерии, куда сотрудник получил права через делегирование или через полный доступ к общему ящику;
• прочие нетиповые операции — заметки (IPM.StickyNote), персональные списки контактов, ящики Microsoft 365 Групп и публичные папки, административные операции с разрешениями на папки.

Для каждой строки перечня стоит сразу зафиксировать: какое приложение выполняет операцию, с какой периодичностью, через делегированный доступ или через олицетворение (impersonation) сервисного аккаунта, и что произойдёт с бизнес-процессом, если операция перестанет работать в конкретную дату.

Шаг 3. Сопоставить операции с возможностями Microsoft Graph и выявить неподдержанные сценарии

Большая часть типовых сценариев уже имеет прямое соответствие между операциями EWS и методами Graph, и Microsoft поддерживает отдельную таблицу такого сопоставления [2]. Но для части возможностей паритета либо ещё нет, либо он не планируется вовсе — это стоит проверять для каждой строки перечня из шага 2, а не полагаться на общее ощущение «Graph всё умеет».

Карта замены операций

Уже поддержано в Microsoft Graph — прямой аналог есть уже сейчас [2]:

• чтение и отправка писем, работа с вложениями;
• календари, встречи и приглашения;
• общие и делегированные ящики — с отдельной проверкой delegated и app-only доступа; разрешения с суффиксом .Shared относятся к делегированным сценариям, а не ко всем фоновым приложениям [19][20][22].

В разработке — Microsoft подтверждает планы, но паритета пока нет, и полагаться на готовность раньше срока не стоит [2]:

• импорт и экспорт архивных ящиков, публичных папок и ящиков Microsoft 365 Групп — цель Q4 2026;
• заметки (IPM.StickyNote) и персональные списки контактов — цель Q3 2026;
• административный API для разрешений на папки и настроек почтовых ящиков — цель Q4 2026.

Не будет реализовано никогда — для этих сценариев нужен обходной путь без Graph [2]:

• универсальные CRUD-операции с публичными папками (кроме отдельно выделяемого импорта/экспорта);
• универсальные CRUD-операции с почтовыми ящиками групп Microsoft 365 — вместо них Microsoft предлагает специализированные API для переписки, тредов и постов групп;
• доступ к ящикам Discovery Mailbox — вместо этого Microsoft рекомендует API Microsoft Purview eDiscovery.

Если в перечне из шага 2 встречается операция, которой нет ни в одной из строк этой карты, по умолчанию не стоит рассчитывать, что паритет появится до полного отключения EWS — Microsoft прямо предупреждает: если возможность не упомянута в дорожной карте, не стоит планировать соответствующую функцию Graph или Exchange Admin API до отключения EWS [2]. Для таких операций нужно заранее продумывать обходной путь — например, перенос данных в собственное хранилище компании или отказ от автоматизации конкретного узкого сценария.

Шаг 4. Перенести разрешения и авторизацию с минимально необходимым доступом

Здесь меняется не только протокол вызова, но и сама модель безопасности — и это главная работа, которую нельзя свести к замене URL в существующем коде.

Как было в EWS. У EWS всё-или-ничего модель доступа: приложение с правами на олицетворение (impersonation) через сервисный аккаунт получает доступ ко всему, что доступно этому аккаунту, без детальной настройки на уровне отдельных возможностей — читать письма, но не календарь, отдельно ограничить в EWS нельзя [21]. Второй способ доступа в EWS — делегирование, когда пользователь лично предоставляет другому человеку права на свой ящик или отдельные его папки, без участия администратора.

Как устроено в Graph. Разрешения разделены по данным и операциям: например, чтение почты и изменение календаря. Есть delegated-доступ от имени вошедшего пользователя и app-only доступ фонового приложения. Для второго обычно используют client credentials, но это не единственный режим Graph. Область доступных ящиков нужно ограничивать отдельно [21][22].

Порядок переноса прав. Сначала определите операции и тип доступа. Для интерактивного delegated-сценария общих папок применяются разрешения вроде Mail.Read.Shared и права пользователя в Exchange; для фонового app-only сценария нужны соответствующие application permissions или роли приложения, а не механическое добавление .Shared. Проверьте доступ к общим и делегированным папкам. Ограничивайте доступ нужными ящиками через RBAC for Applications; параллельные разрешения Entra и RBAC складываются, поэтому узкая роль сама по себе не отменяет оставленный широкий grant. Протестируйте как разрешённый ящик, так и отказ для постороннего, затем удалите ненужные старые полномочия.

Шаг 5. Заменить уведомления и синхронизацию: от подписок EWS к вебхукам и delta-запросам

EWS поддерживал push-, pull- и потоковые (streaming) уведомления об изменениях в одном фреймворке; в Graph аналогичной модели длительного потокового соединения нет — вместо неё используется сочетание двух механизмов [25].

Change notifications. Приложение создаёт подписку и HTTPS-обработчик уведомлений. Подписку нужно регулярно продлевать: сроки зависят от ресурса и включения данных, а не одинаковы для всех вариантов. Для Outlook обычные подписки ограничены примерно семью сутками, rich notifications с данными — менее суток; точные пределы проверяйте по таблице сроков подписок Microsoft. Обрабатывайте уведомления жизненного цикла и восстановление после пропуска, а содержимое письма получайте по API либо через предусмотренную шифрованную доставку [26].

Delta-запросы. Это pull-модель: приложение периодически запрашивает у Graph только то, что изменилось с прошлого запроса, используя токен состояния (@odata.deltaLink) вместо повторного скачивания всех данных [4][27]. Рекомендованная практика — гибридная схема: вебхуки дают близкое к реальному времени уведомление о событии, а delta-запросы используются как страховочный механизм для сверки на случай пропущенного уведомления, разрыва соединения или истечения подписки [25]. Важное ограничение: подписки Graph работают не для всех папок почтового ящика — нестандартные, «легаси»-папки, связанные со старыми функциями клиентов, недоступны через стандартные конечные точки сообщений, контактов, событий и задач; для таких сценариев нужно либо переносить данные в поддерживаемую папку, либо искать решение вне Exchange [25].

Идентификаторы писем. Обычный ID может меняться при перемещении. Для устойчивой ссылки внутри одного ящика используйте заголовок Prefer: IdType="ImmutableId", включая создание подписок и delta-запросы. ImmutableId меняется при переносе в архивный ящик или экспорте с повторным импортом. Но отправка черновика не означает обязательную смену ImmutableId: Microsoft описывает получение копии в «Отправленных» по сохранённому ID черновика; она может появиться с задержкой. См. документацию Microsoft по ImmutableId. Для сверки храните также ящик, internetMessageId и собственный ключ операции; один Message-ID не следует считать безусловно уникальным во всех ящиках.

Шаг 6. Проверить идентификаторы, повторные уведомления, изменения встреч и отсутствие дублей в CRM

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

Дедупликация писем. internetMessageId — это идентификатор конкретного сообщения, назначаемый отправляющей системой и сохраняемый Exchange при доставке; он подходит как ключ дедупликации для одного и того же письма, но не подходит для группировки цепочки переписки в один тред — реплаи и исходное сообщение имеют разные internetMessageId [30][31]. Для устойчивой группировки треда рекомендуемый паттерн — разбирать заголовки In-Reply-To и References и сопоставлять их с уже сохранёнными internetMessageId, а не полагаться на conversationId Graph, который не гарантированно стабилен между системами [31]. При тестировании стоит специально проверить сценарий, из-за которого чаще всего появляются дубли в CRM: повторный опрос той же выборки писем без корректной обработки идентификаторов приводит к повторному созданию заявки или тикета в CRM на одно и то же входящее письмо [30].

Изменения встреч и повторные уведомления. Для календарных событий стоит отдельно тестировать сценарии: перенос времени встречи организатором, частичный ответ участников (принял/отклонил/под вопросом), отмену встречи и создание встречи не через тот аккаунт, который CRM ожидает увидеть организатором. Поскольку у подписок Graph есть срок жизни и они могут истекать без явного уведомления приложения, тестовый план должен включать сценарий «подписка истекла между двумя изменениями встречи» — именно здесь без резервной сверки через delta-запрос компания рискует пропустить изменение молча [25][26].

Тестовый план миграции, который стоит закрыть до перевода интеграции на Graph в проде:

1. первичная синхронизация — Graph корректно забирает исторические письма и события, ранее синхронизированные через EWS, без задвоения уже существующих записей CRM;
2. новое входящее письмо и новая исходящая встреча создают ровно одну запись в CRM;
3. повторная доставка того же уведомления о письме (намеренно смоделированная) не создаёт вторую запись;
4. перемещение письма между папками не приводит к повторной обработке как «нового» письма;
5. изменение и отмена встречи корректно обновляют, а не дублируют существующую запись в CRM;
6. истечение и продление подписки на вебхук проходит без потери уведомлений — за счёт delta-сверки;
7. обращение к общему или делегированному ящику проходит с ограниченными правами, а не с широким доступом сервисного аккаунта;
8. throttling — намеренная имитация всплеска запросов (например, массовая первичная синхронизация) корректно обрабатывает ответ 429 с задержкой по заголовку Retry-After, не переходя в цикл немедленных повторов, которые Microsoft прямо называет ошибочной практикой [33][34].

Отдельно стоит учитывать лимиты Graph при проектировании нагрузки: сервис Outlook ограничивает количество запросов на комбинацию «приложение + почтовый ящик», а не общий лимит на тенант, поэтому массовую синхронизацию нескольких ящиков стоит распараллеливать по ящикам, а не наращивать частоту запросов к одному ящику [35][36][37].

Временные меры на период перехода и поэтапное переключение до окончательного отключения

Пока миграция не завершена, компании доступен официальный временный механизм отсрочки — но использовать его стоит осознанно, а не как повод отложить проект. Условия временного сохранения доступа могут меняться по ходу развёртывания, поэтому перед началом работ стоит свериться с последней версией официального сообщения Microsoft, а не только с датами из этой статьи [1].

1. Зафиксировать EWSEnabled = True до конца сентября 2026 года, если EWS ещё нужен хотя бы одному приложению — это защищает тенант от автоматического перевода в False при начале развёртывания в октябре [1].
2. Настроить собственный EWSAllowedAppIDs вместо того, чтобы полагаться на автоматически предзаполненный Microsoft список — свой список отражает осознанное решение администратора, а не текущее фактическое использование, которое может включать и то, что давно пора отключить [1][7].
3. Протестировать список на реальном тенанте — контролируемая проверка «приложение из списка получает доступ, приложение вне списка получает отказ» до того, как ограничение станет обязательным, с учётом что изменения в EWSAllowedAppIDs применяются во всех серверах Exchange Online не сразу, а в течение примерно суток [38][39].
4. Мигрировать приложения по приоритету критичности бизнес-процесса, а не по порядку удобства разработки: сначала — интеграции, отказ которых напрямую остановит продажи или поддержку клиентов (CRM, обработка обращений), затем — вспомогательные и аналитические сценарии. Именно для этого в реестре из шага 1 предусмотрена колонка «критичность процесса».
5. Держать EWSAllowedAppIDs в актуальном состоянии до полного завершения миграции и убрать оттуда приложение сразу после переноса на Graph, а не ждать до 2027 года — список пишется целиком при каждом изменении, инкрементального добавления или удаления одной записи нет, поэтому важно контролировать его актуальную версию, а не полагаться на память [39][6].
6. Не откладывать миграцию до 2027 года «на всякий случай» — часть возможностей Graph (импорт-экспорт архивных ящиков, публичных папок, ящиков групп) ещё в статусе предварительной версии и целится на конец 2026 года; компаниям, зависящим от таких сценариев, стоит закладывать завершение перехода раньше формального дедлайна, чтобы оставить время на исправление проблем [18][2].

Ограничения, ошибки и типичные риски

• Ложное ощущение, что EWS не используется. Отчёт использования агрегируется по неделям и показывает только активность за выбранный период — редкие фоновые задания легко пропустить, если смотреть только последние 7 дней вместо максимальных 90 [13].
• Перенос широких прав олицетворения «как есть». Соблазн выдать приложению Mail.Read и Mail.Send на уровне приложения без ограничения политикой доступа фактически воссоздаёт проблему EWS «всё или ничего» уже в Graph — с той лишь разницей, что теперь это разрешение приложения, а не сервисного аккаунта [40][15].
• Хранение изменяемого идентификатора письма как постоянного ключа в CRM. Если коннектор использует стандартный, а не неизменяемый идентификатор, перемещение письма в другую папку выглядит для CRM как исчезновение старой записи и появление новой [28].
• Игнорирование сценариев без паритета. Публичные папки, ящики Microsoft 365 Групп и ящики Discovery не получат такого же CRUD-доступа, как EWS — если CRM или коннектор завязаны именно на эти типы ящиков, нужен отдельный архитектурный план, а не ожидание, что Graph «когда-нибудь добавит» [2].
• Немедленные повторные запросы при получении ошибки 429. Каждый повторный запрос без задержки засчитывается в лимит и продлевает период ограничения, а не ускоряет восстановление доступа [33][34].
• Расчёт на автоматически предзаполненный список разрешённых приложений как на постоянное решение. Этот список отражает то, что уже происходит в тенанте, а не то, что должно происходить, — включая устаревшие или скомпрометированные интеграции, которые давно пора закрыть [1][7].

Как выбрать вариант реализации

Если у компании простая связка «одна CRM + один способ синхронизации почты», а вендор CRM уже опубликовал готовый модуль на Microsoft Graph, может быть достаточно обновить коннектор до актуальной версии, аккуратно перепроверить права доступа и провести приёмочное тестирование по плану из шага 6 — отдельная разработка не потребуется. Если же интеграция самописная, использует нестандартные операции без прямого аналога в Graph, обслуживает несколько CRM или систем одновременно, либо годами накапливала специфическую логику (правила сопоставления полей, обработку исключений, синхронизацию нескольких общих ящиков) — стоит закладывать отдельный проект: аудит фактической зависимости от EWS, проектирование модели прав Graph с минимально необходимым доступом, миграцию логики синхронизации на гибридную схему вебхуков и delta-запросов и полноценное тестирование на сценариях дублей и пропущенных изменений.

Вывод

Отключение EWS в Exchange Online — не разовое событие 1 апреля 2027 года, а процесс, который для конкретного тенанта может начаться уже в конце 2026 года и потребовать полноценного проекта: обнаружения скрытых зависимостей, пересмотра модели прав доступа, замены механизма уведомлений и повторного тестирования на устойчивость к дублям и пропущенным изменениям. Технически сложность не в замене одного API на другой, а в том, что модель безопасности Graph устроена иначе, чем у EWS, а часть узкоспециализированных сценариев (публичные папки, ящики групп, ящики электронного раскрытия) не получит прямого аналога вовсе. Компаниям, у которых CRM, календарь и почта Exchange Online связаны хотя бы одной фоновой интеграцией, разумно начать инвентаризацию уже сейчас, не дожидаясь официального дедлайна — время на тестирование и исправление ошибок стоит закладывать заранее, а не искать его в последние недели перед отключением.

Источники

[1] techcommunity.microsoft.com — Exchange Online EWS, Your Time is Almost Up — https://techcommunity.microsoft.com/blog/exchange/exchange-online-ews-your-time-is-almost-up/4492361

[2] learn.microsoft.com — Deprecation of Exchange Web Services in Exchange Online — https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-exchange-online

[3] techcommunity.microsoft.com — Retirement of Exchange Web Services in Exchange Online — https://techcommunity.microsoft.com/blog/exchange/retirement-of-exchange-web-services-in-exchange-online/3924440

[4] learn.microsoft.com — Use delta query to track changes in Microsoft Graph data — https://learn.microsoft.com/en-us/graph/delta-query-overview

[5] zerobit.ru — Блокировка Microsoft в России: что делать компаниям — https://zerobit.ru/blog/microsoft_stops_its_cloud_services_for_russian_companies_what_to_do_2024

[6] learn.microsoft.com — Set-OrganizationConfig (параметр EwsAllowedAppIDs) — https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-organizationconfig?view=exchange-ps

[7] techcommunity.microsoft.com — Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement — https://techcommunity.microsoft.com/blog/exchange/introducing-ewsallowedappids-preparing-for-the-final-phase-of-ews-retirement/4529471

[8] 1ps.ru — Полный гид по 152-ФЗ об обработке персональных данных с изменениями 2026 года — https://1ps.ru/blog/dirs/2025/kak-ne-popast-na-millionyi-razbiraem-novyie-trebovaniya-po-obrabotke-personalnyix-dannyix/

[9] inmarlegal.ru — Сбор персональных данных: требования 152-ФЗ и штрафы — https://inmarlegal.ru/press/publications/pdn/sbor-personalnyh-dannyh-lokalizaciya/

[10] klerk.ru — 152-ФЗ о персональных данных: требования закона для бизнеса в 2026 году — https://www.klerk.ru/blogs/roskom24/674017/

[11] techcommunity.microsoft.com — Introducing Exchange Web Services (EWS) Usage Reports in Microsoft 365 Admin Center — https://techcommunity.microsoft.com/blog/exchange/introducing-exchange-web-services-ews-usage-reports-in-microsoft-365-admin-cente/4411263

[12] petri.com — Microsoft 365 Admin Center Adds New EWS Usage Reports — https://petri.com/microsoft-365-admin-center-ews-usage-reports/

[13] learn.microsoft.com — Exchange Web Services (EWS) Usage Report — https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/ews-usage?view=o365-worldwide

[14] techcommunity.microsoft.com — Notes From the Field: Finding and Remediating EWS App Usage Before Retirement — https://techcommunity.microsoft.com/blog/exchange/notes-from-the-field-finding-and-remediating-ews-app-usage-before-retirement/4496469

[15] office365itpros.com — Find Active Exchange Web Services Apps in Microsoft 365 — https://office365itpros.com/2025/04/29/exchange-web-services-apps/

[16] github.com — EWS App Identifier (PowerShell-модуль для сопоставления App ID) — https://github.com/peterschmidtdk/EWS-App-Identifier

[17] veeam.com — Exchange Web Services (EWS) Deprecation, Support Statement KB4820 — https://www.veeam.com/kb4820

[18] help.druva.com — Exchange Online EWS Retirement: Status and Configuration Guide — https://help.druva.com/en/articles/16160529-exchange-online-ews-retirement-status-and-configuration-guide

[19] learn.microsoft.com — Can you differentiate between shared mailbox and delegate mailbox using Microsoft Graph API — https://learn.microsoft.com/en-us/answers/questions/1437543/can-you-differentiate-between-shared-mailbox-and-d

[20] github.com — Accessing a Shared Mailbox Folder (Graph PowerShell 101) — https://github.com/gscales/Graph-Powershell-101-Binder/blob/master/Shared-Mailboxes/Accesing%20a%20Shared%20Mailbox%20Folder.md

[21] learn.microsoft.com — Migrate Exchange Web Services authentication to Microsoft Graph — https://learn.microsoft.com/en-us/graph/migrate-exchange-web-services-authentication

[22] learn.microsoft.com — Microsoft Graph permissions reference — https://learn.microsoft.com/en-us/graph/permissions-reference

[23] practical365.com — New application access policies extend support for more scenarios — https://practical365.com/new-application-access-policies-extend-support-for-more-scenarios/

[24] practical365.com — Migrate from EWS Application Access Policy to RBAC for Applications — https://practical365.com/migrate-from-ews-application-access-policy-to-rbac-for-applications/

[25] devblogs.microsoft.com — Migrating EWS notifications to Microsoft Graph — https://devblogs.microsoft.com/microsoft365dev/migrating-ews-notifications-to-microsoft-graph/

[26] learn.microsoft.com — Change notifications for Outlook resources in Microsoft Graph — https://learn.microsoft.com/en-us/graph/outlook-change-notifications-overview

[27] learn.microsoft.com — calendar: delta (Microsoft Graph beta) — https://learn.microsoft.com/en-us/graph/api/calendar-delta?view=graph-rest-beta

[28] learn.microsoft.com — Outlook immutable id (жизненный цикл идентификатора) — https://learn.microsoft.com/fr-ca/graph/outlook-immutable-id

[29] learn.microsoft.com — Immutable ID for draft (изменение ID при переходе Draft → Sent) — https://learn.microsoft.com/en-us/answers/questions/391064/immutable-id-for-draft

[30] techcommunity.microsoft.com — Query Regarding Duplicate Message IDs from Microsoft Graph API — https://techcommunity.microsoft.com/discussions/officegraph/query-regarding-duplicate-message-ids-from-microsoft-graph-api/4430895

[31] learn.microsoft.com — Microsoft Graph Webhook — conversationId changes, email thread grouping — https://learn.microsoft.com/en-us/answers/questions/5883983/microsoft-graph-webhook-conversationid-changes-whe

[32] github.com — Intermittent ErrorItemNotFound on message/attachment GET after change notifications — https://github.com/microsoftgraph/msgraph-sdk-dotnet/discussions/3142

[33] learn.microsoft.com — Microsoft Graph throttling guidance — https://learn.microsoft.com/en-us/graph/throttling

[34] learn.microsoft.com — Microsoft Graph service-specific throttling limits — https://learn.microsoft.com/en-us/graph/throttling-limits

[35] learn.microsoft.com — Increasing Microsoft Graph Per-Mailbox Throttling Limits — https://learn.microsoft.com/en-us/answers/questions/5853334/increasing-microsoft-graph-per-mailbox-throttling

[36] learn.microsoft.com — Graph Api rate limits — https://learn.microsoft.com/en-us/answers/questions/5589984/graph-api-rate-limits

[37] 4sysops.com — EWSAllowedAppIDs: Configure the application allow list — https://4sysops.com/archives/ewsallowedappids-configure-the-application-allow-list-for-exchange-web-services-ews/

[38] 4sysops.com — Test EWSAllowedAppIDs in Exchange Online — https://4sysops.com/archives/test-ewsallowedappids-in-exchange-online/

[39] techcommunity.microsoft.com — Notes from the field: testing EWSAllowedAppIDs safely — https://techcommunity.microsoft.com/blog/exchange/notes-from-the-field-testing-ewsallowedappids-safely/4548568

[40] office365itpros.com — Control Graph Mail.Send Permission with RBAC for Applications — https://office365itpros.com/2026/02/17/mail-send-rbac-for-applications/