Exchange Hybrid Rückbau

Die meisten Firmen mit Exchange On-Premises migrieren über den Hybrid Mode zu Exchange Online. Irgendwann ist aber das letzte Postfach in der Cloud und die öffentlichen Ordner migriert. Auf dieser Seite beschreibe ich die Schritte zum Abbau der On Premises Umgebung bis auf den vorletzten Server. Denn aktuell muss ein Hybrid Connector Server bestehen bleiben.

Diese Seite beschreibt nicht, wie Sie den Exchange Hybrid Mode komplett entfernen.

Zielumgebung

Wer heute gleich mit Exchange Online anfängt und gar keine lokalen Exchange Server mehr installieren will, wird sich verwundert die Augen reiben, dass er dennoch das lokale Active Directory mit einem Exchange Schema erweitern und einen Exchange Server installieren muss. Das gilt immer dann, wenn Sie mit ADSync mit Exchange einsetzen wollen. Sobald ADSync eingerichtet ist, können Sie in Exchange Online keine Mailadressen oder ProxyAddresses mehr verwalten. Diese Attribute der Cloud-Identitäten sind auf einmal "ReadOnly" und müssen über die lokale Exchange Installation verwaltet werden.

Noch ist nicht absehbar, wann Microsoft diesen Zwang lockert. Es wäre durchaus denkbar die Verwaltung in der Cloud frei zu geben, wenn man z.B.: ADSync ohne Exchange Option eingerichtet hat.

Aber auf dieser Seite gehen wir davon aus, dass Sie eine vollständige Exchange Umgebung haben, die auf eine minimalen lokale Umgebung zurückgebaut werden soll.

Ausgangsumgebung

Ich gehe davon aus, dass Sie vor einiger Zeit mit Exchange On Premises begonnen und dann den klassischen Hybrid Mode eingerichtet haben und auch immer noch betreiben mit:

  • ADSync mit Exchange Synchronisation
  • Autodiscover verweist auf On Premises
  • EWS zumindest für Office 365 erreichbar
  • Microsoft Federation Gateway
  • Mailrouting mit Connectoren
  • Hybrid Connector Server
    Ein Server bleibt übrig und sollte bereits installiert worden sein.

Allerdings "tun" die Server idealerweise nichts mehr, d.h. sind lastfrei und enthalten keine Daten. Wenn Sie viele Server haben, könnten Sie durchaus schon einige Server selbst deinstalliert haben. Das ist nicht sonderlich schwer, da das Exchange Setup schon meckert, wenn noch Daten auf den Servern sind. Es beschwert sich aber nicht, wenn ein Server z.B. noch als Frontend für Client-Zugriffe oder SMTP-Verkehr bedient. Hier müssen sie selbst die Augen aufmachen und die Logs auswerten.

Checklist

Checklisten helfen bestimmte Routinetätigkeiten strukturiert und fehlerarm durchzuführen. Sie unterliegen natürlich einer kontinuierlichen Anpassung und ersetzen nicht den eigenen Kopf.

Prüfpunkt Erledigt

On Premises Objekte

Auf den lokalen Servern sollten natürlich keine Postfächer mehr liegen. Das Exchange Setup verhindert zwar die Installation aber da die Migration in die Cloud je nach Bandbreite auch länger dauern kann, sollten Sie mal schnell den aktuellen Status mit den beiden Commandlets prüfen.

Set-ADServerSetting -ViewEntireForest $true
Get-mailbox
Get-PublicFolder
Get-MailPublicFolder
  • Set-ADServerSetting -ViewEntireForest $true
    Wenn Sie mehrere Domains in ihrem Forest bedienen, dann stellen Sie damit sicher, dass der komplette Forest und nicht nur die aktuelle Domäne durchsucht wird
  • Get-mailbox
    Liefert ihnen alle Postfächer. Office 365 Postfächer sind als Remote-Mailbox hier nicht sichtbar. Die Systempostfächer, Healthcheck etc. sind nicht weiter relevant und werden später einfach entfernt
  • Get-PublicFolder / Get-MailPublicFolder
    Es sollte keine Ordner mehr geben, die sie nicht schon migriert haben.

On Premises Mailrouting / Client Access

