EWS в Exchange Online спира на 1 април 2027 г.: как да прехвърлите интеграциите си към Microsoft Graph

Microsoft започна да изключва Exchange Web Services (EWS) в Exchange Online. Първите стъпки по прилагането се провеждат този месец, а след това наемателите (tenants), които никога не са пипали настройките си за EWS, ще бъдат изключвани един по един. Целта на Microsoft е EWS да бъде изключен напълно на 1 април 2027 г., макар че в известието MC1485116 в Message Center от 1 октомври компанията очаква внедряването в световния облак и в облаците за правителството на САЩ да приключи в началото на юли 2027 г. Планирайте за 1 април. Microsoft заяви ясно, че след април 2027 г. изключения няма да има.

Ако нещо, разработено от вашата компания, комуникира с пощенски кутии в Microsoft 365 през EWS, то ще спре да работи най-късно на тази дата, а може би и много по-рано. Обичайните заподозрени: CRM система, която прикача имейлите от клиенти към съответните акаунти, скрипт за архивиране или съхранение, екран за резервиране на заседателни зали, система за заявки, която чете обща пощенска кутия за поддръжка, задача за отчети, която брои имейлите по екипи. Решението е пренаписване спрямо Microsoft Graph, а за част от възможностите на EWS в Graph изобщо няма еквивалент.

Какво се случва, дата по дата

Microsoft управлява EWS за всеки наемател чрез настройката EWSEnabled, която има три стойности: Null (по подразбиране), True и False. До нея вече има и втора настройка, EWSAllowedAppIDs: списък с идентификатори на приложения, на които все още е позволено да използват EWS. Актуалната страница в Microsoft Learn дава общата рамка: „Октомври 2026 г.: EWS започва да се изключва глобално за всички организации" и „Април 2027 г.: EWS е напълно изключен."

Подробностите са в публикацията на екипа на Exchange от 1 октомври, EWS Deprecation Is Here. За световния търговски облак:

• 2 октомври 2026 г., в края на деня по тихоокеанско време: Microsoft записва всеки наемател, при който EWSEnabled е True, но няма списък с разрешени приложения.
• 8 и 9 октомври 2026 г.: за тези наематели Microsoft създава списъка с разрешени приложения и го попълва с идентификаторите на приложенията, използвали EWS през предходните 60 дни.
• От 10 октомври 2026 г.: когато EWSEnabled е True, списъкът с разрешени приложения е задължителен. Приложение, което не е в него, получава отказ.
• Втора фаза, след това: на наемателите, които все още са на Null, EWSEnabled се задава на False, което блокира EWS за всички приложения. Всеки получава предупреждение 7 дни по-рано в Message Center, а малко преди това Microsoft попълва списък с разрешени приложения по данните за използване от 60 дни, така че администраторът да може да включи EWS отново със стойност True.
• 1 април 2027 г.: целевата дата на Microsoft, на която EWS ще бъде „напълно и окончателно изключен", след което администраторите на наемателите губят възможността изобщо да променят EWSEnabled. Според MC1485116 внедряването в Worldwide, GCC, GCC High и DoD се очаква да приключи в началото на юли 2027 г., така че някои наематели може да запазят EWS малко по-дълго. Никой не бива да разчита, че ще е сред тях.

Наемателите в другите облаци на Microsoft получават собствени графици чрез Message Center.

Списъкът с разрешени приложения печели време, но не е решение

Автоматичният списък се съставя по трафика от 60 дни, а в собствените си насоки от 4 септември Microsoft предупреждава, че той „може да пропусне приложения, които се изпълняват рядко". Експорт в края на тримесечието или годишна задача за архивиране няма да са в него и ще се провалят при следващото си изпълнение.

Промените в списъка с разрешени приложения влизат в сила след 24 часа, а промените в EWSEnabled след около час. Всяка корекция след отказ ви струва поне един ден.

