Microsoft Teams | Private Kanäle ziehen ins Gruppenpostfach

Microsoft hat zwischen Oktober 2025 und Ende April 2026 sämtliche privaten Kanäle in Teams auf eine neue Speicherarchitektur migriert, ohne dass du davon im Admin Center etwas gesehen hast. Die Nachrichten privater Kanäle liegen seitdem nicht mehr als Kopien in den Postfächern der einzelnen Mitglieder, sondern in einem eigenen Kanalpostfach an der Microsoft-365-Gruppe des Teams.

Das klingt nach internem Umbau, verschiebt aber deine komplette Compliance-Basis: Aufbewahrung, Legal Hold, eDiscovery und DLP greifen für neue Nachrichten nur noch auf Gruppenebene, nicht mehr am Nutzerpostfach. Begleitet wird der Umzug von einer Kommunikation im Zickzack.

Die Message-Center-Nachricht MC1134737 wurde seit August 2025 elfmal aktualisiert, eine Löschdrohung für verwaiste Kanäle kam Ende April, wurde Anfang Juni verlängert und am 7. Juli 2026 zurückgezogen. Wer jetzt nicht prüft, arbeitet unter Umständen mit Richtlinien, die für private Kanäle ins Leere laufen.

Bisher speicherte Teams jede Nachricht eines privaten Kanals als Kopie im Exchange-Online-Postfach jedes einzelnen Kanalmitglieds. Für Compliance war das ein teures Modell, weil jede Aufbewahrungsrichtlinie und jeder Legal Hold am Nutzerpostfach ansetzen musste. Wollte deine Rechtsabteilung einen einzelnen privaten Kanal sichern, musstest du die Postfächer aller Mitglieder in den Hold nehmen und hast dabei zwangsläufig deren gesamte übrige Kommunikation mit eingesammelt.

Mit der Migration erhält jeder private Kanal ein eigenes Kanalpostfach, technisch angelehnt an das Modell der Shared Channels. Richtlinien docken dadurch an der Microsoft-365-Gruppe des Teams an, wodurch Purview private Kanäle genauso behandelt wie Standardkanäle. Der Preis: Eine Richtlinie auf der Teamgruppe wirkt auf alle Kanäle des Teams. Den kanalgenauen Zuschnitt, den das alte Modell über die Nutzerpostfächer indirekt erlaubte, gibt es nicht mehr.

Der Umbau räumt gleichzeitig die alten Grenzen ab. Nach abgeschlossener Migration gilt:

Die neuen Limits und die Terminplanung erhält ein Kanal erst, wenn seine Migration abgeschlossen ist. Hängt die Migration in deinem Tenant, fehlen also auch die Features. Genau daran haben viele Admins das Problem überhaupt erst bemerkt, etwa weil sich die Kalender-App einem privaten Kanal nicht hinzufügen ließ.

Ende April 2026 meldete Microsoft die Migration als weitgehend abgeschlossen, mit Ausnahme zweier Konfigurationen, die sich in ihrem Zustand nicht migrieren lassen:

Für beide Szenarien setzte Microsoft am 30. April eine Frist zum 5. Juni 2026: Owner nachpflegen, sonst werden die Kanäle soft-deleted, bleiben 30 Tage wiederherstellbar und verschwinden danach endgültig. Anfang Juni verlängerte Microsoft die Frist auf Ende Juli. Am 7. Juli folgte die Rolle rückwärts: Die verwaisten Kanäle werden jetzt unverändert mitmigriert und bleiben erhalten, gelöscht wird nichts. Die Migration dieser Kanäle in der Public Cloud soll bis zum 31. Juli 2026 abgeschlossen sein.

Kurios dabei: Der alte Absatz mit der Löschdrohung steht unverändert unter dem Update in derselben MC-Nachricht. Verbindlich ist die neueste Aussage, der Widerspruch zeigt aber, wie holprig die Kommunikation zu diesem Umbau läuft.

