Es führen viele Wege zu einer Hybridorganisation, die mehrere Microsoft-365-Mandanten beinhaltet. In größeren Unternehmen starten regionale Niederlassungen unabhängig voneinander M365-Initiativen. Diese gehen oft vom Proof of Concept in den produktiven Betrieb über und werden so inklusive der jeweils gebuchten Mandanten (Tenants) Bestandteil der hybriden IT. In manchen Fällen schreiben gesetzliche Regelungen in einer oder mehreren Zweigstellen den Ort der Datenhaltung vor, was im Fall der M365-Dienste ebenfalls zu mehreren Mandanten führt.

Ein noch häufigeres Szenario, das in mehreren bis vielen Mandanten mündet, stellen Übernahmen (Mergers and Acquisitions, M&A) dar. Entweder hatte die übernommene Firma bereits vor dem Merger Dienste aus der M365-Cloud im Einsatz oder es handelt sich um die Übernahme eines ausgegliederten Geschäftsbereichs, wobei M365 als Vehikel benutzt wird, um die Daten des scheidenden Unternehmensteils aus der Infrastruktur des Mutterunternehmens herauszutrennen. Schließlich sollte jeder Besitzer eines M365-Tenants ab einer gewissen Größe sehr intensiv darüber nachdenken, einen zweiten, kleineren Mandanten für Test und Entwicklung zu buchen, um die Produktion beim Austesten neuer Applikationen und Managementverfahren nicht zu gefährden.

In allen Fällen sieht sich die IT am Ende mit mehreren M365-Mandanten konfrontiert, die nach gemeinsamen Richtlinien und Vorgaben durch ein gemeinsames Team verwaltet werden müssen. Bereits im Dezember 2020 hat Microsoft festgestellt [1], dass über ein Drittel der M365-Tenants von Administratoren verwaltet werden, die mehr als einen Mandanten managen. Dies traf damals auf 66 Prozent der Enterprise-Kunden von M365 zu. Im vergangenen Jahr dürfte sich der Anteil am Multimandanten-Management noch einmal erhöht haben.

Im zuvor verlinkten Microsoft-Video werden bereits einige wichtige Funktionen genannt, die von M365-Kunden und -Partnern gewünscht oder sogar als formelle "Feature Requests" gefordert wurden.

Im Wesentlichen laufen die häufigsten Anforderungen der Kunden auf folgende Funktionalität hinaus:

- Schnell zwischen Tenants hin- und herschalten; dabei muss die Sicherheitsrichtlinie des jeweiligen Tenants berücksichtigt werden.

- Einen schnellen Überblick über den Gesundheitszustand der vorhandenen Tenants gewinnen und grundlegende Maßnahmen zur Entstörung ergreifen.

- Einen schnellen Überblick über die geltenden Policies in sämtlichen Tenants und über etwaige Abweichungen von diesen Policies erhalten.

- Policies und andere Artefakte einheitlich auf mehrere Tenants ausrollen können.

Nicht von Microsoft genannt, aber trotzdem nicht weniger wichtig sind die folgenden Anforderungen:

- Einen schnellen Überblick über vorhandene (gebuchte) Lizenzen und deren Ausnutzung in sämtlichen Tenants gewinnen. Dies ist besonders wichtig, wenn das Unternehmen innerhalb kurzer Zeit viele Tenants hinzugekauft hat. Gebuchte und bezahlte, aber nicht genutzte Lizenzen für Clouddienste sind ein wesentlicher Kostentreiber und gehen aus Sicht des Managements konträr zum Leistungsversprechen der Cloud, schnell hoch- und herunterskalieren zu können.

- Identitäten, Daten und Anwendungen aus einem Tenant in einen anderen mit möglichst wenig Datenverlust und Downtime migrieren. Die Auslöser für eine solche Migration können dabei vielfältig sein.

Schließlich ist mit dem Triumphzug von Microsoft Teams das Thema "Gruppenverwaltung in M365" stark ins Blickfeld der IT-Verantwortlichen gerückt. Besteht die Cloudlandschaft aus mehreren Tenants, möchten die Administratoren natürlich auch diesen Punkt möglichst einheitlich regeln und mandantenübergreifend überwachen.

Nicht alle im Video demonstrierten oder angekündigten Funktionen haben es in das öffentlich verfügbare Produkt geschafft. Die tatsächlich verfügbare Funktionalität ist Microsoft-Partnern vorbehalten, die die Tenants ihrer Kunden administrieren. Sie läuft Stand Dezember 2021 auf die folgenden drei Funktionen hinaus, die unter [2] beschrieben sind:

- Schnelles Umschalten zwischen Tenants, denen die eigene Organisation als verwaltender Partner zugewiesen ist,

- Überblick über den Gesundheitszustand der einzelnen M365-Dienste über die verwalteten Tenants hinweg und

- Überblick über die Lizenznutzung der verwalteten Tenants. Für die Verwendung dieser Funktion besteht für dn verwaltenden Partner unter Umständen eine andere Motivation als für den zahlenden Endkunden.

Für Administratoren, die mehrere M365- und Azure-Mandanten zu verwalten haben, gibt es derzeit keine grafischen Hilfsmittel innerhalb der gewohnten Admin-Portale. Natürlich steht es Ihnen frei, die gewünschten Informationen mit Hilfe von Microsoft Graph aus den einzelnen Tenants auszulesen und mit den üblichen Mitteln zu konsolidieren. Für eine Übersicht gebuchter und verbrauchter Lizenzen können Sie den folgenden PowerShell-Code verwenden:

Sie müssen natürlich einen Weg finden, die Anmeldedaten zu den einzelnen Tenants sicher zu speichern, wenn das resultierende Skript unbeaufsichtigt laufen soll. Die Informationen zu den gebuchten Lizenzen beziehen sich auf eine als GUID vorliegende SKU-ID oder eine oft ähnlich nichtssagende SKU-PartNumber (hier entspricht beispielsweise "ENTERPRISEPACK" der "Office 365 E3"-Lizenz). Die Übersetzung dieser Daten in managementfreundliche Produktbezeichnungen, wie sie in den Admin-Portalen automatisch stattfindet, müssen Sie anhand der Tabellen unter [3] selbst durchführen. Es existieren einige Community-Skripte, die die Übersetzung für Sie übernehmen. Allerdings sind die offizielle Liste und mit ihr auch die Daten in Microsoft Graph ständiger Veränderung unterworfen, und nicht alle Maintainer der inoffiziellen Skripte haben Zeit oder Lust, damit Schritt zu halten.

Ein anderer Ansatz ist nötig, um den Gesundheitszustand der Services Ihrer M365-Mandanten zu ermitteln. Dafür existiert eine eigene REST-API, die unter [4] dokumentiert ist. Um die benötigten Informationen aus dieser API zu erhalten, müssen Sie zu jedem Tenant einen Token generieren, der den Zugriff auf die API erlaubt und anschließend den Dienststatus mithilfe dieses Tokens abrufen. Wie das mit PowerShell gelingt, beschreibt beispielsweise Adam Bertram [5].

Solche Auswertungen können Sie von Ihrem Management-PC aus durchführen oder beispielsweise einen PowerAutomate-Flow in einem Ihrer Mandanten einrichten und die Ergebnisse entweder als eine statische HTML-Seite oder als ein dynamisches PowerBI-Dashboard anzeigen lassen. Auch ein regelmäßiger E-Mail-Versand einer CSV-Datei mit den konsolidierten Ergebnissen ist ein gangbarer Weg – alles hängt davon ab, wie Sie die Auswertungen später weiterverarbeiten möchten.

Natürlich lassen sich mit PowerShell, PowerAutomate und REST-APIs auch einheitliche Richtlinien zentral definieren und auf mehrere Tenants anwenden sowie die Abweichungen von diesen Richtlinien dokumentieren oder sogar automatisch korrigieren. Einige IT-Abteilungen haben ihre Multitenant-Umgebungen in Eigenregie weitgehend automatisiert. Doch nicht jeder Admin ist in der M365-PowerShell, PowerAutomate oder PowerBI ausreichend sattelfest, um solche Aufgaben zu bewältigen. Es ist daher wenig überraschend, dass Drittanbieter-Produkte auf den Plan getreten sind, um die fehlende Funktionalität nachzuliefern.

Während Microsoft an den Admin-Portalen feilt und ihnen in regelmäßigen Abständen neue Features hinzufügt und ein moderneres Aussehen verleiht, haben sich einige Microsoft-Partner darauf spezialisiert, den Cloudadministratoren einen einfacheren und schnelleren Zugang zu den benötigten Informationen zu bieten – sei es in Bezug auf erworbene und tatsächlich genutzte Lizenzen, Sicherheit oder Compliance. Viele Anbieter solcher Lösungen wie Rencore oder CoreView sprechen in ihren Datenblättern von Multitenant-Fähigkeiten und erlauben dabei primär die gleichzeitige Einbindung mehrerer Tenants und das schnelle Umschalten zwischen ihnen.

