Co wycofanie EWS przez Microsoft oznacza dla synchronizacji kalendarzy

Exchange Web Services zaczyna być wyłączane 1 października 2026 r., a całkowicie gaśnie 1 kwietnia 2027 r. Oto co naprawdę przestanie działać, co pozostanie nienaruszone i które dwa ustawienia tenanta decydują o tym, do której grupy należysz.

Microsoft wycofuje Exchange Web Services (EWS) w Exchange Online. Wyłączanie rozpoczyna się globalnie 1 października 2026 r., a EWS zostaje całkowicie wyłączone 1 kwietnia 2027 r. Synchronizacja kalendarzy oparta na Microsoft Graph pozostaje nienaruszona. Przestanie natomiast działać międzytenantowa informacja wolny/zajęty między organizacjami partnerskimi, obsługa skrzynek z licencjami Kiosk, F1 i F3 oraz każda aplikacja innej firmy, która nadal wywołuje EWS.

Harmonogram i konkretne daty

Wydarzą się cztery rzeczy w czterech różnych terminach. Często relacjonuje się je jako jedno zdarzenie i dlatego tak wielu administratorów ma w głowie niewłaściwy termin.

Microsoft ogłosił po raz pierwszy w 2018 r., że EWS przestanie otrzymywać aktualizacje funkcjonalne, a w 2023 r. wyznaczył termin wyłączenia na październik 2026 r. Incydent Midnight Blizzard ze stycznia 2024 r. dotyczył EWS i rozszerzył zakres z aplikacji innych firm na własne produkty Microsoftu — dlatego Outlook, Office, Teams i Dynamics 365 również są z niego przenoszone.

Dwa ustawienia, które decydują o wszystkim

Wyłączanie EWS jest sterowane dwiema właściwościami na poziomie tenanta, a to właśnie na ich wzajemnym oddziaływaniu organizacje dają się złapać.

EWSEnabled

Ma trzy wartości: True, False i Null. Null jest dziś wartością domyślną i obecnie zachowuje się jak True. 1 października 2026 r., gdy wdrożenie dotrze do Twojego tenanta, Null zostaje zmienione na False. Ta jedna zmiana blokuje EWS naraz dla każdej aplikacji w tenancie.

Jeśli nadal masz aplikację, która rzeczywiście potrzebuje EWS między październikiem 2026 r. a kwietniem 2027 r., musisz jawnie ustawić EWSEnabled na True. Pozostawienie wartości domyślnej to nie to samo co pozostawienie rzeczy w obecnym stanie.

EWSAllowedAppIDs

Samo ustawienie EWSEnabled na True już nie wystarczy. Od 1 października 2026 r. potrzebujesz również wypełnionej listy dozwolonych z identyfikatorami App ID aplikacji uprawnionych do wywoływania EWS. Pominięcie którejkolwiek z tych dwóch części sprawia, że EWS przestaje działać dla wszystkiego, co od niego zależy.

Microsoft wstępnie wypełnia tę listę przed wrześniem 2026 r. dla tenantów, które jej nie zbudowały, na podstawie zaobserwowanego użycia w każdym tenancie. To pomaga, ale lista powstaje z tego, co Twój tenant akurat ostatnio wywoływał. Aplikacja uruchamiana raz na kwartał albo taka, która była bezczynna w oknie próbkowania, może nie znaleźć się na liście, którą uważasz za kompletną.

Jak sprawdzić własnego tenanta

Zanim cokolwiek zaplanujesz, połącz się z Exchange Online PowerShell i odczytaj bieżący stan:

Get-OrganizationConfig | Format-List EWSEnabled, EWSAllowedAppIDs, EWSApplicationAccessPolicy, EWSAllowList, EWSBlockList

Następnie ustal, czy cokolwiek faktycznie wywołuje EWS. Raporty użycia EWS w centrum administracyjnym Microsoft 365 pokazują rzeczywisty ruch w podziale na aplikacje, co jest bardziej wiarygodne niż wewnętrzne wypytywanie zespołów.

Jeśli udostępniasz dostępność organizacjom partnerskim, sprawdź trzy konfiguracje, które pod spodem opierają się na EWS:

Get-OrganizationRelationship | Format-List Name, DomainNames, FreeBusyAccessEnabled
Get-AvailabilityAddressSpace | Format-List Name, ForestName, AccessMethod
Get-SharingPolicy | Format-List Name, Domains, Enabled

Puste wyniki we wszystkich trzech przypadkach oznaczają, że część międzytenantowa Ciebie nie dotyczy. Microsoft wysłał powiadomienie w centrum wiadomości do każdego tenanta, więc bardzo wielu administratorów otrzymało ostrzeżenie o czymś, czego w ogóle nie używa.

Co przestanie działać, a co nie

Istotne jest rozróżnienie, czy dane narzędzie rozmawia z Exchange Online przez EWS, czy przez Microsoft Graph. Graph to interfejs zastępczy i żadna z powyższych dat go nie dotyczy.

