Írta: Kristijan Sekereš

Az EWS 2027. április 1-jén megszűnik az Exchange Online-ban: integrációk átköltöztetése a Microsoft Graphra

Nyitott laptop egy e-mail-postafiókkal egy sötét szobában

A Microsoft megkezdte az Exchange Web Services (EWS) kikapcsolását az Exchange Online-ban. Az első kikényszerítési lépések ebben a hónapban futnak, ezután azokat a bérlőket (tenant), amelyek soha nem nyúltak az EWS-beállításaikhoz, egyenként kapcsolják le, 2027. április 1-jétől pedig az EWS minden Microsoft 365-bérlőnél megszűnik. A Microsoft egyértelműen kimondta, hogy 2027 áprilisa után nem lesznek kivételek.

Ha valami, amit a cége épített, EWS-en keresztül kommunikál Microsoft 365-postafiókokkal, legkésőbb erre a dátumra leáll, de lehet, hogy sokkal hamarabb. A szokásos gyanúsítottak: egy CRM, amely az ügyfél-e-maileket az ügyfélfiókokhoz iktatja, egy archiváló vagy adatmegőrzési szkript, egy tárgyalófoglaló kijelző, egy jegykezelő rendszer, amely egy közös ügyfélszolgálati postafiókot olvas, egy jelentéskészítő feladat, amely csapatonként számolja az e-maileket. A megoldás a Microsoft Graphra történő újraírás, és amit az EWS tudott, annak egy részére a Graphban egyáltalán nincs megfelelő.

Mi történik, dátumról dátumra

A Microsoft az EWS-t bérlőnként az EWSEnabled beállítással vezérli, amelynek három értéke van: Null (az alapértelmezés), True és False. Mellette mostantól van egy második beállítás is, az EWSAllowedAppIDs: azoknak az alkalmazásazonosítóknak a listája, amelyek továbbra is használhatják az EWS-t. Az aktuális Microsoft Learn-oldal vázlatosan így foglalja össze: „2026. október: az EWS globális letiltása minden szervezetnél megkezdődik”, és „2027. április: az EWS teljesen le van tiltva.”

A részletek az Exchange-csapat október 1-jei bejegyzésében szerepelnek: EWS Deprecation Is Here. A globális kereskedelmi felhőre:

  • 2026. október 2., a csendes-óceáni idő szerinti nap végén: a Microsoft rögzíti az összes olyan bérlőt, amelynél az EWSEnabled értéke True, de nincs engedélyezési lista.
  • 2026. október 8. és 9.: ezeknél a bérlőknél a Microsoft létrehozza az engedélyezési listát, és feltölti azokkal az alkalmazásazonosítókkal, amelyek az előző 60 napban használták az EWS-t.
  • 2026. október 10-étől: ha az EWSEnabled értéke True, az engedélyezési lista kötelező. A rajta nem szereplő alkalmazást elutasítják.
  • Második szakasz, ezt követően: azoknál a bérlőknél, amelyek még Null értéken állnak, az EWSEnabled False értéket kap, ami minden alkalmazásnál blokkolja az EWS-t. Mindegyik 7 nappal előtte figyelmeztetést kap az Üzenetközpontban (Message Center), és a Microsoft röviddel előtte 60 napnyi használat alapján feltölt egy engedélyezési listát, hogy egy rendszergazda True értékkel visszakapcsolhassa az EWS-t.
  • 2027. április 1.: az EWS-t „teljesen és véglegesen letiltják”, és a bérlők rendszergazdái egyáltalán nem módosíthatják többé az EWSEnabled értékét.

A Microsoft többi felhőjében lévő bérlők az Üzenetközpontban kapják meg a saját ütemtervüket.

Az engedélyezési lista időt vásárol, nem megoldást

Az automatikus lista 60 napnyi forgalomból készül, és a Microsoft saját, szeptember 4-i útmutatója figyelmeztet, hogy „kihagyhatja a ritkán futó alkalmazásokat”. Egy negyedév végi export vagy egy év végi archiváló feladat nem lesz rajta, és a következő futásakor el fog bukni.

Az engedélyezési lista módosításai 24 óra alatt lépnek életbe, az EWSEnabled módosításai nagyjából egy óra alatt. Bármely javítás, amelyet egy hiba után végez, legalább egy napba kerül.

Ha látni szeretné, hol tart a bérlője, egy Exchange Online PowerShell-lel rendelkező rendszergazda ezt futtathatja:

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

Kinek szól ez, és ki hagyhatja abba az olvasást

