Koniec EWS w Exchange Online 1 kwietnia 2027: przenoszenie integracji do Microsoft Graph

Microsoft zaczął wyłączać Exchange Web Services (EWS) w Exchange Online. Pierwsze kroki egzekwowania przypadają na ten miesiąc, po nich wyłączane są po kolei dzierżawy, w których nikt nigdy nie ruszał ustawień EWS, a od 1 kwietnia 2027 EWS znika dla wszystkich dzierżaw Microsoft 365. Microsoft powiedział wprost, że po kwietniu 2027 nie będzie wyjątków.

Jeśli coś, co zbudowała Twoja firma, komunikuje się ze skrzynkami Microsoft 365 przez EWS, przestanie działać najpóźniej w tym dniu, a być może dużo wcześniej. Typowi podejrzani: CRM, który przypisuje e-maile klientów do kont, skrypt archiwizacji lub retencji, ekran rezerwacji sal konferencyjnych, system zgłoszeń czytający wspólną skrzynkę wsparcia, zadanie raportowe liczące e-maile na zespół. Rozwiązaniem jest przepisanie na Microsoft Graph, a części tego, co potrafiło EWS, w Graph w ogóle nie ma.

Co się dzieje, data po dacie

Microsoft steruje EWS w każdej dzierżawie przez ustawienie EWSEnabled, które ma trzy wartości: Null (domyślna), True i False. Obok niego jest teraz drugie ustawienie, EWSAllowedAppIDs: lista identyfikatorów aplikacji, które nadal mogą korzystać z EWS. Aktualna strona Microsoft Learn podaje zarys: „Październik 2026: EWS zaczyna być globalnie wyłączane dla wszystkich organizacji” oraz „Kwiecień 2027: EWS zostaje całkowicie wyłączone”.

Szczegóły są we wpisie zespołu Exchange z 1 października, EWS Deprecation Is Here. Dla globalnej chmury komercyjnej:

• 2 października 2026, koniec dnia czasu pacyficznego: Microsoft odnotowuje każdą dzierżawę, która ma EWSEnabled ustawione na True, ale nie ma listy dozwolonych.
• 8 i 9 października 2026: dla tych dzierżaw Microsoft tworzy listę dozwolonych i wypełnia ją identyfikatorami aplikacji, które korzystały z EWS w poprzednich 60 dniach.
• Od 10 października 2026: gdy EWSEnabled ma wartość True, lista dozwolonych jest wymagana. Aplikacja, której na niej nie ma, dostaje odmowę.
• Druga faza, później: dzierżawy, które wciąż mają Null, dostają EWSEnabled ustawione na False, co blokuje EWS dla wszystkich aplikacji. Każda dostaje ostrzeżenie w Centrum wiadomości z 7-dniowym wyprzedzeniem, a Microsoft tuż wcześniej wypełnia listę dozwolonych na podstawie 60 dni użycia, żeby administrator mógł ponownie włączyć EWS wartością True.
• 1 kwietnia 2027: EWS zostaje „całkowicie i trwale wyłączone”, a administratorzy dzierżaw tracą w ogóle możliwość zmiany EWSEnabled.

Dzierżawy w innych chmurach Microsoftu dostają własne harmonogramy przez Centrum wiadomości.

Lista dozwolonych kupuje czas, a nie rozwiązanie

Automatyczna lista powstaje z 60 dni ruchu, a wytyczne Microsoftu z 4 września ostrzegają, że „może pominąć aplikacje uruchamiane rzadko”. Eksportu na koniec kwartału albo zadania archiwizacji na koniec roku na niej nie będzie i przy następnym uruchomieniu zawiodą.

Zmiany na liście dozwolonych zaczynają działać po 24 godzinach, a zmiany EWSEnabled po mniej więcej godzinie. Każda poprawka wprowadzona po awarii kosztuje co najmniej dzień.

Żeby sprawdzić stan swojej dzierżawy, administrator z Exchange Online PowerShell może uruchomić:

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

Dla kogo to jest, a kto może przestać czytać

Lokalny Exchange Server nie jest objęty zmianą. Microsoft mówi, że wycofanie dotyczy „wyłącznie Microsoft 365 i Exchange Online” i że „w Exchange Server nie ma żadnych zmian w EWS”. Jeśli wszystkie Twoje skrzynki są na własnych serwerach, możesz tu skończyć.

