Microsoft ändert die Adresse des Teams-Webclients. Im September 2026 können Nutzer, die teams.microsoft.com öffnen, auf teams.cloud.microsoft weitergeleitet werden. Microsoft beschreibt dies als Domainwechsel und nicht als Migration einer Funktion: Bestehende Links und Lesezeichen sollen weiterhin funktionieren, und Endnutzer müssen keinen neuen Client installieren.

Redaktionelle Illustration einer Browser-Weiterleitung durch unternehmensweite Firewall-, DNS-, Proxy- und App-Prüfungen.

Das klingt zunächst nach Routine. Anders sieht es aus, wenn die Anfrage durch einen Unternehmensproxy, ein Secure Web Gateway, eine DNS-Richtlinie, eine Browser-Allowlist, eine Content-Security-Policy, ein App-Manifest oder eine Fernzugriffskontrolle läuft. In solchen Umgebungen ist eine Weiterleitung nicht automatisch harmlos. Der Browser muss das Ziel auflösen und erreichen können, die Sicherheitskomponenten müssen es zulassen, und eingebettete Teams-Anwendungen müssen den neuen Ursprung erkennen.

Die unmittelbare Empfehlung ist klar: Behandeln Sie teams.cloud.microsoft wie einen produktiven Endpunkt, prüfen Sie die von Ihrer Organisation verwendeten Microsoft-365-Endpunktdaten und testen Sie das vollständige Web-Erlebnis, bevor Nutzer die Änderung durch einen fehlgeschlagenen Anmeldevorgang oder einen leeren Tab bemerken. Die wichtigere Lehre reicht über Teams hinaus. SaaS-URL-Änderungen gehören in Endpoint-Management und Change Control, auch wenn der Anbieter sagt, dass sich keine Produktfunktion ändert.

Was Microsoft ändert

Microsofts Message-Center-Hinweis MC1465764 besagt, dass Teams-Webnutzer bis September 2026 von teams.microsoft.com zu teams.cloud.microsoft weitergeleitet werden. Der Hinweis kennzeichnet die Änderung als wesentliche Änderung mit Auswirkungen auf Administratoren. Das Ziel verwendet Microsofts umfassendere Domainfamilie cloud.microsoft, die Microsoft für authentifizierte, nutzerseitige Microsoft-365-Erlebnisse eingeführt hat.

Die Migration wird nicht als neuer Teams-Client und nicht als neues Kontosystem präsentiert. Wer den Browser nutzt, soll weiterhin denselben Dienst mit denselben Unterhaltungen, Besprechungen, Dateien und Organisationskontexten erreichen. Sichtbar ändert sich die Adresse im Browser – und das Netzwerk- sowie Webanwendungsverhalten, das sich aus dieser Adresse ergibt.

Microsoft sagt, dass die alte URL weiterleiten und bestehende Links weiterhin funktionieren werden. Das verringert die Störung für gewöhnliche Nutzer, beseitigt aber nicht den Bedarf an administrativen Tests. Ein Lesezeichen kann einer HTTP-Weiterleitung folgen; ein streng verwalteter Proxy kann die beiden Hostnamen getrennt bewerten. Eine Seite kann im Browser laden, während ein eingebetteter Tab scheitert, weil seine frame-ancestors-Richtlinie noch nicht aktualisiert wurde. Eine Firewall kann teams.microsoft.com zulassen, aber *.cloud.microsoft ablehnen.

Der Message-Center-Hinweis sagt außerdem, dass eine vorübergehende Administratorsteuerung die Weiterleitung deaktivieren kann. Diese Möglichkeit endet jedoch am 31. Dezember 2026. Sie ist daher ein Migrationshilfsmittel und kein dauerhaftes Betriebsmodell. Organisationen, die sie nutzen, sollten die Ausnahme dokumentieren, einen Verantwortlichen benennen und ihre Entfernung planen.

