Microsoft Exchange: Produktfamilie und Betriebsmodelle

Der Name Microsoft Exchange bezeichnet heute zwei eng verwandte, aber unterschiedlich betriebene Plattformen. Bei Exchange Online betreibt Microsoft die Server, Datenbankkopien und interne Transportinfrastruktur. Bei Exchange Server liegen Hosts, Active Directory, Datenbanken, Queues, Zertifikate und Wiederherstellung in der eigenen Verantwortung. Exchange Hybrid verbindet beide Organisationen, wenn Postfächer oder Funktionen auf beide Seiten verteilt sind (Microsoft Learn: Exchange, Exchange hybrid deployments).

Diese Unterscheidung ist der Ausgangspunkt für jede weitere Frage. Ein Postfach kann in der Cloud oder im eigenen Rechenzentrum liegen. Der sichtbare Absender, die SMTP-Domain und das Adressbuch können trotzdem gemeinsam genutzt werden. Erst wenn der Standort des Postfachs, die Herkunft seiner Empfängerattribute und der tatsächliche Nachrichtenweg feststehen, lassen sich Zustellung, Berechtigungen und Fehler sinnvoll untersuchen.

Zuerst klären: Wo liegt das Postfach?

Exchange verwaltet E-Mail, Kalender, Kontakte, Aufgaben, Adressbuchobjekte und Zugriffsrechte. Für Benutzer sieht das weitgehend gleich aus. Für Admins ändert der Standort des Postfachs dagegen fast jedes Werkzeug und jede Zuständigkeit.

Die Tabelle ist nur die Übersicht. Die vier Vertiefungen behandeln die Betriebsmodelle getrennt:

• Exchange Online erklärt Tenantobjekte, EOP, Konnektoren, Message Trace, Aufbewahrung und den Betrieb eines Clouddienstes.
• Exchange On-Premises folgt der Transport-Pipeline, ESE-Datenbanken, DAGs, Active Directory und dem Recovery im eigenen Rechenzentrum.
• Exchange Hybrid behandelt Verzeichnissynchronisation, Empfängerverwaltung, OAuth, Organisationsbeziehungen, Autodiscover und den Hybrid Configuration Wizard.
• Hybrid-Mailfluss verfolgt Nachrichten zwischen Internet, Exchange Online, lokaler Organisation und optionalem Mail-Gateway.

Gemeinsamer technischer Aufbau: Was bei allen Exchange-Varianten gleich bleibt

Nachdem der Betriebsort geklärt ist, lohnt sich der Blick auf das gemeinsame fachliche Modell. Exchange kennt Empfänger, Nachrichten, Postfächer, Transportregeln, Domains und Konnektoren. Diese Begriffe tauchen in der Cloud und auf eigenen Servern auf, auch wenn die dahinterliegenden Systeme unterschiedlich zugänglich sind (Microsoft Learn: Recipients, Mail flow and the transport pipeline).

Ein Empfänger ist zunächst ein mailfähiges Verzeichnisobjekt. Er besitzt Adressen und einen Typ, etwa Benutzerpostfach, freigegebenes Postfach, Gruppe, Kontakt oder Mailbenutzer. Das Objekt beantwortet die Frage, wer eine Adresse repräsentiert und wohin Exchange zustellen soll. Das Postfach speichert anschliessend die eigentlichen Elemente. Deshalb können ein fehlerhaftes Empfängerobjekt und ein gesundes Postfach gleichzeitig existieren, oder umgekehrt.

Auch der Nachrichtenweg folgt auf beiden Plattformen denselben groben Schritten: Exchange nimmt eine SMTP-Nachricht an, löst die Empfänger auf, wendet Transportregeln und Schutzfunktionen an, wählt das nächste Ziel und stellt entweder in ein Postfach oder an einen weiteren SMTP-Hop zu. Die genaue Implementierung unterscheidet sich. Auf eigenen Servern kann der Admin Queues und lokale Trackinglogs sehen; in Exchange Online stehen dafür Message Trace, Berichte und Service Health bereit (Exchange Server mail flow, Trace an email message in Exchange Online).

Von der Adresse zum Nachrichtenweg

