Exchange On-Premises: Serverarchitektur und Betrieb

Exchange On-Premises bedeutet, dass die Organisation Exchange Server in der eigenen Infrastruktur betreibt. Sie kontrolliert Windows-Hosts, Active Directory, Zertifikate, Transportdienste, Queues, Mailboxdatenbanken und Wiederherstellung. Microsoft liefert Produktcode, Dokumentation und Updates; Verfügbarkeit und sichere Wartung bleiben Aufgabe des Betreibers (Exchange Server documentation, Exchange Server architecture).

Der praktische Unterschied zu Exchange Online zeigt sich sofort bei einer Störung. Ein On-Prem-Admin kann eine Transportqueue auf einem konkreten Server untersuchen, den Zustand einer Datenbankkopie prüfen und kontrolliert auf eine andere Kopie umschalten. Dafür muss er aber auch verstehen, wie SMTP, Active Directory, ESE, Windows Failover Clustering, IIS und Exchange-Dienste zusammenspielen.

Der Mailboxserver ist der zentrale Baustein

Moderne Exchange-Server verwenden den Mailboxserver als gemeinsamen Baustein. Er enthält Client-Access-Dienste, die Verbindungen annehmen und weiterleiten, Transportdienste für den Nachrichtenfluss sowie den Information Store mit Mailboxdatenbanken. Eine Installation kann klein beginnen; mehrere Server und Datenbankkopien bauen dasselbe Grundmodell für Hochverfügbarkeit aus (Exchange Server architecture).

Diese Zusammenführung bedeutet nicht, dass alle Funktionen denselben Zustand haben. Ein HTTPS-Frontend kann erreichbar sein, obwohl die angesprochene Datenbank nicht gemountet ist. SMTP kann Verbindungen annehmen, während eine Nachricht später in einer Queue wartet. Die Diagnose folgt deshalb dem tatsächlichen Weg und nicht nur dem Gesamtstatus des Servers.

Die optionale Edge-Transport-Rolle steht typischerweise im Perimeternetz und verarbeitet ausschliesslich SMTP-Verkehr. EdgeSync überträgt ausgewählte Empfänger- und Konfigurationsinformationen in eine lokale AD-LDS-Instanz. Edge hält keine Mailboxdatenbank und ist kein Ersatz für die internen Mailboxserver (Edge Transport servers).

Technologiestack und Abhängigkeiten

Aus dem Serverbaustein ergibt sich der Technologiestack. Exchange läuft auf unterstützten Windows-Server-Versionen und verwendet Active Directory für Organisations-, Server- und Empfängerkonfiguration. IIS stellt HTTP-Endpunkte bereit. PowerShell bildet die Verwaltungsoberfläche. ESE speichert Mailbox- und Queuedaten in getrennten Datenbanken (Exchange Server system requirements, Active Directory in Exchange Server).

Für Experten ist vor allem die Active-Directory-Abhängigkeit wichtig. Exchange-Setup erweitert das Schema und schreibt Organisationskonfiguration in die Configuration Partition. Empfängerattribute liegen in der Domainpartition. Replikationsverzögerung oder ein nicht erreichbarer Domain Controller kann daher unterschiedliche Funktionen verschieden treffen.

Die Transport-Pipeline Schritt für Schritt

Mit dem technischen Fundament lässt sich der Nachrichtenweg genauer lesen. Eine eingehende SMTP-Verbindung erreicht zunächst den Front End Transport Service. Er nimmt den Dialog an und vermittelt ihn zum Transport Service; er stellt die Nachricht nicht selbst in ein Postfach zu (Mail flow and the transport pipeline).

Der Transport Service speichert die Nachricht in seiner Queue-Datenbank. Danach kategorisiert er sie: Empfänger werden aufgelöst, Regeln und Transport Agents laufen, und das Routing bestimmt den nächsten Hop. Für ein lokales Postfach übergibt Mailbox Transport Delivery die Nachricht an den Store. Eine vom Postfach abgesendete Nachricht gelangt über Mailbox Transport Submission zurück in den Transport.