Microsofts öffentliche Endpunktdokumentation führt für Teams bereits sowohl *.teams.microsoft.com als auch *.teams.cloud.microsoft sowie teams.microsoft.com und teams.cloud.microsoft auf. Dieselbe Dokumentation nennt *.cloud.microsoft als erforderlichen Unified-Domain-Endpunkt für authentifizierte Microsoft-365-Erlebnisse. Die praktische Konsequenz ist wichtig: Eine Organisation sollte ihren maßgeblichen Endpunktprozess aktualisieren und nicht nur einen einzelnen Hostnamen in einer einzelnen Firewallregel ergänzen.

Warum eine Weiterleitung zum Ausfall führen kann

Eine Weiterleitung durchläuft mehrere Kontrollpunkte. Jeder davon kann ein anderes Fehlerbild erzeugen. Für Nutzer sieht das möglicherweise wie ein Ausfall von Teams aus, obwohl der Microsoft-Dienst einwandfrei funktioniert.

Firewalls und Secure Web Gateways

Traditionelle Allowlists enthalten oft ausdrücklich benannte Hostnamen. Erlaubt die Richtlinie teams.microsoft.com, aber nicht teams.cloud.microsoft, kann die erste Anfrage erfolgreich sein und die weitergeleitete Anfrage blockiert werden. Je nach Gateway sehen Nutzer eine verweigerte Zugriffsseite, einen Timeout, eine Authentifizierungsschleife oder ein unvollständiges Anwendungsskelett.

Einige Organisationen verwenden kategoriebasiertes Filtern, TLS-Inspektion oder eine explizite Proxy-Zuordnung. Solche Kontrollen können sich auf Zertifikatsnamen, URL-Kategorien oder Regeln stützen, die um die alte Domain herum geschrieben wurden. Der neue Host muss unter derselben beabsichtigten Richtlinie bewertet werden. Ein breiter Wildcard-Eintrag ohne Prüfung der Gateway-Logik kann unnötige Angriffsfläche schaffen; ein kategorisches Ablehnen des Wildcards ohne Verständnis der Microsoft-Endpunktempfehlungen kann den Betrieb brüchig machen. Die richtige Entscheidung hängt vom Kontrollmodell der Organisation ab, sollte aber bewusst getroffen und dokumentiert werden.

DNS und getrennte Netzwerkpfade

Ein neuer Hostname gelangt ebenfalls in DNS-Abläufe. Interne Resolver, Filterdienste, Secure-DNS-Produkte und Remote-Access-Clients können eine neu beobachtete Domain unterschiedlich behandeln. Testen Sie aus dem Büronetz, von VPN-verbundenen Geräten, aus dem Homeoffice und aus jeder verwalteten Virtual-Desktop-Umgebung. Ein erfolgreicher Test auf dem Laptop eines Administrators beweist nicht, dass sich jeder Ausgangspfad gleich verhält.

Hinterlegen Sie für diese Änderung keine feste IP-Adresse. Microsofts Endpunkthinweise sind auf Dienstdomains und veröffentlichte Adressdaten ausgerichtet, und Cloud-Dienste können ihre zugrunde liegende Infrastruktur ändern. Ein IP-basierter Workaround kann bei einer normalen Dienständerung ausfallen und die Absicht hostnamebasierter Kontrollen umgehen.

Der Teams-Webzugriff hängt neben der Netzwerkerreichbarkeit auch vom Browserverhalten ab. Microsofts Troubleshooting-Hinweise für Teams nennen *.cloud.microsoft unter den Domains, die als vertrauenswürdig eingestuft werden müssen, wenn Browserkontrollen Cookies oder vertrauenswürdige Sites einschränken. Organisationen, die Drittanbieter-Cookies blockieren, Browser-Sitelisten erzwingen oder Gruppenrichtlinien verteilen, sollten Anmeldung, Besprechungsstart und Navigation nach der Weiterleitung prüfen.

Eine Domainausnahme sollte auf die benötigten Microsoft-Dienste begrenzt und über denselben Prüfprozess wie andere authentifizierungsbezogene Ausnahmen gesteuert werden. Deaktivieren Sie nicht global eine Browser-Datenschutzfunktion, nur damit ein einzelner Test gelingt. Klären Sie zuerst, ob Cookie-Gültigkeitsbereich, Trusted-Site-Richtlinie, TLS-Inspektion, Proxyregel oder ein blockierter Endpunkt die Ursache ist.