Konfiguracje hybrydowe wymagają bliższego przyjrzenia się. Skrzynki lokalne mogą nadal korzystać z EWS; skrzynki w chmurze muszą przejść na Graph. Wpis Microsoftu o środowiskach hybrydowych z 30 września opisuje dwa przypadki, które wymagają działania już teraz, w tym skrzynki lokalne z archiwami w Exchange Online, dla których zalecenie na razie brzmi: zostaw EWS włączone i dodaj aplikację hybrydową do listy dozwolonych.

Oprogramowanie komercyjne to zadanie producenta. Jeśli EWS wywołuje produkt komercyjny, dostarczenie wersji na Graph należy do producenta, a Twoim zadaniem jest uzyskać od niego datę i zainstalować aktualizację. Klienci samego Microsoftu nie są wyjątkiem: niektórzy wciąż pojawiają się w raportach użycia i do czasu aktualizacji potrzebują listy dozwolonych.

Własny kod to Twoje zadanie. Skrypty, usługi wewnętrzne, dostosowane narzędzia open source i integracje, które agencja zbudowała lata temu, nie mają nikogo wyżej w łańcuchu, kto by je naprawił. Tam jest praca. Dla skali: exchangelib, biblioteka Pythona do komunikacji z Exchange przez EWS, została w ostatnim miesiącu pobrana z PyPI 1 174 625 razy. Część tego to użycie lokalne, ale daje to wyobrażenie, ile kodu rozmawia z EWS bezpośrednio.

Krok pierwszy: znajdź wszystko, co korzysta z EWS

Zacznij od raportu użycia EWS w centrum administracyjnym Microsoft 365 (Raporty, Użycie, Exchange, a potem karta użycia EWS). Dla każdej aplikacji pokazuje identyfikator aplikacji Microsoft Entra, każdą akcję SOAP wywołaną przez tę aplikację, liczbę wywołań i datę ostatniej aktywności. Możesz spojrzeć wstecz o 7, 30 lub 90 dni i wyeksportować dane do CSV.

Trzy rzeczy, które warto o nim wiedzieć:

• Dane są agregowane co tydzień i mogą pojawić się dopiero po 10 dniach.
• Identyfikator aplikacji to nie właściciel. Dopasuj każdy identyfikator do aplikacji dla przedsiębiorstw w Microsoft Entra, a potem znajdź osobę albo zespół, który ją utrzymuje. Spodziewaj się kilku identyfikatorów, których nikt nie rozpozna.
• Kolumna akcji SOAP pokazuje, jak duże jest każde zadanie. Aplikacja, która wywołuje tylko FindItem i GetItem, to krótka praca. Taka, która wywołuje SyncFolderItems, Subscribe i ExportItems, to projekt.

Nawet 90 dni nie wyłapie zadań rocznych, więc sprawdź też drugą stronę: zaplanowane zadania i wpisy cron oraz repozytoria kodu przeszukane pod kątem punktu końcowego EWS (Exchange.asmx), EWS Managed API dla .NET i exchangelib. Strona Microsoftu o wycofaniu odsyła też do analizatora EWS dla kodu .NET (oznacza wywołania EWS w Visual Studio i VS Code i podpowiada odpowiedniki w Graph) oraz do samouczka o refaktoryzacji wspomaganej przez AI.

Krok drugi: zdecyduj, czym stanie się każda integracja

Każda aplikacja z listy dostaje jedną z czterech odpowiedzi:

1. Wycofaj ją. Niektóre integracje istnieją tylko dlatego, że nikt ich nie wyłączył.
2. Zaktualizuj ją. Produkty komercyjne dostają aktualizację od producenta. Uzgodnij datę już teraz.
3. Przepisz ją na Microsoft Graph. Domyślna odpowiedź dla własnego kodu.
4. Zaprojektuj ją od nowa. Dla wszystkiego, co opiera się na funkcji, której Graph nigdy nie będzie miał (patrz niżej).

Microsoft wymienia też Power Platform jako sposób na ponowne zbudowanie przepływu pracy. Dla skryptu, który przekazuje załączniki do folderu, to może być najtańsza odpowiedź.

Co naprawdę oznacza przepisanie na Graph

Większość operacji EWS ma bezpośredni odpowiednik w Graph, a Microsoft utrzymuje mapowanie EWS na Graph. Mapowanie to łatwa część. Trudniejsze są te, których ono nie pokazuje.