Das Exchange Setup kontrolliert nur Datenspeicher (Mailbox, Public Folder) aber keine sonstigen Funktionen. Ehe Sie einen Server abschalten, sollten Sie die IIS/POP3/IMAP4-Logs und SMTP-Logs prüfen, ob hier noch Clients sich verbinden.

  • Client Access Role
    Bis auf Autodiscover und Healthchecks sollte kein Client sich mehr mit den zu deinstallierenden Servern verbinden, da es dort ja keine Daten mehr gibt. Ein lokaler Exchange CAS/Frontend-Server kann auch kein Proxy in die Cloud sein. Sollte es noch Zugriffe geben, müssen Sie diesen nachgehen, da hier Prozesse nicht mehr arbeiten können und es anscheinend bislang niemand bemerkt hat,
  • Mail Routing
    Bei SMTP liegt der Sachverhalt etwas anders, da auch ohne Postfach ein Exchange Server durchaus Mails per SMTP annimmt und weiterreichen kann. Es kann also Clients geben, die bislang per SMTP Mails einliefern und erst umgestellt werden müssten. Hier ist dann zu entscheiden, wie diese Clients zukünftig Mails einliefern. Ein direkter Versand zu Exchange Online ist möglich. wenn diese Systeme per SMTP das Internet erreichen können und Sie im Tenant die Quell-IP-Adressen aus dem Spamfilter ausnehmen.
    Solange aber lokal ein Hybrid Connector Server installiert bleibt, sollten sie die Clients dann auf diesen Server umstellen.

Mailrouting via Cloud

Damit die Mails später über die Cloud gesendet und empfangen werden, sind ein paar Einstellungen erforderlich

  • Internet: MX-Record
    Sofern noch nicht geschehen, sollten Sie zuerst  ihren eingehenden MX-Record auf Exchange Online umstellen. Es dauert Stunden und manchmal auch Tage, bis andere Mailserver diese neue Konfiguration übernehmen. Dies ist zugleich auch die Zeit, die Exchange Online Protection ggfls. noch mal anzupassen. Hier gilt es die Quarantäne u.a. zu überwachen und ggfls. Systeme zu erlauben.
  • SPF, SenderID
    Aber auch in die ausgehende Richtung gibt es Veränderungen. Wenn sie bislang noch nicht über Office 365 versendet haben, dann wird es Zeit die Exchange Online Mailserver im SPF-Eintrag zu addieren.
  • DKIM
    Sie können in dem Zuge auch ihre Domains von Office 365 mittels "DKIM" signieren lassen. Sie schalten das im Tenant ein und veröffentlichen dazu einen passenden Eintrag im DNS. So können Empfänger schon mal DKIM prüfen und die Mails positiv bewerten. Ablehnen ist aber erst möglich, wenn wirklich alle ausgehenden Mails per DKIM signiert sind.
  • DMARC
    Daher setzten Sie bitte ein DMARC-Policy, die weder SPF noch DKIM erzwingt, solange Sie noch unklare Absender haben. Sie sollten aber DMARC im "Report Only"-Mode konfigurieren, damit Sie über alle Systeme informiert werden, die noch mit ihrer Domain senden und am Ende nicht mehr senden dürfen.

Hybrid Server bestimmen

Ein Server muss bestehen bleiben. Das kann ein bestehender Server oder auch ein neuer Server sein. Wer heute schon Exchange 2016 Server hat, die von der Installation und Hardware auch noch weiter betrieben werden sollen, kann einen oder zwei Server davon weiter betreiben.

Bei den meisten Firmen ist es aber so, dass eine Migration von Exchange 2010/2013/2016 in die Cloud erfolgt, weil die Hardware schon "älter" ist und die Kosten für Wartung und Betrieb mit reduziert werden sollen. Dann kann es eine Option sein, eine VM mit Exchange 2016 als reinen Provisioning-Server mit vielleicht etwas Mailrouting aufzubauen. Theoretisch könnten Sie auch einen DC samt dem Exchange als AzureVM betreiben. Wenn Sie aber so "klein" sind, dass es lokal gar keine Server mehr gibt, dann könnte auch der Verzicht auf ADSync eine Option darstellen.

Public Folder in die Cloud

Wenn sie auch zukünftig mit öffentlichen Ordnern in der Cloud arbeiten will, dar beim Umzug nicht vergessen, am Ende den Switch durchzuführen und die Clients generell in die Cloud zu verweisen. Prüfen Sie dies mit:

Get-Organizationconfig | fl PublicFoldersEnabled

Hier sollte ein "Remote" oder "Null" aber nicht "Local" rauskommen. Geändert wird dies dann mit:

Set-Organizationconfig `
   -PublicFoldersEnabled remote

Noch einfacher ist es natürlich, wenn Sie gar keine öffentlichen Ordner mehr nutzen

Set-Organizationconfig `
   -PublicFoldersEnabled none `
   -RemotePublicFolderMailboxes $null

Danach können Sie eventuell lokal vorhandene öffentliche Ordner, Öffentliche Ordner Datenbanken (bis Ex2010) oder auch öffentliche Order Postfächer (Ab Ex2013) entfernen.

Autodisover in die Cloud

Es gibt keine lokalen Informationen mehr. Dann ist es auch an der Zeit die Funktion "Autodiscover" in die Cloud zu lenken. Ändern Sie dazu die DNS-Einträge in den DNS-Zonen ihrer SMTP-Domänen auf den Wert, den ihnen Office 365 vorgibt. DNS-Änderungen werden abhängig vom TimeToLive (TTL)-Feld des Eintrags propagiert. Es kann also einige Stunden dauern, bis Clients im Internet dies übernehmen. Kontrollieren Sie einfach ihren bislang extern veröffentlichten Webservice, wie die Anfragen abnehmen.

Auch interne Clients müssen diese URLs gegen das Internet auflösen. Wenn Sie eine "Split-DNS"-Konfiguration fahren, bei denen intern Clients eine interne gleichnamige DNS-Zone auflösen, dann sollten Sie dort den Autodiscover-Eintrag addieren.

Outlook 365 ist davon nicht mehr abhängig sondern nutzt als Fallback auch immer noch s-autodiscover.outlook.com, um solche Fehlkonfigurationen zu umschiffen. Aber es gibt ja noch andere Dienste, die auf "Autodiscover" aufsetzen.

Autodiscover ist natürlich auch intern vorhanden und Outlook erfragt dazu per LDAP vom Domain Controller die Autodiscover-URL. Diese URL sollten wir auf allen internen Servern auf $null setzen, damit Outlook und Co auf DNS schwenken.

# Exchange 2010 und neuer 
Get-ClientAccesService `
| Set-ClientAccessService `
   -AutoDiscoverServiceInternalUri $null

#Exchange 2016 und hoeher
Get-ClientAccesService `
| Set-ClientAccessService `
   -AutoDiscoverServiceInternalUri $null

Damit sollte Outlook den Schwenk auf DNS vollziehen und keine lokalen Exchange Server mehr benötigen.

Postfachdatenbanken entfernen

Wenn die Server nicht mehr tun, dann können Sie zurück gebaut werden. Die Frontend-Rolle (bis Exchange 2010 auch CAS und HubTransport genannt) kann einfach so mit deinstalliert werden. Die Postfachrolle muss erst von seinen Datenbanken befreit werden.

  • DAG: Passive Kopien entfernen
  • Aktive Datenbank löschen
  • DAG auflösen

Server deinstallieren

Kling einfach und ist auch einfach. Ich mache hier auch nichts anderes als über die Systemsteuerung Exchange zu deinstallieren. Sollte ich in der  Vorbereitung etwas vergessen haben, dann wird mich das Setup mit einer Fehlermeldung stoppen und mir die Gelegenheit geben, die vergessenen Daten zu verschieben oder zu entfernen.

DMARC und SPF

Nachdem sichergestellt ist, dass keine Mails mehr von den lokalen Servern ins Internet gehen und jeder Versand z.B. durch die Cloud übertragen wird, können Sie die Konfiguration von SPF und DMARC etwas strenger fassen.

  • SPF Anpassen
    Über die früher aktivierten DMARC-Reports sollten Sie gut erkennen, welche Quellen mit ihrer Domain versenden. Über SPF können Sie dann vorgeben, welche IP-Adressen überhaupt mit ihrem schützenswerten Domainnamen versenden dürfen. Dann ist es an der Zeit alle anderen Quellen aus dem SPF-Record zu entfernen und die Konfiguration mit einem "-all" am Ende abzurunden.
  • DMARC
    Zusätzlich können Sie nun auch über den DMARC-Eintrag die Zielsysteme anweisen, sowohl die SPF als auch DKIM-Einträge entsprechend zu honorieren.

Dies ist ein Zwischenstand vom Oktober 2019. Sie können sicher sein, dass zukünftige Umstellungen natürlich berücksichtigt werden. Wenn Sie aber noch einen wichtigen Schritt vermissen. dann schreiben Sie mir doch einfach Kontakt

Zwischenstand

Mit diesen Schritten sollten Sie nun ihre Exchange On Premises Umgebung soweit zurück gebaut haben, dass vor Ort nur noch ein kleiner Hybrid Connector Server läuft, welchen Sie weiter zu Verwaltung der Exchange Empfänger nutzen müssen und der zugleich weiterhin "Brückenkopf" für SMTP sein kann. Ihr Exchange Online Tenant kann weiterhin per TLS gesichert Mails an Subdomains senden, über die sie On Premises andere Dienste anbinden, z.B. ERP, CRM, Helpdesk, Monitoring etc. und lokale Dienste können Mails intern an dem Hybrid Connector Server abliefert, die von dort dann gesichert und am Spamfilter der Cloud vorbei in ihren Tenant zugestellt werden.

Sie könnten den Hybrid-Mode sogar noch weiter zurück bauen, indem Sie Federation Gateway Organization Trust und SMTP-Connectoren entfernen, so dass am Ende nur noch der Exchange Rumpf-Server zum Provisioning übrig bleibt.

Ich persönlich lasse aber Hybrid am Ende noch bestehen, da speziell das "sicherere Mailrouting" mit On Premises Diensten den meisten Kunden wichtig ist.

Weitere Links