Warum entsteht Chaos bei Microsoft 365 Groups und Teams – und wie Sie es mit Governance stoppen

Was bei einer Microsoft 365 Group sofort entsteht

Eine Microsoft 365 Group ist mehr als nur eine Mitgliederliste. Bei der Erstellung werden unmittelbar verbundene Dienste bereitgestellt, die gemeinsam Berechtigungen und Datenbereiche definieren. Das geschieht automatisch, unabhängig davon, ob die Gruppe in Outlook, im Microsoft 365 Admin Center oder als Nebenprodukt anderer Apps erzeugt wurde.

• Exchange Online: Ein Gruppenpostfach mit Konversationen und ein Gruppenkalender (beides in Outlook sichtbar).
• SharePoint Online: Eine gruppenverbundene Teamwebsite mit Dokumentbibliotheken, Listen und Berechtigungsmodell, das an die Group gekoppelt ist.
• OneNote: Ein Notizbuch in der zugehörigen SharePoint-Website, das der Gruppe gehört.

Nicht sofort angelegt werden Anwendungen, die eine bewusste Aktivierung brauchen, etwa ein Microsoft Teams-Team oder ein Planner-Plan. Diese entstehen erst, wenn sie genutzt oder explizit hinzugefügt werden.

Planner: wann ein Plan wirklich existiert

Planner ist für jede Microsoft 365 Group verfügbar, aber ein Plan wird erst angelegt, sobald Planner für diese Gruppe erstmals geöffnet oder ein Plan erstellt wird (zum Beispiel über einen Tab in Teams oder direkt unter tasks.office.com). Der Plan gehört dann der Group und übernimmt deren Mitglieder und Berechtigungen.

• Ein neuer Plan in einer bestehenden Group erbt Besitzer und Mitglieder der Group.
• Wird in Planner eine „neue Gruppe“ erstellt, entsteht dabei eine neue Microsoft 365 Group mitsamt Postfach und SharePoint-Website.
• To Do zeigt persönliche Aufgaben; gemeinsam genutzte Aufgabenlisten kommen aus Planner und hängen an der Group.

Teams-Zuordnung: wann aus der Gruppe ein Team wird

Ein Team in Microsoft Teams benötigt immer eine Microsoft 365 Group. Wird ein Team neu erstellt, erzeugt Teams im Hintergrund eine Group (falls noch keine vorhanden ist) und verknüpft sie. Existiert bereits eine Group, lässt sich daraus ein Team erstellen („Team aus einer bestehenden Gruppe“). Umgekehrt erzeugt das Anlegen einer Group in Outlook oder im Admin Center nicht automatisch ein Team.

• Eine Group kann genau ein Team haben.
• Die Zuordnung ist in der Group technisch erkennbar; in PowerShell (Exchange Online) erscheint dann in ResourceProvisioningOptions der Eintrag „Team“.
• Kanal-spezifische Artefakte entstehen erst bei Kanalerstellung (siehe unten).

SharePoint-Details: Standard-, private und geteilte Kanäle

Die SharePoint-Website der Group ist die zentrale Dateiablage. Bei Teams gilt:

• Standardkanäle erzeugen Ordner in der vorhandenen Dokumentbibliothek der gruppenverbundenen Website.
• Private Kanäle erzeugen eine eigene, getrennte SharePoint-Website mit eigenem Berechtigungsmodell, die nur den Mitgliedern des privaten Kanals gehört.
• Geteilte Kanäle (Shared Channels) erzeugen ebenfalls eine separate SharePoint-Website, die organisationsübergreifend freigegeben werden kann, ohne die gesamte Team-Website zu teilen.

Diese zusätzlichen Websites entstehen erst beim Anlegen des jeweiligen Kanals, nicht beim Erstellen von Group oder Team.

So prüfen Sie für eine konkrete Gruppe die angelegten Ressourcen

Über das Microsoft 365 Admin Center: Verwaltung > Teams & Gruppen > Aktive Teams & Gruppen > „Microsoft 365“-Register. Gruppe auswählen und die Detailseite öffnen. Dort finden sich E-Mail-Adresse, Link zur SharePoint-Website und (sofern vorhanden) der Hinweis, ob ein Team zugeordnet ist.

Per Exchange Online PowerShell lässt sich die Zuordnung ebenfalls verifizieren: Mit dem Cmdlet Get-UnifiedGroup die Eigenschaften PrimarySmtpAddress, SharePointSiteUrl und ResourceProvisioningOptions prüfen. Steht „Team“ in ResourceProvisioningOptions, existiert ein zugeordnetes Team. Planner-Pläne sind in Planner sichtbar und erscheinen in Teams als „Planner“- bzw. „Planner und To Do“-Tabs.

Doppelte Team-Namen und überlappende Arbeitsräume

Microsoft 365 Groups erlauben identische Anzeigenamen. Da jedes Team eine solche Gruppe nutzt, können zwei unterschiedliche Teams gleich heißen. Das führt zu Verwechslungen bei Kanalwahl, Dateiablage und Gast­einladungen. Häufig stecken dahinter parallele Initiativen, Migrationen oder das Erstellen neuer Teams statt Wiederverwendung bestehender Räume.