Diese Reihenfolge erklärt typische Beobachtungen. Ein erfolgreicher SMTP-Test belegt nur die Annahme am Frontend. Ein RECEIVE-Ereignis im Message Tracking beweist noch keine Zustellung. Erst die weiteren Ereignisse, die Queue und gegebenenfalls der Storezustand zeigen, wo der Ablauf endete (Message tracking).

Transport Agents und Mailflow Rules können Nachrichten ablehnen, umleiten, kopieren oder verändern. Weil dabei mehrere Transportinstanzen entstehen können, sollte die Suche nicht nur nach Betreff erfolgen. Network Message ID, Internet Message ID, Absender, Empfänger, Zeitpunkt und Server ergeben zusammen die verlässlichere Spur.

Routing, Domains und Connectors

Nach der Annahme muss Exchange wissen, ob ein Empfänger lokal ist oder ob die Nachricht weitergereicht wird. Accepted Domains beschreiben dieses Verhältnis. Eine autoritative Domain erwartet alle gültigen Empfänger in der eigenen Organisation. Eine Internal-Relay-Domain erlaubt die Weiterleitung unbekannter Empfänger. External Relay übergibt die Domain vollständig an einen anderen Mailserver (Accepted domains in Exchange Server).

Receive Connectors klassifizieren eingehende Sitzungen anhand lokaler Bindung, Remote-IP-Bereich, Authentisierung und Berechtigungen. Send Connectors wählen aus Adressraum, Kosten, Quellservern und DNS- oder Smart-Host-Routing einen ausgehenden Weg. Mehrere passende Connectors werden nach den dokumentierten Routingregeln bewertet; der Name eines Connectors steuert die Auswahl nicht (Connectors on Exchange servers, Mail routing in Exchange Server).

Für den normalen Betrieb reicht ein einfaches Modell: Receive Connector erklärt, wie eine Nachricht hereinkommt; Accepted Domain und Empfängerauflösung erklären, ob Exchange zuständig ist; Send Connector und Routing erklären, wohin sie weitergeht. Experten ergänzen AD-Sites, Delivery Groups, DAG-Mitgliedschaft, Connector-Scoping und Transportregeln.

Mailboxdatenbank, Logs und Checkpoint

Wenn der Transport an den Store übergibt, beginnt ein anderer Teil des Systems. Exchange speichert Postfächer in ESE-Mailboxdatenbanken. Änderungen werden zuerst in Transaktionslogs geschrieben und später in die .edb-Datei übernommen. Das Checkpointfile hält fest, bis zu welcher Logposition die Datenbankseiten geschrieben wurden (Transaction logs and checkpoint files).

Diese Reihenfolge ermöglicht Crash Recovery, verlangt aber zusammengehörige Dateien. Eine kopierte .edb ohne passende Logs und bekannten Shutdownzustand ist nicht automatisch wiederherstellbar. Ebenso darf ein Backup nicht unkontrolliert Logdateien löschen, die für Recovery oder Replikation noch benötigt werden.

Die Transportqueue verwendet ebenfalls ESE, ist aber eine eigene Datenbank mit eigenen Logs. Mailboxdatenbank und Queue werden deshalb getrennt überwacht und wiederhergestellt. Eine gesunde Mailboxdatenbank beseitigt keinen blockierten SMTP-Next-Hop; eine leere Queue repariert keine beschädigte Mailboxkopie (Queues and the queue database).

Database Availability Group und Active Manager

Ein einzelner Mailboxserver erklärt den Normalbetrieb. Für Hochverfügbarkeit werden mehrere Server zu einer Database Availability Group, DAG, verbunden. Jede Mailboxdatenbank besitzt genau eine aktive Kopie und kann passive Kopien auf anderen DAG-Mitgliedern haben. Änderungen werden über Log- und Blockreplikation übertragen und auf den passiven Kopien wiedergegeben (Database availability groups, Mailbox database copies).

Der Active Manager im Microsoft Exchange Replication Service entscheidet, welche Kopie aktiv ist. Best Copy and Server Selection bewertet unter anderem Kopier- und Wiedergabezustand, Aktivierungsblockaden und Servergesundheit. Eine Copy Queue von null ist deshalb hilfreich, aber kein vollständiger Nachweis, dass eine Kopie sofort aktivierbar ist (Active Manager).