Czy dotyczy to CalendarBridge?

Nie. CalendarBridge łączy się z Microsoft 365 przez Microsoft Graph, korzystając z uprawnień delegowanych Calendars.ReadWrite i User.Read. Nie ma żadnej zależności od EWS, więc daty październik 2026 r. i kwiecień 2027 r. w niczym nie zmieniają działania Twoich połączeń synchronizacji, a CalendarBridge nie wymaga wpisu na liście EWSAllowedAppIDs.

Jeśli przed terminem audytujesz dostawców, to właśnie o to warto zapytać każdego z nich: Graph czy EWS. Każde narzędzie kalendarzowe wciąż oparte na EWS ma przed sobą twardy koniec w kwietniu 2027 r. i migrację do przeprowadzenia jeszcze wcześniej.

Jak migrować, zależnie od tego, co faktycznie masz

Nie ma jednej migracji. To, co zrobisz, zależy od tego, która z czterech powyższych sytuacji Cię dotyczy — a większość organizacji ma więcej niż jedną.

Zastąpienie międzytenantowej informacji wolny/zajęty synchronizacją kalendarzy

Część międzytenantowa najpewniej dotknie zwykłych użytkowników kalendarza, więc warto zrozumieć ten wybór, zamiast domyślnie sięgać po migrację „jeden do jednego”.

Cross-Tenant Access Policy zachowuje obecny model: jeden tenant odpytuje drugi w czasie rzeczywistym, ilekroć ktoś otworzy asystenta planowania. Utrzymuje odpytywanie na żywo i jest właściwą odpowiedzią, gdy naprawdę potrzebujesz dostępności aktualnej co do sekundy w różnych organizacjach. Kosztem jest to, że migrujesz konfigurację zaufania między tenantami, a oba tenanty muszą ją potem utrzymywać w dobrej kondycji.

Synchronizacja kalendarzy odwraca ten model. Zamiast odpytywać tenanta partnerskiego, CalendarBridge kopiuje wydarzenia do kalendarza w Twoim własnym tenancie, gdzie zachowują się jak wszystkie inne wydarzenia. Blokują czas, pojawiają się w asystencie planowania i w Find a Time, a także przetrwają wszystko, co stanie się z relacją między dwoma tenantami, bo nie ma tu żadnego odpytywania na żywo, które mogłoby przestać działać.

Synchronizacja zwykle sprawdza się lepiej, gdy wymaganiem jest, aby ludzie widzieli, kiedy ich odpowiednicy mają zajęty czas. Cross-Tenant Access Policy sprawdza się lepiej, gdy potrzebujesz dokładności w czasie rzeczywistym albo prawdziwego dwustronnego wglądu w szczegóły kalendarza partnera.

Konfiguracja dla siebie

1. Podłącz oba konta do CalendarBridge. Konta Microsoft 365 łączą się przez OAuth przy użyciu delegowanych uprawnień Graph Calendars.ReadWrite i User.Read, więc EWS nie jest w to w ogóle zaangażowane i nie potrzeba żadnego wpisu na liście dozwolonych.
2. Utwórz synchronizację jednokierunkową z kalendarza partnerskiego lub dodatkowego do kalendarza, w którym faktycznie pracujesz.
3. W ustawieniach prywatności połączenia synchronizacji pozostaw pola Subject, Description, Location i Attendees niezaznaczone, aby każda kopia była zwykłym blokiem zajętości. Zaznacz też All Private, jeśli chcesz, aby kopie były odczytywane jako zajętość w Outlook Scheduling Assistant i Google Find a Time.

Konfiguracja dla całej organizacji

Jeśli zastępujesz Organization Relationship obsługujące całą firmę, potrzebujesz synchronizacji zarządzanych, a nie proszenia każdego użytkownika o samodzielną konfigurację:

1. Utwórz konto grupowe z licencjami synchronizacji zamiast licencji użytkownika.
2. Autoryzuj dostęp dla synchronizacji zarządzanych w każdym tenancie, w którym znajdują się potrzebne Ci kalendarze. W Microsoft 365 jest to nadanie uprawnień aplikacji przez administratora tenanta — również w Graph.
3. Podłącz autoryzowane domeny do konta grupowego, po jednej na tenant.
4. Utwórz zarządzane połączenia synchronizacji. Poniżej dwudziestu przypisuj je pojedynczo. Dwadzieścia lub więcej — użyj zadania zbiorczego, aby zaimportować całą listę powiązań w jednym przebiegu.

Ponieważ działa to na uprawnieniach aplikacji nadanych przez administratora każdego tenanta, nie zależy od Organization Relationship, Availability Address Space ani Sharing Policy. Żadna z trzech konfiguracji migrowanych we wrześniu 2026 r. nie leży na tej ścieżce.

Jeśli potrzebujesz tylko opublikować dostępność

