--- service: "Publicasta" schema_version: "1.0" article_id: 610 title: "Microsoft Teams przenosi klienta webowego do teams.cloud.microsoft: kontrole sieci, które zespoły IT muszą przeprowadzić już teraz" language: "pl" default_language: "en" canonical_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=pl" json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=pl" api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=pl" channel_url: "https://publicasta.com/api/public/v1/channels/it_today_news" channel_articles: "https://publicasta.com/api/public/v1/channels/it_today_news/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-14T14:11:33+00:00" updated_at: "2026-09-14T14:11:33+00:00" translations: - language: "ar" html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=ar" markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=ar" json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=ar" - language: "de" html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=de" markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=de" json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=de" - language: "en" html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=en" markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=en" json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=en" - language: "es" html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=es" markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=es" json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=es" - language: "fr" html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=fr" markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=fr" json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=pl" markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=pl" json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=ru" markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=ru" json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026?lang=zh" markdown_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.md?lang=zh" json_url: "https://publicasta.com/it_today_news/microsoft_teams_web_domain_migration_firewall_checks_september_2026.json?lang=zh" --- # Microsoft Teams przenosi klienta webowego do teams.cloud.microsoft: kontrole sieci, które zespoły IT muszą przeprowadzić już teraz > Wrześniowe przekierowanie Teams to pozornie drobna zmiana adresu, która może wywołać incydent w firmowym help desku. Sprawdź zapory, proxy, DNS, polityki przeglądarek, aplikacje osadzone i reguły CSP. Microsoft zmienia adres klienta webowego Teams. We wrześniu 2026 r. użytkownicy, którzy otworzą `teams.microsoft.com`, mogą zostać przekierowani do `teams.cloud.microsoft`. Microsoft opisuje tę operację jako zmianę domeny, a nie migrację funkcji: istniejące linki i zakładki mają nadal działać, a użytkownicy końcowi nie muszą instalować nowego klienta. ![Ilustracja redakcyjna przekierowania przeglądarki przez firmowe kontrole zapory, DNS, serwera proxy i aplikacji osadzonej.](https://publicasta.com/storage/projects/17/pages/610/2026/09/fb6a5668-f4dd-4a25-b9b1-c88a15dfa7ae.webp) Brzmi rutynowo, dopóki żądanie nie przejdzie przez firmowe proxy, bezpieczną bramę internetową, politykę DNS, listę dozwolonych witryn w przeglądarce, politykę bezpieczeństwa treści, manifest aplikacji albo mechanizm kontroli dostępu zdalnego. W takich środowiskach przekierowanie nie jest automatycznie obojętne. Przeglądarka musi rozpoznać i osiągnąć docelowy adres, warstwa bezpieczeństwa musi go dopuścić, a osadzone aplikacje Teams muszą rozpoznawać nową domenę źródłową. Bezpośrednia rada jest prosta: traktuj `teams.cloud.microsoft` jak produkcyjny punkt końcowy, sprawdź dane punktów końcowych Microsoft 365 wykorzystywane w organizacji i przetestuj całą obsługę webową, zanim użytkownicy odkryją zmianę przez nieudane logowanie albo pustą kartę. Wniosek wykracza poza Teams. Zmiany adresów URL usług SaaS powinny trafiać do zarządzania punktami końcowymi i kontroli zmian, nawet gdy dostawca zapewnia, że funkcjonalność produktu się nie zmienia. ## Co zmienia Microsoft Komunikat Message Center MC1465764 informuje, że do września 2026 r. użytkownicy webowego Teams będą przekierowywani z `teams.microsoft.com` do `teams.cloud.microsoft`. Komunikat oznacza zmianę jako istotną i mającą wpływ na administratorów. Docelowy adres należy do szerszej rodziny domen `cloud.microsoft`, którą Microsoft wprowadził dla uwierzytelnionych, widocznych dla użytkownika usług Microsoft 365. Migracja nie jest przedstawiana jako nowy klient Teams ani nowy system kont. Osoba korzystająca z przeglądarki powinna nadal uzyskiwać dostęp do tej samej usługi, z tymi samymi rozmowami, spotkaniami, plikami i kontekstem organizacji. Widoczna różnica to adres w przeglądarce oraz wynikające z niego zachowanie sieci i aplikacji webowych. Microsoft podaje, że stary adres będzie przekierowywał, a istniejące linki zachowają działanie. Ogranicza to zakłócenia dla zwykłych użytkowników, ale nie usuwa potrzeby przeprowadzenia testów administracyjnych. Zakładka może poprawnie podążyć za przekierowaniem HTTP, podczas gdy restrykcyjne proxy oceni obie nazwy hostów osobno. Przeglądarka może wczytać stronę, ale osadzona karta może się nie otworzyć, bo jej polityka `frame-ancestors` nie została zaktualizowana. Zapora może dopuszczać `teams.microsoft.com`, a odrzucać `*.cloud.microsoft`. Komunikat Message Center mówi również, że tymczasowa kontrola administracyjna może wyłączyć przekierowanie, lecz kontrola ta przestanie działać 31 grudnia 2026 r. Jest więc pomocą migracyjną, a nie trwałym modelem działania. Organizacje, które z niej skorzystają, powinny zapisać wyjątek, wyznaczyć właściciela i zaplanować jego usunięcie. Publiczna dokumentacja punktów końcowych Microsoftu wymienia już zarówno `*.teams.microsoft.com`, jak i `*.teams.cloud.microsoft` dla Teams, a także `teams.microsoft.com` oraz `teams.cloud.microsoft`. Ta sama dokumentacja wskazuje `*.cloud.microsoft` jako wymagany zunifikowany punkt końcowy dla uwierzytelnionych usług Microsoft 365. Praktyczny wniosek jest istotny: organizacja powinna zaktualizować proces korzystający ze źródła prawdy o punktach końcowych, a nie tylko dopisać jedną nazwę hosta do jednej reguły zapory. ## Dlaczego przekierowanie może stać się awarią Przekierowanie przechodzi przez kilka punktów kontroli. Każdy z nich może wygenerować inny objaw, a dla użytkownika objaw ten może wyglądać jak „Teams nie działa”, nawet jeśli usługa Microsoftu funkcjonuje prawidłowo. ### Zapory i bezpieczne bramy internetowe Tradycyjne listy dozwolonych adresów często zawierają konkretne nazwy hostów. Jeśli polityka dopuszcza `teams.microsoft.com`, ale nie `teams.cloud.microsoft`, pierwsze żądanie może się udać, a żądanie po przekierowaniu zostanie zablokowane. Zależnie od bramy użytkownik zobaczy stronę odmowy dostępu, przekroczenie czasu, pętlę uwierzytelniania albo niekompletny interfejs aplikacji. Niektóre organizacje używają filtrowania według kategorii, inspekcji TLS albo jawnego kierowania przez proxy. Takie mechanizmy mogą opierać się na nazwach z certyfikatu, kategoriach URL lub regułach napisanych wokół starej domeny. Nowy host trzeba ocenić zgodnie z tą samą zamierzoną polityką. Dodanie szerokiego wildcardu bez sprawdzenia sposobu obsługi może niepotrzebnie zwiększyć ekspozycję; odrzucenie wildcardu bez zrozumienia wskazówek Microsoftu może z kolei stworzyć kruchą konfigurację. Właściwa decyzja zależy od modelu kontroli w organizacji, ale powinna być świadoma i udokumentowana. ### DNS i działanie sieci rozdzielonych Nowa nazwa hosta trafia również do procesów DNS. Wewnętrzne resolvery, usługi filtrujące, produkty bezpiecznego DNS i klienci dostępu zdalnego mogą stosować inne zasady wobec nowo zaobserwowanej domeny. Testuj sieć biurową, urządzenia połączone przez VPN, scenariusze pracy z domu oraz każde zarządzane środowisko wirtualnego pulpitu. Udany test na laptopie administratora nie dowodzi, że każda ścieżka wyjścia zadziała tak samo. Nie wpisuj na stałe adresu IP dla tej zmiany. Wskazówki Microsoftu dotyczące punktów końcowych są sformułowane w kategoriach domen usług i publikowanych danych adresowych, a usługi chmurowe mogą zmieniać bazową infrastrukturę. Obejście oparte na IP może przestać działać przy zwykłej zmianie usługi i ominąć założenia kontroli opartych na nazwach hostów. ### Zaufanie przeglądarki i polityki plików cookie Dostęp do Teams w przeglądarce zależy nie tylko od osiągalności sieci, lecz także od jej zachowania. Wskazówki Microsoftu dotyczące rozwiązywania problemów z Teams wskazują `*.cloud.microsoft` wśród domen, które mogą wymagać zaufania, gdy mechanizmy przeglądarki ograniczają pliki cookie lub listę zaufanych witryn. Organizacje blokujące pliki cookie innych firm, wymuszające listy witryn albo wdrażające polityki grupowe powinny po przekierowaniu sprawdzić logowanie, uruchamianie spotkań i nawigację. Wyjątek dla domeny powinien obejmować tylko wymagane usługi Microsoftu i podlegać temu samemu procesowi przeglądu co inne wyjątki związane z uwierzytelnianiem. Nie wyłączaj globalnie ochrony prywatności przeglądarki tylko po to, aby zaliczyć jeden test. Najpierw ustal, czy problem dotyczy zakresu plików cookie, polityki zaufanych witryn, inspekcji TLS, reguły proxy czy zablokowanego punktu końcowego. ### Osadzone aplikacje i karty Teams Teams jest także gospodarzem aplikacji. Niestandardowa karta, narzędzie biznesowe albo aplikacja partnera może być ładowana wewnątrz webowego klienta Teams, zamiast otwierać się jako strona najwyższego poziomu. W takiej sytuacji nowy host zmienia źródło przeglądarki i może ujawnić założenia, które pod starym adresem pozostawały niewidoczne. Wskazówki deweloperskie Microsoftu dotyczące Teams mówią, że właściciele aplikacji powinni zaktualizować bibliotekę Teams JavaScript do wersji 2.19.0 lub nowszej i zainicjalizować aplikację dla nowego hosta. Dokumentacja wskazuje także, że aplikacje korzystające z nagłówków Content Security Policy powinny uwzględnić `*.cloud.microsoft` w dyrektywie `frame-ancestors`, zachowując dotychczasowe wartości na czas migracji i zapewnienia zgodności wstecznej. Nie oznacza to, że należy bez wyboru zmieniać wszystkie nagłówki bezpieczeństwa. Trzeba natomiast zestawić nagłówek z rzeczywistą listą obsługiwanych hostów, przetestować aplikację w webowym kliencie Teams i sprawdzić, czy walidacja źródła, wpisy `validDomains`, ustawienia cookie oraz obsługa `postMessage` nadal odpowiadają zamierzonemu przepływowi aplikacji. Częsty jest scenariusz częściowego działania: powłoka Teams się ładuje, ale karta pokazuje pustą ramkę; karta się otwiera, lecz wybór pliku nie działa; albo uwierzytelnianie wraca do aplikacji bez użytecznej sesji. Zanim zmienisz kod aplikacji, zapisz host widoczny w przeglądarce oraz host pojawiający się w śladach sieciowych. ## Kogo dotyczy zmiana Najbardziej narażone są organizacje używające Teams w przeglądarce i kontrolujące dostęp wychodzący przez zapory, proxy, bezpieczne bramy internetowe, filtry DNS lub zarządzane polityki przeglądarek. Zmiana będzie mniej widoczna dla osób korzystających wyłącznie z klienta desktopowego albo mobilnego, choć linki, przekazanie uwierzytelniania i osadzone doświadczenia nadal mogą wykorzystywać komponenty przeglądarkowe. Drugą grupą są właściciele aplikacji Teams. Należą do niej wewnętrzne zespoły deweloperskie, dostawcy oprogramowania, zespoły intranetowe i działy utrzymujące karty, rozszerzenia wiadomości, witryny osadzane w Teams lub integracje walidujące źródło Teams. Ich ryzyko nie ogranicza się do początkowego przekierowania. Nowy host może wpłynąć na polityki ramek, sprawdzanie źródła, założenia dotyczące URI przekierowania, atrybuty cookie, filtry telemetrii i dokumentację wsparcia. W prace powinny zostać włączone także zespoły sieciowe i tożsamości. Często odpowiadają za różne fragmenty ścieżki: sieć zarządza wyjściem, zespół urządzeń polityką przeglądarki, zespół tożsamości kontrolami logowania, a zespół aplikacyjny treścią osadzoną. Zmiana przecinająca wszystkie cztery obszary może utknąć między kolejkami, jeśli ktoś nie potraktuje jej jako jednej zmiany usługi. Małe organizacje nie są automatycznie wyłączone. Firma może nie mieć złożonego proxy, ale może korzystać z zarządzanej zapory, zewnętrznego dostawcy IT albo polityki przeglądarki odziedziczonej po organizacji nadrzędnej. W najprostszych środowiskach należy wykonać szybki test, zamiast zakładać, że prostota gwarantuje zgodność. ## Szczegóły punktów końcowych, które mają znaczenie Dokumentacja Microsoftu dotycząca adresów URL i zakresów adresów IP Microsoft 365 mówi, że wymagane punkty końcowe powinny być osiągalne, oraz wskazuje `*.cloud.microsoft` jako wymagane miejsce docelowe zunifikowanej domeny przez TCP 443 i UDP 443. W sekcji Teams wymienia `*.teams.cloud.microsoft`, `*.teams.microsoft.com`, `teams.cloud.microsoft` i `teams.microsoft.com`, z użyciem TCP 443 i 80 oraz UDP 443. Te wpisy są bardziej użyteczne niż lista skopiowana z forum, ponieważ Microsoft aktualizuje dane punktów końcowych wraz ze zmianami usługi. Dokumentacja wyjaśnia, że dane są zwykle publikowane z wyprzedzeniem, ale aktualizacje mogą pojawić się także w trakcie miesiąca z powodu eskalacji wsparcia, incydentów bezpieczeństwa lub innych pilnych wymagań operacyjnych. To mocny argument za automatyzacją źródła punktów końcowych w narzędziach bezpieczeństwa, które ją obsługują. Przypomina to również, że kategorie punktów końcowych mają znaczenie. Microsoft rozróżnia miejsca wymagane, opcjonalne i domyślne oraz wyjaśnia, że jedna funkcja może zależeć od punktów końcowych należących do kilku grup obciążeń. Zespół, który po prostu wyszuka „Teams” w statycznej liście, może pominąć wspólny punkt uwierzytelniania albo treści potrzebny do pełnego działania. Bezpieczna kolejność działań to porównanie aktualnych danych Microsoftu z rzeczywistymi warstwami kontroli w organizacji, a następnie test wyniku. Nie zakładaj, że jedna lista dozwolonych adresów na zaporze brzegowej opisuje całą politykę. Broker bezpieczeństwa dostępu do chmury, agent na urządzeniu, konfiguracja przeglądarki, prywatna strefa DNS albo reguła dzielonego tunelowania VPN nadal może blokować nowy host. ## Praktyczny plan walidacji ### 1. Ustal rzeczywistych użytkowników i ścieżki Zacznij od inwentaryzacji, a nie od zmiany reguły. Ustal, które grupy otwierają Teams w przeglądarce, które korzystają z wirtualnych pulpitów, kto łączy się przez VPN oraz czy kontrahenci albo dostawcy usług zarządzanych korzystają z osobnych ścieżek wyjścia. Uwzględnij współdzielone stacje robocze, urządzenia kioskowe i systemy w salach konferencyjnych, jeśli uruchamiają linki Teams w przeglądarce. Zapisz kontrole stosowane na każdej ścieżce: filtrowanie DNS, proxy, inspekcję TLS, zaporę, bezpieczną bramę internetową, politykę przeglądarki, zabezpieczenia punktów końcowych i warunkową politykę dostępu tożsamości. Taka mapa ułatwi później odróżnienie problemu usługi od problemu lokalnej polityki. ### 2. Przejrzyj źródło punktów końcowych organizacji Korzystaj z aktualnej dokumentacji Microsoftu dotyczącej punktów końcowych Microsoft 365, a jeśli to możliwe, także z jej danych do pobrania lub usługi webowej, zamiast opierać się na lokalnym arkuszu. Potwierdź, że wymagane wpisy zunifikowanej domeny i wpisy Teams są odwzorowane w systemach, które faktycznie egzekwują dostęp. Jeśli organizacja celowo dopuszcza wyłącznie określone FQDN-y, zdecyduj, czy dla obecnego przekierowania webowego Teams wystarczy `teams.cloud.microsoft`, czy też dla szerszego użycia Microsoft 365 potrzebny jest udokumentowany wildcard. Decyzję podejmij z właścicielem bezpieczeństwa. Wildcard upraszcza utrzymanie, natomiast pojedyncze nazwy hostów dają węższy zakres, lecz wymagają częstszej obsługi. ### 3. Przetestuj samo przekierowanie Z każdej reprezentatywnej ścieżki sieciowej otwórz stary adres Teams i obserwuj pełny łańcuch. Potwierdź, że żądanie dociera do `teams.cloud.microsoft`, certyfikat zostaje zaakceptowany, uwierzytelnianie kończy się powodzeniem, a aplikacja wczytuje się do końca. Przetestuj zwykłe konto użytkownika oraz konto administratora; konta uprzywilejowane mogą mieć inną politykę i inny stan pamięci podręcznej. Użyj narzędzi deweloperskich przeglądarki albo logów bramy, aby zapisać zablokowane żądania, kody statusu i decyzje polityk. Nie chodzi o ogromny zrzut pakietów. Trzeba odpowiedzieć na cztery konkretne pytania: czy DNS rozwiązał nazwę, czy połączenie przeszło, czy przekierowanie się zakończyło i czy aplikacja wczytała wszystkie wymagane zasoby? Wyczyść dane witryny dopiero po zapisaniu pierwszego wyniku. Czyszczenie pamięci podręcznej może ukryć powtarzalny problem migracji albo stworzyć fałszywy błąd, którego zwykli użytkownicy nie zobaczą. Wykonaj co najmniej jeden test w czystym profilu i jeden w zarządzanym profilu produkcyjnym. ### 4. Testuj działania użytkownika, nie tylko stronę startową Zielony ekran logowania nie wystarczy. Sprawdź czynności ważne dla organizacji: otwarcie czatu, dołączenie do spotkania, rozpoczęcie połączenia, jeśli jest włączone, otwarcie udostępnionego pliku, przełączanie dzierżawców, jeśli dotyczy, wczytanie niestandardowej karty oraz użycie zatwierdzonej integracji Teams. Przetestuj bezpośrednią zakładkę przeglądarki i link otrzymany w wiadomości e-mail albo zaproszeniu kalendarzowym. W przypadku spotkań sprawdź ścieżkę od linku z kalendarza, ponieważ przeglądarka może przejść przez dodatkowe etapy przekierowania i uwierzytelniania. W przypadku plików przetestuj otwarcie i edycję przykładowego dokumentu, jeśli ten przepływ jest ważny. Dla aplikacji niestandardowych sprawdź każdą krytyczną kartę biznesową oraz powrót po logowaniu. ### 5. Sprawdź polityki aplikacji osadzonych Właściciele aplikacji powinni przeszukać kod źródłowy i konfigurację pod kątem zakodowanych na stałe odwołań do `teams.microsoft.com`, jawnych porównań źródeł, wartości CSP `frame-ancestors`, list zaufanych domen, URI przekierowań, założeń dotyczących domeny cookie i filtrów telemetrii. Wyszukiwanie powinno objąć konfigurację wdrożenia i dokumentację, nie tylko kod aplikacji. Postępuj zgodnie ze wskazówkami Microsoftu dla aplikacji Teams dotyczącymi wersji TeamsJS i sposobu inicjalizacji. Zachowaj stare wartości, jeśli wymagana jest zgodność wsteczna, i dodaj nowy host zgodnie z modelem bezpieczeństwa aplikacji. Nie zastępuj starych wartości bez namysłu, jeżeli użytkownicy nadal mogą przychodzić przez stary adres albo jeśli obsługiwane są inne hosty Microsoft 365. Po zmianie nagłówków lub manifestów przetestuj aplikację w każdym obsługiwanym kontekście hosta. CSP działająca w karcie przeglądarki najwyższego poziomu może nadal odrzucać osadzoną ramkę. Z drugiej strony zbyt liberalny nagłówek testowy może ukryć fakt, że odpowiedź produkcyjna jest generowana przez inny reverse proxy albo CDN. ### 6. Zaktualizuj materiały operacyjne Przeszukaj artykuły help desku, przewodniki wdrożeniowe, formularze zgłoszeń dotyczących zapór, polityki proxy, polityki przeglądarek, kontrole monitoringu i runbooki incydentów pod kątem starej nazwy hosta Teams. Stary adres warto zachować w notatkach historycznych, ale trzeba opisać go jako źródło przekierowania, a nie jedyny adres usługi. Zaktualizuj również monitoring. Test syntetyczny, który wymaga końcowej nazwy starego hosta, może zacząć zgłaszać błąd, mimo że usługa działa prawidłowo. Bardziej reprezentatywny będzie test podążający za przekierowaniem i sprawdzający stronę końcową, pod warunkiem że dodatkowo alarmuje o nieoczekiwanej zmianie łańcucha przekierowań. ## Czego nie robić Nie każ użytkownikom omijać proxy, wyłączać zabezpieczeń przeglądarki ani korzystać z niezarządzanego urządzenia jako standardowego rozwiązania. Takie działania mogą ukryć problem z polityką i stworzyć drugie zagrożenie bezpieczeństwa. Nie wyłączaj przekierowania na stałe tylko dlatego, że zespół aplikacyjny nie przetestował swojej karty. Tymczasowa kontrola administracyjna ma termin wygaśnięcia, a odkładanie pracy zamienia kontrolowaną zmianę w incydent na ostatnią chwilę. Używaj kontroli tylko wtedy, gdy jest potrzebna do zachowania ciągłości usługi, a konkretne usunięcie problemu ma zaplanowany termin. Nie zastępuj reguł nazw hostów stałymi adresami IP. Infrastruktura chmurowa Microsoftu została zaprojektowana tak, aby ewoluować, a obejście oparte na IP może się zestarzeć albo kierować ruch w niewłaściwe miejsce. Nie zezwalaj bez przeglądu na każdy adres `*.microsoft`. Odpowiednia dokumentacja Microsoftu wskazuje konkretne rodziny domen i kategorie punktów końcowych; rozszerzenie dostępu poza wymagania biznesowe osłabia wartość kontroli. Nie uznawaj odpowiedzi HTTP 200 z pierwszej strony za dowód, że Teams działa. Awaria może wystąpić po uwierzytelnieniu, podczas wywołania API, przy ładowaniu karty albo przy otwieraniu pliku. ## Jak obsłużyć tymczasowy wyjątek Komunikat Microsoftu mówi, że kontrola administracyjna wyłączająca przekierowanie Teams wygaśnie 31 grudnia 2026 r. Jeśli organizacja z niej skorzysta, wyjątek powinien mieć jasne uzasadnienie i wyznaczonego właściciela. Przydatny wpis obejmuje dzierżawcę lub grupę użytkowników, której dotyczy problem, zablokowaną zależność, odpowiedzialny zespół aplikacyjny albo sieciowy, docelową datę testu oraz datę usunięcia wyjątku. Wyjątek nie powinien zastępować utrzymania punktów końcowych. Jeśli problemem jest reguła proxy, napraw regułę proxy. Jeśli problemem jest CSP niestandardowej karty, popraw odpowiedź aplikacji. Jeśli winna jest integracja zewnętrzna, poproś jej właściciela o obsługiwaną ścieżkę migracji i zapisz odpowiedź. Jeśli aplikacji krytycznej dla biznesu nie da się zweryfikować na czas, rozdziel ryzyko. Utrzymuj wyjątek w tak wąskim zakresie, na jaki pozwala dostępna kontrola, monitoruj dotknięty przepływ i przekaż datę końcową właścicielowi usługi. Celem jest zachowanie ciągłości przy jednoczesnym utrzymaniu widoczności migracji. ## Dlaczego to zmiana infrastrukturalna Dostawca SaaS może zmienić nazwę hosta bez zmiany funkcji widocznej dla użytkownika. Dla klienta nazwa hosta jest jednak częścią kontraktu usługi egzekwowanego przez sieci, przeglądarki i aplikacje. Adres decyduje o tym, która polityka zostanie dopasowana, jaki certyfikat będzie kontrolowany, które pliki cookie zostaną wysłane, któremu źródłu można zaufać i jak ruch zostanie rozpoznany w logach. Dlatego migracje domen zasługują na taką samą lekką dyscyplinę jak inne zmiany produkcyjne. Potrzebny jest właściciel, macierz testów, plan wycofania lub ograniczenia skutków, aktualizacja monitoringu i ścieżka komunikacji. Nie musi to być duży projekt. Ktoś musi jednak sprawdzić całą ścieżkę, zamiast zakładać, że przekierowanie wszędzie będzie przezroczyste. Ta zmiana pokazuje również kierunek rozwoju operacji chmurowych. Punkty końcowe usług nie są już statycznym dodatkiem utrzymywanym raz, podczas wdrożenia. Microsoft mówi, że dane punktów końcowych zmieniają się wraz z rozwojem usług i mogą być aktualizowane poza zwykłym cyklem, gdy wymagają tego okoliczności operacyjne. Organizacje automatycznie pobierające te dane mogą skrócić opóźnienie ręcznych zmian, ale automatyzacja nadal wymaga przeglądu: źródło może zaktualizować zaporę, podczas gdy CSP aplikacji i runbook pozostaną bez zmian. ## Zwięzła lista kontrolna na wrzesień - Potwierdź, czy w organizacji używany jest Teams w przeglądarce. - Przejrzyj MC1465764 w centrum administracyjnym Microsoft 365 i ustal stan wdrożenia dla dzierżawy. - Potwierdź, że `teams.cloud.microsoft` oraz odpowiednie punkty końcowe `*.cloud.microsoft` są dozwolone przez udokumentowaną politykę sieciową. - Wykonaj testy z sieci biurowej, przez VPN, z lokalizacji zdalnej, z wirtualnego pulpitu i z zarządzanej przeglądarki. - Podążaj za przekierowaniem i sprawdź logowanie, spotkania, pliki oraz krytyczne karty Teams. - Przejrzyj filtrowanie DNS, reguły proxy, inspekcję TLS oraz polityki zaufania przeglądarki i plików cookie. - Poproś właścicieli aplikacji o sprawdzenie TeamsJS, CSP `frame-ancestors`, walidacji źródła, manifestów i URI przekierowań. - Zaktualizuj monitoring syntetyczny, dokumentację i wskazówki dla help desku. - Zapisz każdy tymczasowy wyjątek od przekierowania, podając właściciela i datę usunięcia przypadającą przed 31 grudnia 2026 r. ## Źródła Informacje o terminie przekierowania i tymczasowej kontroli pochodzą z komunikatu Microsoft 365 Message Center MC1465764. Dane dotyczące wymaganych punktów końcowych, domen `cloud.microsoft` oraz adresów używanych przez Teams oparto na dokumentacji Microsoft Learn „Microsoft 365 URLs and IP address ranges”. Zalecenia dotyczące aplikacji osadzonych, biblioteki TeamsJS i dyrektywy CSP `frame-ancestors` odzwierciedlają dokumentację Microsoft Learn „Requirements for Building Tabs”. W kwestii zaufania domen i plików cookie wykorzystano wskazówki Microsoft Learn „Teams doesn't load”. Kontekst rodziny `cloud.microsoft` opisuje materiał Microsoft Community Hub „Introducing cloud.microsoft: a unified domain for Microsoft 365 apps and services”. Dodatkową dyskusję o skutkach zmiany przedstawia artykuł Neowin „Microsoft is changing the domain for Teams on the web, IT admins should validate”. Migracja webowego Teams jest łatwa do przeoczenia w niezarządzanej przeglądarce, a w zarządzanym środowisku firmowym może mieć poważne skutki. Właściwą reakcją nie jest szeroka, awaryjna zmiana zapory, lecz krótka walidacja oparta na dowodach, obejmująca nowy punkt końcowy i rzeczywiste ścieżki użytkowników oraz aplikacji. Po zakończeniu tych prac przekierowanie powinno stać się tym, czym ma być według Microsoftu: zmianą adresu, a nie zmianą dostępności.