Das Microsoft 365 Substrate: Die unsichtbare Datenschicht hinter Exchange, Teams und Copilot

Wer sich mit der Architektur von Microsoft 365 beschäftigt, stößt früher oder später auf einen Begriff, den Microsoft selbst nur selten erklärt: das Substrate. Dabei ist es eine der kritischsten Komponenten der gesamten Plattform. Ohne das Substrate wäre Microsoft 365 das, was es 2011 war (Microsoft Launches Office 365 Globally), eine lose Sammlung cloudifizierter On-Premises-Produkte, die kaum miteinander sprachen. Dass heute Funktionen wie einheitliche Suche, Information Protection, eDiscovery, Compliance und seit 2023 auch Copilot über verschiedene Workloads hinweg konsistent funktionieren, liegt wesentlich am Substrate.

Was ist das Microsoft 365 Substrate?

Microsoft beschreibt das Substrate als "planetary scale people operating system" Die Idee dahinter: So wie ein klassisches Betriebssystem drei Dinge tut: Ressourcen verwalten und schützen, Entwicklern konsistente Dienste bereitstellen und eine Anwendungsschicht bieten, tut Microsoft 365 dasselbe. Nur eben nicht für Geräte, sondern für Menschen und Organisationen.

Im Substrate-Modell sieht das so aus:

• Objects (Ressourcen): Benutzer, Dokumente, Nachrichten, Kalender, Meetings, Aufgaben, Chats. Diese Objekte werden geschützt durch Information Protection und Defender for Office 365.
• Services (Entwicklerschicht): Chat, Calling, E-Mail, Search, semantische Suche, Knowledge Management, AI-Dienste, Compliance. Dazu ein einheitliches API (Microsoft Graph) und wiederverwendbare UI-Komponenten wie die People Card, die File Card und die Topic Card.
• Apps (Anwendungsschicht): Word, Teams, Outlook, Excel, PowerPoint, Copilot.

Das Substrate ist keine App. Man kann es nicht verwalten, nicht sehen, aber es ist immer da. Es bildet die intelligente Plattform für ganz Microsoft 365, nicht nur für einzelne Workloads. Alles, was ein Nutzer in Microsoft 365 tut, wird entweder nativ im Substrate gespeichert oder als sogenannter "Digital Twin" dorthin repliziert.

Die Abhängigkeit von Exchange Online

Die physische Implementierung des Substrates basiert auf Exchange Online. Exchange ist in der Cloud nicht mehr das Zentrum eines Ökosystems wie der On-Premises-Server es war. Stattdessen hat Exchange Online zwei klar getrennte Rollen:

• Provider von Mail- & Messaging Services: Wenn ein Dienst in Microsoft 365 E-Mails versenden will, nutzt er Exchange.
• Provider von Storage-Services für das Substrate: Exchange Online stellt den physischen Speicher bereit, auf dem das gesamte Substrate operiert.

Jeder Tenant (Microsoft 365-Mandant) hat deutlich mehr Postfächer, als Administratoren über Get-EXOMailbox sehen. Neben den bekannten Benutzer-, Shared- und Gruppenpostfächern existieren zahlreiche versteckte Postfächer, die das Substrate und die darauf aufbauenden Dienste nutzen:

• Cloud-only Mailboxes für Compliance Records von Teams, Yammer und Planner
• Channel-Mailboxes, die E-Mails an Teams-Kanäle entgegennehmen
• Scheduling-Mailboxes für Microsoft Bookings
• Audit-Mailboxes, die das Unified Audit Log speichern, wer die Audit-Suche ausführt, durchsucht im Hintergrund Postfächer, ohne es zu wissen
• App-Mailboxes für Hybrid-Benutzer und Gastbenutzer, die kein eigenes Exchange-Online-Postfach haben