За да види какво е положението на наемателя, администратор с достъп до Exchange Online PowerShell може да изпълни:

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

За кого се отнася това и кой може да спре да чете

Локалният Exchange Server не е засегнат. Microsoft посочва, че оттеглянето се отнася „само за Microsoft 365 и Exchange Online" и че „няма промени в EWS в Exchange Server". Ако всичките ви пощенски кутии са на ваши собствени сървъри, можете да спрете дотук.

Хибридните конфигурации изискват по-внимателен поглед. Локалните пощенски кутии могат да продължат да използват EWS, а тези в облака трябва да преминат към Graph. Публикацията на Microsoft за хибридните среди от 30 септември разглежда два случая, които изискват действие още сега, включително локални пощенски кутии с архиви в Exchange Online. Засега съветът за тях е EWS да остане включен, а хибридното приложение да бъде добавено в списъка с разрешени приложения.

Готовият софтуер е задача на доставчика. Ако EWS се извиква от търговски продукт, пускането на версия за Graph е работа на доставчика, а ваша задача е да получите дата от него и да инсталирате обновлението. Собствените клиенти на Microsoft не правят изключение: някои все още се появяват в отчетите за използване и имат нужда от списъка с разрешени приложения, докато не бъдат обновени.

Вътрешно разработеният код е ваша задача. Скриптове, вътрешни услуги, адаптирани инструменти с отворен код и интеграции, изградени от агенция преди години, нямат кой да ги поправи вместо вас. Именно там е работата. За мащаба: exchangelib, библиотека за Python за комуникация с Exchange през EWS, е изтеглена 1 174 625 пъти от PyPI през последния месец. Част от това е за локални инсталации, но дава представа колко код говори директно с EWS.

Стъпка първа: открийте всичко, което използва EWS

Започнете с отчета за използването на EWS в центъра за администриране на Microsoft 365 (Reports, Usage, Exchange и след това разделът EWS usage). За всяко приложение той показва идентификатора на приложението в Microsoft Entra, всяко SOAP действие, извикано от приложението, обема на извикванията и датата на последната активност. Можете да погледнете 7, 30 или 90 дни назад и да експортирате в CSV.

Три неща, които трябва да знаете за него:

• Данните се обобщават седмично и може да се появят чак след 10 дни.
• Идентификаторът на приложение не е собственик. Съпоставете всеки идентификатор с Enterprise applications в Microsoft Entra и след това намерете човека или екипа, който отговаря за приложението. Очаквайте няколко идентификатора, които никой не разпознава.
• Колоната със SOAP действията показва колко голяма е всяка задача. Приложение, което извиква само FindItem и GetItem, е кратка задача. Такова, което извиква SyncFolderItems, Subscribe и ExportItems, е цял проект.

Дори 90 дни не стигат, за да хванат годишните задачи, затова проверете и от другата страна: планираните задачи и записите в cron, както и хранилищата с код, като търсите крайната точка на EWS (Exchange.asmx), EWS Managed API за .NET и exchangelib. Страницата на Microsoft за оттеглянето съдържа и връзка към анализатор на EWS за код на .NET (той маркира извикванията на EWS във Visual Studio и VS Code и предлага еквиваленти в Graph), както и ръководство за рефакториране с помощта на ИИ.

Стъпка втора: решете какво ще стане с всяка интеграция

Всяко приложение в списъка получава един от четири отговора:

1. Оттеглете го. Някои интеграции съществуват само защото никой не ги е изключил.
2. Обновете го. Продуктите на доставчици получават обновление от доставчика. Уговорете датата още сега.
3. Пренапишете го спрямо Microsoft Graph. Стандартният вариант за вътрешно разработен код.
4. Препроектирайте го. За всичко, което разчита на възможност, каквато Graph никога няма да има (вижте по-долу).

Microsoft посочва и Power Platform като начин за повторно изграждане на даден работен процес. За скрипт, който препраща прикачени файлове в папка, това може да е най-евтиният отговор.