Die gemeinsame SMTP-Domain führt oft zu der falschen Annahme, alle Nachrichten nähmen denselben Weg. Tatsächlich entscheidet eine Kombination aus DNS, Accepted Domains, Empfängerobjekt, Konnektoren und Regeln darüber, wo eine Nachricht als Nächstes hingeht.

Eine Accepted Domain sagt Exchange, wie eine Domain behandelt wird. Bei einer autoritativen Domain erwartet Exchange alle gültigen Empfänger im eigenen Verzeichnis. Bei einer Internal-Relay-Domain dürfen unbekannte Empfänger an ein anderes System weitergehen. Diese Einstellung ist deshalb keine Inventarzeile, sondern Teil der Zustellentscheidung (Accepted domains in Exchange Server, Accepted domains in Exchange Online).

Konnektoren bestimmen danach, von welchen Systemen Exchange Nachrichten annimmt und an welche Systeme es sie sendet. In Exchange Server arbeiten Receive und Send Connectors mit lokalen Bindungen, Adressräumen, Quellservern, Smart Hosts und Berechtigungen. Exchange Online verwendet Inbound und Outbound Connectors für Beziehungen zur eigenen Infrastruktur oder zu Partnern (Connectors on Exchange servers, Set up connectors to route mail).

Erst an dieser Stelle werden Hybridvarianten wichtig. Centralized Mail Transport, ein vorgelagertes Gateway oder eine geteilte Empfängerdomain verändern zusätzliche Hops und Zuständigkeiten. Sie gehören deshalb in den eigenen Artikel Hybrid-Mailfluss, nicht zwischen Identitäts- oder Clientthemen.

Von der Anmeldung zum Postfach

Der Nachrichtenweg erklärt noch nicht, wie Outlook sein Postfach findet. Dafür verwendet Exchange Autodiscover. Ein Client beginnt mit der Identität des Benutzers und ermittelt daraus den passenden Dienstendpunkt. Lokal können Active-Directory-Service-Connection-Points und DNS beteiligt sein; in Exchange Online führen Microsoft-365-Endpunkte zum Clouddienst (Microsoft Learn: Autodiscover).

Nach der Ermittlung des Endpunkts läuft moderner Outlook-Zugriff über HTTPS, insbesondere mit MAPI over HTTP. Outlook im Web, Exchange ActiveSync und verschiedene APIs verwenden ebenfalls HTTPS, aber jeweils eigene Anwendungsprotokolle und Berechtigungen. Eine erfolgreiche Anmeldung im Microsoft-365-Portal beweist daher nicht automatisch, dass Autodiscover, das Outlook-Protokoll oder der Zugriff auf das konkrete Postfach funktionieren (Client Access protocol architecture, MAPI over HTTP).

Im Hybridbetrieb kommt eine weitere Entscheidung hinzu: Liegt das Postfach lokal oder online? Autodiscover und die Empfängerattribute müssen den Client zur richtigen Seite führen. Erst danach spielen organisationsübergreifende Funktionen wie Frei/Gebucht oder Postfachverschiebungen eine Rolle. Diese Reihenfolge wird im Artikel Exchange Hybrid Schritt für Schritt behandelt.

Verwaltung und Berechtigungen

Sind Daten- und Zugriffswege verstanden, folgt die Frage, wer sie ändern darf. Exchange verwendet rollenbasierte Zugriffssteuerung. Rollen enthalten Cmdlets und Parameter, Rollengruppen oder Rollenzuweisungen verbinden sie mit Administratoren, und Scopes begrenzen den Bereich. Exchange Online und Exchange Server besitzen verwandte RBAC-Konzepte, aber getrennte Konfigurationen (Permissions in Exchange Server, Permissions in Exchange Online).

Für den Alltag heisst das: Eine Entra-Administratorrolle, eine Exchange-Rollengruppe und eine Postfachberechtigung sind nicht dasselbe. Full Access erlaubt das Öffnen eines Postfachs, Send As das Senden als Empfänger und Send on Behalf das erkennbare Senden im Auftrag. Keine dieser Berechtigungen erklärt allein, ob eine Anwendung über Microsoft Graph oder EWS zugreifen darf (Manage permissions for recipients in Exchange Online).

