Substrate

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

Yannic Röcken

02 Apr. 2026 — 14 Min. Lesezeit

Das Microsoft 365 Substrate ist eine der wichtigsten Komponenten der Plattform, und gleichzeitig eine, über die Microsoft selten redet. Ohne das Substrate wäre Microsoft 365 das, was es 2011 war: eine lose Sammlung cloudifizierter On-Premises-Produkte, die kaum miteinander sprachen. Einheitliche Suche, Information Protection, eDiscovery, Compliance und seit 2023 auch Copilot funktionieren heute workloadübergreifend. Dass das überhaupt geht, liegt am Substrate. [1]

Was ist das Microsoft 365 Substrate?

Den Begriff hat Jeffrey Snover geprägt, damals Microsoft Technical Fellow und Architekt der Intelligent Substrate Platform in Office 365. In einem Microsoft-Mechanics-Beitrag von der Ignite 2019 beschreibt er das Substrate als Kern eines "planetary scale people operating system" (so überliefert durch Tony Redmond). Die Analogie zu klassischen Betriebssystemen: Ressourcen verwalten und schützen, konsistente Dienste für Entwickler bereitstellen, eine Anwendungsschicht bieten. Nur eben nicht für ein einzelnes Gerät, sondern für Menschen und Organisationen. [2][5]

Microsoft 365 gliedert sich in dieser Darstellung grob in drei Ebenen:

Objects (Ressourcen): Benutzer, Dokumente, Nachrichten, Kalender, Meetings, Aufgaben, Chats, geschützt durch Information Protection und Defender for Office 365.
Services (Entwicklerschicht): Mail, Chat, Calling, Suche, Compliance, KI-Dienste, Knowledge Management, zugänglich über einheitliche Schnittstellen, allen voran den Microsoft Graph.
Apps (Anwendungsschicht): Word, Excel, PowerPoint, Outlook, Teams, Microsoft 365 Copilot.

Das Substrate ist keine Anwendung, sondern die gemeinsame Daten- und Servicebasis darunter. Dienste wie einheitliche Suche, eDiscovery, Retention, Information Protection und seit 2023 auch Copilot arbeiten über sie workloadübergreifend. [3]

Drei-Schichten-Modell von Microsoft 365: Apps über Services über Objects, darunter das Substrate als gemeinsame Basis

Historisch ist das Substrate der direkte Nachfolger des "Office Graph", den Microsoft im März 2014 auf der SharePoint Conference zusammen mit Delve (Codename "Oslo") vorgestellt hat. Satya Nadella nannte das damals den strategischsten API-Ansatz der Company. Aus dieser Idee wurde 2015 der Microsoft Graph als einheitliche Entwickler-API, zunächst auf der //build als "Office 365 Unified API" vorgestellt und im November 2015 bei Microsoft Connect() in Microsoft Graph umbenannt. Die Datenschicht dahinter heißt heute Substrate. Wer eine einfache Merkformel sucht: das Substrate sind die Daten, der Graph ist die Tür dorthin. [24]

Die Rolle von Exchange Online

Die physische Speicherschicht, auf die sich das Substrate in weiten Teilen stützt, liefert Exchange Online. Exchange füllt in der Cloud damit zwei Rollen gleichzeitig aus:

Mail- & Messaging-Service für alle Dienste, die in Microsoft 365 E-Mails erzeugen, empfangen oder zustellen müssen.
Storage-Plattform für substrate-relevante Daten, darunter Compliance-Records aus anderen Workloads.

Warum gerade Exchange Online diese zweite Rolle übernimmt, hat pragmatische Gründe. Die Exchange-Online-Speicherarchitektur ist ausgereift, hochverfügbar und kommt ohne klassische Backups aus (dazu unten mehr). Und sie geht effizient mit Objekten sehr unterschiedlicher Form um.

In einem Microsoft-365-Tenant gibt es deshalb deutlich mehr Postfächer, als Administratoren im Alltag sehen. Neben den klassischen Benutzer-, Shared- und Gruppenpostfächern existieren unter anderem:

Postfächer zur Aufnahme von Teams-Compliance-Records. Die Zuordnung hat sich 2025/2026 verändert. 1:1-Chats liegen weiterhin im Benutzerpostfach. Standard-, Shared- und, nach der Microsoft-Migration von Ende 2025 bis in den späten April 2026 hinein, auch Private-Channel-Nachrichten landen jetzt im zugehörigen Microsoft-365-Gruppenpostfach. Für eine saubere eDiscovery privater Kanäle muss man Vor- und Nach-Migrationsdaten parallel betrachten: Altdaten in den Benutzerpostfächern, Neudaten im Gruppenpostfach. [4]
Channel-Mailboxes als Zustellpunkt, wenn E-Mails an eine Teams-Kanal-Adresse gehen. Microsoft verwaltet diese Postfächer, Kunden kommen nicht direkt dran.
Booking-Postfächer hinter Microsoft Bookings, als Shared Mailboxes vom Service Principal "Microsoft Substrate Management" angelegt (mehr dazu weiter unten).
Systempostfächer diverser Microsoft-365-Dienste.

Für Endanwender sind viele dieser Postfächer unsichtbar. Indexiert werden sie trotzdem, und je nach Konfiguration tauchen sie in eDiscovery oder Content Search auf.

Das häufigste Beispiel für das Zusammenspiel ist Microsoft Teams. Teams nutzt Exchange Online für Compliance-Aufbewahrung, SharePoint Online bzw. OneDrive for Business für Dateien und Azure-Dienste für die eigentliche Chat-Infrastruktur in Azure Cosmos DB. Große Teile des Storage-Stacks bringt Teams also mit, statt Compliance- und Governance-Funktionen in jeder Komponente neu zu implementieren. [5]

ESE als Storage-Engine

Technisch steht unter dem Exchange-Online-Storage die Extensible Storage Engine (ESE), intern auch als "JET Blue" bekannt. Microsofts eigene Dokumentation beschreibt sie als "advanced indexed and sequential access method (ISAM) storage technology". [6]

Anders als manche Darstellungen suggerieren, ist ESE keine NoSQL-Datenbank im Stil von MongoDB oder Cassandra. Sie ist eine ISAM-basierte, eingebettete Datenbank-Engine mit ACID-Transaktionen, Write-Ahead-Logging und Snapshot-Isolation. [7]

Zwei Eigenschaften sind für den Substrate-Kontext entscheidend:

Sie unterstützt denormalisierte Schemata, inklusive breiter Tabellen mit vielen sparse columns, multi-valued columns und dünn besetzten Indizes. Das passt gut zu den unterschiedlichen Objekttypen in einem Postfach: Mails, Kalendereinträge, Kontakte, Compliance-Records. [7]
Transaktionssicherheit über ein Crash-Recovery-Modell mit Write-Ahead-Log. Das ist die Voraussetzung dafür, dass Exchange Online auf klassische Backups verzichten kann. [7]

ESE ist nicht neu. Erstmals ausgeliefert wurde sie 1995 mit Windows NT 3.51, übernommen in Exchange 4.0 (1996). Bis heute bildet sie unter anderem das Storage-Backend von Active Directory und mehrerer Windows-Komponenten. 2021 hat Microsoft den Quellcode auf GitHub veröffentlicht. [7]

Exchange Online Native Data Protection

Wie die Hochverfügbarkeit der Exchange-Online-Speicherschicht funktioniert, beschreiben das Microsoft Service Trust Portal und die offizielle Compliance-Dokumentation. Stand Januar 2026 gilt:

Every mailbox database in Microsoft 365 is hosted in a database availability group (DAG) and replicated to geographically separate datacenters within the same territory. The most common configuration is three database copies in three datacenters; however, some territories have fewer datacenters (two datacenters in Australia and Japan). But in all cases, every mailbox database has at least three copies that are distributed across multiple datacenters. [8]

Alle Kopien sind hochverfügbar konfiguriert, einschließlich der verzögerten Kopie. Microsoft spricht heute von einer "available lag copy": Resilienz einer klassischen Lagged Copy kombiniert mit der Aktivierungsbereitschaft einer HA-Kopie. Im Notfall übernimmt sie automatisch. Der Restore-Horizon beträgt sieben Tage. Microsoft kann eine Datenbank damit auf definierte Punkte der vergangenen Woche zurücksetzen. [8]