Dashboards, die für einen Mandanten erstellt wurden, lassen sich bei diesen Tools meist exportieren und für einen anderen verbundenen Tenant des gleichen Kunden verwenden. Das ist bereits viel mehr als der Leistungsumfang der nativen M365-Adminportale. Die Integration der einzelnen Tenants ist dank einheitlicher Authentifizierung über Azure-AD-Accounts und dem durchgehenden Berechtigungskonzept von M365 ein Kinderspiel, sofern der einrichtende Administrator über ausreichende Berechtigungen verfügt. Meist ist ein Mitglied der "Global Administrator"-Rolle für das Einbinden der Tenants gefordert, anschließend erstellt die Anwendung einen Service Principal und erteilt ihm nach Rückfrage die erforderlichen Berechtigungen.

Ein Paradebeispiel für ganzheitlich gedachtes Multitenant-Management von M365 ist das Produkt "Nova" [8] der Firma Quadrotech, die im November 2020 von Quest übernommen wurde. Hier lassen sich Lizenzen mandantenübergreifend verfolgen, Policies und Berechtigungen einheitlich anwenden und vieles mehr. Alles ist gestützt durch moderne Weboberflächen und Dashboards. Viele der Berichte, die Nova bietet, sind auch mit den Bordmitteln der M365-Admin-Portale möglich. Falls Sie nur einen Tenant zu verwalten haben, ist die Zusatzleistung, die Sie im Rahmen des Nova-Abonnements erhalten, tatsächlich eher überschaubar. Sobald jedoch das Multitenant-Management auf Ihrer Agenda steht, spren Sie mit dem mandanten-übergreifenden Reporting und den zentralen Policies viel Zeit und vermeiden teure Fehler, die sich andernfalls durch Wiederholungen, Copy & Paste oder einfach durch Unachtsamkeit einschleichen können.

Neben den zuvor erwähnten Produkten tummeln sich unzählige weitere Anbieter auf dem Markt. Viele von ihnen versprechen "Mehrmandantenfähigkeit" – die Evaluierung und die letztendliche Entscheidung obliegt den Firmen beziehungsweise deren IT-Teams. Die Beschaffenheit der Cloud und der Mietcharakter der cloudzentrischen Lösungen machen hier einen möglichen Anbieterwechsel allerdings einfacher und preiswerter als im On-Premises-Betrieb. Auch bleiben danach in der Regel weniger Artefakte zurück, die das Sicherheitsniveau Ihrer Umgebung beeinträchtigen würden. Die erstellten Dienstprinzipale in Azure AD müssen Sie allerdings selbst bereinigen, wenn Sie ein bereits eingeführtes Produkt wieder aufgeben.

In Deutschland wurden viele der damals noch Office-365-Kunden mit der Herausforderung einer Tenant-to-Tenant-Migration konfrontiert, noch bevor Mergers & Acquisitions dieses Thema weltweit in den Fokus der IT-Verantwortlichen rückten. Von 2016 bis Ende August 2018 hat Microsoft neben "Office 365 Global" hierzulande auch die Variante "Office 365 DE" angeboten, betrieben und überwacht durch die Deutsche Telekom. Kunden, die aus Datenschutzgründen auf dieses Angebot aufgesprungen sind, mussten jedoch wenig später in die globale O365-Cloud migrieren, als der Service eingestellt wurde.

Diese Migrationen fielen allerdings nicht sehr kompliziert aus – schließlich musste der ganze Tenant mit seinen Einstellungen und Inhalten auf eine andere Cloudplattform umziehen. Den technischen Teil der Migration hatte Microsoft hinreichend unterstützt, die Administratoren vor Ort mussten lediglich die notwendigen Anpassungen an ihren On-Premises-Systemen vornehmen, wie beispielsweise veränderte Zugriffs-URLs und Mailserver-Adressen.

