Exchange loswerden (Teil 1): Warum jetzt, welcher Weg, und zuerst der Mailflow

Die Postfächer sind seit Jahren in Exchange Online, und trotzdem steht im Keller noch ein Exchange-Server. Er wird gepatcht, lizenziert, gesichert und ist aus dem Internet erreichbar, obwohl kaum noch jemand weiß, wofür. Microsoft nennt das das Last Exchange Server Problem. Diese Serie zeigt, wie du den letzten Exchange-Server loswirst, Schritt für Schritt und in der Reihenfolge, in der es in der Praxis funktioniert.

Die Serie:

1. Warum jetzt, welcher Weg, und zuerst der Mailflow (dieser Teil)
2. Postfächer und Public Folders in die Cloud (erscheint in Kürze)
3. Die Verwaltung zieht in die Cloud (erscheint in Kürze)
4. Der Rückbau: System-Postfächer abräumen, Hybrid entfernen, den letzten Server deinstallieren (erscheint in Kürze)

Warum der Server überhaupt noch da ist

Solange Benutzer aus dem AD synchronisiert werden, liegen ihre Exchange-Attribute im AD: Adressen, CustomAttributes, Ausblenden aus der GAL. In Exchange Online darfst du sie nicht ändern. Unterstützt war bisher nur der Weg über die Exchange-Cmdlets on-prem, also Set-RemoteMailbox, Set-DistributionGroup, Set-MailContact. ADUC, ADSI Edit und Fremdwerkzeuge sind für diese Attribute ausdrücklich nicht unterstützt.

Daher der Server. Er verwaltet nur noch Attribute, muss dafür aber laufen, gepatcht und erreichbar sein.

Warum jetzt

Drei Termine machen das Thema dringend:

• Exchange 2016 und 2019: Die zweite und letzte Phase der Extended Security Updates endet am 31. Oktober 2026. Microsoft hat erklärt, dass es keine weitere Verlängerung gibt; ab November erscheinen Updates nur noch für Exchange SE (Exchange Team Blog: October 2026 Exchange Server Security Updates). Betreibst du danach noch einen 2016er oder 2019er, läuft er ohne Sicherheitsupdates.
• EWS in Exchange Online: Seit dem 1. Oktober 2026 ist EWS in Exchange Online blockiert, wenn der Tenant keine Freigabeliste (EWSAllowedAppIDs) gesetzt und EWS ausdrücklich eingeschaltet hat. Am 1. April 2027 wird EWS endgültig abgeschaltet, ohne Ausnahmen (Exchange Team Blog: Retirement of Exchange Web Services in Exchange Online, Message-Center-Meldungen MC1227454 und MC1447678). Das betrifft Anwendungen, die heute gegen den lokalen Server sprechen und die du „einfach in die Cloud umziehen“ wolltest.
• Die Werkzeuge sind da: Seit 2025/2026 lassen sich die Exchange-Attribute in die Cloud verlagern (Teil 3). Damit fällt der letzte technische Grund für den Server weg.

Bist du auf Exchange SE, bekommst du weiter Updates. Aber auch dann bleibt die Frage, warum du einen internetfähigen Server für ein paar Attribute betreibst.

Zwei Wege, und sie schließen sich aus

Microsoft beschreibt zwei Verfahren, und du musst dich vorher für eines entscheiden:

Weg A, Exchange Management Tools (EMT): Nur die Verwaltungstools werden auf einem Domänenrechner installiert. Der Server darf heruntergefahren werden, aber nicht deinstalliert: Die Exchange-Container und -Gruppen im AD müssen bleiben, sonst funktionieren die Tools nicht. Danach räumt CleanupActiveDirectoryEMT.ps1 auf. Microsoft nennt EMT inzwischen einen „temporary workaround“: Die Verwaltung bleibt im AD verankert.

Weg B, Source of Authority (SOA) in die Cloud: Die Exchange-Attribute werden in Exchange Online verwaltet, danach wird der Server regulär mit Setup.exe /m:Uninstall entfernt. Das ist der Weg dieser Serie. Nutzt du heute EMT, sollst du laut Microsoft zuerst auf diesen Weg wechseln.

Nicht mischen: /m:Uninstall entfernt genau die AD-Objekte, die EMT braucht. Willst du EMT weiter nutzen, darfst du nicht deinstallieren.