Eingebettete Teams-Apps und Tabs

Teams ist auch eine Plattform für Anwendungen. Ein benutzerdefinierter Tab, ein Fachverfahren oder eine Partner-App kann innerhalb des Teams-Webclients geladen werden, statt als eigenständige Seite zu erscheinen. Dann verändert der neue Host den Browser-Ursprung und kann Annahmen sichtbar machen, die unter der alten Adresse unbemerkt geblieben sind.

Microsofts Entwicklerdokumentation für Teams empfiehlt App-Verantwortlichen, die Teams-JavaScript-Bibliothek auf Version 2.19.0 oder höher zu aktualisieren und die Anwendung für den neuen Host zu initialisieren. Für Anwendungen mit Content-Security-Policy-Headern soll *.cloud.microsoft in der Direktive frame-ancestors ergänzt werden; die bisherigen Werte sollen während der Migration aus Gründen der Rückwärtskompatibilität erhalten bleiben.

Das ist kein Grund, Sicherheitsheader pauschal zu ändern. Es ist ein Anlass, den Header mit der tatsächlich unterstützten Hostliste abzugleichen, die App im Teams-Webclient zu testen und zu prüfen, ob Ursprungskontrollen, validDomains-Einträge, Cookie-Einstellungen und postMessage-Verarbeitung noch dem vorgesehenen Anwendungsablauf entsprechen.

Ein häufiges Fehlerbild ist Teilerfolg: Das Teams-Shell lädt, aber ein Tab zeigt einen leeren Frame; der Tab öffnet sich, doch die Dateiauswahl scheitert; oder die Authentifizierung kehrt ohne nutzbare Sitzung zur Anwendung zurück. Notieren Sie den im Browser sichtbaren Host und den in Netzwerkspuren auftauchenden Host, bevor Sie Anwendungscode ändern.

Wer betroffen ist

Die wichtigste betroffene Gruppe sind Organisationen, die Teams im Browser verwenden und den ausgehenden Zugriff über Firewalls, Proxys, Secure Web Gateways, DNS-Filter oder verwaltete Browserrichtlinien steuern. Für Menschen, die ausschließlich den Desktop- oder Mobilclient nutzen, ist die Änderung weniger sichtbar. Links, Authentifizierungsübergaben und eingebettete Erlebnisse können jedoch weiterhin Browserkomponenten einbeziehen.

Eine zweite Gruppe sind Teams-App-Verantwortliche. Dazu gehören interne Entwickler, Softwareanbieter, Intranet-Teams und Abteilungen, die Tabs, Nachrichten-Erweiterungen, in Teams eingebettete Websites oder Integrationen mit einer Prüfung des Teams-Ursprungs betreiben. Ihr Risiko beschränkt sich nicht auf die erste Weiterleitung. Ein neuer Host kann Frame-Richtlinien, Ursprungsprüfungen, Annahmen zu Weiterleitungs-URIs, Cookie-Attribute, Telemetrie-Filter und Supportdokumentation beeinflussen.

Auch Netzwerk- und Identitätsteams sollten beteiligt werden. Sie besitzen oft unterschiedliche Teile des Weges: Das Netzwerkteam verwaltet den Ausgang, das Endpoint-Team die Browserrichtlinie, das Identitätsteam die Anmeldungskontrollen und das Anwendungsteam eingebettete Inhalte. Eine Änderung, die alle vier Verantwortungsbereiche berührt, kann zwischen Warteschlangen verloren gehen, wenn niemand sie als eine zusammenhängende Dienständerung behandelt.

Kleine Organisationen sind nicht automatisch ausgenommen. Ein kleines Unternehmen hat vielleicht keinen komplexen Proxy, verlässt sich aber auf eine verwaltete Firewall, einen externen IT-Dienstleister oder eine von der Mutterorganisation übernommene Browserrichtlinie. In einfachen Umgebungen sollte man schnell testen, statt anzunehmen, dass Einfachheit Kompatibilität garantiert.