Transporthochverfügbarkeit schützt einen anderen Abschnitt des Wegs. Shadow Redundancy hält eine zusätzliche Kopie, solange die Nachricht unterwegs ist. Safety Net bewahrt bereits verarbeitete Nachrichten für eine mögliche Neuübermittlung nach Datenbankaktivierung. DAG, Shadow Redundancy und Safety Net ergänzen einander; keine der drei Funktionen ersetzt ein Backup gegen versehentliche Löschung oder lange unbemerkte Beschädigung (Transport high availability).

Clientzugriff und Autodiscover

Die Datenbank kann gesund sein und ein Benutzer trotzdem kein Outlook öffnen. Client Access Services nehmen HTTPS-Verbindungen an und leiten sie zum Backend auf dem Server mit der aktiven Datenbank weiter. Ein Load Balancer braucht daher mehr als einen offenen TCP-Port: Name, Zertifikat, Protokollendpunkt und Backendgesundheit müssen zusammenpassen (Client Access protocol architecture).

Autodiscover liefert dem Client die passenden Einstellungen. Domäneninterne Clients können Service Connection Points in Active Directory verwenden; externe und andere Clients folgen DNS- und HTTPS-Verfahren. Fehler entstehen häufig durch veraltete SCPs, widersprüchliche DNS-Antworten, falsche Zertifikatsnamen oder ein Frontend, das zum falschen Backend weiterleitet (Autodiscover service).

MAPI over HTTP ist der typische Outlook-Transport. Outlook im Web, EWS und ActiveSync verwenden ebenfalls HTTPS, besitzen aber eigene virtuelle Verzeichnisse, Authentisierung und Anwendungseigenschaften. Ein erfolgreicher OWA-Test beweist deshalb nicht automatisch eine gesunde MAPI/HTTP-Sitzung (MAPI over HTTP).

Active Directory und Empfänger

Nach Transport und Clientzugriff bleibt das Verzeichnis als gemeinsame Grundlage. Exchange speichert Organisations- und Serverkonfiguration sowie Empfängerattribute in Active Directory. Cmdlets schreiben diese Daten nicht in eine private Exchange-Datenbank, sondern über Exchange-Logik in AD (Active Directory in Exchange Server).

Ein Empfängerproblem wird daher entlang von drei Fragen untersucht: Existiert das richtige Objekt? Sind Typ, primäre Adresse, Proxyadressen und Zielattribute korrekt? Hat die Änderung den Domain Controller erreicht, den der betroffene Exchange-Dienst verwendet? Erst danach lohnt sich die Suche im Transport.

Für Experten kommen globale Kataloge, AD-Sites, Recipient Update, Address Book Policies und Hybridattribute hinzu. Direkte Änderungen mit generischen AD-Werkzeugen umgehen Exchange-Validierung und können Konfigurationen erzeugen, die syntaktisch vorhanden, aber fachlich inkonsistent sind.

Sicherheit und administrative Kontrolle

Exchange veröffentlicht SMTP- und HTTPS-Dienste und verarbeitet hoch privilegierte Verzeichnis- und Postfachdaten. Die Basis besteht aus zeitnahen Security Updates, minimal erreichbaren Endpunkten, passenden Zertifikaten, abgesicherten Administrationskonten und nachvollziehbaren Änderungen (Exchange Server Security Updates, TLS certificates in Exchange Server).

RBAC trennt Aufgaben über Rollen, Rollengruppen und Scopes. Postfachrechte wie Full Access oder Send As bleiben davon getrennt. Administrator Audit Logging protokolliert Cmdletänderungen, ersetzt aber keine Betriebssystem-, Active-Directory- und Sicherheitsprotokolle (Permissions in Exchange Server, Administrator audit logging).

Für Experten ist die Verwaltungsoberfläche selbst Teil des Schutzmodells. EAC, Exchange Management Shell, Remote PowerShell, WinRM, RDP und Hypervisorzugriff besitzen unterschiedliche Rechte und Protokolle. Ein kompromittierter Serveradmin kann Massnahmen ausserhalb von Exchange-RBAC durchführen; Tiering und separate privilegierte Konten bleiben deshalb wichtig.

Betrieb: vom Symptom zum konkreten Server

