Microsoft verschiebt die Verwaltung von Teams-Android-Geräten (Teams Rooms on Android, Teams Phones und Teams Panels) aus dem Teams Admin Center in das Teams Rooms Pro Management Portal. Das bringt endlich alles in ein zentrales Portal – verändert aber auch ein paar eingespielte Abläufe im täglichen Betrieb.
Microsoft räumt weiter auf. Das Management von Android-basierten Teams Devices wandert aus dem Teams Admin Center in das Teams Rooms Pro Management Portal. Und ja, ich weiß: „Microsoft konsolidiert ein Portal“ klingt erstmal nicht nach dem spannendsten Thema der Welt. Oft bedeutet so etwas am Ende nur: gleicher Inhalt, andere Navigation, neue Screenshots für die interne Doku und ein paar genervte Admins, die ihre gewohnten Menüpunkte nicht mehr finden.
Aber in diesem Fall ist es mehr als nur ein neuer Menüpunkt. Es ist ein echter Wechsel im Betriebsmodell für Teams Devices. Und wenn du heute Teams Rooms on Android, Teams Phones, Teams Panels oder SIP Devices im Einsatz hast, dann wird diese Änderung im Alltag sichtbar. Nicht dramatisch. Aber sichtbar.
TL;DR
Microsoft verschiebt das Management von Android-basierten Teams Devices aus dem Teams Admin Center in das Teams Rooms Pro Management Portal. Seit Juni 2026 befindet sich diese Umstellung in Einführung. Betroffen sind Teams Rooms on Android, Teams Phones, Teams Panels und SIP Devices. Teams Rooms on Windows sind bereits im Pro Management Portal und werden damit Teil eines einheitlicheren Betriebsmodells. Geräte sollen automatisch im PMP auftauchen, sobald die Voraussetzungen erfüllt sind. Für dich heißt das: weniger Portal-Chaos, aber du solltest Rollen, Update-Ringe, Support-Prozesse, Admin-Agent-Versionen und interne Dokus rechtzeitig prüfen.
Warum du das Thema nicht ignorieren solltest
Ich weiß, das klingt erstmal nach einem dieser typischen Microsoft-Sätze: „Wir konsolidieren das in ein neues Portal.“ Und ganz ehrlich: In 50 % der Fälle ist das auch nur ein UI-Refresh mit neuen Icons und einem anderen Menü auf der linken Seite.
Hier ist es aber anders.
Bisher war es in vielen Umgebungen ziemlich klar getrennt. Teams Rooms on Windows wurden im Teams Rooms Pro Management Portal verwaltet. Teams Rooms on Android, Teams Phones und Teams Panels lagen im Teams Admin Center. Das hatte sich über die Zeit irgendwie eingespielt, war aber nie wirklich schön. Unterschiedliche Portale, unterschiedliche Health-Ansichten, unterschiedliche Update-Logik, unterschiedliche Remote Actions und unterschiedliche Stellen, an denen dein Support-Team nachschauen musste.
Microsoft beendet diese Trennung jetzt schrittweise und zieht das Management der Android-basierten Teams Devices in das Teams Rooms Pro Management Portal. Ziel ist ein zentraleres Portal für Inventory, Monitoring und Management. Oder anders gesagt: weniger Portal-Springerei und mehr Fokus auf echten Device-Betrieb. Genau das ist aus meiner Sicht auch der wichtige Punkt. Es geht nicht nur darum, Geräte an einem anderen Ort anzuzeigen. Es geht darum, Teams Device Operations sauberer und konsistenter aufzubauen.
Welche Geräte sind betroffen?
Wichtig ist hier die genaue Einordnung, weil das Thema schnell falsch zusammengefasst wird. Microsoft nennt für die Transition aus dem Teams Admin Center ins Teams Rooms Pro Management Portal Teams Rooms on Android, Teams Phones, Teams Panels und SIP Devices. Teams Rooms on Windows sind in diesem Zusammenhang etwas anders zu betrachten. Sie waren bereits im Teams Rooms Pro Management Portal. Der große Schritt ist jetzt, dass Android-basierte Teams Devices ebenfalls in dieses Betriebsmodell wandern.
Das ist also keine reine „Teams Rooms“-Story. Es geht nicht nur um Meetingräume, sondern um einen größeren Schritt in Richtung einheitliches Teams Device Management.
Ebenfalls wichtig:
Teams Displays (ich rede nicht von Scheduling Panels wie das TC10) sind laut Microsoft nicht Teil dieser Remote-Management-Migration. Das passt zum angekündigten Ende des Supports für die Teams Displays App.
Warum macht Microsoft das?
Aus meiner Sicht ist das eine Mischung aus mehreren Dingen. Microsoft braucht ein Portal, das stärker nach Device Operations aussieht. Das Teams Admin Center war für viele Admin-Aufgaben wichtig, aber es war nie wirklich als tiefes Endpoint-Operations-Portal für Meetingräume, Phones, Panels und andere Teams Devices gedacht. Gleichzeitig werden Teams Devices in vielen Unternehmen nicht weniger, sondern mehr. Hybrid Work, mehr Meetingräume, mehr Shared Spaces, mehr Frontline-Szenarien, mehr Support-Aufwand und höhere Erwartungen an Stabilität und Monitoring.
Ganz pragmatisch gesagt: Wenn du 50, 100 oder 500 Teams Devices betreibst, willst du nicht im Jahr 2026 noch verschiedene Admin-Portale offen haben, nur um zu verstehen, warum Raum 2 heute Morgen wieder „Sign-in required“ spielt oder warum das Panel vor dem Konferenzraum nicht sauber synchronisiert.
Zeitplan: Wann passiert das?
Seit Juni 2026 befindet sich die Umstellung in Einführung. Je nach Tenant, Region und Cloud kann sich die tatsächliche Verfügbarkeit natürlich etwas ziehen. Das ist bei solchen Änderungen nichts Neues. Wichtig ist aber: Das Thema ist nicht mehr „kommt irgendwann“. Es ist jetzt relevant.
Microsoft beschreibt den Ablauf in Phasen. Ende Juni 2026 sollen Android Device Management Capabilities im Pro Management Portal sichtbar werden und erste TAC-Workflows in Richtung PMP weiterleiten. Im Juli und August 2026 wird der Funktionsumfang erweitert, PMP wird zunehmend zur Default Experience und TAC-Workflows werden stärker umgeleitet. Für September 2026 ist die Stilllegung überlappender Device-Management-Funktionen im Teams Admin Center vorgesehen. Das bedeutet nicht, dass jeder Tenant an jedem Tag exakt gleich aussieht. Aber die Richtung ist eindeutig: PMP wird die primäre Stelle für Teams Device Management.
Muss ich etwas migrieren?
Die gute Nachricht: Du musst nach aktuellem Stand keine Geräte manuell migrieren. Bestehende Teams Rooms on Android, Teams Panels, Teams Phones und SIP Phones, die im Teams Admin Center enrolled sind, sollen automatisch im Teams Rooms Pro Management Portal erscheinen. Und ja, das ist genau die Art von Satz, die man als Admin gerne liest.
Aber: Nur weil du nichts manuell migrieren musst, heißt das nicht, dass du nichts vorbereiten solltest. Die technische Migration ist nur die eine Seite. Die eigentliche Arbeit liegt in Rollen, Prozessen, Dokumentation, Update-Strategie und in den Voraussetzungen auf den Geräten.
Ein Punkt ist dabei besonders wichtig: Für das Management im PMP brauchen Android-basierte Teams Devices eine passende Admin-Agent-Version. Microsoft nennt hier mindestens AA 830 beziehungsweise die jeweils für das Gerät verfügbare erforderliche Version. Geräte, die nicht auf einer passenden Version sind, können im schlechtesten Fall nach der TAC-Ablösung nicht sauber im PMP verwaltet werden. Genau deshalb sollte man nicht nur schauen, ob Geräte irgendwann sichtbar werden, sondern aktiv prüfen, ob sie auch wirklich managebar sind.
Was bedeutet das für deinen Alltag?
Der erste Punkt ist ziemlich simpel: Dein Support-Team muss umdenken. Wenn dein 1st Level heute sagt „Ich schau mal kurz im Teams Admin Center nach“, dann wird das künftig nicht mehr der erste Griff sein. Das Teams Rooms Pro Management Portal wird die zentrale Stelle für Inventory, Monitoring und Management dieser Geräteklassen.
Das ist gut, aber es heißt auch: neue Oberfläche, neue Navigation, neue Standard-Workflows, neue Begriffe und eine neue Stelle, an der man Fehlerbilder sieht und Remote Actions ausführt. Genau das muss man vorbereiten. Nicht mit einem dreitägigen Workshop. Aber mit einem kurzen Enablement, damit im Incident-Fall niemand erst suchen muss, wo die Funktion jetzt liegt.
Der zweite Punkt ist Rollen und Rechte. Und der ist aus meiner Sicht wichtiger, als viele im ersten Moment denken. Im Teams Admin Center war man in vielen Umgebungen relativ schnell bei sehr breiten Admin-Rollen. Nicht selten hatten Personen deutlich mehr Rechte, als sie eigentlich gebraucht hätten. Im Pro Management Portal wird das Rollenmodell wichtiger, und das ist grundsätzlich gut.
Denn jetzt kannst du sauberer trennen, wer welche Geräte sehen und verwalten darf. Ein lokaler Supporter braucht vielleicht Zugriff auf die Meetingräume in Hamburg, aber nicht auf München, Wien oder Amsterdam. Ein Phone-Admin soll vielleicht Teams Phones verwalten, aber nicht automatisch Räume ändern können. Ein externer Dienstleister soll eventuell bestimmte Remote Actions ausführen dürfen, aber nicht den kompletten Tenant sehen.
Genau das ist einer der echten Vorteile dieser Umstellung. Es geht nicht nur um ein neues Portal, sondern auch darum, Betrieb sauberer zu delegieren. Nicht jeder Supporter muss Zugriff auf alles haben. Und nicht jeder Admin muss automatisch für jeden Raum, jedes Phone und jedes Panel im Unternehmen verantwortlich sein.
Phone-Admins und Room-Admins müssen zusammenrücken
Ein Punkt, der gerne vergessen wird: Teams Phones sind ebenfalls Teil dieser Veränderung. In vielen Unternehmen sind Phone und Video organisatorisch getrennt. Da gibt es die Phone-Leute, die Meeting-Room-Leute, die UC-Admins, den 1st Level und manchmal noch externe Dienstleister. Und plötzlich schauen alle in Richtung Pro Management Portal.
Das ist nicht schlimm. Aber du solltest vorher klären, wer was darf. Sonst passiert der Klassiker: Der Phone-Admin sieht seine Geräte nicht. Der Room-Admin sieht zu viel. Der Dienstleister hat noch TAC-Rechte, aber keine PMP-Rechte. Der Support weiß nicht, welches Portal jetzt führend ist. Das ist dann kein technisches Problem mehr, sondern ein Betriebsproblem. Und Betriebsprobleme kosten am Ende meistens mehr Zeit als technische Probleme.
Update Management wird deutlich wichtiger
Für mich ist das einer der spannendsten Punkte aus der Umstellung. Denn es geht nicht nur darum, wo du Geräte siehst. Es geht auch darum, wie du Updates steuerst.
Bisher war das Thema je nach Gerätetyp und Portal unterschiedlich verteilt. Windows-basierte Teams Rooms waren im Pro Management Portal, Android-basierte Teams Devices wurden im Teams Admin Center verwaltet. Mit der Konsolidierung wird das Update Management deutlich einheitlicher. Und damit wird auch deine Update-Strategie wichtiger.
Nicht alle Räume sollten blind im gleichen Update-Flow hängen. Besser ist ein sauberes Ring-Modell. Zum Beispiel einige wenige Piloträume, danach ein kleiner Early-Adopter-Ring, danach der normale Produktionsring und vielleicht ein späterer Ring für besonders kritische Räume.
Das klingt erstmal nach Overhead, ist es aber nicht. Es ist genau das, was dir hilft, wenn eine Version Probleme macht. Und ja, natürlich liefert Microsoft niemals eine fehlerhafte Version aus. Rein theoretisch. Aber falls doch mal ein Client, ein Treiber, eine Firmware oder eine App-Version Probleme macht, willst du das nicht zuerst in 200 produktiven Räumen merken. Du willst es in zwei oder drei Piloträumen sehen und dann reagieren können.
Wichtig während der Übergangsphase: Update-Ringe und Update-Logiken in PMP sind nicht einfach nur ein 1:1-Abbild aus dem Teams Admin Center. Microsoft beschreibt, dass während der Transition bestehende TAC-Update-Phasen zunächst berücksichtigt werden können, bis Admins aktiv auf die neuen PMP-Update-Ringe umstellen. Genau deshalb sollte man diesen Bereich nicht nur nebenbei anklicken, sondern bewusst prüfen.
Pause Updates ist ein echter Praxisgewinn
Ein weiterer Punkt, der in der Praxis richtig wertvoll ist: Updates pausieren. Das klingt unspektakulär, ist aber im Betrieb Gold wert.
Stell dir vor, du hast eine wichtige Vorstandswoche, ein großes Kundenevent, einen internen Change Freeze oder es gibt Hinweise auf ein Problem mit einer neuen Version. Früher wurden solche Dinge oft irgendwie über Workarounds gelöst. Geräte in andere Ringe schieben, Updates manuell verzögern, eine Mail an alle Beteiligten schreiben und dann hoffen, dass nichts schiefgeht.
Jetzt wird das sauberer. Du kannst Updates temporär pausieren und damit eine geplante Betriebsruhe abbilden. Wichtig ist natürlich: Eine Pause ist nicht dafür gedacht, Updates dauerhaft zu blockieren. Das wäre auch keine gute Idee. Aber für kurze Zeitfenster ist das extrem hilfreich. Gerade in Meeting-Room-Umgebungen, in denen Stabilität oft wichtiger ist als „immer sofort die neueste Version“.
Gleichzeitig sollte man unterscheiden: Normale Update-Pausen sind ein Betriebswerkzeug. Pflichtupdates, die notwendig sind, damit Geräte überhaupt weiterhin sauber im PMP verwaltet werden können, sind ein anderes Thema. Microsoft beschreibt explizit, dass bestimmte Admin-Agent-Updates für die PMP-Readiness beschleunigt beziehungsweise verpflichtend ausgerollt werden können. Das sollte man wissen, damit man nicht überrascht ist, wenn sich genau dieser Teil nicht wie ein normaler Change behandeln lässt.
Deine Runbooks werden alt
Wenn du irgendwo Dokumente hast wie „Öffne Teams Admin Center → Devices → Android …“, dann kannst du dir ziemlich sicher sein: Das wird irgendwann nicht mehr stimmen. Das betrifft interne Wikis, SOPs, Support-Guides, Ticket-Templates, Onboarding-Dokumente für neue Kollegen, Betriebsdokumentation für Dienstleister und wahrscheinlich noch ein paar Stellen, an die heute keiner denkt.
Und genau hier wird es gefährlich. Nicht weil die neue Lösung schlecht ist, sondern weil alte Dokumentation im Support tödlich ist. Wenn jemand im Incident-Fall erst suchen muss, wo die Funktion jetzt liegt, hast du schon verloren. Deshalb würde ich dieses Thema nicht erst nach der Umstellung anfassen.
Was solltest du jetzt tun?
Ich würde es simpel halten. Keine riesigen Projekte. Kein 40-Seiten-Migrationsplan. Aber ein paar Dinge solltest du wirklich einplanen.
Nutze das Teams Rooms Pro Management Portal jetzt aktiv, wenn du es bisher nur „mal gesehen“ hast. Mach dich mit der Navigation vertraut. Wo findest du Räume? Wo findest du Phones? Wo siehst du Health? Wo siehst du Inventory? Wo sind Remote Actions? Wo ist der Update-Status? Wo sind Update-Ringe? Welche Rollen gibt es?
Prüfe außerdem Rollen und Zugriffe. Schau dir an, ob 1st Level Support, 2nd Level Teams oder UC, Meeting Room Ops, AV-Teams, Phone-Admins, Teams-Admins, externe Dienstleister und lokale Standort-Admins wirklich das sehen und tun können, was sie brauchen. Und stelle dir dabei ehrlich die Frage: Brauchen diese Personen wirklich Zugriff auf alles? Oder reicht Zugriff auf bestimmte Geräte, Standorte oder Aufgaben?
Falls du noch keine saubere Ring-Strategie hast, ist jetzt ebenfalls ein guter Zeitpunkt. Ich würde nicht alle Räume in denselben Update-Kanal werfen. Ein paar Piloträume, ein kleiner Early-Adopter-Ring, ein normaler Produktionsring und ein späterer Ring für kritische Räume reichen oft schon aus, um deutlich kontrollierter zu arbeiten.
Prüfe zusätzlich die Admin-Agent-Versionen deiner Android-basierten Teams Devices. Es reicht nicht, dass Geräte grundsätzlich existieren. Sie müssen auch die Voraussetzungen erfüllen, um im PMP sauber verwaltet werden zu können. Wenn Geräte nicht sichtbar oder nicht managebar sind, sollte man Netzwerkfreigaben, erforderliche URLs und die Mindestversion des Admin Agents prüfen.
Und plane bewusst ein, wann Updates pausiert werden dürfen. Zum Beispiel bei kritischen Events, Vorstandswochen, Quartalsabschlüssen, bekannten Hersteller-Issues oder wichtigen Kundenveranstaltungen. Das sollte kein Wildwuchs sein, aber als definierter Betriebsprozess ist es sehr sinnvoll.
Zum Schluss: Kommuniziere die Änderung intern. Ein kurzer Hinweis reicht oft schon aus. „Android-basiertes Teams Device Management zieht ins Pro Management Portal. Bitte PMP als zentrale Stelle für Inventory, Monitoring, Management und Updates nutzen.“ Das verhindert später Diskussionen und spart dem Support unnötige Schleifen.
Was sind die Risiken?
Das größte Risiko ist aus meiner Sicht nicht, dass die Technik nicht funktioniert. Das größte Risiko ist, dass die Umstellung still passiert und dein Betrieb plötzlich an den falschen Stellen sucht.
MC-Items gehen unter. Passiert. Immer. Rechte fehlen. Dokus sind veraltet. Phone und Room Ownership ist nicht sauber geklärt. Update-Ringe wurden nie richtig definiert. Admin-Agent-Versionen sind zu alt. Und plötzlich entsteht aus einer eigentlich sinnvollen Plattform-Änderung ein Support-Thema.
Genau das kann man vermeiden. Nicht mit Panik, sondern mit Vorbereitung.
Was Microsoft tatsächlich sagt
Microsoft beschreibt die Änderung so, dass Inventory, Monitoring und Management für Android-basierte Teams Devices aus dem Teams Admin Center in das Teams Rooms Pro Management Portal wechseln. Betroffen sind Teams Rooms on Android, Teams Phones, Teams Panels und SIP Devices. Teams Rooms on Windows sind bereits im Pro Management Portal und werden dadurch Teil eines einheitlicheren Device-Operations-Modells. Teams Displays werden laut Microsoft nicht in diese Remote-Management-Migration übernommen.
Microsoft beschreibt außerdem einen schrittweisen Rollout: Ende Juni 2026 hat die Transition begonnen, im Juli und August 2026 sind / werden Funktionalitäten erweitert und TAC-Workflows zunehmend umgeleitet. Für September 2026 ist vorgesehen, überlappende Teams Device Management Funktionen im Teams Admin Center stillzulegen. Existing Devices sollen automatisch im PMP erscheinen, wenn Android Device Management GA erreicht und die Voraussetzungen erfüllt sind.
Quelle:
https://learn.microsoft.com/en-us/microsoftteams/rooms/aboutunifieddevicemanagement-pmp1
Mein Takeaway
Ich mag solche Änderungen grundsätzlich. Nicht, weil ich „noch ein Portal“ brauche, sondern weil ich „ein Portal weniger“ will.
Wenn Microsoft das sauber umsetzt, ist das ein echter Schritt nach vorne: weniger Fragmentierung, bessere Übersicht, sauberere Rollen, einheitlicheres Update Management, bessere Device Operations und weniger Portal-Springerei. Aber es ist auch genau die Art von Änderung, die im Alltag unterschätzt wird. Nicht wegen der Technik, sondern wegen Rollen, Support-Abläufen, Update-Ringen, Admin-Agent-Versionen und alten Runbooks.
Mein Tipp: Mach das Teams Rooms Pro Management Portal jetzt zu einem festen Bestandteil deines Betriebs. Prüfe Rollen, baue saubere Update-Ringe, definiere Piloträume, plane Pause-Updates für kritische Zeiträume, prüfe die Admin-Agent-Versionen und aktualisiere deine Support-Doku. Dann ist diese Umstellung kein Projekt. Dann ist es einfach ein sauberer Betriebswechsel.