Uprawnienia się zawężają i to jest zaleta

Aplikacja korzystająca z EWS bez zalogowanego użytkownika ma uprawnienie aplikacyjne EWS, które Microsoft opisuje jako „pełny dostęp do wszystkich skrzynek pocztowych”. Graph dzieli to na osobne uprawnienia: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read i tak dalej.

Możesz też ograniczyć, do których skrzynek aplikacja ma dostęp. RBAC dla aplikacji w Exchange Online przypisuje uprawnienie w ramach zakresu zarządzania albo jednostki administracyjnej i zastępuje starsze zasady dostępu aplikacji (Application Access Policies). Ekran rezerwacji sal może czytać kalendarze dwunastu skrzynek sal i nic więcej. Jedna pułapka: uprawnienia nadane w ten sposób dodają się do uprawnień nadanych dla całej dzierżawy w Microsoft Entra, więc jeśli zgoda na Mail.Read nadal tam jest, Twój zakres niczego nie ogranicza. Usuń uprawnienie w Entra.

Do uwierzytelniania aplikacji używaj w miarę możliwości certyfikatów zamiast kluczy tajnych klienta i trzymaj dane uwierzytelniające poza skryptami i repozytoriami.

Synchronizację i powiadomienia buduje się od nowa, a nie tłumaczy

To zwykle największa zmiana dla wszystkiego, co przechowuje lokalną kopię danych ze skrzynki.

Synchronizacja. SyncFolderItems odpowiada zapytaniu delta dla wiadomości w Graph, a SyncFolderHierarchy zapytaniu delta dla folderów poczty. Delta wiadomości działa folder po folderze, więc pełna synchronizacja skrzynki oznacza śledzenie drzewa folderów i przechowywanie osobnego linku delta dla każdego folderu. Filtrowanie jest ograniczone (tylko po dacie otrzymania), a wyniki obejmują usunięcia, przeniesienia poza folder i zmiany stanu przeczytania, nawet jeśli nie pasują do filtra.

Powiadomienia. Subskrypcje strumieniowe i push w EWS stają się powiadomieniami o zmianach w Graph, dostarczanymi do webhooka, który prowadzisz, albo do Azure Event Hubs lub Event Grid. Webhook musi być osiągalny od strony Microsoftu, co oznacza zmianę architektury dla skryptu, który dotąd trzymał otwarte połączenie zza zapory. Subskrypcje dla poczty, kalendarza i kontaktów trwają najwyżej 10 080 minut (niecałe siedem dni) albo 1440 minut, gdy powiadomienie przenosi dane, więc coś musi je odnawiać. Każda skrzynka dopuszcza najwyżej 1000 aktywnych subskrypcji łącznie dla wszystkich aplikacji.

Wzorzec, który się sprawdza: traktuj powiadomienie jako wskazówkę, uruchom zapytanie delta, żeby zobaczyć, co się zmieniło, i uruchamiaj je też według harmonogramu, żeby wyłapać wszystko, co przepadłoby przy pominiętym powiadomieniu.

Dane, identyfikatory i przepustowość

• Zapisane identyfikatory. Jeśli CRM albo system zgłoszeń zapisywał identyfikatory elementów EWS, żeby wiązać e-maile z rekordami, te powiązania trzeba przekonwertować. Graph ma do tego funkcję translateExchangeIds. Zaplanuj konwersję jako osobny krok migracji.
• Wyszukiwania. ResolveNames odpowiada People API, GetUserAvailability odpowiada getSchedule, ustawienia nieobecności w biurze odpowiadają ustawieniom skrzynki. Bliskie odpowiedniki, ale nie identyczne.
• Ograniczanie przepustowości. Graph ogranicza każdą parę aplikacji i skrzynki do 10 000 żądań na 10 minut, czterech równoczesnych żądań i 150 MB przesyłanych danych na 5 minut. Zadanie masowe, które uruchamiało dziesiątki równoległych wątków EWS na jednej skrzynce, trzeba przeprojektować pod te liczby.

Luki i to, czego nigdy nie będzie

