EWS upphör i Exchange Online 1 april 2027: så flyttar du dina integrationer till Microsoft Graph

Microsoft har börjat stänga av Exchange Web Services (EWS) i Exchange Online. De första stegen genomförs den här månaden, och därefter stängs EWS av en efter en hos de klientorganisationer som aldrig rört sina EWS-inställningar. Microsofts mål för att stänga av EWS helt är 1 april 2027, även om meddelandet MC1485116 i Message Center från 1 oktober räknar med att utrullningen i det globala molnet och i molnen för amerikanska myndigheter är klar i början av juli 2027. Planera för 1 april. Microsoft har sagt rakt ut att det inte blir några undantag efter april 2027.

Om något som ditt företag har byggt pratar med postlådor i Microsoft 365 över EWS slutar det att fungera senast det datumet, och kanske mycket tidigare. De vanliga misstänkta: ett CRM-system som kopplar kundmejl till konton, ett skript för arkivering eller lagring, en bokningsskärm för mötesrum, ett ärendesystem som läser en delad supportpostlåda, ett rapportjobb som räknar mejl per team. Lösningen är att skriva om mot Microsoft Graph, och en del av det EWS klarade har ingen motsvarighet alls i Graph.

Vad som händer, datum för datum

Microsoft styr EWS per klientorganisation med inställningen EWSEnabled, som har tre värden: Null (standard), True och False. Bredvid den finns nu en andra inställning, EWSAllowedAppIDs: en lista över program-ID:n som fortfarande får använda EWS. Den aktuella sidan på Microsoft Learn ger huvuddragen: ”Oktober 2026: EWS börjar inaktiveras globalt för alla organisationer” och ”April 2027: EWS är helt inaktiverat.”

Detaljerna finns i Exchange-teamets inlägg från 1 oktober, EWS Deprecation Is Here. För det globala kommersiella molnet:

• 2 oktober 2026, vid dagens slut Pacific Time: Microsoft registrerar varje klientorganisation som har EWSEnabled satt till True men ingen tillåtelselista.
• 8 och 9 oktober 2026: för de klientorganisationerna skapar Microsoft tillåtelselistan och fyller den med de program-ID:n som använt EWS de senaste 60 dagarna.
• Från 10 oktober 2026: när EWSEnabled är True krävs tillåtelselistan. Ett program som inte står på den nekas.
• Andra fasen, därefter: klientorganisationer som fortfarande står på Null får EWSEnabled satt till False, vilket blockerar EWS för alla program. Var och en får en varning sju dagar i förväg i Message Center, och strax innan fyller Microsoft en tillåtelselista utifrån 60 dagars användning, så att en administratör kan slå på EWS igen med True.
• 1 april 2027: Microsofts måldatum för att EWS ska vara ”helt och permanent inaktiverat”, varefter administratörer inte längre kan ändra EWSEnabled alls. MC1485116 anger början av juli 2027 som förväntat slut på utrullningen i Worldwide, GCC, GCC High och DoD, så vissa klientorganisationer kan få behålla EWS lite längre. Ingen bör räkna med att vara en av dem.

Klientorganisationer i Microsofts andra moln får sina egna tidslinjer via Message Center.

Tillåtelselistan köper tid, inte en lösning

Den automatiska listan byggs från 60 dagars trafik, och Microsofts egen vägledning från 4 september varnar för att den ”kan missa program som körs sällan”. En export vid kvartalsskiftet eller ett arkiveringsjobb vid årsskiftet kommer inte att stå på den och misslyckas nästa gång det körs.

Ändringar i tillåtelselistan tar 24 timmar att slå igenom, och ändringar av EWSEnabled ungefär en timme. Varje åtgärd du gör efter ett fel kostar minst ett dygn.

För att se var din klientorganisation står kan en administratör med Exchange Online PowerShell köra:

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

Vem det här gäller, och vem som kan sluta läsa

Lokala Exchange Server-installationer påverkas inte. Microsoft säger att avvecklingen gäller ”endast Microsoft 365 och Exchange Online” och att ”det inte blir några ändringar av EWS i Exchange Server”. Om alla dina postlådor ligger på egna servrar kan du sluta läsa här.

Hybridmiljöer behöver en närmare titt. Lokala postlådor kan fortsätta använda EWS; postlådor i molnet måste flytta till Graph. Microsofts inlägg om hybridmiljöer från 30 september tar upp två fall som kräver åtgärder nu, bland annat lokala postlådor med arkiv i Exchange Online, där rådet tills vidare är att låta EWS vara aktiverat och lägga hybridprogrammet på tillåtelselistan.

Standardprogramvara är leverantörens jobb. Om det som anropar EWS är en kommersiell produkt är det leverantörens jobb att leverera en version för Graph, och ditt jobb är att få ett datum av dem och installera uppdateringen. Microsofts egna klienter är inget undantag: några syns fortfarande i användningsrapporterna och behöver tillåtelselistan tills de uppdaterats.