Die verzögerte Kopie ist ausdrücklich kein Backup für einzelne Mailbox-Items, sondern ein Rettungsring für den seltenen Fall einer systemweiten, logischen Korruption. [8]

Exchange Online DAG · Standard-Konfiguration: drei Datenbankkopien in drei Rechenzentren, eine als Available Lag Copy mit 7-Tage-Restore-Fenster

Schematische Darstellung. In Australien und Japan liegen Datenbanken in zwei Rechenzentren; mindestens drei Kopien bleiben aber in jedem Fall bestehen.

Das Digital-Twin-Konzept

Nicht alle Tenant-Daten liegen nativ im Exchange-Online-Speicher. SharePoint Online setzt auf Azure SQL für Metadaten und Azure Blob Storage für die eigentlichen Dateiinhalte (verschlüsselte, read-only Blobs). Microsoft Teams speichert Chat-Nachrichten in Azure Cosmos DB und Dateianhänge in Azure Storage. Weitere Dienste haben ihre eigenen Azure-Backends. Damit Suche, Retention, eDiscovery oder Information Protection trotzdem übergreifend funktionieren, nutzt Microsoft das Konzept "Digital Twin". Relevante Daten werden, vollständig oder als Teilmenge, zusätzlich im Substrate abgelegt. [5]

Diese Twins sind keine vollen Kopien. Ein Teams-Compliance-Record im Exchange-Postfach enthält nicht jede Reaktion und nicht jedes Detail einer Chat-Nachricht. Er wird als Mail-Item gespeichert, bei dem nur die Properties gefüllt sind, die Retention, Search und eDiscovery brauchen. Einen Compliance-Record kann man deshalb nicht einfach "zurück in Teams" einspielen. Für die echte Ausgabe der Nachrichten gibt es eine eigene Microsoft Teams Export API. [9]

Microsoft hat den EWS-Zugriff auf Teams-Daten bereits am 31. Januar 2023 eingeschränkt. Seitdem läuft der unterstützte Zugang ausschließlich über Microsoft Graph beziehungsweise die Teams Export API. [26]

Wie viel in einem Exchange-Postfach tatsächlich liegt, verglichen mit dem, was Outlook anzeigt, lässt sich mit MFCMAPI oder über Get-EXOMailboxFolderStatistics auch hands-on zeigen.

Substrate-Ordner im Non-IPM-Teilbaum der Mailbox

Ein Exchange-Postfach ist intern in zwei Teilbäume unterteilt. Den sichtbaren IPM-Teilbaum (Inbox, Sent Items, Calendar) sehen Nutzer in Outlook. Darunter liegt der Non-IPM-Teilbaum (in EWS "Root" oder "Message Store Root"). Hier sitzen die Systemordner, die Microsoft 365 und seine Apps für interne Aufgaben nutzen. [10]

Struktur eines Exchange-Online-Postfachs: IPM-Teilbaum mit sichtbaren Ordnern links, Non-IPM-Teilbaum mit Substrate-internen Ordnern rechts

Files: In jeder Exchange-Online-Mailbox vorhanden. Der Ordner enthält Metadaten und Referenzen auf Dateien, mit denen jemand zuletzt gearbeitet hat. Dabei ist egal, ob die Datei per E-Mail-Anhang, als "Cloud Attachment", aus SharePoint Online oder aus OneDrive kam. Microsoft beschreibt den Zweck offiziell als Performance-Beschleunigung der Suche: [11]

The Files folder within a mailbox is used to store the metadata of attachments that come into the mailbox. This content is then used to improve search performance and the overall user experience when search is used to find attachments. [11]

Wichtig: Der Ordner zählt nicht gegen das Mailbox-Quota des Benutzers, sondern gegen ein separates System-Quota.