Die Tenant-to-Tenant-Migrationen, mit denen IT-Teams heute konfrontiert sind – etwa aus Anlass eines Mergers –, gestalten sich ungleich komplexer. Zum einen beinhaltet ein M365-Mandant heutzutage viel mehr Anwendungen und Dienste als Office 365 im Jahr 2018. Nicht alle Dienste verfügen dabei über eine Schnittstelle, über die sich Inhalte geordnet auslesen und in die gleiche Anwendung in einem anderen Mandanten übertragen lassen. Dieser Herausforderung begegnen Administratoren bereits bei der Konzeption der Datensicherung für die M365-Anwendungen, doch in Migrationsszenarien ist sie zusätzlich durch die Notwendigkeit erschwert, die Übertragung im laufenden Betrieb durchzuführen.

Selbst bei Diensten wie Exchange Online oder OneDrive for Business, die bereits seit Langem bekannte Schnittstellen zum maschinellen Lesen und Schreiben von anwendungsspezifischen Daten bieten, wirft eine Tenant-zu-Tenant-Migration einige zu berücksichtigende Aspekte auf:

- Domänen und Namespaces können stets nur einem Mandanten zugeordnet sein.

- Cloudidentitäten lassen sich nicht einfach zwischen Mandanten (und somit zwischen Azure-AD-Organisationen) migrieren.

- Inhalte, die mittels Azure Information Protection geschützt sind, können nicht migriert werden, ohne entweder den Informationsgehalt oder den Schutz zumindest vorläufig zu verlieren.

Microsoft hat den Bedarf an Angeboten für Tenant-zu-Tenant-Migrationsszenarien erkannt und im Mai 2021 ein White­paper veröffentlicht [6], das verschiedene Szenarien und Vorgehensweisen in einem "Migrations-Architekturmodell" betrachtet. Gleich auf der zweiten Seite listet das Whitepaper die hauptsächlichen M365-Anwendungen auf und bewertet deren Migrationsfähigkeit.

Die häufigste Angabe hier ist "Microsoft Consulting Services und/oder Dritthersteller-Tool", gefolgt von "Begrenzte Unterstützung von Mig rationsszenarien". Dabei können auch die Microsoft Consulting Services (MCS) in der Regel nicht zaubern und werden sich eines Dritthersteller-Tools bedienen, um die Migration technisch abzuwickeln.

Seit einiger Zeit gibt es aus Redmond ein eigenes Tenant-zu-Tenant-Migrationsverfahren, das sich im Dezember 2021 noch im Preview befand: Mandantenübergreifende Migration von Exchange-Postfächern [7]. Die Liste der bekannten Probleme ist derzeit noch lang und das Problem der Beibehaltung von E-Mail-Adressen löst dieses Vorgehen ebenfalls nicht, da eine SMTP-Domain stets nur einem Mandanten zugeordnet sein kann. Mit diesem Ansatz sind daher allenfalls Big-Bang- oder Cutover-Migrationen möglich. Hierbei ziehen alle Postfächer, die den Quellmandanten verlassen, innerhalb eines Wartungsfensters in den Zielmandanten um und bekommen neue E-Mail-Adressen aus den dort registrierten SMTP-Namespaces.

Auch im Migrationsgeschäft helfen langjährige Microsoft-Partner, die Unzulänglichkeiten der nativen Bordmittel in Tenant-to-Tenant-Szenarien aufzufangen und eine möglichst nahtlose Koexistenz mit dem Ergebnis einer verlustfreien Migration zu ermöglichen. Dabei können die Partner keine Wunder vollbringen, daher bleibt beispielsweise die Migration der im Endpoint-Manager verwalteten Geräte oder der To-Do-Listen auch mit deren Werkzeugen schwierig. Allerdings können Sie für die Kernapplikationen Exchange und SharePoint (und somit Teams und OneDrive for Business) beim Einsatz von Drittanbieter-Tools eine weitgehend automatisierte Migration und in vielen Fällen eine deutlich benutzerfreundlichere Koexistenz erwarten.

Auch hier, ähnlich wie im Fall der Verwaltung und der Berichterstattung über mehrere Mandanten, ist die Auffassung der einzelnen Anbieter in Bezug auf die ideale Migration jedoch unterschiedlich. Für Anbieter wie CodeTwo, die ursprünglich aus der Exchange-Administration und der Automatisierung von Exchange-Migrationen kommen, spielt die Vollständigkeit der übertragenen Daten und Einstellungen in Exchange Online eine zentrale Rolle.