Egen kod är ditt jobb. Skript, interna tjänster, anpassade verktyg med öppen källkod och integrationer som en byrå byggde för flera år sedan har ingen uppströms som kan rätta dem. Det är där arbetet finns. För att ge en uppfattning om skalan: exchangelib, ett Python-bibliotek för att prata med Exchange över EWS, laddades ner 1 174 625 gånger från PyPI den senaste månaden. En del av det är lokal användning, men det säger något om hur mycket kod som pratar EWS direkt.

Steg ett: hitta allt som använder EWS

Börja med rapporten över EWS-användning i administrationscentret för Microsoft 365 (Rapporter, Användning, Exchange och sedan fliken för EWS-användning). För varje program listar den program-ID:t i Microsoft Entra, varje SOAP-åtgärd som programmet anropat, anropsvolymen och datumet för senaste aktivitet. Du kan se 7, 30 eller 90 dagar bakåt och exportera till CSV.

Tre saker att känna till om den:

• Datan sammanställs varje vecka och kan ta upp till tio dagar att dyka upp.
• Ett program-ID är inte en ägare. Matcha varje ID mot företagsprogram (Enterprise applications) i Microsoft Entra och leta sedan upp personen eller teamet som driver det. Räkna med några ID:n som ingen känner igen.
• Kolumnen med SOAP-åtgärder visar hur stort varje jobb är. Ett program som bara anropar FindItem och GetItem är ett kort jobb. Ett som anropar SyncFolderItems, Subscribe och ExportItems är ett projekt.

Inte ens 90 dagar fångar årliga jobb, så kontrollera också den andra sidan: schemalagda uppgifter och cron-poster, och sök i kodförråden efter EWS-slutpunkten (Exchange.asmx), EWS Managed API för .NET och exchangelib. Microsofts sida om avvecklingen länkar också till en EWS-analysator för .NET-kod (den flaggar EWS-anrop i Visual Studio och VS Code och föreslår motsvarigheter i Graph) och en handledning om AI-stödd refaktorering.

Steg två: bestäm vad varje integration ska bli

Varje program på listan får ett av fyra svar:

1. Avveckla det. Vissa integrationer finns bara för att ingen har stängt av dem.
2. Uppdatera det. Leverantörsprodukter får en uppgradering från leverantören. Kom överens om datumet nu.
3. Skriv om det mot Microsoft Graph. Standardvalet för egen kod.
4. Gör om designen. För allt som bygger på en förmåga som Graph aldrig kommer att få (se nedan).

Microsoft nämner också Power Platform som ett sätt att bygga om ett arbetsflöde. För ett skript som vidarebefordrar bilagor till en mapp kan det vara det billigaste svaret.

Vad en omskrivning mot Graph faktiskt innebär

De flesta EWS-åtgärder har en direkt motsvarighet i Graph, och Microsoft underhåller en mappning från EWS till Graph. Mappningen är den enkla delen. De svåra delarna är de som den inte visar.

Behörigheterna blir snävare, och det är en fördel

Ett program som använder EWS utan inloggad användare har EWS-programbehörigheten, som Microsoft beskriver som ”full åtkomst till alla postlådor”. Graph delar upp den i separata behörigheter: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read och så vidare.

Du kan också begränsa vilka postlådor ett program når. RBAC för program i Exchange Online tilldelar en behörighet mot ett hanteringsomfång eller en administrativ enhet, och ersätter de äldre principerna för programåtkomst (Application Access Policies). En bokningsskärm för mötesrum kan läsa kalendrarna för tolv rumspostlådor och ingenting annat. En fälla: behörigheter som ges på det här sättet läggs till ovanpå alla behörigheter för hela klientorganisationen i Microsoft Entra, så om Mail.Read fortfarande är godkänd där begränsar ditt omfång ingenting. Ta bort behörigheten i Entra.

Använd certifikat i stället för klienthemligheter för programautentisering där du kan, och håll inloggningsuppgifter borta från skript och kodförråd.

Synkronisering och aviseringar byggs om, de översätts inte

Det här är oftast den största förändringen för allt som håller en lokal kopia av data från postlådan.

Synkronisering. SyncFolderItems motsvaras av deltafrågan för meddelanden i Graph, och SyncFolderHierarchy av deltafrågan för e-postmappar. Deltafrågan för meddelanden arbetar en mapp i taget, så en fullständig synkronisering av en postlåda innebär att hålla reda på mappträdet och spara en separat deltalänk per mapp. Filtreringen är begränsad (bara på mottagningsdatum), och resultaten innehåller borttagningar, flyttar ut ur mappen och ändringar av läst-status även när de inte matchar ditt filter.

Aviseringar. Strömmande prenumerationer och push-prenumerationer i EWS blir ändringsaviseringar i Graph, som levereras till en webhook som du driver eller till Azure Event Hubs eller Event Grid. En webhook måste gå att nå från Microsofts sida, vilket är en arkitekturförändring för ett skript som tidigare höll en anslutning öppen bakom brandväggen. Prenumerationer för e-post, kalender och kontakter gäller som längst 10 080 minuter (knappt sju dygn), eller 1 440 minuter när aviseringen innehåller datan, så något måste förnya dem. Varje postlåda tillåter högst 1 000 aktiva prenumerationer från alla program sammantaget.

