Copilot Pages und Microsoft Loop verändern die Zusammenarbeit in Teams spürbar. Gleichzeitig stellen sie an Governance und Kontrolle Anforderungen, die es so bisher nicht gab. In vielen Tenants, die ich begleite, kommt deshalb früh die Frage auf, wo diese neuen Inhalte eigentlich liegen und wie sich Zugriffe steuern und Compliance-Vorgaben einhalten lassen. Einfacher als bei klassischen Teams oder OneDrive ist das nicht: Pages und Loop-Workspaces werden in sogenannten SharePoint-Embedded-Containern gespeichert, und die verhalten sich deutlich anders als normale SharePoint-Sites.

Loop und Copilot Pages speichern ihre Inhalte in Embedded-Containern

Für Loop und Copilot Pages gibt es keine klassische SharePoint-Teamsite. Stattdessen erhalten die Nutzer eigene Embedded-Container, und jeder Container gehört dem Benutzer, der den Workspace oder die Page angelegt hat. Das hat Folgen für die Zugriffsverwaltung und für die Frage, wer wofür verantwortlich ist. Im SharePoint-Admincenter erscheinen die Container nämlich nicht einfach als Sites, und mit Site Policies oder Gruppensteuerung kommt man hier auch nicht weiter. Viele Admins sind zunächst irritiert, weil sie die Inhalte nicht dort finden, wo sie sie vermuten, und fragen sich, was sie überhaupt noch steuern können.

Die folgende Mermaid-Grafik stellt die Architektur rund um Loop, Copilot Pages und Embedded-Container vereinfacht dar:

flowchart TD
  user["Benutzer"] --> container["Embedded-Container"]
  container --> loopworkspace["Loop Workspace"]
  container --> copilotpage["Copilot Page"]
  admin["Admincenter / PowerShell"] --> container

Abbildung: Architektur – Nutzer erzeugen die Container für Loop und Copilot Pages, Admins verwalten sie nur indirekt.

Cloud Policies regeln die Erstellung und Freigabe neuer Inhalte

Die wichtigsten Stellschrauben für die Governance von Copilot Pages stecken derzeit in den Cloud-Policy-Einstellungen, konkret in den Richtlinien für Loop-Workspaces und Copilot Pages. Wie in der Konfiguration der Loop-Workspaces beschrieben, lässt sich beispielsweise per Richtlinie steuern, ob neue Workspaces oder Pages angelegt werden dürfen. Das geht auch granular, etwa für bestimmte Benutzergruppen oder Standorte. Neu daran ist, dass diese Einstellungen nicht auf klassische Site-Collections wirken, sondern auf die Embedded-Container. So kann man unter anderem festlegen, ob Nutzer überhaupt neue Workspaces oder Copilot Pages erstellen dürfen oder ob das nur bestimmten Gruppen vorbehalten ist. Im Oktober 2024 umfassen die Cloud Policies folgende Optionen:

  • Erstellung von Loop-Workspaces und Copilot Pages erlauben oder verbieten
  • Besitz und Nutzung auf bestimmte Nutzer-Scopes beschränken
  • Standardfreigabe für neue Workspaces und Pages festlegen
  • Loop-Komponenten in anderen M365-Apps optional kontrollieren

Ausführlicher beschreibt das die offizielle Dokumentation von Microsoft.

Sensitivity Labels und Retention greifen, eDiscovery hinkt noch hinterher