Die wichtigen Endpunktdetails

Microsofts Dokumentation zu Microsoft-365-URLs und IP-Adressbereichen sagt, dass erforderliche Endpunkte erreichbar sein müssen, und nennt *.cloud.microsoft als erforderliches Unified-Domain-Ziel über TCP 443 und UDP 443. Im Teams-Abschnitt werden *.teams.cloud.microsoft, *.teams.microsoft.com, teams.cloud.microsoft und teams.microsoft.com mit TCP 443 und 80 sowie UDP 443 aufgeführt.

Diese Einträge sind hilfreicher als eine aus einem Forum kopierte Liste, weil Microsoft die Endpunktdaten bei Änderungen des Dienstes aktualisiert. Die Dokumentation erklärt, dass Endpunktdaten normalerweise im Voraus veröffentlicht werden, Aktualisierungen aber auch untermonatlich wegen Supporteskalationen, Sicherheitsvorfällen oder anderer unmittelbarer betrieblicher Anforderungen erfolgen können. Das spricht dafür, den Endpunkt-Feed zu automatisieren, sofern die eigenen Sicherheitswerkzeuge dies unterstützen.

Zugleich zeigt es, warum Endpunktkategorien eine Rolle spielen. Microsoft unterscheidet zwischen erforderlichen, optionalen und standardmäßigen Zielen und erklärt, dass eine Funktion von Endpunkten aus mehreren Arbeitslastgruppen abhängen kann. Wer in einer statischen Liste lediglich nach „Teams“ sucht, kann einen gemeinsamen Authentifizierungs- oder Inhaltsendpunkt übersehen, der für das vollständige Erlebnis notwendig ist.

Die sichere betriebliche Reihenfolge lautet: Vergleichen Sie zunächst die aktuellen Microsoft-Endpunktdaten mit den tatsächlichen Kontrollschichten der Organisation und testen Sie anschließend das Ergebnis. Gehen Sie nicht davon aus, dass eine einzige Allowlist in der Perimeter-Firewall die gesamte Richtlinie darstellt. Ein Cloud Access Security Broker, ein Endpoint-Agent, eine Browserkonfiguration, eine private DNS-Zone oder eine VPN-Split-Tunnel-Regel kann den neuen Host weiterhin blockieren.

Ein praktischer Prüfplan

1. Tatsächliche Nutzer und Wege erfassen

Beginnen Sie mit einer Bestandsaufnahme und nicht mit einer Regeländerung. Ermitteln Sie, welche Nutzergruppen Teams im Browser öffnen, welche Gruppen virtuelle Desktops verwenden, wer über VPN verbunden ist und ob Auftragnehmer oder Managed-Service-Provider eigene Ausgangspfade nutzen. Beziehen Sie gemeinsam genutzte Arbeitsplätze, kioskähnliche Geräte und Besprechungsraumsysteme ein, wenn sie browserbasierte Teams-Links starten.

Dokumentieren Sie die Kontrollen für jeden Pfad: DNS-Filter, Proxy, TLS-Inspektion, Firewall, Secure Web Gateway, Browserrichtlinie, Endpoint-Sicherheit und bedingte Zugriffsrichtlinie der Identitätsplattform. Diese Übersicht erleichtert später die Unterscheidung zwischen einem Dienstproblem und einem lokalen Richtlinienproblem.

2. Quelle der Endpunktdaten prüfen

Verwenden Sie Microsofts aktuelle Dokumentation zu Microsoft-365-Endpunkten und, wenn möglich, deren herunterladbare Daten oder Webservice-Daten, statt sich auf eine lokal gepflegte Tabelle zu verlassen. Bestätigen Sie, dass die erforderlichen Unified-Domain- und Teams-Einträge in den Systemen vertreten sind, die den Zugriff tatsächlich erzwingen.