Microsoft publikuje plan rozwoju z funkcjami EWS, których wciąż brakuje w Graph. Są na nim pełny import i eksport dla skrzynek archiwalnych, folderów publicznych i skrzynek grup, dostęp do archiwów lokalnych w skrzynce (in-place archives), uprawnienia do folderów przez Exchange Admin API i tworzenie wiadomości innych niż wersje robocze z MIME. Większość ma termin w czwartym kwartale 2026. Kilka miało pojawić się w trzecim kwartale, który właśnie się skończył, więc zanim zaprojektujesz coś wokół nich, sprawdź, co faktycznie zostało wydane. Ostrzeżenie samego Microsoftu: jeśli funkcji nie ma w planie rozwoju, „nie zakładaj”, że jej odpowiednik w Graph pojawi się przed wyłączeniem EWS.

Trzy funkcje oficjalnie nigdy nie trafią do Graph:

• Ogólny dostęp do folderów publicznych (tworzenie, odczyt, aktualizacja i usuwanie folderów i elementów).
• Ogólny dostęp do skrzynek grup Microsoft 365. Graph obejmuje zamiast tego konwersacje, wątki i wpisy grup.
• Dostęp do skrzynek wyszukiwania (discovery mailboxes). Microsoft odsyła zamiast tego do Purview eDiscovery.

Jeśli narzędzie zależy od jednej z tych funkcji, przeniesienie kodu nie wystarczy: najpierw dane albo przepływ pracy muszą przenieść się gdzie indziej, a to trwa dłużej niż przepisanie.

Plan na sześć miesięcy

Od dziś do 1 kwietnia 2027 zostało niecałe sześć miesięcy. Realistyczna kolejność:

Październik 2026: sprawdź, gdzie jesteś. Sprawdź EWSEnabled i listę dozwolonych. Wyeksportuj 90 dni raportu użycia. Przejrzyj listę wypełnioną przez Microsoft, usuń to, czego nie powinno na niej być, i dodaj rzadkie zadania, o których wiesz. Jeśli Twoja dzierżawa wciąż ma Null, rozważ samodzielne ustawienie listy i wartości True, zamiast czekać, aż Microsoft przełączy ją na False, i dopiero wtedy przekonywać się, co przestało działać.

Listopad 2026: selekcja. Przypisz właściciela i odpowiedź (wycofać, zaktualizować, przepisać, zaprojektować od nowa) do każdego identyfikatora aplikacji. Przeskanuj kod. Oznacz wszystko, co dotyka folderów publicznych, skrzynek grup albo skrzynek wyszukiwania, i zacznij przeprojektowanie już teraz. Utwórz rejestracje aplikacji w Graph z ograniczonymi uprawnieniami.

Od grudnia 2026 do stycznia 2027: budowa. Zacznij od integracji, której brak firma odczułaby najwcześniej. Zbuduj mechanizm synchronizacji i powiadomień raz i używaj go wielokrotnie. Przekonwertuj zapisane identyfikatory.

Luty 2027: uruchom oba warianty równolegle. Dopóki EWS jeszcze działa, uruchamiaj starą i nową wersję na tych samych skrzynkach i porównuj wyniki. Po zaakceptowaniu każdej usuń jej identyfikator z listy dozwolonych. To jest zarazem test: odczekaj 24 godziny i potwierdź, że nic innego nie przestało działać.

Marzec 2027: wyłącz EWS samodzielnie. Ustaw EWSEnabled na False dużo wcześniej niż 1 kwietnia. Wszystko, co przeoczyłeś, zawiedzie wtedy, gdy wciąż jeszcze możesz ponownie włączyć EWS. Po 1 kwietnia ta możliwość znika. Przed tym terminem przeprowadź też celowe uruchomienie testowe zadań kwartalnych i rocznych: zadanie, które startuje po zamknięciu pierwszego kwartału, po raz pierwszy uruchomi się już po zniknięciu EWS.

Gdzie szukać pomocy

Trudny przypadek to integracja, której pierwotny autor już odszedł. Nasza usługa utrzymania systemów odziedziczonych jest zbudowana właśnie pod to: czytamy istniejący kod, przepisujemy części EWS na Microsoft Graph (uprawnienia, synchronizacja, powiadomienia, migracja identyfikatorów) i uruchamiamy starą i nową wersję równolegle, aż liczby się zgodzą. Jeśli zamiast tego potrzebujesz inżynierów pracujących w Twoim zespole, zobacz naszą usługę wsparcia zespołów (staff augmentation).

Jeśli Twój raport użycia jest pełen identyfikatorów aplikacji, których nikt nie rozpoznaje, napisz na office@c9group.dev.