Für Weg B gibt es zwei Mechanismen. Bei Postfächern reicht es, nur die Exchange-Attribute in die Cloud zu verlagern (IsExchangeCloudManaged). Die Identität bleibt im AD und wird weiter synchronisiert. Alternativ lässt sich das ganze Benutzerobjekt in die Cloud übernehmen (User SOA), dann ist der Benutzer cloud-only. Für die meisten Umgebungen mit AD ist der erste Mechanismus der richtige, darum geht es in Teil 3.

Die Reihenfolge

Die Reihenfolge ist wichtig, weil jeder Schritt den nächsten voraussetzt:

1. Vorbereitung und Mailflow: Nichts darf mehr über den Server laufen (dieser Teil).
2. Daten: Benutzerpostfächer, Archive und Public Folders müssen in die Cloud, solange der Server noch läuft und die Verwaltung noch on-prem ist (Teil 2).
3. Verwaltung: Exchange-Attribute, Verteiler und Kontakte in die Cloud (Teil 3).
4. Rückbau: System-Postfächer abräumen, Hybrid-Objekte entfernen, deinstallieren, aufräumen (Teil 4). Die System-Postfächer kommen bewusst erst hier, weil sich nach der SOA-Umstellung einige Abhängigkeiten von selbst erledigt haben.

Vorbereitung

Ist-Zustand dokumentieren

Bevor irgendetwas geändert wird, die Organisation komplett herausschreiben: Connectors, Accepted Domains, Address Policies, Transportregeln, Verteiler, Kontakte. Wenn der Server weg ist, beantwortet niemand mehr die Frage „wie war das eigentlich eingestellt?“. Ich nehme dafür ExchangeDocumentation aus meinen exchange-tools, für on-prem und Exchange Online.

Email Address Policies notieren

Nach dem Rückbau gibt es für Benutzer keine Address Policy mehr. In Exchange Online gelten Address Policies nur für Microsoft 365 Groups. Das Adressschema muss danach beim Anlegen per Skript gesetzt werden (Teil 3). Deshalb jetzt festhalten, was gilt:

Get-EmailAddressPolicy | Format-List Name, Priority, RecipientFilter, EnabledEmailAddressTemplates

Entra Connect aktualisieren

Für die Cloud-Verwaltung der Exchange-Attribute braucht es Entra Connect Sync ab 2.5.190.0. Ältere Versionen versuchen, die Attribute bereits umgestellter Postfächer weiter nach Entra zu schieben, und scheitern dabei. Die Version zeigt:

(Get-ADSyncGlobalSettings).Parameters['Microsoft.Synchronize.ServerConfigurationVersion']

Wenn ohnehin aktualisiert wird, dann gleich auf den aktuellen Stand.

Rollen klären

• Postfächer umstellen (IsExchangeCloudManaged): Exchange Administrator, Hybrid Identity Administrator oder Global Administrator, und nur mit interaktiver Anmeldung.
• Tenant-Standard für neue Postfächer: Hybrid Identity Administrator oder Global Administrator.
• Verteiler und Kontakte per Graph: passende Graph-Berechtigungen, deren Consent ein Application Administrator erteilen muss.
• Writeback ins AD einrichten: Hybrid Identity Administrator.

AD sichern

Vor dem eigentlichen Rückbau (Teil 4) eine System-State-Sicherung eines DCs. Die Deinstallation entfernt Objekte aus der Konfigurationspartition, und dafür gibt es keinen Rückweg per Klick.

Mailflow: Wer schickt noch über den Server?

SMTP-Relay

Das ist der Punkt, an dem Rückbauten in der Praxis scheitern. Die Deinstallation entfernt alle Receive Connectors, ohne Rückfrage. Drucker, Scanner, Fachanwendungen und Monitoring verlieren danach den Mailversand, und zwar dauerhaft.

Wer relayen darf, zeigt dir:

Get-ReceiveConnector | Where-Object { $_.PermissionGroups -match 'AnonymousUsers' } |
    Format-Table Name, Bindings, RemoteIPRanges -AutoSize