A helyszíni Exchange Servert nem érinti. A Microsoft szerint a kivezetés „csak a Microsoft 365-re és az Exchange Online-ra” vonatkozik, és „az Exchange Server EWS-ében nincs változás”. Ha minden postafiókja a saját szerverein van, itt abbahagyhatja.

A hibrid környezeteket közelebbről kell megnézni. A helyszíni postafiókok továbbra is használhatják az EWS-t; a felhőben lévő postafiókoknak át kell állniuk a Graphra. A Microsoft szeptember 30-i, hibrid környezetekről szóló bejegyzése két olyan esetet tárgyal, amely most azonnali lépést igényel, köztük azokat a helyszíni postafiókokat, amelyek archívuma az Exchange Online-ban van; ezekre egyelőre az a tanács, hogy tartsa bekapcsolva az EWS-t, és tegye fel a hibrid alkalmazást az engedélyezési listára.

A dobozos szoftver a szállító dolga. Ha az EWS-t hívó dolog kereskedelmi termék, a Graph-változat szállítása a szállító feladata, az Öné pedig az, hogy dátumot kérjen tőle, és telepítse a frissítést. A Microsoft saját kliensei sem kivételek: némelyik még megjelenik a használati jelentésekben, és a frissítésig szüksége van az engedélyezési listára.

A házon belüli kód az Ön dolga. A szkripteknek, a belső szolgáltatásoknak, a testre szabott nyílt forráskódú eszközöknek és az egy ügynökség által évekkel ezelőtt épített integrációknak nincs senkijük feljebb, aki kijavítaná őket. Itt van a munka. A nagyságrend érzékeltetésére: az exchangelibet, egy Python-könyvtárat, amellyel EWS-en keresztül lehet az Exchange-dzsel kommunikálni, az elmúlt hónapban 1 174 625 alkalommal töltötték le a PyPI-ról. Ennek egy része helyszíni használat, de jól mutatja, mennyi kód beszél közvetlenül EWS-ül.

Első lépés: keressen meg mindent, ami EWS-t használ

Kezdje a Microsoft 365 Felügyeleti központ EWS-használati jelentésével (Reports, Usage, Exchange, majd az EWS usage lap). Minden alkalmazáshoz felsorolja a Microsoft Entra alkalmazásazonosítót, az alkalmazás által hívott összes SOAP-műveletet, a hívások volumenét és az utolsó aktivitás dátumát. 7, 30 vagy 90 napra tekinthet vissza, és CSV-be exportálhat.

Három dolgot érdemes tudni róla:

  • Az adatokat hetente összesítik, és akár 10 nap is eltelhet, mire megjelennek.
  • Egy alkalmazásazonosító nem gazda. Vesse össze minden azonosítót a Microsoft Entra vállalati alkalmazásaival (Enterprise applications), majd keresse meg azt a személyt vagy csapatot, amely üzemelteti. Számítson néhány olyan azonosítóra, amelyet senki nem ismer fel.
  • A SOAP-művelet oszlop megmutatja, mekkora az egyes feladatok. Az az alkalmazás, amely csak FindItem és GetItem hívásokat végez, rövid munka. Amelyik SyncFolderItems, Subscribe és ExportItems hívásokat végez, az projekt.

Még a 90 nap is kihagyja az éves feladatokat, ezért nézze meg a másik oldalt is: az ütemezett feladatokat és a cron-bejegyzéseket, valamint a kódtárakat, rákeresve az EWS-végpontra (Exchange.asmx), a .NET-es EWS Managed API-ra és az exchangelibre. A Microsoft kivezetési oldala egy .NET-kódhoz készült EWS-elemzőre is hivatkozik (Visual Studióban és VS Code-ban megjelöli az EWS-hívásokat, és Graph-megfelelőket javasol), valamint egy MI-támogatott refaktorálásról szóló oktatóanyagra.

Második lépés: döntse el, mi lesz az egyes integrációkból

A listán szereplő minden alkalmazás négy válasz egyikét kapja:

  1. Kivezetés. Egyes integrációk csak azért léteznek, mert senki nem kapcsolta ki őket.
  2. Frissítés. A szállítói termékek szállítói frissítést kapnak. Egyeztesse a dátumot most.
  3. Újraírás a Microsoft Graphra. A házon belüli kód alapértelmezése.
  4. Újratervezés. Mindenre, ami olyan képességre épül, amely a Graphban soha nem lesz meg (lásd lent).

A Microsoft a Power Platformot is megemlíti egy munkafolyamat újbóli megvalósításának módjaként. Egy szkriptnél, amely mellékleteket továbbít egy mappába, ez lehet a legolcsóbb válasz.