So spüren Sie Dubletten auf und quantifizieren das Problem:

• Microsoft 365 Admin Center > Teams & Gruppen > Aktive Teams & Gruppen: Nach Typ „Microsoft 365“ filtern, nach „Name“ sortieren und identische Anzeigenamen notieren. Optional Liste exportieren und nach doppelten Namen gruppieren.
• Teams Admin Center > Teams > Teams verwalten: Nach „Teamname“ sortieren; bei Verdacht Details prüfen (Besitzer, Mitglieder, verbundene SharePoint-Site, letzte Aktivität).
• Postfach-Aliasse prüfen: In der Gruppenliste ist „E-Mail-Alias“ eindeutig – unterschiedliche Aliasse bei gleichem Anzeigenamen deuten auf echte Dubletten hin.

Typische Indikatoren sind identische Namen mit abweichenden Besitzern, redundante Channels („Allgemein 2“), parallele Dateienstrukturen oder mehrfach angelegte Planner-Pläne.

Verwaiste SharePoint-Sites und Kanalsites

„Verwaist“ bedeutet in der Praxis: Die zugehörige Gruppe oder das Team hat keine aktiven Besitzer mehr oder niemand fühlt sich verantwortlich. Besonders betroffen sind eigenständige SharePoint-Sites ohne Gruppenbindung, sowie Kanal-Sites (Private/Shared Channels), deren ursprüngliche Besitzer das Unternehmen verlassen haben.

So identifizieren Sie Kandidaten systematisch:

• SharePoint Admin Center > Websites > Aktive Websites: Spalten „Primäre Administratoren“ und „Letzte Aktivität“ einblenden. Nach „Letzte Aktivität“ absteigend sortieren und Sites mit sehr alter Aktivität prüfen.
• Für gruppenverbundene Sites: In der Detailansicht der Site die verknüpfte Microsoft 365-Gruppe öffnen und prüfen, ob mindestens zwei Besitzer vorhanden sind.
• Kanalsites: In der Detailansicht erkennen Sie den Bezug zu einem Team und Kanal. Fehlt ein aktiver Teambesitzer, ist die Site de facto ohne verantwortliche Instanz.
• Microsoft 365 Admin Center > Teams & Gruppen: Nach Gruppen mit „0 Besitzer“ filtern/sortieren. Diese Einträge gegen die Liste der aktiven Sites abgleichen.

Hinweis: Gelöschte Gruppen/Sites werden in Microsoft 365 in der Regel zunächst befristet aufbewahrt (Papierkorb/Soft-Delete). Das schützt vor Datenverlust, löst aber das Verwaisungsproblem nicht.

Unklare oder fehlende Besitzerrollen

Ohne klar benannte Besitzer wird nicht entschieden, wer Mitglieder einlädt, Kanäle strukturiert oder externe Freigaben verantwortet. Häufige Symptome: Teams mit zu vielen Besitzern (jeder darf alles), Teams ohne Besitzer (niemand fühlt sich zuständig), oder Besitzer mit inaktiven Konten.

Prüfpfade, die sich bewährt haben:

• Microsoft 365 Admin Center > Teams & Gruppen > Aktive Teams & Gruppen: Spalte „Besitzer“ einblenden und auf „0“ oder ungewöhnlich hohe Anzahl prüfen.
• Microsoft Entra Admin Center > Gruppen > Alle Gruppen: Nach „Microsoft 365“ filtern, Spalten „Besitzer“ und „Mitglieder“ anzeigen, sortieren und Ausreißer identifizieren.
• Mitglieder-zu-Besitzer-Verhältnis prüfen: Sehr große Teams mit nur einem Besitzer sind riskant; zwei bis drei aktive Besitzer sind in den meisten Szenarien die minimale Zielgröße.

Pragmatische Quick-Checks für den Alltag

• Wöchentlich: In „Aktive Teams & Gruppen“ nach „0 Besitzer“ sortieren und sofort beheben.
• Monatlich: Export der Gruppenliste und Doppelnamen identifizieren; mit Team-Besitzern klären und konsolidieren.
• SharePoint: „Aktive Websites“ nach „Letzte Aktivität“ > 180 Tage filtern und Verantwortliche bestätigen oder Archivierung anstoßen.
• Kanalsites: Teams mit vielen Private/Shared Channels prüfen – sind alle noch benötigt, und gibt es aktive Besitzer?
• Namen prüfen: Auffällige Suffixe/Präfixe („-neu“, „-alt“, „-final“) deuten auf fehlende Namenskonventionen und oft auf Dubletten.

Diese Symptome weisen nicht nur auf fehlende Governance hin, sie verursachen auch Suchaufwand, inkonsistente Freigaben und unnötige Lizenz- sowie Speicherlast. Je schneller sie sichtbar gemacht und bereinigt werden, desto stabiler bleibt die Arbeitsumgebung.

Naming Policies in Microsoft Entra ID: konsistente Namen und gesperrte Begriffe