RemoteIPRanges zeigt aber nur, wer darf, nicht wer es tatsächlich tut. Wer wirklich sendet, steht in den SMTP-Receive-Protokollen. Die wertet zum Beispiel mein ExchangeLogAnalyzer je Gegenstelle aus.

Wie du das Relay umziehst, habe ich ausführlich beschrieben:

• SMTP Relay migrieren, Teil 1: Inventur
• SMTP Relay migrieren, Teil 2: die Microsoft-Wege, exo-smtp-relay und E-MailRelay
• Wenn der Scanner nicht mehr mailen will: Altgeräte mit TLS-Problemen

Erst wenn jedes Gerät umgestellt ist und die Testmails ankommen, geht es weiter. Willst du das Relay bewusst auf dem Exchange-Server lassen, darfst du laut Microsoft nicht deinstallieren.

MX und Autodiscover, intern und extern

Im DNS geht es um zwei Fragen: Wo landet Post aus dem Internet (MX)? Und wo findet Outlook die Einstellungen für ein Postfach (Autodiscover)? Solange einer der beiden Einträge auf den lokalen Server zeigt, hängt der Betrieb an ihm, auch wenn alle Postfächer längst in der Cloud sind.

MX: Wohin geht Post aus dem Internet?

In vielen Hybrid-Umgebungen zeigt der MX noch auf den lokalen Server. Post aus dem Internet kommt dort an und wird über den Hybrid-Connector an Exchange Online weitergereicht. Nach dem Rückbau gibt es diesen Weg nicht mehr, eingehende Post würde zurückgewiesen oder bliebe beim Absender in der Warteschlange.

Deshalb muss der MX direkt auf Exchange Online zeigen. Den genauen Wert nicht abtippen, sondern aus dem Microsoft 365 Admin Center übernehmen: Einstellungen → Domänen → Domäne → DNS-Einträge. Dort steht, was Microsoft für diese Domäne erwartet.

Praktisch bewährt:

• TTL vorher senken: Ein, zwei Tage vor der Umstellung die TTL des MX auf wenige Minuten setzen. Dann wirkt die Änderung schnell, und ein Rückweg ebenso.
• Danach testen: Eine Mail von außen schicken, zum Beispiel von einem privaten Postfach, und im Exchange Admin Center unter Nachrichtenablaufverfolgung prüfen, dass sie direkt angekommen ist.
• Firewall: Die Freigabe für Port 25 auf den lokalen Server bleibt vorerst. Solange es den Hybrid gibt, stellt Exchange Online darüber noch Post für lokale Empfänger zu. Geschlossen wird sie in Teil 4.

Autodiscover: Wie findet Outlook das Postfach?

Outlook und Mobilgeräte fragen beim Einrichten eines Profils und danach regelmäßig per Autodiscover, wo das Postfach liegt. Im Hybrid zeigt autodiscover.contoso.com meist auf den lokalen Server. Der antwortet für Cloud-Postfächer mit einer Weiterleitung nach Exchange Online. Ist der Server weg, fehlt diese Antwort: Neue Profile lassen sich nicht einrichten, bestehende melden Verbindungs- oder Zertifikatsfehler.

Deshalb zeigt autodiscover als CNAME auf autodiscover.outlook.com.

Intern und extern: das geteilte DNS

Hier liegt die eigentliche Falle. Viele Firmen haben ihre Domäne zweimal im DNS:

• extern beim Provider, für das Internet,
• intern auf den Domänencontrollern, für das LAN („Split-Brain“). Dort stehen oft eigene Einträge für autodiscover und mail, die auf die interne IP des Exchange-Servers zeigen.

Stellst du nur extern um, stimmt zu Hause und unterwegs alles, im Büro aber landen die Clients weiter beim alten Server. Microsoft betont deshalb ausdrücklich: internes und externes DNS anpassen.

Am einfachsten siehst du den Unterschied, wenn du von einem PC im LAN einmal den internen und einmal einen öffentlichen DNS-Server fragt:

# intern (Standard-DNS des PCs, also meist der DC)
Resolve-DnsName -Name contoso.com -Type MX
Resolve-DnsName -Name autodiscover.contoso.com

# extern (öffentlicher Resolver)
Resolve-DnsName -Name contoso.com -Type MX -Server 1.1.1.1
Resolve-DnsName -Name autodiscover.contoso.com -Server 1.1.1.1