Mit jelent valójában egy Graph-újraírás

A legtöbb EWS-műveletnek van közvetlen Graph-megfelelője, és a Microsoft karbantart egy EWS és Graph közötti megfeleltetést. A megfeleltetés a könnyű rész. A nehezebbek azok, amelyeket nem mutat meg.

A jogosultságok szűkülnek, és ez előny

Az az alkalmazás, amely bejelentkezett felhasználó nélkül használja az EWS-t, az EWS alkalmazásszintű jogosultságával rendelkezik, amelyet a Microsoft „teljes hozzáférés minden postafiókhoz”-ként ír le. A Graph ezt külön jogosultságokra bontja: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read és így tovább.

Azt is korlátozhatja, mely postafiókokat ér el egy alkalmazás. Az Exchange Online alkalmazásokra vonatkozó RBAC-ja egy jogosultságot egy felügyeleti hatókörhöz vagy egy felügyeleti egységhez rendel, és felváltja a régebbi Application Access Policies megoldást. Egy tárgyalófoglaló kijelző így tizenkét tárgyalóterem-postafiók naptárát olvashatja, és semmi mást. Egy csapda: az így adott jogosultságok hozzáadódnak a Microsoft Entra bármely bérlőszintű jogosultságához, így ha ott még mindig jóvá van hagyva a Mail.Read, a hatókör semmit nem korlátoz. Távolítsa el az Entra-beli jogosultságot.

Az alkalmazás hitelesítéséhez, ahol lehet, tanúsítványt használjon titkos ügyfélkulcs (client secret) helyett, és a hitelesítő adatokat tartsa távol a szkriptektől és a kódtáraktól.

A szinkronizálást és az értesítéseket újra kell építeni, nem lefordítani

Ez általában a legnagyobb változás mindennél, ami helyi másolatot tart a postafiókadatokról.

Szinkronizálás. A SyncFolderItems a Graph üzenetekre vonatkozó delta lekérdezésének, a SyncFolderHierarchy pedig a levélmappákra vonatkozó delta lekérdezésnek felel meg. Az üzenet-delta mappánként működik, így egy teljes postafiók szinkronizálása a mappafa követését és mappánként külön delta link tárolását jelenti. A szűrés korlátozott (csak a beérkezés dátumára), és az eredmények a törléseket, a mappából való áthelyezéseket és az olvasottsági állapot változásait is tartalmazzák, akkor is, ha nem felelnek meg a szűrőnek.

Értesítések. Az EWS streaming és push előfizetéseiből Graph-változásértesítések lesznek, amelyeket egy Ön által üzemeltetett webhookra, vagy az Azure Event Hubsba, illetve az Event Gridbe kézbesítenek. A webhooknak a Microsoft oldaláról elérhetőnek kell lennie, ami architekturális változás egy olyan szkriptnél, amely korábban a tűzfal mögül tartott nyitva egy kapcsolatot. A levelezésre, a naptárra és a névjegyekre vonatkozó előfizetések legfeljebb 10 080 percig (alig kevesebb mint hét napig) élnek, vagy 1440 percig, ha az értesítés az adatot is hordozza, így valaminek meg kell újítania őket. Postafiókonként, az összes alkalmazást együtt számolva legfeljebb 1000 aktív előfizetés lehet.

A minta, amely beválik: kezelje az értesítést jelzésként, futtassa a delta lekérdezést, hogy lássa, mi változott, és futtassa időzítve is, hogy elkapja azt, ami egy elmaradt értesítés miatt elveszne.

Adatok, azonosítók és átbocsátóképesség

  • Tárolt azonosítók. Ha a CRM-je vagy a jegykezelő rendszere EWS-elemazonosítókat mentett, hogy e-maileket kapcsoljon rekordokhoz, ezeket a hivatkozásokat át kell alakítani. A Graphban pontosan erre van a translateExchangeIds függvény. Az átalakítást önálló migrációs lépésként tervezze meg.
  • Keresések. A ResolveNames a People API-nak, a GetUserAvailability a getSchedule-nek, a házon kívüli beállítások a postafiók-beállításoknak felelnek meg. Közeli megfelelők, nem azonosak.
  • Szabályozás (throttling). A Graph alkalmazás és postafiók páronként 10 percenként 10 000 kérést, négy egyidejű kérést és 5 percenként 150 MB feltöltést enged. Az a tömeges feladat, amely egy postafiókkal szemben több tucat párhuzamos EWS-szálat futtatott, e számok köré kell újratervezni.

A hiányok, és ami soha nem jön el

