Welche Exchange-Online- und Microsoft-365-Lizenz brauche ich für Archiv, Retention, Litigation Hold und Defender-Funktionen?

Pläne und Lizenzlogik: Exchange Online (Plan 1/2), Microsoft 365 Business und Enterprise (E3/E5) plus typische Add-ons und Abhängigkeiten

Bei Exchange- und Microsoft-365-Plänen überlagern sich drei Ebenen: (1) die reine Messaging-Workload (Exchange Online Plan 1/2), (2) Suite-Pläne, die Exchange Online als Bestandteil enthalten (z. B. Microsoft 365 Business Standard/Premium, Office 365 E3/E5, Microsoft 365 E3/E5) und (3) Add-ons, die Funktionen nachziehen, die in der Basislizenz nicht oder nur eingeschränkt verfügbar sind (z. B. Exchange Online Archiving, Microsoft Purview Add-ons, Microsoft Defender Add-ons). Für eine belastbare Feature-Matrix ist daher entscheidend, welche SKU die Funktion technisch bereitstellt und welche Abhängigkeiten (z. B. Entra ID P1/P2, Defender-Plan, Purview-Plan) bestehen.

Exchange Online als Workload: Plan 1 vs. Plan 2 (und was „in der Suite“ bedeutet)

Exchange Online (Plan 1) und (Plan 2) lizenzieren primär die Postfachfunktionalität in Exchange Online. Suite-Pläne enthalten faktisch eine Exchange-Online-Entsprechung: Viele Business- und Enterprise-SKUs beinhalten Exchange Online Plan 1; einige Enterprise-Pläne enthalten Exchange Online Plan 2 (z. B. Office 365 E5, Microsoft 365 E5) oder kombinieren Exchange Online Plan 1 mit separaten Security/Compliance-Bausteinen, die in der Matrix getrennt betrachtet werden müssen. Für die Bewertung gilt: Postfach- und Transportfunktionen hängen an Exchange Online; Identitäts-, Geräte- und Compliance-Funktionen werden oft über andere Produktfamilien lizenziert, obwohl sie im Alltag „wie Mail-Funktionen“ wirken (z. B. Conditional Access, DLP, eDiscovery).

Plan 2 ist typischerweise relevant, wenn erweiterte Archivierung/Compliance-Funktionen oder höhere Grenzwerte gebraucht werden. Ob eine Suite diese Fähigkeiten wirklich abdeckt, hängt vom exakten Plan ab (Office 365 vs. Microsoft 365, E3 vs. E5, Business Premium vs. Business Standard) und zusätzlich davon, ob Microsoft Purview oder Defender als eigenständige Lizenzbestandteile enthalten sind.

Business vs. Enterprise: Segmentgrenzen, Service-Limits und Plan-Mischung

Business-Pläne adressieren Organisationen bis zu den jeweiligen Seat-Grenzen der Business-Suite-Familie. Diese Grenze ist keine technische Exchange-Online-Grenze, sondern eine kommerzielle Eligibility-Regel. In Umgebungen mit Wachstum oder mit Bedarf an Enterprise-Compliance (z. B. erweiterte eDiscovery-Workflows, Kommunikations-Compliance, Information Barriers) führt das häufig zu einer Mischlizenzierung: Ein Teil der Benutzer bleibt auf Business, während Rollen mit erweiterten Anforderungen auf Enterprise oder Add-ons wechseln.

Für die Matrix ist außerdem relevant, dass einige „Grenzwerte“ nicht lizenziert, sondern serviceweit sind (z. B. bestimmte Transport- oder Protokolllimits), während andere klar an SKU-Funktionen gekoppelt sind (z. B. Archivpostfach, bestimmte Compliance-Workloads). Entscheidend ist die Trennung zwischen mandantenweiten Konfigurationen und nutzerbezogenen Rechten: Manche Features lassen sich im Tenant konfigurieren, wirken aber nur für lizenzierte Benutzer oder lizenzierte Postfächer.