Aus der Pflicht wird damit eine dringende Empfehlung. Microsoft fordert weiterhin ausdrücklich dazu auf, verwaiste Kanäle zu bereinigen, und dafür gibt es handfeste Gründe: Ein Kanal ohne Roster ist totes Kapital, an dessen Inhalte niemand mehr herankommt. Ein Kanal, in dem nur noch externe Gäste sitzen, hat keinen internen Verantwortlichen für Mitgliedschaft, Inhalte und Lebenszyklus. Beides bleibt nach der Zwangsmigration bestehen und taucht bei jedem Audit als Governance-Lücke auf.

Das Teams Admin Center zeigt den Migrationsstand nicht an. Die einzige Sicht in den Prozess liefert das Cmdlet Get-TenantPrivateChannelMigrationStatus aus dem MicrosoftTeams-PowerShell-Modul. Fehlt das Cmdlet in deiner Session, ist dein Modul zu alt, dann zuerst aktualisieren. Für die Abfrage brauchst du Tenant-Admin-Rechte.

Das Feld MigrationStatus kennt vier Werte: NotStarted, InProgress, Completed und RequiresAdminAttention. Nur bei Completed sind alle privaten Kanäle umgezogen und bekommen die neuen Limits. RequiresAdminAttention bedeutet: Es existieren verwaiste Kanäle. Fehlgeschlagene Kanäle (failedChannels) wiederholt Microsoft automatisch, hier musst du nichts tun.

Die Details liefert das Cmdlet als einzelnen JSON-String, den du mit ConvertFrom-Json aufbereitest:

Die teamId aus der Ausgabe entspricht der GroupId der Microsoft-365-Gruppe des Teams, die channelThreadId identifiziert den Kanal. Ältere Kanäle tragen dabei IDs im Format @thread.skype, neuere @thread.tacv2.

Zur Bereinigung ergänzt du je Kanal mindestens einen internen Nutzer als Owner. Der Nutzer muss zuerst Mitglied des Teams sein, dann des Kanals, erst danach klappt die Owner-Zuweisung:

Das Message Center nennt als Bereinigungsweg Microsoft Graph. Wenn du ohnehin mit dem Graph-SDK arbeitest, setzt du den Owner direkt beim Hinzufügen. Benötigt wird die Berechtigung ChannelMember.ReadWrite.All:

Eine Stolperfalle sind archivierte Teams: Deren private Kanäle blockieren als remainingChannels, weil die Migration sie im archivierten Zustand nicht anfassen kann. Hier hilft nur, das Team vorübergehend zu entarchivieren, den Owner zu setzen und anschließend wieder zu archivieren:

Rechne damit, dass die Migration nach der Bereinigung nicht sofort weiterläuft. Einen Befehl zum Anstoßen gibt es nicht, der Prozess läuft serverseitig als Blackbox. Tony Redmond (Office 365 for IT Pros) dokumentierte für seinen Tenant eine wochenlange Hängepartie trotz bereinigter Kanäle. Plane die Kontrolle der Statusabfrage deshalb als wiederkehrende Aufgabe ein, bis dein Tenant Completed meldet.

Der Wechsel vom Nutzer- zum Gruppenpostfach entwertet jede Richtlinie, die private Kanäle bisher über Nutzerpostfächer erfasst hat. Alte Richtlinien wirken weiter auf die Altdaten in den Nutzerpostfächern, neue Nachrichten landen aber im Kanalpostfach und werden nur von Richtlinien auf der Teamgruppe erfasst. Ohne Anpassung entsteht ab dem Migrationszeitpunkt eine Lücke. Lizenzseitig ändert sich nichts: Aufbewahrung für Teams ist ab E3 enthalten, DLP auf Teams-Nachrichten braucht weiterhin E5 oder das E5-Compliance-Add-on.