Część relacji międzytenantowych istnieje wyłącznie po to, aby strona zewnętrzna widziała, kiedy Twoi ludzie są dostępni. Do tego publiczny kanał kalendarza jest prostszy niż którakolwiek z powyższych opcji. Wybierz kalendarze, wyłącz każde pole szczegółów i udostępnij powstały link lub adres URL subskrypcji ICS. Odbiorca nie potrzebuje ani tenanta Microsoft 365, ani relacji z Twoim, ani żadnego konta. Wersję pole po polu znajdziesz w artykule jak synchronizować kalendarze bez udostępniania szczegółów wydarzeń.

Co zrobić w ciągu najbliższych sześciu tygodni

1. Odczytaj bieżący stan. Uruchom powyższe polecenie Get-OrganizationConfig i zapisz, na jaką wartość ustawione jest dziś EWSEnabled.
2. Pobierz raport użycia. Ustal, co naprawdę wywołuje EWS, zamiast polegać na pamięci organizacji.
3. Sprawdź konfiguracje międzytenantowe. Jeśli Get-OrganizationRelationship nic nie zwraca, możesz przestać martwić się wrześniową datą.
4. Zaudytuj przypisanie licencji. Użytkownicy Kiosk, F1 i F3 tracą EWS bez możliwości wyjątku. Jeśli którykolwiek z nich zależy od narzędzia opartego na EWS, potrzebuje innej licencji.
5. Zadaj dostawcom pytanie o Graph. Poproś o odpowiedź na piśmie i traktuj wymijanie się jako odpowiedź.

Lista dozwolonych to most, a nie cel podróży. Wszystko, co dopiszesz do niej w październiku 2026 r., i tak przestanie działać w kwietniu 2027 r., więc wykorzystaj to okno na migrację, a nie na odkładanie sprawy.

Najczęściej zadawane pytania

Kiedy dokładnie EWS przestanie działać?

EWS zaczyna być globalnie wyłączane 1 października 2026 r., a całkowicie wyłączone zostaje 1 kwietnia 2027 r. Między tymi datami EWS może działać tylko wtedy, gdy tenant ma EWSEnabled ustawione na True, a App ID wywołującej aplikacji znajduje się na liście EWSAllowedAppIDs. Po 1 kwietnia 2027 r. żadne ustawienie go nie utrzyma.

Czy moja synchronizacja kalendarzy przestanie działać po wycofaniu EWS?

Tylko wtedy, gdy Twoje narzędzie do synchronizacji kalendarzy korzysta z EWS. Narzędzia zbudowane na Microsoft Graph pozostają nienaruszone, bo Graph jest interfejsem zastępczym, a nie ofiarą wycofania. CalendarBridge korzysta z Microsoft Graph i nie wymaga wpisu na liście dozwolonych ani żadnej zmiany konfiguracji.

Co się stanie, jeśli nic nie zrobię przed 1 października 2026 r.?

Tenanty, które nadal mają EWSEnabled ustawione na Null, mają tę wartość zmienioną na False w miarę docierania do nich wdrożenia, co blokuje EWS dla każdej aplikacji w tenancie. Null jest obecnie wartością domyślną, więc większość tenantów, które nie podejmą działań, zostanie wyłączona automatycznie.

Czy wycofanie EWS wpływa na międzytenantową informację wolny/zajęty?

Tak. Międzytenantowa informacja wolny/zajęty, MailTips i udostępnianie kalendarzy skonfigurowane przez Organization Relationship, Availability Address Space lub Sharing Policy działają na EWS. Microsoft przenosi je do Microsoft 365 Cross-Tenant Access Policy — wdrożenie ruszyło w sierpniu 2026 r. i kończy się do 1 września 2026 r.

Czy skrzynki Kiosk, F1 i F3 mogą zachować dostęp do EWS?

Nie. Od 1 października 2026 r. żądania EWS ze skrzynek posiadających wyłącznie licencje Exchange Online Kiosk, Microsoft 365 F1 lub Office 365 F3 zwracają HTTP 403. Lista dozwolonych ich nie zwalnia. Tacy użytkownicy potrzebują licencji obejmującej prawa do EWS, na przykład Exchange Online Plan 1 lub 2 albo Microsoft 365 E3 lub E5.

Jak sprawdzić, które aplikacje nadal korzystają z EWS?

Skorzystaj z raportów użycia EWS w centrum administracyjnym Microsoft 365, które pokazują rzeczywisty ruch EWS w podziale na aplikacje. Microsoft udostępnia też narzędzie EWS Analyzer do skanowania kodu wewnętrznego w poszukiwaniu wywołań EWS.

Źródła

Harmonogram i mechanizm zweryfikowane na podstawie dokumentacji Microsoftu: Deprecation of Exchange Web Services in Exchange Online, Exchange Online EWS, Your Time is Almost Up, Introducing EWSAllowedAppIDs oraz Migrate to Microsoft 365 Cross-Tenant Access Policy. Odwołania do centrum wiadomości: MC1446796, MC1227454, MC1191578.