• Eligibility vs. Technik: Business-Suite-Seat-Grenzen sind kommerziell; Exchange Online selbst arbeitet im gleichen Dienst, aber die Lizenzzuteilung steuert, welche Funktionen pro Benutzer aktiv werden.
• Tenantweite Policies, nutzerbezogene Wirkung: Retention/DLP/eDiscovery werden im Purview-Portal zentral konfiguriert, greifen aber nur dort vollständig, wo die passende Lizenz vorliegt (z. B. für erweiterte eDiscovery-Fälle).
• Protokollzugriff als Policy-Thema: Authentifizierungs- und Clientzugriffe werden häufig über Conditional Access und Auth-Policies gesteuert; dafür ist je nach Szenario Microsoft Entra ID P1 (oder höher) der relevante Lizenzanker, nicht Exchange Online.
• Shared Mailboxes: Kostenlos im Sinne von „ohne eigene Benutzerlizenz“ sind Shared Mailboxes nur innerhalb der veröffentlichten Größen- und Nutzungsvoraussetzungen; bei Überschreitung oder bei aktivierten Archiv-/Hold-Szenarien entsteht schnell Lizenzbedarf (Exchange Online oder Archiv/Compliance-Add-on).

Typische Add-ons: Archiv, Purview-Compliance, Defender und Entra-Abhängigkeiten

Add-ons werden in der Praxis selten wegen „noch einer App“ gekauft, sondern wegen eines konkreten Feature-Bausteins: Archivpostfach für ansonsten zu große Shared Mailboxes, erweiterte Aufbewahrung und eDiscovery, oder höherwertige Schutzfunktionen im Mail-Flow und am Postfach. Für eine saubere Vergleichstabelle empfiehlt sich, Add-ons als eigene Spalten zu führen und zusätzlich eine Spalte „Voraussetzung“ zu pflegen, weil viele Funktionen ein Zusammenspiel aus Exchange Online, Purview und Defender sind.

Für Security ist die Unterscheidung zwischen „EOP“ (Baseline-Filter in Exchange Online) und „Defender for Office 365“ (Plan 1/Plan 2) zentral. Für Compliance ist die Unterscheidung zwischen Standardfunktionen (z. B. Basis-Retention und Core-eDiscovery) und erweiterten Workloads (z. B. Advanced eDiscovery, Insider Risk, Kommunikations-Compliance) zentral, die typischerweise E5 oder entsprechende Add-ons erfordern. Identität und Geräteverwaltung hängen wiederum häufig an Entra ID und Intune (häufig in Business Premium bzw. in Enterprise-Suites enthalten, ansonsten Add-on).

Lizenzzuweisung, Servicepläne und Prüfpfade für die technische Verifikation

Lizenzentscheidungen werden operativ erst dann belastbar, wenn die aktivierten Servicepläne je Benutzer geprüft sind. In Microsoft 365 kann eine Suite zwar „E5“ heißen, einzelne Servicepläne lassen sich aber deaktivieren oder fehlen in bestimmten Bundles. Für die Feature-Matrix ist daher sinnvoll, neben der SKU auch den jeweiligen Serviceplan-Status und gegebenenfalls die resultierende Funktion im Ziel-Portal zu verifizieren.

• Benutzerlizenz und Servicepläne prüfen (Graph): GET https://graph.microsoft.com/v1.0/users/{id}?$select=assignedLicenses,assignedPlans
• Lizenz-SKUs im Tenant auflisten (Graph): GET https://graph.microsoft.com/v1.0/subscribedSkus
• Exchange Online Features verifizieren (PowerShell): Get-EXOMailbox -Identity user@domain.tld | Select DisplayName,RecipientTypeDetails,ArchiveStatus,RecoverableItemsQuota
Get-Mailbox -Identity user@domain.tld | Select LitigationHoldEnabled,InPlaceHolds,RetentionPolicy
• Protokoll-/Auth-Realität statt Lizenzannahmen: Clientzugriffe und Legacy-Auth hängen häufig an Tenant-Settings und Policies; technische Prüfpunkte sind z. B. Get-AuthenticationPolicy und Get-OrganizationConfig (wo anwendbar), nicht der Produktname auf der Rechnung.

