Die Anforderung „Daten jedes Mitarbeiters in seinem Land speichern“ klingt zunächst nach einer zusätzlichen Lizenz. Tatsächlich betrifft sie Identitäten, Heimatregionen von Benutzern, gemeinsame Sites, Betriebsprozesse und die rechtliche Auslegung. Microsoft 365 Multi-Geo erweitert einen Tenant auf mehrere Geografien, macht daraus aber keine voneinander isolierten nationalen Instanzen. Die Unterscheidung zwischen physischem Datenstandort und logischer Trennung ist der Ausgangspunkt für eine belastbare Entscheidung.
Laut aktueller Microsoft-Dokumentation bleibt der Tenant zentral verwaltet; Informationen über Benutzer, Gruppen und geografische Standorte werden in Microsoft Entra ID geführt. Dadurch bleibt die Zusammenarbeit über Regionen hinweg erhalten. Multi-Geo ersetzt jedoch weder separate Tenants noch getrennte Verzeichnisse oder Sicherheitsgrenzen. Die Planung beginnt deshalb mit einer Datenkarte und einer präzisen Residenzanforderung, nicht mit der Preisliste.
Was sich in einem Multi-Geo-Tenant wirklich ändert
Ein Tenant besitzt eine Primary Provisioned Geography und eine oder mehrere Satellite Geographies. Benutzer erhalten eine Preferred Data Location (PDL), an der sich unterstützte Dienste orientieren. Exchange Online verwendet sie für das Postfach, OneDrive für die persönliche Site; SharePoint-Sites und Microsoft-365-Gruppen folgen workload-spezifischen Regeln. Eine Änderung der PDL ist daher keine kosmetische Profiländerung, sondern steuert asynchrone Verlagerungen bestimmter Datensätze.
Das zentrale Verzeichnis, Tenant-Konfigurationen und viele Servicemetadaten bleiben global. Personen werden weiterhin in einem Verzeichnis gefunden, teilen Dokumente und arbeiten in Teams zusammen. Lautet eine Vorgabe „keine Metadaten dürfen das Land verlassen“ oder „Administratoren eines Landes dürfen das andere nicht sehen“, muss geprüft werden, ob Multi-Geo diese Formulierung erfüllt. Häufig ist dies eine rechtliche und architektonische Bewertung, keine reine Administrationsaufgabe.
| Bereich | Was lokalisiert werden kann | Was gemeinsam bleibt | Kontrollfrage |
|---|---|---|---|
| Exchange Online | Primäres Postfach und Archiv eines berechtigten Benutzers | Globales Verzeichnis und Mailflow | Gilt die Vorgabe nur für Inhalte oder auch Transportmetadaten? |
| OneDrive | Persönliches OneDrive gemäß Benutzer-PDL | Identität und Freigabe im Tenant | Wer verantwortet Daten nach Rollen- oder Länderwechsel? |
| SharePoint | Sites können in einer Satellitenregion erstellt oder verschoben werden | Tenant-Verwaltung und regionsübergreifende Zusammenarbeit | Gehört die Site einer Region oder einer globalen Funktion? |
| Teams und Gruppen | Unterstützte Daten folgen den Workload-Regeln | Mitgliedschaft und Zusammenarbeit über Regionen | Wo liegen Daten einer multinationalen Gruppe? |
| Copilot | Unterstützte Arbeitsdaten folgen den zugrunde liegenden Diensten | Orchestrierung und Servicedaten haben eigene Zusagen | Ist der Datenumfang dokumentiert oder nur der Produktname? |
Lizenzierung: fünf Prozent sind die Untergrenze
Multi-Geo ist ein benutzerbezogenes Add-on für qualifizierende Enterprise-Pläne. Microsoft nennt unter anderem Microsoft 365 F1, F3, E3, E5 und E7, Office 365 F3, E1, E3 und E5, eigenständige Exchange-Online-, OneDrive- und SharePoint-Pläne sowie ausgewählte Teams-Lizenzen. Small-Business- und Education-Abonnements qualifizieren sich derzeit nicht. Entscheidend ist das konkrete SKU, nicht der bekannte Paketname.
Für Enterprise Agreement und CSP beträgt die Mindestmenge mindestens 5 % aller berechtigten Benutzer. Zusätzlich benötigt jeder in einer Satellite Geography gehostete Benutzer das Add-on. Eine Organisation mit 2.000 berechtigten Benutzern und 60 Satellitenbenutzern braucht somit mindestens 100 Lizenzen. Bei 320 Satellitenbenutzern sind es 320. Diese Untergrenze kann die Wirtschaftlichkeit kleiner regionaler Gruppen bestimmen.
Gemeinsame Ressourcen erhalten keine eigene Multi-Geo-Lizenz. Nach Erreichen der erforderlichen Benutzermenge können SharePoint-Sites, Microsoft-365-Gruppen, freigegebene Postfächer und Teams ohne objektbezogenes Add-on genutzt werden. Das bedeutet nicht, dass beliebige Daten ohne Einschränkung verschoben werden können. Unterstützte Workloads, verfügbare Geografien und die jeweiligen Serviceverfahren bleiben verbindlich.
PDL folgt einer Datenregel, nicht nur der Büroadresse
Die einfache Formel „Land des Mitarbeiters gleich PDL“ scheitert bei globalen Rollen, externen Kräften, Übernahmen und Shared Services. PDL beschreibt den vorgesehenen Standort unterstützter Benutzerdaten. Ein HR-Länderattribut kann ein Eingangswert sein, sollte aber nicht die gesamte Regel darstellen. Versetzung, langfristige Entsendung und Wechsel des rechtlichen Arbeitgebers können unterschiedlich behandelt werden.
Vor einer Automatisierung braucht es eine Entscheidungsmatrix mit Rechtsgrundlage, Benutzerpopulation, Verantwortlichem, Zielgeografie, Ausnahmen und Änderungsprozess. Gemeinsame Sites und Gruppen werden separat betrachtet. Ihr Standort sollte nicht zufällig vom ersten Besitzer abhängen, sondern von Datenverantwortung und Geschäftszweck. Der Site Owner muss außerdem Auswirkungen auf Integrationen, Suche und Support kennen.
- Jede PDL-Regel mit einer rechtlichen oder vertraglichen Anforderung verknüpfen
- Benutzerdaten von gemeinsamen Ressourcen trennen
- Joiner-, Mover- und Leaver-Prozesse definieren
- Ausnahmen und Ablaufdatum dokumentieren
- PDL-Änderungen nur mit verantwortlichem Data Owner automatisieren
Der Hinweis zur EU Data Boundary
Eine wenig intuitive Anmerkung in der Multi-Geo-Dokumentation besagt, dass Kunden, die Multi-Geo erworben oder genutzt haben, nicht in den Anwendungsbereich der EU Data Boundary fallen, selbst wenn das Tenant-Land in EU oder EFTA liegt. Das macht die Architektur nicht automatisch unzulässig. Es bedeutet, dass die allgemeine EU-Data-Boundary-Zusage und ein konkretes Multi-Geo-Design nicht gleichgesetzt werden dürfen.
Vor der Bestellung muss das tatsächliche Residenzziel mit den Servicezusagen verglichen werden. Manche Organisationen müssen nur bestimmte Kundendaten lokalisieren, andere einen einzelnen Workload in einem Land. Multi-Geo allein wegen des Begriffs „europäisch“ zu kaufen, kann die Dokumentation erschweren, ohne die ursprüngliche Verpflichtung zu erfüllen. Legal, DPO, Service Owner und Lizenzspezialisten brauchen dieselbe Scope-Beschreibung.
Einführung ohne operative Überraschungen
Nach der Bestellung konfiguriert Microsoft den Tenant zunächst für Multi-Geo. Die Dokumentation nennt für die meisten Tenants einen Zeitraum von bis zu einem Monat; größere oder komplexere Umgebungen können länger benötigen. Ein Plan mit PDL-Änderungen am Tag nach dem Kauf ist unrealistisch. Erst workload-spezifische Meldungen im Message Center bestätigen die Bereitschaft.
- 01
Residenzanforderung präzise formulieren
Daten, Benutzer, Dienst sowie rechtlichen oder vertraglichen Grund festhalten. Nicht mit einer Lizenzliste beginnen.
- 02
Berechtigte und Satellitenbenutzer zählen
Zielpopulation mit der 5-Prozent-Untergrenze vergleichen und Basis-SKUs prüfen. Wachstum, Versetzungen und Übernahmen einbeziehen.
- 03
PDL und Eigentum gemeinsamer Daten entwerfen
Regeln für Benutzer, SharePoint-Sites, Gruppen, Teams und freigegebene Postfächer mit Owner und Ausnahmeprozess definieren.
- 04
Workload-Bereitschaft bestätigen
Message-Center-Bestätigung abwarten. Für jeden Workload Geografie, Verfahren, Abhängigkeiten und Monitoring prüfen.
- 05
Repräsentative Personas pilotieren
Standardbenutzer, Führungskraft, Delegation, globales Teammitglied und SharePoint Owner einbeziehen. Nutzerergebnis und Administration testen.
- 06
Kontinuierliche Kontrolle betreiben
PDL regelmäßig mit HR-Realität, Migrationsstatus, Lizenzen und Datenkarte abgleichen. Benutzerwechsel dürfen keine stille Lücke erzeugen.
Der Pilot testet Zusammenarbeit, nicht nur einen Befehl
Der Nachweis, dass PDL geschrieben werden kann, ist nur der erste technische Check. Der Pilot umfasst Mailzustellung, Kalender, Delegation, OneDrive-Freigaben, Teams- und Site-Zugriff, Suche, eDiscovery, Retention und Support. Auch Dauer und Status der Verlagerung werden gemessen. Die Migration ist asynchron; Workloads können sich unterschiedlich schnell ändern.
Anwendungen und Automatisierungen mit festen URLs, regionalen Endpunkten, Servicekonten oder SharePoint-Standorten benötigen eigene Tests. Multi-Geo erhält die Standardzusammenarbeit, zertifiziert aber keine Eigenentwicklungen. Das Integrationsinventar braucht Owner, Testfall und Rollback. Andernfalls validiert der Pilot nur Standardclients und lässt das größte Betriebsrisiko unangetastet.
Wann Multi-Geo nicht die richtige Lösung ist
Multi-Geo passt nicht, wenn der bestehende Tenant-Standort die Anforderung bereits erfüllt, echte Trennung von Identitäten und Administration nötig ist oder der Ziel-Workload nicht unterstützt wird. Riskant ist es auch ohne Team, das PDL und gemeinsame Ressourcen dauerhaft pflegt. Ein Add-on ohne Betriebsmodell erzeugt lediglich einen teureren und schwerer erklärbaren Tenant.
Ein starker Anwendungsfall ist dagegen eine globale Organisation, die ein Verzeichnis und nahtlose Zusammenarbeit behalten, aber definierte Benutzerpopulationen in Satellitengeografien hosten möchte. Entscheidend sind Services, Benutzer, Länder und Ausnahmen. Axeti verbindet diese Architektur mit Lizenzinventar und Renewal, damit technisches Design und Bestellung nicht getrennt entstehen.
Checkliste für die Entscheidung
| Frage | Nachweis | Owner | Stop-Bedingung |
|---|---|---|---|
| Welche Anforderung wird gelöst? | Fundstelle in Regulierung, Vertrag oder Richtlinie | Legal / DPO | Nur allgemeiner Wunsch nach lokalen Daten |
| Welche Daten und Dienste sind im Scope? | Workload- und Datenkategorienkarte | Enterprise Architect | Nicht unterstützte Dienste sind Bestandteil |
| Wie viele Lizenzen werden benötigt? | Berechtigte Benutzer, 5 % und Satellitenpopulation | Einkauf / Licensing | Konkretes Basis-SKU ungeprüft |
| Wie wird PDL gesteuert? | Regeln, Quellattribute, Freigabe und Ausnahmen | IAM / M365-Team | Kein Owner für Mitarbeiterwechsel |
| Wie wird der Betrieb abgenommen? | Pilotszenarien und messbare Kriterien | Service Owner | Test schreibt nur ein Attribut |
Häufig gestellte Fragen
Ist Microsoft 365 Multi-Geo dasselbe wie ein eigener Tenant pro Land?
Nein. Multi-Geo behält einen Tenant, zentrale Identitäten und Zusammenarbeit. Unterstützte Daten liegen in Primary und Satellite Geographies, ohne getrennte Verzeichnisse oder vollständige Administrationsgrenzen zu erzeugen.
Benötigt jeder Benutzer eine Multi-Geo-Lizenz?
Jeder Benutzer in einer Satellite Geography benötigt eine. Zusätzlich verlangt Microsoft bei EA und CSP mindestens 5 % aller berechtigten Benutzer, sodass die Untergrenze größer als eine kleine Satellitenpopulation sein kann.
Braucht jede SharePoint-Site oder jedes Shared Mailbox eine Lizenz?
Microsoft definiert keine objektbezogenen Multi-Geo-Lizenzen für gemeinsame Ressourcen. Nach Erfüllung der erforderlichen Benutzermenge gelten die Regeln des jeweiligen unterstützten Dienstes.
Verschiebt eine PDL-Änderung Daten sofort?
Nein. Workload-Verlagerungen sind asynchron und besitzen serviceabhängige Laufzeiten und Status. Bereitschaft bestätigen, pilotieren und jeden Umzug überwachen.
Garantiert Multi-Geo die rechtliche Datenresidenz?
Es ermöglicht die technische Platzierung unterstützter Daten in angebotenen Geografien. Ob der Umfang eine konkrete regulatorische oder vertragliche Pflicht erfüllt, muss die Organisation selbst bewerten.
Was ist der erste praktische Schritt?
Die Residenzanforderung nach Workload und Benutzerpopulation formulieren. Danach qualifizierende Pläne, 5-Prozent-Minimum, verfügbare Geografien und PDL-Betrieb prüfen.