GraphWorkingSet / GraphFilesAndWorkingSetSearchFolder: In der offiziellen Microsoft-Learn-Doku taucht der Ordner nicht auf. Via PowerShell (Get-MailboxFolderStatistics -FolderScope NonIpmRoot) und in MFCMAPI sieht man ihn aber. Community-Analysen (u. a. Vasil Michev, Tony Redmond) beschreiben ihn als Search-Folder mit Pointer-Properties wie FileId oder GraphNodeId, über die der Graph Objektgrenzen hinweg traversieren kann.

TeamsMessagesData: Hier landen Teams-Compliance-Records für persönliche Chats und private Kanäle im Benutzerpostfach. Microsoft stellt klar, dass der Ordner nicht für den Zugriff durch Drittanbieter-APIs wie EWS vorgesehen ist. Der unterstützte Zugriff läuft über eDiscovery oder die Teams Export API. [12]

Ebenfalls substratrelevant sind die Unterordner des Recoverable-Items-Containers. Microsoft dokumentiert insgesamt sieben Unterordner. Die für das Substrate-Thema wichtigsten: [13]

Deletions: Soft-deleted Items innerhalb der Aufbewahrungsfrist. Für Nutzer über "Gelöschte Elemente wiederherstellen" zugänglich.
Versions: Originalkopien geänderter Items unter In-Place Hold, Litigation Hold oder Retention Policy (Copy-on-Write-Schutz). Für Endanwender nicht sichtbar.
Purges: Hard-deleted Items bei aktivem Litigation Hold oder Single Item Recovery. Nicht sichtbar.
DiscoveryHolds: Hard-deleted Items unter eDiscovery-Hold (In-Place Hold) oder Retention Policy. Nicht sichtbar.
SubstrateHolds: Aufbewahrungsort für originale Kopien von Nachrichten aus substrate-basierten Workloads, die geändert oder gelöscht wurden, sofern ein In-Place Hold, Litigation Hold oder eine entsprechende Retention-Policy greift. Primär betrifft das Teams; Microsoft nennt daneben auch Viva Engage und Copilot-/KI-App-Interaktionen. Nicht sichtbar. [13]

Zwei weitere Unterordner, Audits (Mailbox-Audit-Einträge) und Calendar Logging (Kalender-Änderungsprotokolle), sind für das Substrate-Thema weniger relevant und hier nur der Vollständigkeit halber genannt. [13]

Der Recoverable-Items-Ordner hat ein eigenes Quota. Standard sind 20 GB (Soft Limit) und 30 GB (Hard Limit). Unter aktiven Holds oder Retention Policies steigt das auf 90 bzw. 100 GB. In der Praxis gibt es dokumentierte Fälle, in denen dieser Ordner, meist durch Teams-Substrate-Daten in SubstrateHolds, gegen die 100-GB-Grenze läuft, obwohl der IPM-Teilbaum klein bleibt. Betroffene Nutzer können dann zum Beispiel keine Kalendereinladungen mehr annehmen, weil die zugehörigen Items nicht mehr in die Recoverable-Items-Struktur geschrieben werden können. [14]

Um das abzufedern, gibt es einen Background-Prozess. Er verschiebt Inhalte aus Purges, Versions und DiscoveryHolds zeitversetzt ins Archivpostfach, sofern eines konfiguriert ist. [15]

Ein Detail, das im Alltag gern untergeht: Retention-Timer-Jobs laufen nicht kontinuierlich. Greift in Teams eine Retention-Policy, prüft ein periodischer Exchange-Timer-Job im Intervall von typischerweise 1 bis 7 Tagen, welche Items ihre Aufbewahrungsfrist überschritten haben und in den SubstrateHolds-Ordner verschoben werden müssen. Dort verbleiben sie mindestens einen weiteren Tag, bevor sie endgültig gelöscht werden. Für Nachrichten, die ein Nutzer aktiv löscht, kommt eine Besonderheit dazu: Aus der Teams-App verschwindet die Nachricht sofort, die eigentliche Verschiebung in SubstrateHolds passiert aber erst nach 21 Tagen. Bis dahin ist sie weiterhin durchsuchbar, auch via eDiscovery. Das ist der Grund, warum scheinbar gelöschte Teams-Nachrichten in eDiscovery-Suchen häufig noch Tage oder Wochen später auftauchen. [22]