Damit die spätere Funktionsmatrix auf Feature-Ebene konsistent bleibt, sollte jedes Feature einer dieser Kategorien zugeordnet werden: „Exchange-Workload“ (postfachnah), „Security“ (EOP/Defender), „Compliance“ (Purview), „Identity/Device“ (Entra/Intune) oder „Hybrid/Verwaltung“ (z. B. Koexistenz, Verwaltungsoberflächen, API-/PowerShell-Zugriff). Erst diese Zuordnung verhindert, dass Suite-Namen als Proxy für Fähigkeiten missverstanden werden, obwohl die technische Freischaltung über einen anderen Lizenzbaustein erfolgt.

Mailbox-, Archiv- und Aufbewahrungsfunktionen: Postfachgrößen, Onlinearchiv, Auto-Expanding Archive, Retention/MLM, Litigation Hold, Shared Mailbox und Grenzwerte

Mailbox- und Aufbewahrungsfunktionen wirken auf den ersten Blick wie einfache Größenangaben. In der Praxis entscheiden jedoch Lizenzgrenzen, Rollout-Optionen und „gated features“ (z. B. Auto-Expanding Archive oder Microsoft Purview-Funktionen) darüber, ob ein Szenario technisch sauber, prüfbar und dauerhaft betreibbar ist. Für eine belastbare Vergleichsmatrix müssen deshalb Postfach- und Archivlimits, Aufbewahrungsmechaniken (MRM vs. Purview Retention), eDiscovery-Haltefunktionen sowie Shared-Mailbox-Regeln gemeinsam betrachtet werden.

Primäres Postfach: Größen, Limits und praktische Auswirkungen

In Exchange Online wird die nutzbare Kapazität des Primärpostfachs primär durch den Lizenzplan bestimmt. Typische Pläne liegen bei 50 GB (z. B. Exchange Online Plan 1 sowie Microsoft 365 Business Basic/Standard) oder 100 GB (z. B. Exchange Online Plan 2 sowie Office 365 E5 und Microsoft 365 E5). In vielen E3-Suiten ist Exchange Online Plan 2 nicht enthalten; dort bleibt das Primärpostfach typischerweise bei 50 GB, auch wenn zusätzliche Compliance-Bausteine separat lizenziert sein können. Zusätzlich existieren technische Obergrenzen für einzelne Elemente (Item Size), Ordnerhierarchien und die Gesamtzahl von Elementen, die unabhängig von der reinen GB-Angabe zu Betriebsproblemen führen können (z. B. Clientsynchronisation, Suchindizierung, Migrationen).

Wichtig ist die Trennung zwischen „Quota“ (Warn-/Send-/Send&Receive-Limits) und der faktischen Datenhaltung: Wird das Sende- oder Empfangslimit erreicht, blockiert dies Messaging-Flüsse, selbst wenn Archivierung oder Retention korrekt konfiguriert sind. In Hybrid- oder Migrationsszenarien beeinflussen Postfachgrößen außerdem die Dauer von Moves und die Fehleranfälligkeit bei großen Elementen; dies ist weniger eine Lizenzfrage als ein operatives Risiko, das sich durch Richtlinien (z. B. Attachment-Handling, Auto-Archive-Strategie) reduzieren lässt.

Onlinearchiv und Auto-Expanding Archive: Voraussetzungen und typische Stolperstellen