Wenn die Organisation bewusst nur bestimmte FQDNs erlaubt, entscheiden Sie gemeinsam mit dem Sicherheitsverantwortlichen, ob teams.cloud.microsoft für die aktuelle Teams-Webweiterleitung genügt oder ob der dokumentierte Wildcard für die umfassendere Microsoft-365-Nutzung erforderlich ist. Ein Wildcard kann die Pflege vereinfachen; einzelne Hostnamen begrenzen den Geltungsbereich, verlangen aber häufigere Wartung.

3. Die Weiterleitung selbst testen

Öffnen Sie aus jedem repräsentativen Netzwerkpfad die alte Teams-URL und beobachten Sie die vollständige Kette. Bestätigen Sie, dass die Anfrage teams.cloud.microsoft erreicht, das Zertifikat akzeptiert wird, die Authentifizierung abgeschlossen wird und die Anwendung vollständig lädt. Testen Sie ein normales Benutzerkonto ebenso wie ein Administratorkonto; privilegierte Konten können andere Richtlinien und zwischengespeicherte Zustände haben.

Halten Sie mit den Entwicklertools des Browsers oder Gateway-Logs blockierte Anfragen, Statuscodes und Richtlinienentscheidungen fest. Ziel ist keine riesige Paketerfassung. Vier konkrete Fragen müssen beantwortet werden: Wurde DNS aufgelöst? Hat die Verbindung passiert? Wurde die Weiterleitung abgeschlossen? Hat die Anwendung alle benötigten Ressourcen geladen?

Löschen Sie zwischengespeicherte Websitedaten erst, nachdem Sie das erste Ergebnis dokumentiert haben. Das Leeren des Caches kann ein reproduzierbares Migrationsproblem verstecken oder einen künstlichen Fehler erzeugen, den gewöhnliche Nutzer nicht erleben. Führen Sie mindestens einen Test mit einem sauberen Profil und einen mit dem verwalteten Produktionsprofil durch.

4. Nutzeraktionen statt nur die Startseite testen

Eine erfolgreiche Anmeldeseite reicht nicht. Prüfen Sie die für die Organisation relevanten Aktionen: einen Chat öffnen, einer Besprechung beitreten, sofern aktiviert einen Anruf starten, eine freigegebene Datei öffnen, gegebenenfalls zwischen Mandanten wechseln, einen benutzerdefinierten Tab laden und jede genehmigte Teams-Integration verwenden. Testen Sie sowohl ein direktes Browser-Lesezeichen als auch einen Link aus einer E-Mail oder Kalendereinladung.

Bei Besprechungen sollte der Weg über einen Kalenderlink geprüft werden, weil der Browser zusätzliche Weiterleitungs- und Authentifizierungsschritte durchlaufen kann. Bei Dateien testen Sie das Öffnen und Bearbeiten eines repräsentativen Dokuments, sofern dieser Ablauf wichtig ist. Bei benutzerdefinierten Anwendungen müssen alle geschäftskritischen Tabs und der Rückweg nach der Anmeldung funktionieren.

5. Richtlinien eingebetteter Anwendungen prüfen

App-Verantwortliche sollten Quellcode und Konfiguration nach fest codierten Verweisen auf teams.microsoft.com, expliziten Ursprungsvergleichen, CSP-Werten für frame-ancestors, Listen vertrauenswürdiger Domains, Weiterleitungs-URIs, Annahmen zur Cookie-Domain und Telemetrie-Filtern durchsuchen. Die Suche muss Deployment-Konfiguration und Dokumentation einschließen, nicht nur Anwendungscode.

Befolgen Sie Microsofts Teams-App-Hinweise zur TeamsJS-Version und zum Initialisierungsverhalten. Behalten Sie alte Hostwerte bei, wenn Rückwärtskompatibilität nötig ist, und ergänzen Sie den neuen Host entsprechend dem Sicherheitsmodell der Anwendung. Ersetzen Sie alte Werte nicht blind, wenn Nutzer weiterhin über die alte URL kommen können oder andere Microsoft-365-Hosts unterstützt bleiben.