A Microsoft ütemtervet tesz közzé azokról az EWS-képességekről, amelyek még hiányoznak a Graphból. Ebben szerepel az archív, a nyilvános mappás és a csoportpostafiókok teljes hűségű importja és exportja, a helyben tárolt archívumok elérése, a mappajogosultságok kezelése az Exchange Admin API-n keresztül, valamint a nem piszkozat üzenetek létrehozása MIME-ből. A legtöbb céldátum 2026 negyedik negyedéve. Néhányat a harmadik negyedévre ígértek, amely mostanra véget ért, ezért ellenőrizze, mi jelent meg ténylegesen, mielőtt köré tervezne. A Microsoft saját figyelmeztetése: ha egy képesség nincs az ütemtervben, „ne számítson” Graph-megfelelőre az EWS lekapcsolása előtt.

Három képességről megerősítették, hogy soha nem kerül be a Graphba:

  • Általános hozzáférés a nyilvános mappákhoz (mappák és elemek létrehozása, olvasása, módosítása és törlése).
  • Általános hozzáférés a Microsoft 365-csoportpostafiókokhoz. A Graph ehelyett a csoportbeszélgetéseket, a szálakat és a bejegyzéseket fedi le.
  • Hozzáférés a felderítési (discovery) postafiókokhoz. A Microsoft ehelyett a Purview eDiscoveryre mutat.

Ha egy eszköz ezek valamelyikére épül, a kód átírása nem elég: előbb az adatnak vagy a munkafolyamatnak kell máshová költöznie, és ez tovább tart, mint egy újraírás.

Hat hónapos terv

Mától 2027. április 1-jéig valamivel kevesebb mint hat hónap van hátra. Egy reális sorrend:

2026. október: nézze meg, hol tart. Ellenőrizze az EWSEnabled értékét és az engedélyezési listát. Exportáljon 90 napnyi használati jelentést. Nézze át a Microsoft által feltöltött listát, távolítsa el, aminek nem kellene rajta lennie, és adja hozzá azokat a ritkán futó feladatokat, amelyekről tud. Ha a bérlője még mindig Null értéken áll, fontolja meg, hogy maga állítja be a listát és a True értéket, ahelyett hogy megvárná, míg a Microsoft False-ra kapcsol, és kiderül, mi romlik el.

2026. november: osztályozás. Rendeljen gazdát és választ (kivezetés, frissítés, újraírás, újratervezés) minden alkalmazásazonosítóhoz. Vizsgálja át a kódot. Jelöljön meg mindent, ami nyilvános mappákhoz, csoportpostafiókokhoz vagy felderítési postafiókokhoz nyúl, és kezdje el most az újratervezést. Hozza létre a Graph-alkalmazásregisztrációkat hatókörrel korlátozott jogosultságokkal.

2026. december és 2027. január között: fejlesztés. Azzal az integrációval kezdje, amelyet az üzlet elsőként hiányolna. A szinkronizálási és értesítési infrastruktúrát egyszer építse meg, és használja újra. Alakítsa át a tárolt azonosítókat.

2027. február: párhuzamos futtatás. Amíg az EWS még működik, futtassa a régi és az új változatot ugyanazokkal a postafiókokkal, és hasonlítsa össze a kimenetet. Ahogy egyenként elfogadják őket, vegye le az azonosítóikat az engedélyezési listáról. Ez egyben a teszt is: várja ki a 24 órát, és győződjön meg róla, hogy semmi más nem állt le.

2027. március: kapcsolja ki saját maga az EWS-t. Állítsa az EWSEnabled értékét False-ra jóval április 1. előtt. Ami kimaradt, akkor bukik el, amikor még visszakapcsolhatja az EWS-t. Április 1. után ez a lehetőség megszűnik. A negyedéves és éves feladatokat is futtassa le tudatosan előtte: egy feladat, amely az első negyedév zárásakor fut, először azután fut le, hogy az EWS már megszűnt.

Hol kaphat segítséget

A nehéz eset az az integráció, amelynek eredeti fejlesztője már elment. A régi rendszerek karbantartására vonatkozó szolgáltatásunk erre készült: elolvassuk a meglévő kódot, az EWS-részeket újraírjuk a Microsoft Graphra (jogosultságok, szinkronizálás, értesítések, azonosítók migrációja), és a régit és az újat párhuzamosan futtatjuk, amíg a számok nem egyeznek. Ha inkább a saját csapatában dolgozó mérnökökre van szüksége, nézze meg a csapatbővítési szolgáltatásunkat.

Ha a használati jelentése tele van olyan alkalmazásazonosítókkal, amelyeket senki nem ismer fel, írjon az office@c9group.dev címre.