Das Exchange-Onlinearchiv ist ein eigenes Postfach (Archive Mailbox) und wird entweder über den Plan bereitgestellt oder über ein Add-on lizenziert. Es ist für langfristige Aufbewahrung und zur Entlastung des Primärpostfachs gedacht, ersetzt aber keine Compliance-Strategie. Auto-Expanding Archive erweitert das Archiv in Stufen, sobald Schwellenwerte erreicht werden. Diese Funktion ist lizenz- und tenantabhängig, setzt eine korrekte Archivaktivierung voraus und entfaltet ihren Nutzen erst, wenn Archivierung tatsächlich in Richtlinien abgebildet ist (z. B. Exchange MRM oder Purview Retention mit „Move to Archive“, sofern im jeweiligen Retention-Szenario genutzt).

In der Praxis scheitern Archivkonzepte häufig an inkonsistenter Policy-Logik: Wird etwa nur eine kurze MRM-Policy konfiguriert, entstehen zwar Verschiebungen ins Archiv, jedoch keine echte Aufbewahrungsgarantie. Umgekehrt kann eine reine Purview-Retention ohne Archivierungsstrategie große Primärpostfächer stabil „vollhalten“, weil Retention die Löschung verhindert. Für den Vergleich der Pläne ist deshalb nicht nur „Archiv vorhanden“, sondern auch „welche Retention-/Hold-Funktionen sind lizenziert“ entscheidend.

• Archivpostfach aktivieren (Beispiel): Enable-Mailbox -Identity user@domain.tld -Archive
• Archivstatus prüfen: Get-Mailbox -Identity user@domain.tld | Select DisplayName,ArchiveStatus,ArchiveQuota,ArchiveWarningQuota
• Auto-Expanding Archive Indikator prüfen (tenant-/mailboxabhängig): Get-OrganizationConfig | Select AutoExpandingArchiveEnabled
Get-Mailbox -Identity user@domain.tld | Select AutoExpandingArchiveEnabled

Retention: MRM in Exchange vs. Microsoft Purview Retention (Labels/Policies)

Exchange MRM (Messaging Records Management) arbeitet mit Retention Tags und Retention Policies, die auf Mailbox-/Folder-Ebene wirken und durch den Managed Folder Assistant abgearbeitet werden. MRM kann Elemente löschen oder ins Archiv verschieben, ist aber in seiner Governance-Reichweite im Kern auf Exchange begrenzt. Microsoft Purview Retention (früher „Microsoft 365 Retention“) setzt dagegen an der Compliance-Schicht an und kann je nach Lizenzstand mehrere Workloads abdecken; es liefert außerdem ein anderes Reporting- und Audit-Verständnis als reine Mailbox-Policies.

Für die Feature-Matrix ist relevant, ob ein Plan lediglich MRM erlaubt (häufig breit verfügbar) oder zusätzlich Purview-Retention mit Labels, automatischer Klassifizierung oder erweiterten Aufbewahrungsoptionen. Ebenso zählt, ob Aufbewahrung „nur“ zur Löschverhinderung (Retention) dient oder ob spezielle Haltefunktionen für Ermittlungen und Rechtsstreitigkeiten erforderlich sind. In Exchange-Umgebungen mit strikter Hold-Pflicht zeigt sich der Unterschied in Recoverable-Items-Wachstum, Suchbarkeit und der Fähigkeit, Richtlinien revisionssicher nachzuweisen.

• MRM-Policy-Zuordnung prüfen: Get-Mailbox -Identity user@domain.tld | Select RetentionPolicy
• Retention Tags/Policies auflisten (MRM): Get-RetentionPolicy
Get-RetentionPolicyTag
• Managed Folder Assistant gezielt anstoßen (MRM): Start-ManagedFolderAssistant -Identity user@domain.tld

Litigation Hold: Wirkung, Grenzen und Betriebsfolgen