Andere Provider wie AvePoint, deren Schwerpunkt traditionell eher im Bereich SharePoint lag, punkten bei der Analyse und der anschließenden Inhaltsmigration von OneDrive for Business und Teams, während die Exchange-Online-Migration zwar robust, aber weniger detailversessen konzipiert ist.

Einige sehr unterschiedliche Lösungsansätze haben sich um den neuralgischen Punkt in der Tenant-zu Tenant-Migration gebildet, an dem der SMTP-Namespace und damit der Domainname vom alten Mandanten gelöst und auf den neuen übertragen wird.

Nicht in jeder Migration ist dieser Schritt notwendig – wenn ein Geschäftsbereich verkauft wird und IT-technisch herausgetrennt werden muss, nehmen die scheidenden Nutzer den Namespace nicht mit. Falls jedoch die Übertragung der Domäne Teil des Migrationsprozesses ist, stellt sie die Administratoren vor zwei prinzipielle Herausforderungen:

- Während der Phase des Domänenwechsels bleibt der MX im DNS zwar weiterhin auf Exchange Online gerichtet, E-Mails an diese Domäne werden dort aber nicht akzeptiert. Die Dauer des Wechsels lässt sich durch den Kunden nicht beeinflussen, sodass es im schlimmsten Fall bis zu 48 Stunden dauert, ehe die Exchange-Online-Server weltweit wieder die Domain akzeptieren.

- Bei Migrationen großer oder komplexer Mandanten ist ein Cutover-Szenario nicht immer möglich, sodass es zwingend eine Koexistenzphase geben muss. Während dieser Phase befindet sich ein Teil der Postfächer bereits im neuen Mandanten und der Rest noch im alten. Unabhängig davon muss der Empfang und Versand aller E-Mails durch diese Postfächer mit den ursprünglichen E-Mail-Adressen möglich sein.

Das erste Problem adressieren einige Anbieter, indem sie auf einen Office-365-optimierten Backup-MX setzen. Dieser wird für die Dauer der Domänentransition als primärer MX für die umziehenden Domains verwendet und nimmt zunächst alle eingehenden E-Mails entgegen. Die Idee besteht darin, dass länger und häufiger als im Standard vorgesehen versucht wird, die E-Mails an Exchange Online zuzustellen, sodass keine eingehenden Nachrichten verlorengehen. Für die Zuweisung der ursprünglichen E-Mail-Adressen an umziehende Postfächer und Gruppen bietet dieses Konstrukt natürlich keine Lösung.

Ein umfassenderer Ansatz kommt, wenig überraschend, vom Branchen-Primus Quest – und das gleich im Doppelpack. Sowohl die eigene Entwicklung "On Demand Migration" als auch die Variante "Power365-Integration Pro" des im Herbst 2020 von Quest übernommenen Konkurrenten Binary Tree bieten einen "Address Rewrite Service", der für die korrekte Adressierung und Zustellung ein- wie ausgehender E-Mails in beide Richtungen sorgt.

Die entsprechenden Gateways werden pro Migration in der Azure-Cloud provisioniert, kosten also zusätzlich Gebühren für die in Anspruch genommene Compute-Leistung und ausgehende Datenübertragung. Dafür ist eine dauerhafte Koexistenz zweier Mandanten innerhalb eines SMTP-Namespace möglich, die keine Disruption bei den Nutzern und externen Kommunikationspartnern erzeugt. Am Ende der Koexistenz steht ein erfolgreicher Umzug aller Postfächer und Ressourcen in den neuen Mandanten ohne Unterbrechung der E-Mail-Zustellung.

Einsatzszenarien von Microsoft 365, die entweder eine dauerhafte Verwaltung mehrerer Mandanten innerhalb einer Organisation oder eine möglichst nahtlose Migration aus einem Mandanten in einen anderen beinhalten, kommen immer häufiger vor. Daher ist es für Administratoren wichtig, Werkzeuge und Vorgehensweisen an der Hand zu haben, um den spezifischen Herausforderungen zu begegnen, die mit Multitenant-Szenarien einhergehen.

Microsoft beherrscht hier die richtige Methodik, liefert jedoch derzeit nur Service Providern einen begrenzten Satz an Werkzeugen. Doch mithilfe von Drittanbieter-Tools können Sie bereits jetzt die wesentlichen Aufgaben des Multitenant-Managements bewältigen. Bei der Auswahl der Werkzeuge müssen Sie allerdings auf den tatsächlichen Leistungsumfang im mandantenübergreifenden Betrieb achten.