Bei Legal Hold und eDiscovery kopiert Microsoft während der Migration nur die jeweils letzte Version einer Nachricht aus den Nutzerpostfächern ins Kanalpostfach. Bearbeitungen und gelöschte Nachrichten wandern nicht mit. Bei Nutzern im Hold bleiben diese Kopien im Preserved-Bereich des Nutzerpostfachs erhalten, bis der Hold ausläuft. Für dich heißt das: Bestehende Holds erweiterst du um das Gruppenpostfach, neue Holds setzt du direkt auf die Gruppe. Eine vollständige eDiscovery-Suche zu einem privaten Kanal umfasst beide Speicherorte, die Nutzerpostfächer für die Historie vor der Migration und das Gruppenpostfach für alles danach.

Für DLP muss die Richtlinie für Teams-Chat- und Kanalnachrichten die Teamgruppe des privaten Kanals als Bereich enthalten, weil der Nutzer-Scope neue Kanalnachrichten nicht mehr abdeckt. Prüfe bestehende Richtlinien, die auf einzelne Nutzer oder Verteiler zugeschnitten waren, und ergänze die betroffenen Gruppen.

Bei der Aufbewahrung fällt eine Option komplett weg: Neue Richtlinien speziell für private Kanäle lassen sich im Purview-Portal nicht mehr anlegen. Der Standort Teams-Kanalnachrichten auf der Teamgruppe deckt private Kanäle jetzt mit ab. Bestehende Privatkanal-Richtlinien bleiben wirksam und halten die Altdaten in den Nutzerpostfächern, du kannst sie aber nicht mehr bearbeiten, nur entfernen. Weicht die Aufbewahrung des Teams von der bisherigen Kanalrichtlinie ab, legst du eine gleichwertige neue Richtlinie an, weil sonst zwei unterschiedliche Fristen auf denselben Kanal wirken.

Nutzt du die optische Zeichenerkennung in Purview, stelle den Bereich auf alle Benutzer und Gruppen. Ein Zuschnitt auf einzelne Benutzer oder Gruppen deckt private Kanäle nach der Migration nicht ab.

Fachlich ist der Umbau richtig. Das Kanalpostfach beendet das Kopien-Modell in den Nutzerpostfächern, stellt private Kanäle auf dasselbe Compliance-Fundament wie Standard- und Shared Channels und räumt die alten Grenzen von 30 Kanälen und 250 Mitgliedern ab. Die Ausführung verdient weniger Lob. Eine Migration, die im Admin Center unsichtbar bleibt und ihren Zustand nur über ein PowerShell-Cmdlet preisgibt, verlagert die Kontrolle komplett zu Microsoft. Und die Fristenkommunikation (erst 5. Juni, dann Ende Juli, dann Rücknahme der Löschung) hat Admins ohne Not unter Druck gesetzt und verwirrt zurückgelassen, zumal die widersprüchlichen Absätze weiterhin gemeinsam in derselben MC-Nachricht stehen.

Für deinen Betrieb bleiben drei Aufgaben. Führe die Statusabfrage jetzt aus, auch ohne sichtbare Symptome, weil ein hängender Status RequiresAdminAttention sonst monatelang unbemerkt bleibt. Bereinige verwaiste Kanäle trotz zurückgezogener Löschdrohung, denn unzugängliche Inhalte ohne Verantwortlichen sind ein Audit-Finding, kein Feature. Und prüfe deine Purview-Richtlinien gegen das neue Speichermodell, weil Holds und Aufbewahrung, die nur am Nutzerpostfach hängen, neue Nachrichten privater Kanäle nicht mehr erfassen. Wenn du nach ISO 27001 oder NIS2 nachweisen musst, dass Aufbewahrung und Beweissicherung lückenlos funktionieren, gehört dieser Architekturwechsel in deine Dokumentation, inklusive Migrationsdatum deines Tenants und der angepassten Richtlinien. Der Verlust der kanalgenauen Richtliniensteuerung ist der einzige echte Rückschritt: Wer bisher einen einzelnen privaten Kanal strenger behandelt hat als den Rest des Teams, braucht dafür künftig ein eigenes Team.