Litigation Hold ist eine Exchange-Funktion, die gelöschte oder veränderte Inhalte in den „Recoverable Items“-Bereichen bewahrt und damit ein konsistentes eDiscovery-Fundament schafft. Die Verfügbarkeit hängt typischerweise an Exchange Online Plan 2 beziehungsweise den entsprechenden Enterprise-Suiten. Technisch führt Litigation Hold nicht zu einer „Verschlüsselung“ oder „Archivierung“, sondern zu einer Nichtlöschbarkeit bestimmter Inhalte innerhalb des Postfachs. Dadurch können Postfächer auch bei strikter Löschpolicy wachsen, wenn Nutzer hohe Änderungsraten haben (Versionierung/Hard Deletes).

Für Grenzwerte sind vor allem die Quoten für Recoverable Items relevant. In großen, lange gehaltenen Postfächern entstehen Risiken bei Moves, bei der Suchindizierung und bei der Performance von eDiscovery-Abfragen. Zudem ist „Hold“ funktional zu trennen von Purview Retention oder eDiscovery (Standard/Premium). Ein Planvergleich sollte deshalb mindestens ausweisen: Lizenzvoraussetzung für Litigation Hold, ob eine zeitliche Begrenzung gesetzt werden kann (LitigationHoldDuration ist optional), und ob zusätzliche eDiscovery-Funktionen für die Bearbeitung (Review/Analytics) separat lizenziert werden müssen.

• Hold-Status und Dauer prüfen: Get-Mailbox -Identity user@domain.tld | Select LitigationHoldEnabled,LitigationHoldDuration,InPlaceHolds
• Litigation Hold setzen (Beispiel): Set-Mailbox -Identity user@domain.tld -LitigationHoldEnabled $true
• Recoverable-Items-Quoten prüfen: Get-Mailbox -Identity user@domain.tld | Select RecoverableItemsQuota,RecoverableItemsWarningQuota

Shared Mailbox: Lizenzfreiheit, Größenregeln und Zugriffsgrenzen

Shared Mailboxes sind in Exchange Online grundsätzlich ohne eigene Benutzerlizenz betreibbar, sofern sie innerhalb der von Microsoft definierten Bedingungen bleiben. Zentral ist die Größenregel: Bis 50 GB ist eine Shared Mailbox typischerweise ohne Lizenz möglich; für darüber hinausgehende Kapazität oder für ein Onlinearchiv ist in der Regel eine Exchange-Online-Plan-2- oder äquivalente Lizenzzuweisung erforderlich. Diese Zuweisung ist technisch ein Mailbox-Lizenz-Enablement und sollte in der Matrix explizit als „Shared Mailbox benötigt Lizenz ab X“ ausgewiesen werden, weil sonst Kosten- und Betriebskalkulationen auseinanderlaufen.

Für Zugriffe gilt: Eine Shared Mailbox eignet sich für delegierten Zugriff (Full Access/Send As/Send on Behalf). Sie ist nicht als Sammelkonto für viele gleichzeitige interaktive Logins gedacht; direkte Anmeldungen mit deaktivierten Kennwort-/MFA-Controls erzeugen typische Sicherheits- und Auditprobleme. Technisch prägen außerdem Client- und Synchronisationslimits (z. B. Outlook-Caching, Suchindex) das Nutzungsmodell stärker als die reine Postfachgröße. In Aufbewahrungsszenarien ist zu berücksichtigen, dass Shared Mailboxes genauso Retention/Hold unterliegen können wie Benutzerpostfächer, aber die Lizenzvoraussetzungen für bestimmte Compliance-Funktionen dennoch am Benutzer oder an der Mailbox-Lizenz hängen können.

• Shared Mailbox identifizieren und Quoten prüfen: Get-Mailbox -Identity shared@domain.tld | Select RecipientTypeDetails,ProhibitSendQuota,ArchiveStatus
• Delegierte Rechte prüfen (Beispiele): Get-MailboxPermission -Identity shared@domain.tld
Get-RecipientPermission -Identity shared@domain.tld
• Send-As setzen (Beispiel): Add-RecipientPermission -Identity shared@domain.tld -Trustee user@domain.tld -AccessRights SendAs