Nach Änderungen an Headern oder Manifesten testen Sie jeden unterstützten Hostkontext. Eine CSP, die in einem Browser-Tab auf oberster Ebene funktioniert, kann einen eingebetteten Frame trotzdem ablehnen. Umgekehrt kann ein zu großzügiger Testheader verbergen, dass die Produktionsantwort von einem anderen Reverse Proxy oder CDN erzeugt wird.

6. Betriebsmaterial aktualisieren

Durchsuchen Sie Helpdesk-Artikel, Onboarding-Anleitungen, Firewall-Antragsformulare, Proxy-Richtlinien, Browserrichtlinien, Monitoring-Prüfungen und Incident-Runbooks nach dem alten Teams-Hostname. Bewahren Sie die alte URL in historischen Hinweisen auf, wenn das nützlich ist, beschreiben Sie sie aber als Quelle einer Weiterleitung und nicht als einzige Dienstadresse.

Auch das Monitoring muss angepasst werden. Ein synthetischer Test, der den finalen Hostnamen erwartet, kann nach der Umstellung fehlschlagen, obwohl der Dienst gesund ist, wenn er für die alte Adresse geschrieben wurde. Ein Test, der Weiterleitungen verfolgt und die finale Seite prüft, bildet das tatsächliche Verhalten besser ab – vorausgesetzt, er meldet zusätzlich unerwartete Änderungen an der Weiterleitungskette.

Was Sie nicht tun sollten

Weisen Sie Nutzer nicht an, den Proxy zu umgehen, Browserschutz abzuschalten oder standardmäßig ein nicht verwaltetes Gerät zu verwenden. Solche Maßnahmen können das Richtlinienproblem verdecken und ein zweites Sicherheitsproblem schaffen.

Deaktivieren Sie die Weiterleitung nicht dauerhaft, nur weil ein Anwendungsteam seinen Tab noch nicht geprüft hat. Die vorübergehende Administratorsteuerung hat ein Ablaufdatum; wer die Arbeit aufschiebt, macht aus einer kontrollierten Änderung einen Vorfall unter Zeitdruck. Verwenden Sie die Steuerung nur, wenn sie zur Aufrechterhaltung der Dienstkontinuität erforderlich ist und eine konkrete Behebung terminiert wurde.

Ersetzen Sie Hostnamenregeln nicht durch feste IP-Adressen. Microsofts Cloud-Infrastruktur ist auf Weiterentwicklung ausgelegt, und ein IP-Workaround kann veralten oder Datenverkehr falsch routen.

Erlauben Sie nicht pauschal jedes Ziel unter *.microsoft, ohne es zu prüfen. Die einschlägige Microsoft-Dokumentation nennt bestimmte Domainfamilien und Endpunktkategorien; eine über das Geschäftsbedürfnis hinausgehende Freigabe schwächt den Nutzen der Kontrolle.

Behandeln Sie eine HTTP-200-Antwort der ersten Seite nicht als Beweis, dass Teams funktioniert. Der Fehler kann nach der Authentifizierung, während eines API-Aufrufs, beim Laden eines Tabs oder beim Öffnen einer Datei auftreten.

Umgang mit der vorübergehenden Ausnahme

Microsofts Hinweis sagt, dass die Administratorsteuerung zum Deaktivieren der Teams-Weiterleitung am 31. Dezember 2026 endet. Wenn eine Organisation sie verwendet, braucht die Ausnahme einen klaren Grund und einen benannten Verantwortlichen. Ein brauchbarer Eintrag enthält den betroffenen Mandanten oder die Nutzergruppe, die blockierte Abhängigkeit, das verantwortliche Anwendungs- oder Netzwerkteam, den geplanten Testtermin und das Datum der Entfernung.

Die Ausnahme darf kein Ersatz für die Pflege der Endpunkte werden. Ist eine Proxyregel die Ursache, muss die Proxyregel korrigiert werden. Liegt das Problem an der CSP eines benutzerdefinierten Tabs, muss die Anwendungsantwort angepasst werden. Betrifft es eine Drittanbieter-Integration, sollte deren Verantwortlicher nach einem unterstützten Migrationsweg gefragt und die Antwort dokumentiert werden.