Viele Organisationen möchten wissen, wie es bei Loop und Copilot Pages um Compliance und den Schutz sensibler Daten bestellt ist. Hier die wichtigsten Punkte:

  • Sensitivity Labels: Im Oktober 2024 lassen sich Sensitivity Labels auf die Embedded-Container und deren Inhalte anwenden. Technisch läuft das wie bei anderen SharePoint-Inhalten, unter Umständen muss die Funktion aber erst ausdrücklich aktiviert werden. Die Labels beeinflussen anschließend auch das Freigabeverhalten.
  • Retention: Grundsätzlich werden M365-Retention-Policies unterstützt. Wie sie sich auf einzelne Container auswirken, sollte man trotzdem im Compliance-Portal kontrollieren.
  • eDiscovery: eDiscovery (Standard und Advanced) kann Inhalte aus Loop und Copilot Pages bislang nur eingeschränkt erfassen. Im Oktober 2024 wird die Unterstützung zwar ausgerollt, für den produktiven Einsatz reicht sie aber noch nicht vollständig. Einzelheiten nennt die Compliance-Übersicht.

Praxistipp: Sensitivity Labels für Loop und Copilot Pages sollte man vorher testen. In manchen Tenants zeigt sich ihre Wirkung erst, nachdem sie auf neue Container angewendet wurden. Längst nicht jede Compliance-Funktion ist sofort nach der Aktivierung sichtbar, und manche greifen bei bereits vorhandenen Inhalten gar nicht.

Admincenter und PowerShell bieten nur einen Teil der gewohnten Werkzeuge

An die Verwaltung von Embedded-Containern müssen sich Admins erst gewöhnen. Inzwischen enthält das SharePoint-Admincenter eine Ansicht für „Container Sites“, die früher teilweise hinter Feature-Flags verborgen war. Dort ist zu sehen, welchem Benutzer ein Container gehört. Außerdem lassen sich Zugriffsrechte prüfen und einzelne Container bei Bedarf entfernen, etwa wenn jemand das Unternehmen verlässt. PowerShell wird ebenfalls unterstützt, allerdings noch nicht im selben Umfang wie bei klassischen Sites. Für einfache Aufgaben genügt das Modul SharePoint Online Management Shell ab Version 16.x. Wer zum Beispiel alle Embedded-Container eines Benutzers auflisten möchte, führt in einem PowerShell-7-Terminal folgenden Befehl aus (Voraussetzung ist die Rolle SharePoint-Administrator):

Get-SPOSite -Template "SPEMBEDDED#0" -Owner [email protected]

Änderungen wie das Löschen von Containern oder das Anpassen von Zugriffen nehme ich trotzdem lieber im Admincenter vor. Beim Löschen sind nämlich schnell auch persönliche Inhalte betroffen.

Nach einem Austritt bleiben die Container ohne neuen Besitzer zurück

Heikel wird es, wenn Mitarbeitende das Unternehmen verlassen. Anders als bei OneDrive geht der Besitz der Embedded-Container dann nicht automatisch auf jemand anderen über. Die Container bleiben vorerst bestehen, Admins können sie aber übernehmen oder löschen. Ich empfehle, sie regelmäßig im Admincenter zu überprüfen und diese Kontrolle mit den Offboarding-Prozessen der Personalabteilung abzustimmen. Mit bestimmten Richtlinien lassen sich Container nach einem Austritt auch automatisch entfernen oder in ihrer Freigabe einschränken. Das sollte man allerdings vorher ausprobieren.

Mehr aus der Praxis zur Verwaltung von Embedded-Inhalten und zur Aufbewahrung habe ich im Artikel Restricted SharePoint Search: Copilot-Piloten richtig aufsetzen zusammengetragen.

Die Governance muss mit den neuen Werkzeugen mitwachsen

Von allein regelt sich die Governance für Copilot Pages nicht. Wer die neuen Collaboration-Tools sinnvoll und sicher einsetzen möchte, muss Embedded-Container und Cloud Policies bewusst in die eigenen Prozesse aufnehmen und die Compliance-Funktionen gezielt testen. Wie sich der Funktionsumfang in den nächsten Monaten entwickelt, wird sich zeigen. Wer die Besonderheiten kennt und berücksichtigt, kann die Governance für Loop und Copilot Pages aber schon jetzt mit Bordmitteln solide umsetzen.