Sicherheit, Verwaltung und Betrieb: Defender-Funktionsstufen, MDM/Intune-Umfang, Authentifizierung und Protokolle, API-Zugriff, Auditing, Compliance-Optionen und Hybridfähigkeit

Defender für Office 365 und EOP: Schutzschichten und typische Lizenzgrenzen

Im Exchange-Online-Betrieb entsteht der Basisschutz in der Regel aus Exchange Online Protection (EOP): Anti-Spam- und Anti-Malware-Filterung, Verbindungs- und Richtlinienlogik sowie Quarantäne-Workflows. Darüber liegt Microsoft Defender for Office 365 (MDO) als zusätzliche Schicht mit erweiterten Detektions- und Response-Funktionen wie Safe Links, Safe Attachments und (je nach Plan) automatisierter Untersuchung und Reaktion (AIR). In der Funktionsmatrix sollten diese Ebenen strikt getrennt werden, weil EOP teils in Suite-Plänen „mitläuft“, während MDO häufig erst in höherwertigen Sicherheits- oder Compliance-Bundles bzw. als Add-on verfügbar ist.

Technisch relevant sind weniger Marketingnamen als konkrete Kontrollpunkte: Welche Richtlinientypen lassen sich im Tenant tatsächlich anlegen, welche Ereignisse erscheinen im Explorer/Threat Explorer, und ob eine Automatisierung (z. B. AIR) Ereignisse auch aktiv bereinigt oder nur meldet. Zusätzlich beeinflussen Lizenzzuweisungen die Sichtbarkeit und den Umfang in Security-Reports; ein Tenant kann beispielsweise Richtlinien besitzen, ohne dass für alle Benutzer die zugehörigen Schutzfunktionen wirksam werden.

• Nachweis der Schutzschicht (Mailflow): Header-Auswertung über Get-MessageTrace -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date) und ergänzend Quarantäne/Policies in https://security.microsoft.com (Bereiche „Email & collaboration“).
• Safe Attachments / Safe Links (MDO): Richtlinienobjekte und Status typischerweise über Get-SafeAttachmentPolicy
Get-SafeLinksPolicy prüfen; Abhängigkeit von MDO-Lizenzstufe und aktivem Policy-Assignment beachten.
• Automatisierte Untersuchung und Reaktion (AIR): Konfiguration und ausgelöste Aktionen werden in MDO-Workloads geführt; operative Kontrolle erfolgt in https://security.microsoft.com (Investigations/Actions), nicht in Exchange-Cmdlets.

MDM und Gerätemanagement: Intune-Umfang, „Basic Mobility“, App-Schutz und Conditional Access

Für E-Mail-Sicherheit im engeren Sinn ist MDM kein Muss, für Betriebs- und Governance-Anforderungen jedoch häufig entscheidend: Gerätekonformität, Zugriffskontrolle und Durchsetzung von Baselines hängen stark vom enthaltenen Intune-Plan sowie von Entra ID (Azure AD) Premium-Features ab. In vielen Lizenzkombinationen existieren drei klar zu unterscheidende Ebenen: (1) Exchange ActiveSync-Richtlinien (nur für E-Mail), (2) „Basic Mobility and Security“ (historisch in einigen M365-Suiten, funktionsarm gegenüber Intune) und (3) Microsoft Intune Plan 1/2 mit Compliance Policies, Konfigurationsprofilen, Update-Ringen und (je nach Paket) erweiterten Endpoint-Features.

App-Schutzrichtlinien (MAM) für Outlook auf iOS/Android sind in der Praxis besonders lizenzsensitiv, weil sie oft an Intune (bzw. Intune App Protection) und in vielen Szenarien zusätzlich an Conditional Access gekoppelt sind. Für die Matrix ist deshalb wichtig, die Kombinationen aus „Gerät muss compliant sein“, „nur verwaltete Apps“ und „Token-Claims/Auflagen“ getrennt zu erfassen.