Wenn eine geschäftskritische Anwendung nicht rechtzeitig validiert werden kann, trennen Sie die Risiken. Halten Sie die Ausnahme so eng, wie es die verfügbare Kontrolle erlaubt, überwachen Sie den betroffenen Ablauf und teilen Sie dem Serviceverantwortlichen das Enddatum mit. So bleibt die Kontinuität erhalten, ohne dass die Migration aus dem Blick gerät.

Warum dies eine Infrastrukturänderung ist

Ein SaaS-Anbieter kann den Hostnamen ändern, ohne eine sichtbare Funktion zu verändern. Für den Kunden gehört ein Hostname dennoch zum Dienstvertrag, den Netzwerke, Browser und Anwendungen durchsetzen. Die Adresse entscheidet darüber, welche Richtlinie greift, welches Zertifikat inspiziert wird, welche Cookies gesendet werden, welchem Ursprung vertraut wird und welche Protokolle den Datenverkehr erkennen.

Deshalb verdienen Domainmigrationen dieselbe schlanke Disziplin wie andere Produktionsänderungen. Es braucht einen Verantwortlichen, eine Testmatrix, einen Rollback- oder Abhilfeplan, eine Aktualisierung des Monitorings und einen Kommunikationsweg. Daraus muss kein großes Projekt werden. Jemand muss aber den gesamten Pfad verifizieren, statt anzunehmen, dass eine Weiterleitung überall transparent ist.

Die Änderung zeigt außerdem einen Wandel im Cloud-Betrieb. Service-Endpunkte sind kein statischer Anhang mehr, der einmal während des Deployments gepflegt wird. Microsoft sagt, dass sich seine Endpunktdaten mit der Entwicklung der Dienste ändern und außerhalb des normalen Takts aktualisiert werden können, wenn betriebliche Umstände dies erfordern. Organisationen, die Endpunktdaten automatisiert übernehmen, können manuelle Verzögerungen reduzieren. Die Automatisierung braucht trotzdem eine Prüfung: Ein Feed kann eine Firewall aktualisieren, während CSP und Runbook der Anwendung unverändert bleiben.

Kompakte Checkliste für September

  • Klären Sie, ob browserbasiertes Teams in der Organisation verwendet wird.
  • Prüfen Sie MC1465764 im Microsoft-365-Admin Center und ermitteln Sie den Rollout-Status des Mandanten.
  • Bestätigen Sie, dass teams.cloud.microsoft und die relevanten *.cloud.microsoft-Endpunkte gemäß der dokumentierten Netzwerkrichtlinie erlaubt sind.
  • Testen Sie Büro-, VPN-, Remote-, Virtual-Desktop- und verwaltete Browserpfade.
  • Folgen Sie der Weiterleitung und prüfen Sie Anmeldung, Besprechungen, Dateien und kritische Teams-Tabs.
  • Kontrollieren Sie DNS-Filter, Proxyregeln, TLS-Inspektion sowie Browservertrauen und Cookie-Richtlinien.
  • Bitten Sie App-Verantwortliche, TeamsJS, CSP frame-ancestors, Ursprungsvalidierung, Manifeste und Weiterleitungs-URIs zu prüfen.
  • Aktualisieren Sie synthetisches Monitoring, Dokumentation und Helpdesk-Anleitungen.
  • Dokumentieren Sie jede vorübergehende Weiterleitungsausnahme mit Verantwortlichem und Entfernungstermin vor dem 31. Dezember 2026.

Quellen

Microsofts Migration des Teams-Webclients ist in einem nicht verwalteten Browser leicht zu bewältigen, kann für ein gesteuertes Unternehmensnetz aber erhebliche Folgen haben. Die richtige Reaktion ist keine pauschale Notfalländerung an der Firewall. Nötig ist eine kurze, belegbare Prüfung des neuen Endpunkts über die tatsächlichen Wege von Nutzern und Anwendungen. Ist diese Arbeit erledigt, sollte die Weiterleitung das sein, was Microsoft beabsichtigt: eine Änderung der Adresse, keine Änderung der Verfügbarkeit.