Какво всъщност включва пренаписването за Graph

Повечето операции в EWS имат пряк аналог в Graph, а Microsoft поддържа съответствие между EWS и Graph. Съответствието е лесната част. По-трудните части са тези, които то не показва.

Правата стават по-тесни, и това е предимство

Приложение, което използва EWS без влязъл потребител, притежава правото на приложение за EWS, което Microsoft описва като „пълен достъп до всички пощенски кутии". Graph го разделя на отделни права: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read и т.н.

Можете също да ограничите до кои пощенски кутии има достъп дадено приложение. RBAC for Applications in Exchange Online присвоява право спрямо обхват на управление (management scope) или административна единица и заменя по-старите Application Access Policies. Екран за резервиране на зали може да чете календарите на дванадесет пощенски кутии на зали и нищо друго. Един капан: правата, предоставени по този начин, се добавят към всяко право за целия наемател в Microsoft Entra, така че ако там все още е дадено съгласие за Mail.Read, вашият обхват не ограничава нищо. Премахнете правото в Entra.

Където е възможно, използвайте сертификати вместо клиентски тайни за удостоверяване на приложението и не дръжте идентификационни данни в скриптове и хранилища.

Синхронизацията и известията се изграждат наново, а не се превеждат

Обикновено това е най-голямата промяна за всичко, което пази локално копие на данните от пощенската кутия.

Синхронизация. SyncFolderItems съответства на делта заявката за съобщения в Graph, а SyncFolderHierarchy на делта заявката за пощенски папки. Делтата за съобщения работи с по една папка, така че пълната синхронизация на пощенска кутия означава да следите дървото от папки и да пазите отделна делта връзка за всяка папка. Филтрирането е ограничено (само по дата на получаване), а резултатите включват изтривания, премествания извън папката и промени в състоянието „прочетено", дори когато не отговарят на филтъра ви.

Известия. Абонаментите за поточно (streaming) и push известяване в EWS се превръщат в известия за промени в Graph, които се доставят до уеб кука (webhook), поддържана от вас, или до Azure Event Hubs или Event Grid. Уеб куката трябва да е достъпна от страната на Microsoft, а това е промяна в архитектурата за скрипт, който досега е държал отворена връзка зад защитната стена. Абонаментите за поща, календар и контакти траят най-много 10 080 минути (малко под седем дни) или 1 440 минути, когато известието носи самите данни, така че нещо трябва да ги подновява. Всяка пощенска кутия позволява най-много 1 000 активни абонамента общо за всички приложения.

Подходът, който издържа: третирайте известието като подсказка, изпълнете делта заявката, за да видите какво се е променило, и я изпълнявайте и по таймер, за да хванете всичко, което едно пропуснато известие би изгубило.

Данни, идентификатори и пропускателна способност

• Съхранени идентификатори. Ако вашата CRM система или система за заявки е записвала идентификатори на елементи от EWS, за да свързва имейли със записи, тези връзки трябва да бъдат преобразувани. Graph има функцията translateExchangeIds точно за това. Планирайте преобразуването като отделна стъпка от миграцията.
• Търсения. ResolveNames съответства на People API, GetUserAvailability на getSchedule, а настройките за отсъствие на настройките на пощенската кутия. Близки еквиваленти, но не идентични.
• Ограничаване на заявките (throttling). Graph ограничава всяка двойка приложение и пощенска кутия до 10 000 заявки на 10 минути, четири едновременни заявки и 150 MB качени данни на 5 минути. Масова задача, която е пускала десетки паралелни нишки към EWS срещу една пощенска кутия, трябва да бъде препроектирана около тези числа.

Празнините и какво никога няма да дойде