Authentifizierung, Protokolle und Legacy-Zugriffe: Modern Auth, OAuth, SMTP AUTH, IMAP/POP/EWS

Der Betriebszustand von Exchange Online hängt stark davon ab, welche Protokolle zugelassen sind und über welche Authentifizierungsarten sie laufen. Modern Authentication (OAuth 2.0) ist Standard; verbleibende Basic-Auth-Pfade sind heute primär als Risikofaktor zu behandeln. Gleichzeitig existieren weiterhin legitime Spezialfälle: SMTP AUTH für Geräte/Applikationen, IMAP (OAuth) für bestimmte Workflows oder EWS/Graph für Integrationen. Für die Feature-Matrix ist weniger entscheidend, ob ein Protokoll „existiert“, sondern ob es tenantweit bzw. benutzerbezogen blockiert werden kann, wie fein Ausnahmen definierbar sind und ob Audit/Sign-in-Daten ausreichend korreliert werden können.

• SMTP AUTH gezielt steuern: tenantweit über Set-TransportConfig -SmtpClientAuthenticationDisabled $true, benutzerspezifisch über Set-CASMailbox -Identity user@domain.tld -SmtpClientAuthenticationDisabled $false (Ausnahmen nur bewusst und dokumentiert).
• IMAP/POP/EWS für Postfächer abschalten: pro Benutzer über Set-CASMailbox -Identity user@domain.tld -ImapEnabled $false -PopEnabled $false -EwsEnabled $false; Ergänzung durch Conditional Access, wenn Token- und App-Kontext berücksichtigt werden muss.
• Authentication Policies (Basic Auth-Block je Protokoll): Zuweisung über Set-User -Identity user@domain.tld -AuthenticationPolicy "Block Basic Auth"; konkrete Wirkung hängt vom Protokoll und Client-Verhalten ab.

API-Zugriff und Integrationen: Graph, EWS, Application Access Policies und Dienstkonten

Bei Integrationen entsteht häufig die eigentliche Lizenz- und Risikoentscheidung: Graph-Zugriffe sind in Microsoft 365 strategisch gesetzt, EWS ist in Exchange Online weiterhin präsent, jedoch nicht mehr der bevorzugte Integrationspfad. Entscheidend ist, ob eine Lösung als Delegated Permission (Benutzer-Kontext) oder als Application Permission (App-only) arbeitet. App-only-Zugriffe erfordern besonders strikte Begrenzung des Datenradius, da Berechtigungen wie „Mail.Read“ im App-Kontext grundsätzlich tenantweit wirken können.

Zur Einschränkung app-only Mailbox-Zugriffe dient in Exchange Online die Application Access Policy. Sie verknüpft eine App-Registrierung (Service Principal) mit einem definierten Mailbox-Scope (z. B. Sicherheitsgruppe). Für die Matrix ist relevant, dass diese Steuerung unabhängig von MDO/Compliance-Funktionen wirkt, aber operativ Disziplin in der App- und Gruppenpflege verlangt. Zusätzlich sollte erfasst werden, ob ein Plan erweiterte Protokollierung/Audit-Tiefen bietet, weil API-Zugriffe sonst schwer nachweisbar bleiben.

• App-only-Zugriff auf definierte Postfächer begrenzen: New-ApplicationAccessPolicy -AppId <GUID> -PolicyScopeGroupId <group@domain.tld> -AccessRight RestrictAccess -Description "Scope for App"
• Wirkung testen (Exchange Online): Test-ApplicationAccessPolicy -Identity user@domain.tld -AppId <GUID> (liefert „AccessCheckResult“, wichtig für Change- und Audit-Nachweise).
• Servicekonten und Basic-Auth-Fallen vermeiden: Für Integrationen bevorzugt OAuth/Certificate Credentials; Kennwort-basierte Logins erhöhen das Risiko und erschweren Conditional Access.

Auditing, eDiscovery, Records/Retention und Kommunikations-Compliance: Planabhängigkeiten sauber trennen