Was das Substrate noch leistet

Das Substrate ist nicht nur Speicher, sondern auch die Basis für M365-Kernfunktionen, die in der Alltagsadministration selten explizit als "Substrate-Service" auftauchen:

Microsoft Search / einheitliche Suche. Die workloadübergreifende Suche in Bing at Work, Office-Apps und auf der SharePoint-Startseite ist ein Substrate-nativer Dienst. Sie indiziert Mails, Dateien, Teams-Nachrichten und, über Graph Connectors, externe Datenquellen. Berechtigungen des suchenden Nutzers respektiert sie dabei.
Unified Audit Log. Die zentrale Audit-Quelle im Microsoft Purview Compliance Portal führt Audit-Events aus Exchange, SharePoint, Teams, Entra ID und weiteren Workloads zusammen. Community-Analysen (MFCMAPI-Exploration, Verhaltensbeobachtung) beschreiben die Audit-Ablage als substrat-vermittelten Store. Eine offizielle Microsoft-Dokumentation, die diesen Punkt explizit bestätigt, gibt es nicht. Was man aber sicher sagen kann: Retention, Zugriff und eDiscovery dieser Logs folgen den gleichen Mechanismen wie andere substrate-bezogene Daten.
Loop-Komponenten. Fluid/Loop-Komponenten landen technisch in SharePoint Online oder OneDrive, sind aber über das Substrate indiziert und damit in Suche, eDiscovery und Copilot-Grounding vertreten. Ein gutes Beispiel dafür, dass "im Substrate auffindbar" und "in Exchange Online gespeichert" nicht dasselbe sind.
Sensitivity Labels als Metadaten. Microsoft-Purview-Information-Protection-Labels werden an Dokumenten, E-Mails und, je nach Label-Typ und Konfiguration, auch an Container-Objekten (Sites, Gruppen) mitgeführt. Ob diese Metadaten intern als Substrate-Object-Properties gehalten werden, dokumentiert Microsoft nicht öffentlich. Was sich beobachten lässt: Copilot respektiert Labels im Grounding und behandelt Inhalte mit sensiblen Klassifikationen entsprechend, zitiert sie zum Beispiel nicht in unverschlüsselten Prompts.

Microsoft Graph: Die API-Schicht über dem Substrate

Das Substrate ist die Storage-Ebene, der Microsoft Graph ist die einheitliche API-Schicht darüber. Im Substrate steckt der Zustand der Tenant-Daten, der Graph bietet Diensten und Anwendungen einen kontrollierten Zugriff über einen einheitlichen Namespace und einheitliche Endpunkte.

Ältere, anwendungsspezifische APIs wie Exchange Web Services (EWS) werden schrittweise durch Graph-Endpunkte ersetzt. Microsoft hat angekündigt, EWS in Exchange Online ab dem 1. Oktober 2026 standardmäßig zu deaktivieren. Tenants, die EWS noch brauchen, müssen sich über eine Allow List explizit registrieren. Die endgültige Abschaltung ist für 2027 geplant. Dass der Umstieg so lange dauert, hat einen praktischen Grund: die schiere Zahl bestehender Integrationen, Drittanbieter-Tools, Backup-Lösungen und Custom-Skripte, die alle EWS nutzen. Für Teams-Daten ist EWS ohnehin schon länger kein unterstützter Zugangsweg mehr.

Ein wichtiges Konzept des Graphs ist die Graph-Traversierung. Anwendungen fragen nicht nur einzelne Einträge ab, sondern navigieren von einer Entität zu verwandten Entitäten. Das sichtbarste Beispiel dafür ist die People Card. Sie zeigt nicht nur Kontaktdaten, sondern auch gemeinsam bearbeitete Dokumente, gemeinsame Meetings und organisatorische Beziehungen.

Wer es selbst sehen will: Der Graph Explorer (aka.ms/GE) macht Endpunkte wie /me/insights/trending direkt ausprobierbar, zum Beispiel für die aktuell relevantesten Dokumente eines Nutzers. Hinter diesen Trending-Daten stecken KI-basierte Signale: wer hat was bearbeitet, wer hat mit wem zusammengearbeitet, welche Dateien werden oft aufgerufen. Es sind die gleichen Signale, die auch den People Picker, Topic Cards und ähnliche KI-gestützte UI-Komponenten speisen.