Managed Availability führt Probes, Monitors und Responders aus. Health Sets fassen diese Ergebnisse nach Funktion zusammen und können automatische Recoveryaktionen auslösen. Sie sind ein guter Startpunkt, aber keine vollständige Ende-zu-Ende-Prüfung (Managed Availability).

Für Mailflow beginnt die lokale Diagnose mit Get-Queue und Get-MessageTrackingLog. Queuezahl, Next Hop, Retryzeit und LastError gehören zusammen. Für Datenbanken folgen Get-MailboxDatabaseCopyStatus und Test-ReplicationHealth. Get-ServerHealth zeigt Health Sets und Monitore.

Diese Cmdlets laufen in der Exchange Management Shell auf unterstützten Windows-Servern. Netzwerk- und DNS-Tests können dagegen von beiden Adminplattformen erfolgen. Test-NetConnection prüft unter Windows einen TCP-Endpunkt; nc übernimmt denselben Porttest unter Unix. Resolve-DnsName und dig prüfen DNS. Für SMTP mit STARTTLS eignet sich openssl s_client, für einen kontrollierten SMTP-Dialog swaks.

Die Diagnosereihenfolge lautet: öffentlichen oder internen Namen auflösen, Verbindung zum richtigen Frontend prüfen, Annahme im Protokolllog bestätigen, Trackingereignisse verfolgen, Queue und Next Hop prüfen und erst bei lokaler Zustellung Store und Datenbank untersuchen.

Backup und Recovery

Hochverfügbarkeit hält den Dienst bei einzelnen Ausfällen verfügbar; Recovery stellt einen gewünschten früheren oder verlorenen Zustand wieder her. Exchange dokumentiert Server Recovery, Datenbankrestore und Recovery Database als unterschiedliche Verfahren (Backup, restore, and disaster recovery).

Ein wiederherstellbares Inventar umfasst mindestens Active Directory, Exchange-Organisation und Serverkonfiguration, Zertifikate und private Schlüssel, Mailboxdatenbanken mit Logs, Connector- und Regelkonfiguration sowie dokumentierte Installations- und Recoveryparameter. Die Recovery Database erlaubt, eine wiederhergestellte Datenbank isoliert zu mounten und Inhalte in aktive Postfächer zu übertragen (Restore data using a recovery database).

Experten testen nicht nur, ob ein Backupjob erfolgreich war. Sie messen, wie lange Active Directory, ein ausgefallener Server, eine Datenbank und einzelne Mailboxinhalte tatsächlich wiederhergestellt werden können. Dabei wird geprüft, welche Logsequenzen benötigt werden, welche DNS- und Zertifikatsabhängigkeiten bestehen und ob nach dem Restore Client- und SMTP-Pfade wieder funktionieren.

Technische Entwicklung und Grenzen

Exchange 4.0 erschien 1996. Frühe Versionen verwendeten ein eigenes Verzeichnis, MAPI und ESE; SMTP und Active Directory wurden mit Exchange 2000 zentrale Plattformbestandteile. Exchange 2007 führte Serverrollen und Exchange Management Shell ein. Exchange 2010 ersetzte ältere Clustermodelle durch die Database Availability Group (Exchange Team: A brief history of time, Exchange Server 2007 transport redesign).

Spätere Versionen fassten Client Access und Mailboxfunktionen wieder in einem gemeinsamen Serverbaustein zusammen. Exchange Server Subscription Edition setzte die lokale Produktlinie 2025 im Modern Lifecycle fort. Buildstände, unterstützte Upgradepfade und Security Updates werden vor jeder Änderung in Microsofts laufender Dokumentation geprüft (Exchange Server SE release notes, Exchange Server build numbers and release dates).

Exchange On-Premises eignet sich, wenn die Organisation Kontrolle über Datenbankbetrieb, Netzwerkpfade und lokale Integration braucht und den dafür nötigen 24/7-Betrieb leisten kann. Die Kehrseite sind komplexe Abhängigkeiten, kontinuierliche Sicherheitswartung und Recoveryverantwortung. Ein einzelner Server kann einfach aussehen; ein belastbarer Exchange-Dienst ist immer auch ein Active-Directory-, Netzwerk-, Zertifikats-, Storage- und Betriebsprojekt.