Audit- und Compliance-Features sind in Microsoft 365 über mehrere Portale und Lizenzpakete verteilt. Für Exchange-Workloads betrifft das vor allem Unified Audit Log (Purview Audit), Mailbox Audit Events, eDiscovery (Standard/Premium), Retention/Records Management sowie Kommunikations- und Insider-Features. In einer vergleichenden Matrix sollten mindestens drei Dimensionen getrennt werden: (1) ob ein Ereignis überhaupt geloggt wird, (2) wie lange und in welcher Tiefe es aufbewahrt/auswertbar ist, (3) ob darauf basierende Workflows (Hold, Case Management, Review Sets, Advanced eDiscovery-Analytik) verfügbar sind.

Die operative Prüfung erfolgt über Purview und PowerShell: Audit-Suche, Hold-Status, sowie Retention-Konfigurationen sind zwar funktional verknüpft, aber administrativ unterschiedliche Objekte. Besonders kritisch ist die Frage, ob ein Plan „Advanced Audit“ (erweiterte Ereignisabdeckung und längere Audit-Aufbewahrung) ermöglicht; ohne diese Stufe bleiben forensische Zeitfenster kürzer. Für eDiscovery ist außerdem zu erfassen, ob nur Core-eDiscovery (Standard) bereitsteht oder ob Premium-Funktionen wie Review Sets, Analytics und Custodian-Workflows genutzt werden dürfen.

• Unified Audit Log abfragen (Purview/Compliance PowerShell): Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) -RecordType ExchangeItem (Abdeckung/Retention abhängig von Audit-Stufe und Lizenz).
• Mailbox-Auditing prüfen: Get-OrganizationConfig | Select AuditDisabled
Get-Mailbox -ResultSize Unlimited | Select UserPrincipalName,AuditEnabled (Mailbox Audit ist in Exchange Online grundsätzlich verfügbar, Detailtiefe und Audit-Aufbewahrung sind jedoch nicht identisch mit Purview Audit/Advanced Audit).
• Hold-Status im Betrieb verifizieren: Get-Mailbox -Identity user@domain.tld | Select LitigationHoldEnabled,InPlaceHolds,RetentionHoldEnabled (rechtliche/organisatorische Vorgaben getrennt von technischer Aktivierung dokumentieren).

Hybridfähigkeit und Betriebsmodelle: Exchange Hybrid, Identity, Clientzugriff und Compliance-Grenzen

Hybridfähigkeit umfasst mehr als „Mailboxen können verteilt sein“. Technisch zählen dazu mindestens: Identität (synchronisiert vs. cloud-only), Authentifizierung (Pass-through, Seamless SSO, Federation), Mailflow (MX, Centralized Mail Transport), Free/Busy- und Autodiscover-Verhalten, sowie Koexistenzpfade für eDiscovery und Aufbewahrung. Lizenzentscheidungen spielen indirekt hinein, weil bestimmte Compliance- oder Security-Features in der Cloud ihre volle Wirkung erst entfalten, wenn Daten und Identitäten konsistent verwaltet werden.

Für die Matrix ist sinnvoll, Hybrid als Fähigkeitspaket zu behandeln: ob der Plan den Betrieb von Exchange Online in Kombination mit Exchange Server (für Recipient Management, Koexistenz und Routing) unterstützt, ob moderne Authentifizierung im Hybrid-Szenario (z. B. OAuth zwischen Exchange Server und Exchange Online) technisch umsetzbar ist, und welche Features im „Split“-Betrieb funktional brechen (z. B. Policies, die nur auf Cloud-Mailboxen greifen). Die konkrete Ausgestaltung hängt weniger vom Lizenznamen ab als von Architektur- und Konfigurationszustand; dennoch können Audit-/Compliance-Bausteine in höherwertigen Plänen die Governance in Hybridumgebungen erst praktikabel machen, weil Nachweis- und Suchfunktionen zentralisiert werden.