Diese Postfächer existieren im Hintergrund, werden indexiert und sind für eDiscovery durchsuchbar. Teams war die erste große Anwendung, die konsequent aus diesem "Software Toolkit" gebaut wurde. Microsoft Teams nutzt Exchange Online für Compliance, SharePoint Online/OneDrive for Business für Dokumente und Azure-Services für Nachrichten, ohne irgendetwas davon selbst implementieren zu müssen. Die Substrate-Abhängigkeit von Exchange Online ist der Grund, warum ein Exchange-Online-Postfach eine Voraussetzung für viele Microsoft-365-Funktionen ist (Service dependencies, die auf den ersten Blick nichts mit E-Mail zu tun haben.

ESE - Storage-Engine

Die technische Grundlage bildet die Extensible Storage Engine (ESE), eine NoSQL-Datenbank-Engine, die seit Windows NT 3.51 existiert und über 25 Jahre kontinuierlich weiterentwickelt wurde. ESE läuft auf hunderttausenden Servern in Microsofts Rechenzentren und bildet das Speicher-Backend nicht nur für Exchange Online, sondern auch für Active Directory und zahlreiche Windows-Komponenten. Microsoft hat ESE 2021 als Open Source auf GitHub veröffentlicht.

ESE hat mehrere Eigenschaften, die sie für die Substrate-Rolle prädestinieren. Sie verwaltet sehr unterschiedliche Datentypen effizient, skaliert auf kostengünstiger Hardware und unterstützt Sharding, die Fähigkeit, verschiedene Datenblöcke zu einem logischen Ganzen zu verbinden. So werden beispielsweise 100-GB-Startpartitionen mit 50-GB-Segmenten verkettet, um erweiterbare Archivpostfächer mit bis zu 1,5 TB zu bilden.

Die Datensicherheit gewährleistet das Exchange Online Native Data Protection-Modell. Jede Mailbox-Datenbank ist in einer Database Availability Group (DAG) gehostet und wird in vier Datenbankkopien repliziert, darunter eine Lagged Copy. So zumindest der letzte öffentliche bekannte Informationsstand. Die Kopien sind über geografisch getrennte Rechenzentren verteilt. Dadurch erübrigt sich für Substrate-Daten eine separate Backup-Infrastruktur, die Redundanz ist in die Plattform eingebaut.

Das Digital-Twin-Konzept

Nicht alle Daten in Microsoft 365 werden nativ in ESE gespeichert. SharePoint Online nutzt Azure SQL, Microsoft Teams speichert Nachrichten in Azure Cosmos DB, Stream und andere Dienste verwenden Azure-spezifische Storage-Dienste. Das Substrate löst diese Fragmentierung durch sogenannte "Digital Twins" auf.

Für jedes Element, das in einem externen Speicher liegt, wird ein Subset im Substrate angelegt. Dieser digitale Zwilling enthält nicht das vollständige Original, sondern die Metadaten und Inhaltsausschnitte, die Dienste wie Search, Compliance und Information Protection benötigen. Teams-Compliance-Records in Exchange-Online-Postfächern enthalten beispielsweise keine Reaktionen. Sie werden als Mail-Items gespeichert, bei denen nur die für Retention Processing notwendigen Properties befüllt sind.

Compliance Records sind imperfekte Kopien. Sie sind für eDiscovery, Retention und Communications Compliance konzipiert, nicht für Backup und Restore. Man kann einen Microsoft Teams-Compliance-Record nicht zurück in einen Microsoft Teams-Chat einfügen. Microsoft arbeitet dafür an einer separaten Teams-Export-API.

Die Mechanismen, über die Digital Twins ins Substrate gelangen, sind vielfältig. Exchange-Online-Postfächer tragen neben SMTP-Adressen auch Proxy-Adressen mit dem Präfix SPO:. Diese dienen als Route, über die SharePoint benutzerbezogene Informationen in Exchange einspielt.

Substrate-Ordner in der Mailbox

Wer mit MFCMAPI oder Get-EXOMailboxFolderStatistics in den Non-IPM-Root einer Exchange-Online-Mailbox schaut, findet die Spuren des Substrates in versteckten Systemordnern:

• Files: Ein Systemordner seit 2015. Er enthält Referenzen auf Dateien, mit denen der Nutzer zuletzt gearbeitet hat, aus SharePoint Online / OneDrive for Business, E-Mail-Anhängen und Cloud-Attachments. Background-Assistants aktualisieren diesen Ordner kontinuierlich über die Insights-API. Anwendungen wie die SharePoint-Startseite und Office.com greifen darauf zu, statt Exchange Online, SharePoint Online / OneDrive for Businesseinzeln abzufragen.
• GraphWorkingSet: Enthält Subset-Items mit Pointern in Properties wie FileId und GraphNodeId. Diese bilden die Datenbasis für Graph-Traversierung.
• TeamsMessageData: Der Ordner für Teams-Compliance-Items. Hier landen die digitalen Zwillinge aller Nachrichten aus Chats und privaten Kanalkonversationen.
• Neben diesen Ordnern im Non-IPM-Root spielen auch die Unterordner des Recoverable Items-Ordners eine substratrelevante Rolle:
  • Deletions: Vorläufig gelöschte Items, deren Aufbewahrungsfrist noch läuft. Nutzer können diese über "Gelöschte Elemente wiederherstellen" in Outlook zurückholen.
  • DiscoveryHolds: Endgültig gelöschte Items, die durch einen eDiscovery-Hold oder eine Retention Policy aufbewahrt werden. Für Endanwender nicht sichtbar.
• SubstrateHolds: Endgültig gelöschte Items aus Microsoft Teams und anderen Cloud-basierten Apps, die durch eine Retention Policy oder einen Hold aufbewahrt werden. Für Endanwender nicht sichtbar. In der Praxis kann dieser Ordner erhebliche Größen erreichen: Wenn eine Mailbox unter Hold steht, sammeln sich dort Microsoft Teams-Chat-Daten an, die nicht bereinigt werden können, solange der Hold aktiv ist. Es gibt dokumentierte Fälle, in denen SubstrateHolds den Recoverable-Items-Ordner bis an die 100-GB-Grenze gefüllt hat – mit der Folge, dass betroffene Nutzer keine Kalendereinladungen mehr empfangen konnten.
  
  Alle Systemordner im Non-IPM-Root zählen nicht gegen das Mailbox-Quota. Hintergrund-Agenten räumen veraltete Einträge auf, wenn Dateien gelöscht oder Zugriffsrechte entzogen werden.

Microsoft Graph: Die API-Schicht über dem Substrate

Das Substrate ist der Speicher. Der Microsoft Graph ist die API-Schicht darüber. Das Verhältnis lässt sich auf eine Formel bringen: Das Substrate hält den State aller Daten im Tenant. Der Graph bietet Diensten und Anwendungen den Zugriff darauf, über einen einheitlichen Namespace und einheitliche Endpunkte.

Ältere anwendungsspezifische APIs (wie Exchange Web Services) werden schrittweise durch Graph-Endpunkte ersetzt. Dieser Prozess dauert aufgrund der großen Zahl bestehender Integrationen Jahre, wird aber konsequent vorangetrieben. Für neue Funktionen ist der Graph bereits der primäre Zugangsweg.

Was den Graph vom klassischen Datenbankzugriff unterscheidet, ist die Graph-Traversierung. Man schlägt nicht nur einen Eintrag nach, sondern navigiert von einer Entität zu verwandten Entitäten. Die People Card ist das sichtbarste Beispiel, sie zeigt nicht nur Name und Kontaktdaten einer Person, sondern auch geteilte Dokumente, gemeinsame Meetings und organisatorische Beziehungen. Diese Vernetzung entsteht, weil der Graph über das Substrate auf Daten aus verschiedenen Quellen zugreifen und sie zueinander in Beziehung setzen kann.

Über den Graph Explorer (aka.ms/GE) lassen sich Endpunkte direkt ansprechen, etwa me/insights/trending, um die aktuell relevantesten Dokumente eines Nutzers abzurufen. Diese "Trending"-Daten basieren auf AI-Signalen aus dem Substrate: Wer hat was bearbeitet, wer hat mit wem zusammengearbeitet, welche Dateien werden gerade häufig aufgerufen. Dieselben Signale steuern auch Funktionen wie den People Picker (der AI-basiert die wahrscheinlichsten Kontakte vorschlägt) und die automatisch generierten Topic Cards (die Projekte erkennen und Übersichtsseiten mit Beteiligten und Ressourcen erzeugen, ohne manuelle Pflege).

Graph und Copilot

Diese Architektur ist auch die Grundlage für Microsoft 365 Copilot. Copilot operiert innerhalb der Sicherheitsgrenze des Tenants und greift über den Microsoft Graph auf Organisationsdaten zu. Die Berechtigungen des anfragenden Nutzers werden dabei durchgesetzt: Wenn ein Nutzer keinen Zugriff auf ein Dokument hat, liefert der Graph nichts zurück, Copilot kann die vorhandenen Sicherheitskontrollen nicht umgehen.

Work IQ, das mit der dritten Welle von Copilot eingeführt wurde, erweitert diesen Kontextzugriff: Dateien, Meetings, Chats und E-Mails fließen in ein gemeinsames Kontextmodell ein. Das funktioniert nur, weil das Substrate diese Daten bereits konsolidiert vorhält. Die Qualität der Copilot-Antworten hängt direkt davon ab, wie vollständig und aktuell die Digital Twins im Substrate sind.

Praktische Implikationen

Das Substrate ist bewusst unsichtbar. Microsoft dokumentiert es kaum, und es gibt keine dedizierten Admin-Tools dafür. Trotzdem hat es eine Reihe praktischer Konsequenzen, die Administratoren kennen sollten.

Die Substrate-bezogenen Systemordner zählen zwar nicht gegen das Mailbox-Quota, erhöhen aber die tatsächliche Datenmenge pro Postfach. Exchange-Online-Postfächer haben mehr Systemordner als On-Premises-Postfächer. Das wirkt sich auf Backup-Zeiten und -Kosten aus. Wenn ein Backup-Tool den Non-IPM-Root nicht sichert, gehen Compliance Records verloren. Gleichzeitig sind Compliance Records keine vollständigen App-Daten, sie lassen sich nicht zurück in Microsoft Teams einspielen.

Dual-Write und Microsoft Substrate Management

In den Entra-ID-Audit-Logs taucht gelegentlich eine First-Party-Enterprise-App namens "Microsoft Substrate Management" auf. Diese App ist der Service Principal, über den Exchange Online Verwaltungsoperationen im Rahmen des Dual-Write-Mechanismus durchführt. Dual-Write stellt sicher, dass Änderungen an Objekten gleichzeitig in EXODS (Exchange Online Directory Service) und Entra ID geschrieben werden. Schlägt der Schreibvorgang in einem der beiden Verzeichnisse fehl, wird die gesamte Operation abgelehnt. Damit wird verhindert, dass die beiden Verzeichnisse auseinanderlaufen, ein Problem, das in früheren Versionen regelmäßig vorkam.

Wenn bei einer Exchange-Online-Verwaltungsoperation ein Fehler mit Verweis auf "Azure Active Directory" auftritt, liegt das in der Regel am Dual-Write-Mechanismus. Die Empfehlung: Cmdlet erneut ausführen. Besteht das Problem fort, sollte beim Support-Ticket angegeben werden, dass der Exchange-Fehler durch einen Entra-ID-Schreibfehler verursacht wurde.

Substrate in 2026 und der Zukunft, was dürfen wir uns erwarten?

Das Substrate wurde geschaffen, um aus einer fragmentierten Sammlung cloudifizierter Produkte eine kohärente Plattform zu machen. Mit der Einführung von Copilot, Agent 365 und Work IQ in Microsoft 365 E7 wird seine Rolle weiter zunehmen. Die AI-Funktionen, die Microsoft jetzt ausrollt, setzen voraus, dass sämtliche relevanten Daten eines Tenants konsolidiert, durchsuchbar und kontextuell verknüpft sind.