Beide Ergebnisse müssen auf Exchange Online zeigen. Steht intern noch die IP des Exchange-Servers, ist der interne Eintrag auf den DCs zu ändern.

mail., owa., hybrid.: noch nicht löschen

Die A-Einträge für den Server selbst bleiben vorerst stehen. Im klassischen Hybrid erreicht Exchange Online den lokalen Server über diese Namen, solange es den Hybrid noch gibt: für Frei/Gebucht-Abfragen und für den letzten Postfach-Batch in Teil 2. Gelöscht werden sie erst nach der Deinstallation (Teil 4).

SPF, DKIM und DMARC

Wenn die Mail jetzt direkt über Exchange Online raus und rein geht, lohnt ein Blick auf die Absender-Einträge:

• SPF (TXT-Eintrag der Domäne) muss include:spf.protection.outlook.com enthalten. Die IP des alten Exchange-Servers kann raus, aber erst, wenn das neue Relay aus dem Abschnitt oben nicht mehr über diese IP sendet.
• DKIM wird in Exchange Online je Domäne eingeschaltet und braucht zwei CNAME-Einträge (selector1._domainkey, selector2._domainkey). Die genauen Werte zeigt das Defender-Portal beim Einschalten.
• DMARC ändert sich nicht. Bekommst du DMARC-Berichte, siehst du dort nach der Umstellung, ob noch etwas über einen unerwarteten Weg verschickt wird.

Autodiscover-SCP leeren

Domänen-Clients fragen zuerst den Service Connection Point im AD, erst danach DNS. Bleibt der SCP stehen, landen interne Outlooks trotz korrektem DNS beim alten Server:

Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri $Null

Centralized Mail Transport abschalten

Ist CMT aktiv, geht ausgehende Post aus Exchange Online über den lokalen Server. Ohne Server bricht der ausgehende Mailflow.

Ob CMT aktiv ist, zeigt die Hybrid-Konfiguration on-prem. Wichtig ist das -ExpandProperty: Format-List Features kürzt lange Listen je nach $FormatEnumerationLimit mit „…“ ab, und CentralizedTransport steht weit hinten. Siehst du nur das, hältst du CMT leicht für ausgeschaltet.

Get-HybridConfiguration | Select-Object -ExpandProperty Features

Steht CentralizedTransport in der Liste, ist CMT eingeschaltet. In meinem Lab war der Eintrag da, solange CMT im Hybrid Configuration Wizard aktiviert war, und nach dem Abwählen im Wizard verschwunden. Was Exchange Online tatsächlich macht, zeigt der Hybrid-Outbound-Connector:

Get-OutboundConnector | Where-Object { $_.ConnectorSource -eq 'HybridWizard' } |
    Format-Table Name, RouteAllMessagesViaOnPremises -AutoSize

Zum Abschalten empfiehlt Microsoft, den Hybrid Configuration Wizard noch einmal laufen zu lassen und „Enable Centralized Mail Transport“ abzuwählen. Alternativ in Exchange Online:

Set-OutboundConnector -Identity "<Hybrid Outbound Connector name>" `
    -RecipientDomains "<accepted domains, comma-separated>" `
    -RouteAllMessagesViaOnPremises:$False

Anwendungen, die mit dem Server sprechen

Alles, was per EWS oder MAPI gegen den lokalen Server arbeitet, funktioniert nach dem Rückbau nicht mehr: Archivlösungen, CRM-Anbindungen, Scan-to-Mailbox, alte Kalender-Synchronisationen. Ein Umzug auf EWS in Exchange Online ist wegen der Abschaltung im April 2027 eine Sackgasse. Solche Anwendungen gehören direkt auf Microsoft Graph.

Fazit

Bevor der erste Postfach-Batch läuft, steht fest, welcher Weg gegangen wird, was dokumentiert ist und dass keine Mail mehr über den Server läuft. Das Relay ist dabei fast immer der Teil, der am längsten dauert, weil er Geräte und Ansprechpartner betrifft, die niemand auf der Liste hatte.

Im nächsten Teil geht es um die Postfächer: die letzten Benutzer, Public Folders und die System-Postfächer, die gern vergessen werden.

Feedback, Fragen und Erfahrungen gerne in die Kommentare.