Substrate, Microsoft Graph und Copilot

Diese Architektur ist auch die Grundlage für Microsoft 365 Copilot. Laut Microsoft operiert Copilot ausschließlich innerhalb der Sicherheitsgrenze des Tenants und greift über den Graph auf Organisationsdaten zu. Die Berechtigungen des anfragenden Nutzers gelten dabei weiter: [16]

Microsoft 365 Copilot only surfaces organizational data to which individual users have at least view permissions. (…) Semantic Index honors the user identity-based access boundary so that the grounding process only accesses content that the current user is authorized to access. [16]

Zwischen Substrate und LLMs liegt der Semantic Index, ein Copilot-spezifischer Vektorindex, den Microsoft automatisch für jedes Microsoft-365-Abonnement erzeugt. Er existiert auf zwei Ebenen: [25]

Ein Tenant-Level-Index, gebaut aus textbasierten SharePoint-Online-Inhalten, gespeichert im isolierten Tenant-Container in der Region der SharePoint-Home-Location.
Ein User-Level-Index im Postfach des jeweiligen Nutzers, mit persönlichen Signalen wie E-Mails, Dokumenten, in denen jemand erwähnt wird, oder Objekten, mit denen interagiert wurde.

Microsoft 365 Copilot: Request-Flow zwischen Nutzer, Copilot-Orchestrator, Microsoft Graph mit Semantic Index (Tenant-Level und User-Level) und dem Large Language Model

Postfach-Inhalte werden nahezu in Echtzeit indiziert. Neu hinzugefügte SharePoint-Inhalte, auf die mindestens zwei Nutzer Zugriff haben, laufen einmal täglich durch die Indizierung. Der Semantic Index respektiert bestehende Berechtigungen. Copilot bekommt also nur Grounding-Material, das der anfragende Nutzer sowieso sehen dürfte. [25]

Externe Datenquellen wie ServiceNow, Jira oder Confluence lassen sich über Microsoft Graph Connectors in das Substrate indexieren. Damit sind sie für Microsoft Search und Copilot auffindbar, und zwar unter denselben Berechtigungsregeln wie nativer M365-Inhalt. [3]

Auf der Ignite 2025 (November 2025) hat Microsoft mit Work IQ die Intelligenz-Schicht hinter Copilot und Agents vorgestellt. Der Ansatz weitet das Konzept aus: Daten aus E-Mails, Dateien, Meetings, Chats und perspektivisch auch Business-Systemen wie Dynamics 365 oder Power Apps fließen in ein gemeinsames Kontextmodell zusammen. Work IQ respektiert dabei wie Copilot selbst die bestehenden Berechtigungen, Sensitivity-Labels und Compliance-Kontrollen. [17]

Work IQ ist kein eigenes Produkt, sondern Teil von Microsoft 365 Copilot. Wie gut die Copilot-Antworten werden, hängt direkt davon ab, wie vollständig, aktuell und sauber berechtigt die Datenbasis im Tenant ist. Und damit daran, wie konsequent Digital Twins und Indizes im Substrate gepflegt sind.

Dual-Write und "Microsoft Substrate Management"

In den Entra-ID-Audit-Logs taucht gelegentlich eine First-Party-Enterprise-App mit dem Namen "Microsoft Substrate Management" auf (App-ID 98db8bd6-0cc0-4e67-9de5-f187f1cd1b41). Das ist ein von Microsoft betriebener Service Principal, über den Exchange Online Objektänderungen im Rahmen des sogenannten Dual-Write-Mechanismus in Entra ID schreibt. [18]

Der Hintergrund: Historisch lief die Synchronisierung zwischen Exchange-Online-Directory-Service (EXODS) und Entra ID über einen "Back-Sync"-Mechanismus, der mehrere Minuten oder länger dauern konnte. Mit Dual-Write werden bestimmte Änderungen sofort in EXODS und Entra ID geschrieben: [18]