Uneinheitliche Gruppen- und Teamnamen erzeugen Dubletten und Suchchaos. Eine Naming Policy in Microsoft Entra ID (ehemals Azure AD, erfordert Entra ID P1) erzwingt Präfixe/Suffixe und sperrt unerwünschte Begriffe. Sie greift bei der Erstellung von Microsoft 365-Gruppen – damit auch bei Teams, Planner-Plänen und Outlook-Gruppen.

So richten Sie die Richtlinie ein:

• Im Microsoft Entra Admin Center: Gruppen > Namensrichtlinie > Gruppen-Namensrichtlinie öffnen.
• Präfix/Suffix definieren – statisch (z. B. “DE-”) oder mit Attributen wie [Department] oder [Company].
• Liste gesperrter Wörter pflegen (Marken, Projektcodes, sensible Begriffe).
• Speichern und testen: Erstellen Sie ein Test-Team; der Name und die E-Mail-Alias werden automatisch gemäß Richtlinie gesetzt.

Praxis-Tipp: Präfix nach Standort oder Geschäftsbereich plus kurzer, sprechender Name, z. B. “DE-[Department]-Vertrieb-Innendienst”. Das erleichtert Suche, Lifecycle und Reporting.

Ablaufregeln (Group Expiration): automatische Bereinigung statt Karteileichen

Viele Gruppen werden nach Projektende nicht mehr genutzt. Ablaufregeln in Entra ID (P1) löschen inaktive Microsoft 365-Gruppen kontrolliert oder lassen sie vom Besitzer verlängern. Aktive Gruppen erneuern sich automatisch, wenn Nutzung in Teams, Outlook, SharePoint oder Planner erkannt wird.

• Entra Admin Center: Gruppen > Ablauf öffnen.
• Geltungsbereich wählen: Alle oder ausgewählte Microsoft 365-Gruppen.
• Intervall festlegen (z. B. 180 oder 365 Tage) und eine Kontaktadresse für besitzerlose Gruppen hinterlegen.
• Benachrichtigungen an Besitzer aktivieren; Auto-Erneuerung bei Aktivität beibehalten.
• Policy speichern und in einem Pilotbereich verifizieren.

Empfehlung: Kürzere Intervalle für Projekt-Teams (z. B. 180 Tage), längere für Linienbereiche (z. B. 365 Tage). Dokumentieren Sie Ausnahmen klar, damit kritische Bereiche nicht unbeabsichtigt auslaufen.

Sensitivity Labels für Gruppen, Teams und SharePoint-Sites

Mit Sensitivity Labels aus dem Microsoft Purview-Portal steuern Sie neben Dateischutz auch Einstellungen für Gruppen und Sites: Privat/Public, Gastzugriff, externe Freigabe und Zugriff von nicht verwalteten Geräten. Labels sind konsistent, auditierbar und für Benutzer einfach auswählbar.

• Microsoft Purview Compliance-Portal: Informationsschutz > Bezeichnungen > Neue Bezeichnung.
• “Gruppen & Sites” aktivieren. Festlegen: Privat/Public, Gastzugriff erlaubt/verboten, externe Sitefreigabe (SharePoint/OneDrive) und Zugriff von nicht verwalteten Geräten (z. B. eingeschränkter Webzugriff).
• Bezeichnung veröffentlichen: Richtlinie für die Zielbenutzer erstellen (Ersteller von Teams/Sites).
• Optional: Bezeichnungspflicht und Standardbezeichnung für Gruppen/Sites aktivieren, damit bei der Erstellung zwingend eine Bezeichnung gewählt wird.

Beispiel: “Intern – Gäste verboten – Externe Freigabe aus – Privat” vs. “Extern – Gäste erlaubt – Externe Freigabe eingeschränkt – Privat”. So schließen Sie Datenabfluss und Fehlkonfigurationen von Beginn an aus.

Regelmäßige Reviews: Mitgliedschaften, Gäste und Besitzerrollen prüfen

Ohne Reviews bleiben Gäste unnötig lange, Besitzer gehen in Rente, Teams werden “ownerless”. Mit Microsoft Entra ID Access Reviews (P2) automatisieren Sie Prüfungen und räumen auf.

• Entra Admin Center: Identitätsgovernance > Zugriffsüberprüfungen > Neue Überprüfung.
• Ressourcentyp “Teams und Microsoft 365-Gruppen”, Umfang “Nur Gäste” oder “Alle Mitglieder”.
• Reviewer: Gruppenbesitzer. Häufigkeit: z. B. vierteljährlich. Ergebnis automatisch anwenden, Nicht-Reaktionen entfernen.
• Zusätzlich “Ownerless groups”-Richtlinie aktivieren: Mitglieder können auf Einladung Eigentümer werden; so vermeiden Sie verwaiste Teams.
• Im Teams Admin Center regelmäßig exportieren: Teams-Liste mit Anzahl Besitzer prüfen und fehlende zweite Besitzer ergänzen.

Faustregel: Mindestens zwei Besitzer je Team/Gruppe. Gäste nur so lange wie nötig und nur in Labels mit erlaubtem Gastzugriff.