Microsoft публикува пътна карта на възможностите на EWS, които все още липсват в Graph. Тя включва пълноценен импорт и експорт за архивни пощенски кутии, пощенски кутии на публични папки и на групи, достъп до архиви на място (in-place archives), права върху папки чрез Exchange Admin API и създаване на съобщения, които не са чернови, от MIME. Повечето цели са за четвъртото тримесечие на 2026 г. Три трябваше да излязат през третото тримесечие, което вече приключи: API за бележки стана общодостъпен в Graph през август 2026 г., а личните списъци с контакти са в предварителна версия (beta) от юни 2026 г. За останалите проверете какво реално е пуснато, преди да проектирате около него. Собственото предупреждение на Microsoft: ако дадена възможност не е в пътната карта, „не планирайте" еквивалент в Graph, преди EWS да бъде изключен.

Потвърдено е, че три възможности никога няма да дойдат в Graph:

• Общ достъп до публични папки (създаване, четене, обновяване и изтриване на папки и елементи).
• Общ достъп до пощенски кутии на групи в Microsoft 365. Вместо това Graph обхваща разговорите, нишките и публикациите в групите.
• Достъп до пощенски кутии за откриване (discovery mailboxes). Вместо това Microsoft насочва към Purview eDiscovery.

Ако даден инструмент зависи от някоя от тях, не е достатъчно да пренесете кода: първо данните или работният процес трябва да се преместят другаде, а това отнема повече време от пренаписването.

План за шест месеца

От днес до 1 април 2027 г. остават малко под шест месеца. Реалистичен ред:

Октомври 2026 г.: вижте къде сте. Проверете EWSEnabled и списъка с разрешени приложения. Експортирайте отчета за използване за 90 дни. Прегледайте списъка, попълнен от Microsoft, премахнете от него това, което не трябва да е там, и добавете редките задачи, за които знаете. Ако наемателят ви все още е на Null, обмислете сами да зададете списъка и стойност True, вместо да чакате Microsoft да превключи на False и да разберете какво се чупи.

Ноември 2026 г.: сортиране. Определете собственик и отговор (оттегляне, обновяване, пренаписване, препроектиране) за всеки идентификатор на приложение. Сканирайте кода. Маркирайте всичко, което засяга публични папки, пощенски кутии на групи или пощенски кутии за откриване, и започнете препроектирането още сега. Създайте регистрациите на приложения в Graph с ограничени права.

Декември 2026 г. до януари 2027 г.: изграждане. Започнете с интеграцията, чиято липса бизнесът би усетил първа. Изградете механизма за синхронизация и известия веднъж и го използвайте повторно. Преобразувайте съхранените идентификатори.

Февруари 2027 г.: паралелна работа. Докато EWS все още работи, пускайте старата и новата версия срещу едни и същи пощенски кутии и сравнявайте резултатите. Щом дадена версия бъде приета, махнете идентификатора ѝ от списъка с разрешени приложения. Това е и тестът: изчакайте 24 часа и потвърдете, че нищо друго не е спряло.

Март 2027 г.: изключете EWS сами. Задайте EWSEnabled на False доста преди 1 април. Всичко пропуснато ще се провали, докато все още можете да включите EWS отново. След 1 април тази възможност изчезва. Преди това пуснете съзнателно и тестово изпълнение на тримесечните и годишните задачи: задача, която се изпълнява при приключване на първото тримесечие, ще се изпълни за първи път, когато EWS вече го няма.

Откъде да получите помощ

Трудният случай е интеграцията, чийто първоначален разработчик вече го няма. Нашата услуга за поддръжка на наследени системи е създадена точно за това: четем съществуващия код, пренаписваме частите с EWS спрямо Microsoft Graph (права, синхронизация, известия, миграция на идентификатори) и пускаме старото и новото паралелно, докато числата съвпаднат. Ако вместо това ви трябват инженери, които да работят във вашия екип, вижте нашата услуга за разширяване на екипа.

Ако отчетът ви за използване е пълен с идентификатори на приложения, които никой не разпознава, пишете на office@c9group.dev.