Die Expertenfrage lautet deshalb nicht «Ist der Benutzer Admin?», sondern: Welche Identität meldet sich an, welche Rolle gilt in welcher Exchange-Organisation, welches Objekt wird angesprochen und welche zusätzliche Postfach- oder Anwendungsberechtigung wird geprüft?

Betrieb und Fehlersuche beginnen mit der richtigen Seite

Eine sinnvolle Diagnose beginnt mit drei Angaben: betroffener Benutzer oder Empfänger, genauer Zeitpunkt und Standort des Postfachs. Danach wird der Pfad in der Reihenfolge DNS beziehungsweise Autodiscover, Anmeldung, Exchange-Endpunkt, Empfängerauflösung, Transportereignis und Postfachzustellung verfolgt.

Für Exchange Online liefern Message Trace und Microsoft 365 Service Health den vom Kunden sichtbaren Dienstzustand. Für Exchange Server kommen lokale Queues, Message Tracking Logs, Health Sets, Event Logs und Datenbankkopien hinzu. Im Hybridbetrieb werden die Belege beider Seiten auf einer gemeinsamen Zeitachse zusammengeführt (Message Trace FAQ, Server health and performance).

Die vertiefenden Artikel enthalten jeweils passende Windows-/Unix-Diagnoseblöcke und die offiziellen Dokumentationen der verwendeten Werkzeuge. Hier genügt die wichtigste Betriebsregel: Erst den Ort und den Weg bestimmen, dann das Werkzeug wählen.

Datenhaltung, Verfügbarkeit und Wiederherstellung

Der Unterschied zwischen Cloud und Eigenbetrieb wird bei Recovery am deutlichsten. Exchange Server speichert Postfächer in ESE-Datenbanken mit Transaktionslogs. Database Availability Groups replizieren Datenbankkopien und ermöglichen Aktivierungen auf anderen Servern. Die Organisation bleibt dennoch für Backupstrategie, Wiederherstellbarkeit und die Active-Directory-Abhängigkeit verantwortlich (Database availability groups, Backup, restore and disaster recovery).

Exchange Online betreibt Datenbank- und Transportredundanz als Teil des Dienstes. Tenant-Admins arbeiten stattdessen mit gelöschten Elementen, Single Item Recovery, Aufbewahrung, Holds und gegebenenfalls externen Sicherungsanforderungen. Microsofts Dienstresilienz und eine fachliche Aufbewahrungsregel beantworten unterschiedliche Fragen: Die eine schützt den laufenden Dienst, die andere bestimmt, welche Inhalte nach Löschung oder für Compliancezwecke erhalten bleiben (Exchange Online data resiliency, Retention policies for Exchange).

Im Hybridbetrieb müssen beide Recoverymodelle nebeneinander dokumentiert werden. Zusätzlich sind Verzeichnissynchronisation, Zertifikate, OAuth-Konfiguration und Konnektoren nötig, um die Verbindung nach einem Ausfall wiederherzustellen. Diese Konfigurationen enthalten zwar keine Mailboxinhalte, entscheiden aber darüber, ob die zwei Exchange-Organisationen wieder zusammenarbeiten.

Technische Entwicklung

Exchange 4.0 erschien 1996 als Nachfolger früherer Microsoft-Mailplattformen. Die ersten Versionen verwendeten ein eigenes Verzeichnis, MAPI und die ESE-Datenbankfamilie; Internetprotokolle wurden schrittweise wichtiger. Mit Exchange 2000 wurden Active Directory und SMTP zu zentralen Bausteinen. Exchange 2007 führte ausgeprägte Serverrollen und die Exchange Management Shell ein, Exchange 2010 die Database Availability Group (Exchange Team: A brief history of time, Exchange Team: Exchange Server 2007 transport redesign).

Parallel entwickelte Microsoft gehostete Exchange-Angebote zu Exchange Online. Dadurch entstand Hybrid nicht als einzelnes Produkt, sondern als Verbindung zweier eigenständiger Exchange-Organisationen. Exchange Server Subscription Edition führte diese lokale Entwicklungslinie ab 2025 im Modern Lifecycle fort. Konkrete Build- und Updateangaben werden vor Änderungen in der laufend gepflegten Microsoft-Dokumentation geprüft (Exchange Server SE release notes, Exchange Server Subscription Edition lifecycle).