Skaner wysyła plik PDF pocztą. Panel rezerwacji odczytuje współdzielony kalendarz. Stary system firmowy pobiera wiadomości ze skrzynki. Wszystkie trzy funkcje mogą wyglądać jak zwykłe elementy Microsoft 365, choć w tle korzystają z Exchange Web Services.
Microsoft zacznie wyłączać EWS w Exchange Online 1 października 2026 roku. Ostateczne wyłączenie nastąpi 1 kwietnia 2027 roku. Daty wynikają z aktualnego harmonogramu wycofania EWS opublikowanego przez Microsoft (sprawdzone: 2026-08-20).
Jeśli nikt nie sprawdził, które urządzenia i aplikacje nadal zależą od tej technologii, rutynowa zmiana platformy może wyglądać jak kilka niezależnych awarii w firmie.
Co naprawdę może przestać działać
EWS to interfejs używany przez oprogramowanie do pracy ze skrzynkami, kalendarzami, kontaktami i innymi danymi Exchange. Nie jest to aplikacja Outlook, a wycofanie EWS nie oznacza zamknięcia poczty Exchange Online. Ryzyko dotyczy połączeń zbudowanych na tej usłudze.
Warto sprawdzić między innymi:
- systemy firmowe, które odczytują albo porządkują wiadomości
- panele rezerwacji i narzędzia do zarządzania salami, które czytają kalendarze
- starsze integracje archiwizacji, kopii zapasowych lub zgodności
- połączenia CRM kopiujące wiadomości albo spotkania
- własne skrypty i usługi działające bez udziału użytkownika
- urządzenia wielofunkcyjne, dla których dostawca zbudował obieg oparty na skrzynce
Urządzenie wysyłające pocztę wyłącznie przez SMTP nie jest automatycznie zależne od EWS. To samo dotyczy aplikacji korzystającej już z Microsoft Graph. Sama nazwa produktu nie wystarczy. Potrzebne są dane z tenanta oraz informacje od właściciela aplikacji i dostawcy.
Objaw biznesowy zwykle jest prostszy niż techniczna przyczyna. Skan nie trafia do biura. Panel nie aktualizuje rezerwacji. Korespondencja z klientem przestaje pojawiać się w CRM. Właściciel widzi zepsuty proces, nie wycofany interfejs API.
Które etapy pracy zależą od dostępu oprogramowania do skrzynki Exchange Online?
Dlaczego 1 października 2026 ma znaczenie
Pierwszy termin działania przypada na 31 sierpnia 2026 roku. Organizacje, które muszą utrzymać EWS w okresie przejściowym, powinny do tego dnia uzupełnić EWSAllowedAppIDs i ustawić EWSEnabled na True. We wrześniu Microsoft planuje automatycznie wypełnić puste listy na podstawie ruchu wykrytego w tenancie, co może objąć aplikacje, których organizacja jeszcze nie sprawdziła.
Od 1 października 2026 roku tenanty Exchange Online, w których nie wykonano wskazanych działań administracyjnych, wejdą w stopniowe blokowanie EWS. Po rozpoczęciu wymuszania EWSEnabled=True z pustą listą blokuje cały ruch EWS. Microsoft opisuje termin sierpniowy i tę zmianę w aktualnych wytycznych przejściowych oraz tabeli zachowania EWSAllowedAppIDs (sprawdzone: 2026-08-20).
To mechanizm przejściowy, nie migracja. Lista ogranicza dostęp EWS do wskazanych identyfikatorów aplikacji, podczas gdy organizacja przenosi je na obsługiwane rozwiązania. Nie przesuwa ostatecznego terminu.
1 kwietnia 2027 roku Microsoft planuje trwale wyłączyć EWS w Exchange Online. Administratorzy stracą wtedy możliwość sterowania tym ustawieniem, a Microsoft zapowiada brak przedłużeń. Zmiana obejmuje Exchange Online. Nie wycofuje EWS z lokalnego Exchange Server, chociaż środowiska hybrydowe wymagają osobnej oceny, ponieważ skrzynki chmurowe pozostają w zakresie zmiany.
Krótkoterminowym ryzykiem jest przerwa w październiku. Stałym terminem jest kwiecień. Dobry plan uwzględnia oba punkty:
- tymczasowo utrzymuje tylko znane i uzasadnione zależności
- usuwa albo przebudowuje je przed ostatecznym wyłączeniem
Jak znaleźć ukryte zależności od EWS
Zacznij od inwentaryzacji, nie od przełącznika. Celem jest połączenie technicznego użycia z urządzeniem, dostawcą, właścicielem i wynikiem biznesowym.
1. Sprawdź dane z tenanta
Microsoft udostępnia raporty użycia EWS oraz skrypt raportujący użycie aplikacji Exchange. Aktualne wytyczne terenowe pokazują, jak te dane pomagają znaleźć rejestracje aplikacji z uprawnieniami EWS i powiązać je z niedawną aktywnością logowania (sprawdzone: 2026-08-20).
Raport jest początkiem dochodzenia. Każdy identyfikator aplikacji powinien prowadzić do rozpoznawalnego właściciela. Cisza w krótkim okresie nie zawsze dowodzi, że zależność zniknęła. Proces sezonowy albo zadanie miesięczne może nie pojawić się w ograniczonym oknie obserwacji.
Dla każdego wyniku zapisz:
- aplikację lub App ID
- ostatnią zaobserwowaną aktywność
- skrzynki albo użytkowników
- właściciela po stronie firmy
- dostawcę lub programistę
- obsługiwany proces biznesowy
Brak właściciela również jest wynikiem. Niezidentyfikowana integracja nie powinna dostawać stałego dostępu tylko dlatego, że jej wyłączenie wydaje się ryzykowne.
2. Przejdź przez urządzenia i systemy firmowe
Raport z tenanta nie zastąpi praktycznego przeglądu. Sprawdź, gdzie dane pocztowe i kalendarzowe wchodzą do codziennej pracy albo z niej wychodzą.
Obejrzyj skanery, systemy magazynowe, narzędzia serwisowe, panele rezerwacji, programy finansowe, połączenia CRM i skrypty działające na serwerze lub komputerze. Zapytaj dostawców, z jakiego interfejsu Exchange korzysta bieżąca wersja. Określenie „zgodne z Microsoft 365” nie wyjaśnia, czy połączenie używa EWS, Graph, SMTP czy jeszcze innej drogi.
W tym miejscu usługa Microsoft 365 i chmura łączy konfigurację techniczną z pracą, którą ona wspiera. Użytecznym wynikiem jest mapa pokazująca, co może się zatrzymać, kto za to odpowiada i jaki jest następny krok.
3. Podejmij decyzję dla każdej zależności
Każda potwierdzona pozycja potrzebuje jednego z czterech rozstrzygnięć:
- migracja integracji do Microsoft Graph albo innego obsługiwanego interfejsu
- aktualizacja lub rekonfiguracja produktu według wspieranej ścieżki dostawcy
- wymiana produktu, jeśli nie istnieje obsługiwana migracja
- usunięcie połączenia, gdy firma już go nie potrzebuje
Wpis na liście dozwolonych EWS może tymczasowo utrzymać ciągłość pracy, ale powinien mieć właściciela i datę usunięcia. Bez nich wyjątek stanie się kolejnym zapomnianym ustawieniem.
4. Testuj cały proces, nie tylko logowanie
Udane uwierzytelnienie nie dowodzi, że obieg jest gotowy. Sprawdź całą drogę razem z osobami, które na niej polegają.
Dla skanera potwierdź odbiór wiadomości, otwarcie załącznika i widoczność błędu. Dla integracji CRM sprawdź, czy właściwa treść trafia do systemu bez duplikatów. Dla panelu rezerwacji przetestuj aktualizacje, uprawnienia i powrót do działania po zerwaniu połączenia.
Zapisz wynik oraz drogę wycofania zmiany albo eskalacji. Gdy test się nie powiedzie, osoba obsługująca firmę w poniedziałek rano powinna wiedzieć, do kogo zadzwonić, bez odtwarzania całej historii projektu.
5. Monitoruj do całkowitego wyłączenia EWS
Po zmianach ponownie przejrzyj użycie. Czysta inwentaryzacja może się zmienić, gdy stare urządzenie wróci do pracy albo dostawca włączy starsze połączenie podczas serwisu.
Microsoft zapowiada comiesięczne wiadomości w Message Center oraz możliwe krótkie testy wyłączenia w tenantach, które nie zrezygnowały z ich udziału. Wytyczne Exchange Team opisują oba działania (sprawdzone: 2026-08-20). Powiadomienia pomagają, ale nie zastąpią właściciela po stronie firmy.
Użyteczny pierwszy przegląd w 30 minut
Pół godziny nie wystarczy na migrację EWS. Pozwala jednak ustalić, czy firma ma kontrolowany projekt, czy nierozpoznane ryzyko. Celem jest krótki pakiet dowodów do następnej decyzji, a nie szybka zmiana konfiguracji.
Sprawdź stan całej organizacji
Poproś administratora Exchange Online o zapisanie bieżącej wartości EWSEnabled oraz informacji, czy skonfigurowano EWSAllowedAppIDs. Wynik zachowaj razem z datą i nazwą tenanta. Jeśli firma musi nadal korzystać z EWS, a działanie wymagane do 31 sierpnia nie zostało wykonane, natychmiast przekaż sprawę administratorowi tenanta. W innym przypadku podczas pierwszego przeglądu nie zmieniaj żadnej z tych wartości.
To ustala punkt wyjścia. Wartości Null, True i False zachowują się inaczej podczas stopniowego wdrożenia Microsoftu, a istniejąca lista może być wynikiem świadomej pracy innego dostawcy. Zmiana bez poznania tej historii może spowodować awarię, której przegląd miał zapobiec.
Pobierz dostępne dane o użyciu
Otwórz informacje o użyciu EWS dostępne dla tenanta albo uruchom metodę raportowania Microsoftu przy użyciu konta z właściwymi uprawnieniami. Zapisz okres raportowania razem z wynikami. Lista bez informacji o zakresie czasu może wprowadzać w błąd.
Podziel wyniki na trzy grupy:
- rozpoznane i nadal potrzebne
- rozpoznane, ale prawdopodobnie możliwe do wymiany albo zbędne
- niezidentyfikowane i wymagające sprawdzenia
Nie uznawaj jeszcze niezidentyfikowanej pozycji za bezpieczną ani niebezpieczną. Przypisz osobę odpowiedzialną i termin identyfikacji. Niepewność pozostaje wtedy widoczna, ale nie staje się stałym wyjątkiem.
Powiąż najważniejsze wpisy z realną pracą
Dla najbardziej aktywnych lub krytycznych biznesowo pozycji zadaj jedno pytanie operacyjne: co zauważy pracownik, jeśli to połączenie przestanie działać jutro?
Odpowiedź zamienia telemetrię w priorytety. App ID z wysoką liczbą wywołań jest dowodem technicznym. „Potwierdzenia z magazynu przestaną docierać do klientów” opisuje wpływ biznesowy, któremu można przypisać termin, test i właściciela.
Na końcu pierwszego przeglądu zapisz:
- stan tenanta i datę zebrania danych
- znane aplikacje i ich właścicieli
- niezidentyfikowane wpisy
- procesy o istotnym wpływie operacyjnym
- następny krok i osobę odpowiedzialną dla każdej ważnej pozycji
Taka strona wystarczy, żeby zdecydować, czy firma wykona pracę samodzielnie, potrzebuje odpowiedzi dostawców, czy powinna zamówić ukierunkowany przegląd tenanta. Nie wystarczy do zatwierdzenia szerokiego dostępu EWS ani uznania migracji za zakończoną.
Czego nie robić
Nie włączaj EWS szeroko „na wszelki wypadek”. Taki ruch zachowuje niepewność i daje każdej zapomnianej integracji taki sam dostęp jak znanemu, krytycznemu połączeniu.
Nie kopiuj każdego zaobserwowanego App ID na listę dozwolonych bez identyfikacji. Aktywność potwierdza użycie, nie zasadność ani przyszłą wartość.
Nie zakładaj, że każdy problem ze skanerem wynika z EWS. Wiele urządzeń używa SMTP, a ich ścieżka migracji może być całkowicie inna. Najpierw ustal rzeczywiste połączenie.
Nie czekaj do 1 kwietnia 2027 roku tylko dlatego, że październikowa blokada wydaje się odwracalna. Tymczasowe ponowne włączenie może przywrócić usługę po przerwie, ale data ostatecznego wyłączenia pozostaje stała. Terminy dostawców, testy i wymiana sprzętu szybko skracają sześciomiesięczne okno.
Nie traktuj Microsoft Graph jak nowej nazwy dla tego samego interfejsu. Uprawnienia, uwierzytelnianie i obsługiwane operacje różnią się. Dostawca albo programista musi potwierdzić właściwy zamiennik dla konkretnego zastosowania.
Kiedy możesz zrobić to samodzielnie
Wewnętrzny przegląd jest realny, gdy jedna osoba ma uprawnienia administratora Exchange Online, potrafi zinterpretować dane, zna właścicieli aplikacji i ma czas na test każdego obiegu. Zakres powinien pozostać prosty: inwentaryzacja, właściciel, decyzja, test i dowód.
Pomoc jest potrzebna, gdy tenant nie ma wyraźnego właściciela, identyfikatorów aplikacji nie można powiązać z produktami, dostawcy nie są zgodni co do migracji albo awaria zatrzyma obsługę klienta, produkcję czy fakturowanie. To samo dotyczy kilku starych integracji korzystających ze wspólnego konta serwisowego, którego uprawnień nikt nie umie wyjaśnić.
Pilnym zadaniem jest uniknięcie październikowej niespodzianki. Trwałym rezultatem powinny być połączenia Exchange, które po wycofaniu EWS pozostaną udokumentowane, przypisane do właścicieli i możliwe do utrzymania.