Mönstret som håller: behandla en avisering som en ledtråd, kör deltafrågan för att se vad som ändrats, och kör den också med en timer för att fånga upp sådant som en missad avisering annars skulle ha tappat.

Data, ID:n och kapacitet

• Sparade ID:n. Om ditt CRM- eller ärendesystem sparade EWS-objekt-ID:n för att koppla mejl till poster måste de kopplingarna konverteras. Graph har en funktion, translateExchangeIds, för just det. Planera konverteringen som ett eget migreringssteg.
• Uppslag. ResolveNames motsvaras av People API, GetUserAvailability av getSchedule och inställningarna för frånvaro av postlådeinställningarna. Nära motsvarigheter, inte identiska.
• Begränsning. Graph begränsar varje par av program och postlåda till 10 000 anrop per tio minuter, fyra samtidiga anrop och 150 MB uppladdning per fem minuter. Ett massjobb som körde dussintals parallella EWS-trådar mot en och samma postlåda måste byggas om kring de siffrorna.

Luckorna, och det som aldrig kommer

Microsoft publicerar en färdplan över EWS-förmågor som fortfarande saknas i Graph. Den omfattar import och export med full återgivning för arkiv-, offentliga mapp- och grupp-postlådor, åtkomst till arkiv på plats (in-place archives), mappbehörigheter via Exchange Admin API och att skapa meddelanden som inte är utkast från MIME. De flesta målen ligger i fjärde kvartalet 2026. Tre skulle komma i tredje kvartalet, som nu är slut: API:et för anteckningar blev allmänt tillgängligt i Graph i augusti 2026, och personliga kontaktlistor har funnits i förhandsversion (beta) sedan juni 2026. För resten, kontrollera vad som faktiskt har levererats innan du designar runt det. Microsofts egen varning: om en förmåga inte finns på färdplanen ska du ”inte planera för” en motsvarighet i Graph innan EWS stängs av.

Tre förmågor är bekräftade att aldrig komma till Graph:

• Allmän åtkomst till offentliga mappar (skapa, läsa, uppdatera och ta bort mappar och objekt).
• Allmän åtkomst till postlådor för Microsoft 365-grupper. Graph täcker i stället gruppkonversationer, trådar och inlägg.
• Åtkomst till identifieringspostlådor (discovery mailboxes). Microsoft hänvisar i stället till Purview eDiscovery.

Om ett verktyg är beroende av någon av dessa räcker det inte att porta koden: datan eller arbetsflödet måste först flytta någon annanstans, och det tar längre tid än en omskrivning.

En plan för sex månader

Från i dag till 1 april 2027 är det knappt sex månader. En realistisk ordning:

Oktober 2026: se var du står. Kontrollera EWSEnabled och tillåtelselistan. Exportera 90 dagar av användningsrapporten. Gå igenom listan som Microsoft fyllde i, ta bort det som inte ska vara där och lägg till de sällan körda jobb du känner till. Om din klientorganisation fortfarande står på Null, överväg att själv sätta listan och True i stället för att vänta på att Microsoft byter till False och se vad som går sönder.

November 2026: sortering. Ge varje program-ID en ägare och ett svar (avveckla, uppdatera, skriva om, göra om designen). Sök igenom koden. Flagga allt som rör offentliga mappar, grupp-postlådor eller identifieringspostlådor och börja göra om designen nu. Skapa appregistreringarna i Graph med avgränsade behörigheter.

December 2026 till januari 2027: bygg. Börja med den integration som verksamheten skulle sakna först. Bygg rörläggningen för synkronisering och aviseringar en gång och återanvänd den. Konvertera sparade ID:n.

Februari 2027: kör båda parallellt. Medan EWS fortfarande fungerar, kör gamla och nya versioner mot samma postlådor och jämför resultatet. När en version godkänts tar du bort dess ID från tillåtelselistan. Det är också testet: vänta de 24 timmarna och kontrollera att inget annat slutat fungera.

Mars 2027: stäng av EWS själv. Sätt EWSEnabled till False i god tid före 1 april. Allt du missat misslyckas medan du fortfarande kan slå på EWS igen. Efter 1 april finns det alternativet inte längre. Ge också kvartals- och årsjobb en avsiktlig provkörning innan dess: ett jobb som körs när första kvartalet stängs körs annars för första gången efter att EWS försvunnit.

Var du får hjälp

Det svåra fallet är integrationen vars ursprungliga utvecklare har slutat. Vår tjänst för underhåll av äldre system är byggd för det: vi läser den befintliga koden, skriver om EWS-delarna mot Microsoft Graph (behörigheter, synkronisering, aviseringar, ID-migrering) och kör gammalt och nytt parallellt tills siffrorna stämmer. Om du i stället behöver ingenjörer som arbetar i ditt eget team, se vår tjänst för konsultförstärkning.

Om din användningsrapport är full av program-ID:n som ingen känner igen, skriv till office@c9group.dev.