Once this improvement is deployed to your tenant, when you make user object changes in Exchange the changes will now be dual-written to AAD and EXO. The end result is that the replication of those properties should be close to immediate and changes made in EXO will immediately reflect in AAD when the cmdlet completes successfully. [18]

Zwei praktische Folgen:

Bricht eine Exchange-Online-Verwaltungsoperation mit einem Fehler ab, der auf "Azure Active Directory" bzw. Entra ID verweist, steckt oft der Dual-Write-Pfad dahinter. Microsoft empfiehlt in solchen Fällen, das Cmdlet einfach erneut auszuführen. [18]
In Audit-Logs erscheinen Entra-ID-Änderungen, die per Dual-Write eingetragen wurden, mit dem Service Principal "Microsoft Substrate Management" als Akteur. Das erschwert die Rückverfolgung, wer oder welches Cmdlet den Vorgang tatsächlich angestoßen hat. Den ursprünglichen Auslöser findet man dann auf Exchange-Online-Seite im Unified Audit Log. [18]

Praktische Implikationen für Administratoren

Das Substrate ist eine Infrastrukturkomponente ohne eigenes Admin-Portal. Trotzdem gibt es ein paar Effekte, die Administratoren kennen sollten:

Backup-Strategien: Ein Exchange-Online-Postfach enthält deutlich mehr als den IPM-Teilbaum. Drittanbieter-Backup-Tools, die nur den IPM-Teilbaum sichern, sehen Substrate-Ordner und Compliance-Records nicht. Umgekehrt gilt: Compliance-Records sind auch keine 1:1-Restore-Quelle für die Ursprungs-App. Wer einen Teams-Chat wirklich zurückspielen will, kommt an der Teams Export API nicht vorbei.
Quota-Verhalten: Substrate-bezogene Systemordner zählen nicht gegen das sichtbare Mailbox-Quota, da sind sie aber trotzdem. Der Recoverable-Items-Container hat ein eigenes Quota (Hard Limit: 100 GB unter Hold, 105 GB mit zusätzlich aktivem Archiv), das unter Holds schneller an die Grenzen kommt, als viele denken.
Tool-Zugriff: Für tiefere Analysen greift man zu MFCMAPI, EWSEditor oder PowerShell (Get-EXOMailboxFolderStatistics, Get-MailboxFolderStatistics mit -IncludeAnalysis). Schreibende Eingriffe in den Non-IPM-Teilbaum sind nicht supportet.
Dual-Write-Debugging: Nicht jede Fehlermeldung mit "Azure Active Directory" im Text ist ein Entra-ID-Problem. Der Dual-Write-Pfad ist ein häufiger, aber nicht immer offensichtlicher Verdächtiger.
Multi-Geo und Data Residency: In Multi-Geo-Tenants folgt der Substrate-Primärspeicher der jeweiligen Mailbox-Geo-Zuweisung. Microsoft synchronisiert die PreferredDataLocation aus Entra ID in die MailboxRegion im Exchange-Online-Directory-Service. Sie bestimmt, in welcher Geografie Primär- und Archivpostfach und damit die darin liegenden Substrate-Daten physisch liegen. Primär- und Archivpostfach müssen in derselben Geografie stehen. Der Tenant-Level-Semantic-Index folgt aber der SharePoint-Home-Location. Für EU-Data-Boundary-Szenarien heißt das: Mailbox-Geo, SPO-Home und Copilot-Verarbeitung müssen konsistent konfiguriert sein. Wer das ignoriert, landet schnell in schwer zu diagnostizierenden Residency-Problemen. [23]

Ausblick

Das Substrate entstand aus dem Bedarf, aus einer lose gekoppelten Sammlung cloudifizierter Produkte eine kohärente Plattform zu machen. Mit Microsoft 365 Copilot und den Bausteinen der Ignite 2025, Work IQ, Agent 365 und den Frontier-Firm-Szenarien, steigt die Abhängigkeit der KI-Funktionen von einer gut gepflegten Datenbasis im Substrate weiter. Wer seine M365-Umgebung heute schon sauber strukturiert, bezahlt morgen weniger Lehrgeld. [19]