Granikos Technology Blog

Die Migration von E-Mail Postfächern von alternativen E-Mail Servern, wie z.B. Lotus Notes, zu Office 365 ist über das Protokoll IMAP möglich. Die Möglichkeit zur Datenmigration ist in das Office 365 Admin Center implementiert. Über den Menüpunkt Datenmigration können Office 365 Administratoren Postfach-Migrationen zu Office 365 starten. Hierbei werden im Hintergrund die notwendigen Konfigurationen in Exchange Online vorgenommen.

Die nachfolgenden Schritte beschreiben die Migration von Postfächern von einem E-Mail Server mit einer IMAP-Migration, beginnend mit dem Hinzufügen einer neuen Domäne zu Office 365. Für die Einrichtung der IMAP-Migration ist keine vollständige DNS-Konfiguration der Domäne erforderlich. Die Validierung der neuen Domäne ist ausreichend.

An welchem Schritt Sie nun die DNS-Einträge für die MX Ressource Records umstellen, ist Ihnen überlassen und hängt vom Migrationsszenario ab. Sollte die betroffene Domäne weiterhin aktiv für die E-Mail Zustellung verwendet werden, so empfehle ich ein Umstellung der MX-Einträge direkt nach Einrichtung aller Postfächer in Office 365.

Voraussetzungen

Für eine erfolgreiche Migration sind folgende Voraussetzungen notwendig

• Adminkonto auf dem IMAP-Server, um den IMAP-Endpunkt für den Zugriff in Office 365 (Exchange Online) zu konfigurieren
  • E-Mail Adresse und Kennwort
• Liste der zu migrierenden IMAP-Benutzerpostfächer für
  • Anlage neuer Office 365 Benutzer mit zugewiesener Office 365 Lizenz, die einen Exchange Plan enthält
  • IMAP E-Mail-Adresse und Benutzerkennwort zur Synchronisation der Postfachdaten
• Erreichbarkeit des IMAP Endpunktes per TCP 993 aus dem Internet
• Umstellung der MX DNS Ressource Records zur Umstellung der E-Mail Zustellung

Hinzufügen der Domäne zu Office 365

In den folgenden Schritten wird die Domäne azure-usergroup.de als neue Domäne zu einem Office 365 Tenant hinzugefügt.

Schritt 1

Rufen Sie im Office 365 Admin Center den Menüpunkt Setup > Domänen auf und klicken Sie auf Domäne hinzufügen, um den Wizard für eine neue Domäne zu starten.

Geben Sie den Domänennamen ein und klicken Sie auf Weiter.

Schritt 2

Es ist erforderlich, dass Sie die Eigentümerschaft für die Domäne, die Sie hinzufügen möchten, nachweisen. HIerzu stehen Ihnen drei Möglichkeiten zur Verfügung.

1. Validierung mit Hilfe eines TXT Resource Record Eintrages in der Internet DNS Zone der hinzuzufügenden Domäne
2. Validierung mit Hilfe eines MX Resource Record Eintrages in der Internet DNS Zone der hinzuzufügenden Domäne
3. Validierung mit Hilfe eines per E-Mail zu gesandten Codes - Diese Methode steht nur zur Verfügung und wird nur dann angezeigt, wenn die entsprechenden Daten in der DNS Zone hinterlegt sind

Kopieren Sie den TXT-Wert, im aktuellen Beispiel MS=ms81514861 und tragen Sie diesen als Wert für den TXT Resource Record ein.

Je nach DNS Anbieter, kann es mehrere Minuten dauern, bis der Eintrag für Server von Microsoft abrufbar ist. Bei einigen DNS Anbietern kann dies bis zu 24 Stunden in Anspruich nehmen. Wenn Sie bei solch einem Anbieter Ihre DNS Zonen pflegen, sollten Sie über einen Wechsel nachdenken.

Klicken Sie auf Überprüfen, um den TXT Resource Record Eintrag prüfen zu lassen. Wenn der Eintrag erfolgreich geprüft wurde, gelangen Sie zum nächsten Schritt.

Schritt 3

Da Sie die DNS Einträge für Ihre Domäne selber veralten, wählen Sie den Punkt Ich verwalte meine eigenen DNS-Einträge aus und klicken Sie auf Weiter.

Schritt 4

Die Migration der IMAP-Postfachdaten erfordert keine Anpassung der DNS-Einträge für Ihre Domäne. Diese sind erst erforderlich, wenn Sie die Office 365 Dienste bereitstellen und die E-Mail Zustellung zu Exchange Online Protection umstellen möchten.

Wählen Sie die Checkbox am Ende der Seite, um die Aktualisierung der DNS-Einstellungen auszulassen und klicken Sie auf Überspringen. 

Schritt 5

Damit ist die Ersteinrichtung der neuen Domäne in Office 365 abgeschlossen.

Klicken Sie auf Fertig stellen.

IMAP Postfach-Migration 

Nachdem die neue Domäne erfolgreich zu Office 365 hinzugefügt wurde, kann mit der IMAP Migration begonnen werden.

Zur geführten IMAP-Datenmigration zu Office 365 gelangen Sie über den Menüpunkt Setup > Datenmigration.

Einrichtung Benutzerkonten

Vor der Einrichtung der IMAP-Datenmigration über das Office 365 Admin Center müssen Sie die Benutzer in Office 365 anlegen, einen Benutzernamen mit der zu migrierenden Domäne vergeben und eine Office 365 Lizenz zuweisen. Durch diese Zuweisung wird das erforderliche Ziel-Postfach für die Datenmigration erstellt. Der Benutzername in Office 365 kann vom Benutzernamen auf IMAP-Quellseite abweichen.

Im folgenden Beispiel sehen Sie die Erstellung eines Benutzers unter Verwendung der neu hinzugefügten Domäne. Diese Adresse ist sowohl der Office 365 Anmeldename, als auch die neue primäre E-Mail Adresse des Benutzers. 

Optional können Sie neue Benutzer natürlich auch mit Hilfe eines CSV-Datei Imports erstellen.

Schritt 1 : Einrichtung Datenmigration

Im Bereich der Datenmigration bietet Microsoft eine Unterstützung für gängige E-Mail Plattformen an. Die allgemeine E-Mail Datenmigration mit IMAP verbirgt sich unter dem Auswahlpunkt Weitere E-Mail-Quellen.    

Geben Sie den IMAP-Servernamen, den IMAP-Port und die verwendete Sicherheitsmethode an. Eine IMAP-Verbindung ohne Verbindungsverschlüsselung wird nicht unterstützt.

Tragen Sie die E-Mail Adresse des IMAP-Administratorkontos und das dazugehörige Kennwort ein. Klicken Sie anschließend auf Speichern. 

Schritt 2: Start der IMAP-Migration

Wählen Sie das Office 365 Ziel-Konto aus und geben Sie die passende E-Mail Adresse des Quell-Postfaches an. Nach Eingabe der dazugehörigen Kennwortes wird die IMAP-Verbindung zum Postfach überprüft. Wiederholen Sie diesen Schritt für jedes zu migrierende Postfach.

Nach der erfolgreichen Überprüfung des IMAP-Zugriffes können Sie die Migration der Postfachinhalte durch einen Klick auf Migration starten auslösen.

Nach dem Start der Migration erfolgt eine Rückmeldung im Office 365 Admin-Center, dass die Migration in Bearbeitung ist. 

Springen Sie zu Schritt 3, um das nachfolgende Exchange Online Intermezzo zu überspringen.

Intermezzo 1: IMAP-Migration und Exchange Online

Natürlich führt nicht das Office 365 Admin-Center die Migration der Postfächer durch, sondern Exchange Online. Das Office 365 Admin-Center übernimmt die Konfiguration des Migrationsendpunktes, die Erstellung und die Steuerung des Migrationsbatches. Aber wie sieht solch eine erstelle Konfiguration in Exchange Online aus?

Schauen wir uns die Migrationsendpunkte im Exchange Online Admin-Center (EAC) genauer an. Sie finden die Konfiguration der Migrationsendpunkte in der EAC unter:

Empfänger > Migration > ... > Migrationsendpunkte

In der Übersicht der Migrationsendpunkte wurde ein neuer Endpunkt vom Typ IMAP erstellt.

Die Übersicht der Migrationsbatche zeigt den durch das Office 365 Admin-Center konfigurierten Batch und man erkennt, dass in diesem Batch ein Postfach enthalten ist, jedoch noch nicht synchronisiert wurde.

Wählen Sie das IMAP_Batch in der Übersichtsliste aus, um im rechten Fenster die Zusammenfassung des Batches anzuzeigen. Man sieht z.B. die Richtung der Migration (Onboarding) und den aktuellen Gesamtstatus des Batches (Synchronisierung). Hier finden Sie auch Informationen zur zeitlichen Dauer der Migration.

Klicken Sie unterhalb von Postfachstatus auf Details anzeigen, um sich die Liste der im Batch konfigurierten Postfächer und deren Details anzeigen zu lassen. 

Aber nun zurück zum Office 365 Admin-Center.

Schritt 3: Synchronisierte Postfächer

Nachdem im Hintergrund der Migrationsendpunkt in Exchange Online eingerichtet und das Migrationsbatch erstellt wurde, gilt es zu warten. Exchange Online verarbeitet Migrationsbatche in Abhängigkeit der aktuellen Serverlast. Das bedeutet, dass die Einrichtung und der Start einer Migration nicht gleichzusetzen ist mit dem Start der Ausführung. 

Sobald die Erstsynchronisierung abgeschlossen ist, wird das IMAP-Postfach alle 24 Stunden automatisch synchronisiert. Im Office 365 Admin-Center wird im Kopftext zwar angezeigt, dass die Migration erfolgreich abgeschlossen ist, dies ist aber nicht korrekt.   

Dies wird im nächsten Exchange Online Intermezzo deutlich. Springen Sie zu Schritt 4, wenn Sie die IMAP-Migration abgeschliessen möchten.

Intermezzo 2: Status des IMAP-Migrationbatch

In der Übersicht der Exchange Online Migrationsbatche wird deutlich angezeigt, dass das Batch synchronisierte, aber keine finalisierten (abgeschlossenen) Postfächer enthält.

Schritt 4: IMAP-Migration beenden

Über das Office 365 Admin-Center können Sie die IMAP-Migration für jeden Benutzer getrennt beenden. Hierzu wählen Sie einen Benutzer aus, dessen Postfach im Status Synchronisiert ist und klicken auf Migration beenden. Nach der Bestätigung mit Ja wird das ausgewählte Postfach innerhalb des Migrationsbatches finalisiert.

Das bedeutet, dass für diesen Bentuzer eine letzte IMAP-Synchronisierung durchgeführt wird und dieser Benutzer nach Abschluss der Synchronisierung aus dem Migrationsbatch entfernt wird. Alle im Batch verbleibenden Postfächer werden weiterhin alle 24 Stunden synchronisiert.

Wenn kein Postfach mehr Migrationsbatch enthalten ist, haben Sie die Möglichkeit, neue Benutzer auszuwählen und eine Migration zu starten. 

Über die Schaltfläche Verbindung schließen wird die Information über eine laufenden IMAP-Migration aus dem Office 365 Admin-Center entfernt. Nach dem Schließen der Verbindung erreichen Sie über den Menüpunkt Datenmigration die Einstiegsseite der Datenmigration, wie in Schritt 1 beschrieben.

Nachdem alle IMAP-Postfächer zu Office 365 migriert wurden, können Sie mit dem Rückbau der Postfächer auf den Quellsystemen beginnen. 

Intermezzo 3: Exchange Online und der leere IMAP-Migrationbatch

Nach dem Beenden der IMAP-Migrationen und dem Schließen der Verbindung über das Office 365 Admin-Center verbleibt ein leerer IMAP-Migrationsbatch in Exchange Online. Diesen können Sie bedenkenlos über das Papierkorbsymbol löschen. 

Links

• Exchange Online Admin-Center
• Wie funktioniert eine IMAP-Migration

Sie haben Fragen zur IMAP Migration zu Office 365? Nutzen Sie bitte die Kommentarfunktion dieses Blogbeitrages.

Viel Spaß mit Office 365!

Mit Exchange Version 2013 wurden die sog. Modernen Öffentlichen Ordner (Modern Public Folder) eingeführt. In den vorherigen Produktversionen von Exchange Server erfolgte die Replikation der Öffentlichen Ordner mit einer eigenen Replikationstechnologie. Die öffentlichen Ordner bis einschließlich Exchange Server 2010 bezeichnet man als Legacy Public Folder oder als Öffentliche Ordner alter Bauart.

Im April 2017 habe ich bereits die Herausforderungen aufgezeigt, die bei der Migration von Öffentlichen Ordner innerhalb einer lokalen Exchange Organisation auftauchen. Dieser Blogartikel behandelt die Migration von Legacy Public Foldern zu Exchange Online.  

Exchange Online unterstützt die direkte Migration von Legacy Public Foldern aus der lokalen Exchange Organisation zu Modern Public Foldern in Exchange Online. Da es sich hierbei technisch um eine Migration über Exchange Organisationsgrenzen hinweg (sog. Cross-Forest Migration) handelt, ergeben sich ganz eigene Herausforderungen. 

Voraussetzung

Die Postfach-Migration aus einer lokalen Exchange Organisation hin zu Exchange Online erfordert immer die Konfiguration eines Migrationsendpunktes. Über diesen Endpunkt greift Exchange Online auf einen lokal installiert Exchange Server 2016 mit Hybrid Funktion zu.

Das nachfolgende Schaubild zeigt die Zugriffswege für die Migration von Postfächern und die Migration von Öffentlichen Ordnern von Exchange Server 2010 zu Exchange Online. Der Zugriffsweg zur die Migration von Exchange-Postfächern ist grün dargestellt, der für die Migration von Öffentlichen Ordner blau.

Exchange Server 2016 arbeitet bei der Migration von Postfächern als Proxy und nimmt in unserem Beispiel Verschiebeanforderungen von Exchange Online per Exchange Web Service (EWS) unter dem Hostnamen ews.varunagroup.de entgegen. Der Migrationsendpunkt für Exchange-Postfächer kann nicht für die Migration von Legacy Public Foldern verwendet werden. Die Migration der Legacy Public Foldern erfolgt über einen OutlookAnywhere Migrationsendpunkt vom Typ Public Folder. Ein Endpunkt dieses Typs kann im Exchange Admin Center nicht manuell erstellt werden. Die Erstellung erfolgt im Rahmen der Einrichtung des Migrationsbatchs mit Hilfe der Exchange Online Remote PowerShell.  Für die Einrichtung des Migrationsendpunktes wird ein Benutzerkonto (Migrationskonto) im lokalen Active Directory benötigt, dass Organisationsadministrator ist.    

Wenn Sie den externen OutlookAnywhere Zugriff auf Exchange Server 2010 bereits entfernt haben oder ihn noch nie in Betrieb hatten, so müssen Sie diesen Zugriff konfigurieren. Die externe Verfügbarkeit eines OutlookAnywhere Endpunktes ist für die Migration der Legacy Public Folder zu Exchange Online eine Voraussetzung. 

E-Mail aktivierte Öffentliche Ordner

Ein Wort zu E-Mail-aktivierten Öffentlichen Ordnern. E-Mail-aktivierte Öffentliche Ordner hatten in der Vergangenheit ihre Daseinsberechtigung, sind aber in der heutigen Zeit nicht mehr State-of-the-Art. Sie sollten darüber nachdenken, E-Mail-aktivierte Öffentliche Ordner durch eine zeitgemäße Lösung ersetzen. Wenn Sie die Öffentlichen Ordner Hierarchie zu Office 365 migrieren und anschließend zu etwas Neuem wechseln möchten, bringen Sie vielleicht die Funktionen von Microsoft Teams weiter. 

Im Beispiel dieses Artikels gab es zu Beginn der Postfach-Migration in der Exchange Organisation E-Mail-aktivierte Öffentlichen Ordner, die mit Hilfe des Scripts Sync-MailPublicFolders.ps1 (Download) zu Office 365 manuell synchronisiert wurden. Dies war erforderlich, damit Anwender mit einem Postfach in Exchange Online E-Mail-Nachrichten an diese Öffentlichen Ordner senden konnten.  

Als Teil der Vorbereitungen zur Migration der Öffentlichen Ordner zu Exchange Online wurden Funktionen der E-Mail-aktivierten Ordner in Freigegebene Postfächer migriert. Hierzu gehörte damit auch die Deaktivierung der E-Mail Funktionen der betroffenen Öffentlichen Ordner. 

Migrationsschritte

Der Ablauf einer Migration der Öffentlichen Ordner von Exchange Server 2010 zu Exchange Online ist im Grundsatz identisch zur Migration zu Exchange Server 2016 in einer lokalen Exchange Organisation. Der Hauptunterschied liegt in der Konfiguration des Migrationsendpunktes und des Remote-Migrationsbatches.

Die Schritte sind: 

1. Prüfung der Öffentlichen Ordner Namen auf nicht unterstützte Zeichen, wie z.B. "\" "/", und führende oder nachstehende Leerzeichen 
    
   Die Namen der Öffentlichen Ordner müssen vor der Erstellung der Migrationsdateien für eine Migration vorbereitet werden. Sie dürfen keine führenden oder nachstehenden Leerzeichen enthalten. Ebenso dürfen Sie kein "\" oder "/" enthalten, da diese Zeichen in den weiteren Schritten als Trennzeichen für Ordnerebenen identifiziert werden. Hier müssen Sie sich für ein alternatives Trennzeichen entscheiden, wie z.B. "|".  
    
   Hierzu finden Sie in PowerShell-Skript in der TechNet Gallery: https://gallery.technet.microsoft.com/Rename-and-Trim-Legacy-85e483b1 
    
2. Erstellung eines aktuellen Snapshots der gegenwärtigen Öffentlichen Ordner Umgebung 
   
   Hierzu verwenden Sie die von Microsoft im TechNet Artikel bereitgestelten PowerShell Einzeiler. Diese Snapshots haben nur informellen Charakter, da sie in den weiteren Schritten nicht verwendet werden. 
    
3. Download und Ausführung der Legacy Public Folder Migrationsskripte
   
   Laden Sie die Migrationsscripte herunter und führen Sie die Scripte, wie im TechNet Artikel beschrieben aus. 
    
4. Prüfung und Anpassung der Grenzwerte (Quota) zur Bereitstellung von Nachrichten in Modernen Öffentlichen Ordnern in Exchange Online 
    
   Ohne eine Anpassung der Standardgrenzwerte für Modern Public Folder in Exchange Online, steigt das Risiko, dass es bei der Migration der Ordnerinhalte der Legacy Public Folder zu einem Fehler kommt. Der Standardgrenzwert für die Bereitstellung in einen Öffentlichen Ordner ist 2GB.
     

   # Quota für die Migration ganz aufheben
   Set-OrganizationConfig -DefaultPublicFolderProhibitPostQuota Unlimited -DefaultPublicFolderIssueWarningQuota Unlimited

5. Einrichtung des Migrationsendpunktes und Migrationsbatches 
    
   Bei der Einrichtung des Migrationsendpunktes ist es wichtig, dass die Authentifizierungsmethode verwendet wird, die für Ihren OutlookAnywhere Endpunkt konfiguriert ist. Das Beispiel im TechNet konfiguriert Basic als Authentifizierungsmethode. Hier muss als Alternative NTLM konfiguriert werden, wenn OutlookAnywhere in Ihrer Umgebung für NTLM konfiguriert ist. 
    
   Sollte die Legacy Public Folder Hierarchie zu diesem Zeitpunkt noch Fehler, wie z.B. Ordner mit nicht ungültigen Ordnernamen beinhalten, so wird die Einrichtung des Batchs fehlschlagen. In diesem Fall müssen Sie die Fehler beheben und die Einrichtung des Batches wiederholen. 
   
   In diesem Schritt wird das Migrationsbatch nur eingerichtet und nicht automatisch gestartet.
    
6. Start des Migrationsbatchs
   
   Nach dem Start des Batchs erfolgt die erste Synchronisation der Ordnerinhalte und auch der Hierarchie. Nach Abschluss der Synchronisation können Sie für jedes Zielpostfach der Öffentliche Ordner Postfächer prüfen, ob es Probleme mit den Inhalten gab und aufgetretene Probleme beheben. Das Postfach zur Speicherung der primären Hierarchie der Öffentlichen Ordner wird Fehler anzeigen die sich auf die Hierarchie beziehen. Ein Fehlerszenario im Zusammenhang mit E-Mail-aktivierten Ordnern ist unten beschrieben.
   
   Nach Abschluss der ersten Synchronisierung erfolgt alle 24 Stunden eine inkrementelle Synchronisierung.
    
7. Finalisierung des Migrationsbatchs
   
   Mit der Finalisierung des Batchs wird eine letzte Synchronisation der Legacy Public Folder Inhalte ausgelöst. Für die Finalisierung werden die Legacy Public Folder für den Zugriff durch Endanwender gesperrt. Damit diese Sperrung zeitnah angewandt wird, sollten Sie auf den Exchange 2010 Servern, die die Public Folder Datenbank hosten, den Dienst MSExchangeIS neustarten.
   
   Die Finalisierung wird einige Zeit in Anspruch nehmen. Da während dieser Zeit Anwender keine neuen Daten in den Legacy Public Foldern ablegen können, muss diese Finalisierung während eines Wartungsfensters stattfinden.
   
   Tipp
   Kopieren Sie die Datenbanken vor dem finalen Abschluss der Migration auf ein anderes System, um im Anschluss auf die alten Inhalte mit Tools, wie z.B. Veeam Exchange Explorer, zugreifen zu können. Aktivieren Sie vor dem Erstellen der Kopien die Umlaufprotokollierung.
    
8. Testzugriff auf die migrierten Inhalte
   
   Sie testen den Zugriff auf die migrierten Öffentlichen Ordner, indem Sie die erste Public Folder Mailbox für den Zugriff auf die Hierarchie freigeben und für den Test-Benutzer die Default Public Folder Mailbox konfigurieren.
    

   # Erste Public Folder Mailbox freigeben
   Set-Mailbox Mailbox1 -PublicFolder -IsExcludedFromServingHierarchy:$false
   
   # Default Public Folder Mailbox für Test-Benutzer setzen
   Set-Mailbox -Identity JohneDoe@varunagroup.de -DefaultPublicFolderMailbox Mailbox1

9. Abschluss der Migration
   
   Der Abschluss der Migration in der lokalen Exchange Organisation führt dazu, dass die Öffentliche Ordner Hierarchie entfernt wird. Sie haben anschließend keinerlei Möglichkeit mehr, auf normalem Weg auf Daten der Öffentliche Ordner zuzugreifen. Achten Sie nach dem Abschluss der Migration darauf, dass alle Öffentlichen Ordner Postfächer in Exchange Online die Hierarchie bereitstellen. 

   # Alle Public Folder Postfächer für den Hierarchie-Zugriff freigeben
   Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy:$false
   
   # Öffentlichen Ordner Zugriff auf "local" setzen (aus Sicht der Office 365 E-Mail Postfächer)
   Set-OrganizationConfig -PublicFoldersEnabled Local

   
   Die Änderung des Zugriffes auf Öffentliche Ordner wird den Clients über die automatische Konfiguration (AutoDiscover) bereitgestellt. Durch das Caching der Konfiguration kann es mehrere Stunden dauern, bis alle Clients die neue Konfiguration verwenden. Planen Sie diese zusätzliche Zeit in das Wartungsfenster zur Finalisierung ein.

Migrationsfehler mit E-Mail-aktivierten Öffentlichen Ordnern

Wie bereits erwähnt, wurden alle E-Mail-aktivierten Ordner vor der Migration zu Exchange Online deaktiviert und das Skript zur Synchronisation der E-Mail-aktivierten Öffentlichen Ordner mit Office 365 ausgeführt. Leider führt das Skript nicht alle notwendigen Schritte aus, um die Informationen in Exchange Online korrekt zu entfernen.

Fehlermeldung im Migrationsbatch:

"Error: More than N mail public folders in Active Directory were not linked to any public folder during migration. Mail flow will stop working for these public folders after the migration is finalized. Please check whether these are important"

Lösung

Sie müssen die nicht mehr vorhanden Ordner manuell mit Hilfe der Exchange Online Remote PowerShell löschen. Mit dem nachfolgenden Beispiel löschen Sie alle E-Mail aktivierten Öffentlichen Ordner, die mit Hilfe des Skriptes  Sync-MailPublicFolders.ps1 in Exchange Online erstellt wurden.

# Löschung eines einzelnen ehemals E-Mail-aktivieren Öffentlichen Ordners in Exchange Online
Get-MailPublicFolder 'My Mail Public Folder' | Remove-SyncMailPublicFolder

# Löschung aller ehemals E-Mail-aktivierten Öffentlichen Ordner in Exchange Online
Get-MailPublicFolder -ResultSize Unlimited | Remove-SyncMailPublicFolder

Zusammenfassung

Die Migration von Legacy Public Foldern zu Exchange Online ist nicht schwer. Sie erfordert aber, dass die zu migrierende Hierarchie der Öffentlichen Ordner vorbereitet wird und Ordnernamen keinen unzulässigen Zeichen enthalten. Ebenso muss ein passender OutlookAnywhere Endpunkt aus dem Internet erreichbar sein. Ohne einen OutlookAnywhere Endpunkt und ohne ein berechtigtes Migrationskonto kann der Migrationsbatch von Exchange Online keine Daten kopieren.

Stellen Sie die E-Mail-Aktivierung von Öffentlichen Ordnern in Frage und suchen Sie modernere Lösungen. Eventuell notwendige Umzüge von E-Mail-Adressen müssen vor der Migration der Öffentlichen Ordner abgeschlossen sein.

Planen Sie für die Finalisierung der Migration genügend Zeit ein. Im direkten Vergleich zu lokale durchgeführten Modern Public Folder Migrationen benötigten Finalisierungen von Migrationen zu Exchange Online das Vierfache an Zeit. Bedenken Sie, dass nach einer Umstellung des Public Folder Zugriffes für die Postfachnutzer in Exchange Online es noch mehrere Stunden dauern kann, bis die Konfigurationsänderungen durch Outlook Clients genutzt werden.

Viel Spaß mit modernen Öffentlichen Ordnern.

Links

• Download der Public Folder Migrationsscripte
• Use batch migration to migrate legacy public folders to Office 365 and Exchange Online

Exchange Server 2019 ist die aktuelle Version der E-Mail-Messaging Plattform für die Installation in der lokalten IT-Infrastruktur (aka On-Premises). Als lokale Infrastruktur gilt auch die Nutzung von Exchange Server 2019 auf virtualisiserten Serversystemen in Microsoft Azure. Bei Microsoft handelt sich, technisch gesehen, nur um ein ausgelagertes Rechenzentrum. Als wirkliche Alternative zu einem eigenen Betrieb von Exchange Server 2019 steht Ihnen Exchange Online, als Bestandteil des Software-as-a-Service Angebotes von Office 365, zur Verfügung.

Der Betrieb von Exchange Server 2019, die hybride Verbindung zwischen einer lokalen Exchange Organisation und Exchange Online oder die alleinige Nutzung von Exchange Online erfordern eine detaillierte Planung und Vorbereitung. 

Auf dieser Seite finden Sie die wichtigsten Referenz-Links zu Online Ressourcen von Microsoft und anderen Quellen, um das für Sie richtige Exchange Produkt zu installieren, einzurichten und zu betreiben.

Planung einer Exchange Organisation

Wie einleitend schon ausgeführt, kann Exchange grundsätzlich in vier unterschiedlichen Architekturmodellen betrieben werden, die ihre ganz individuellen Vor- und Nachteile bieten. Diese sind:

• Exchange Online (SaaS)
  Hierbei wird Exchange als integraler Bestandteile des SaaS-Angebotes von Office 365 verwendet. Sie nutzen  hierbei immer die aktuellste Version von Exchange Server.
   
• Exchange Hybrid
  Hierbei werden eine lokale Exchange Organisation und Exchange Online parallel betrieben und sind bidirektional miteinander verbunden. Beide Umgebungen können mit der jeweils anderen Umgebung kommunizieren und auf Inhalte.
   
• Exchange Server in Azure (IaaS)
  Hier agiert Azure als Erweiterung Ihrer internen IT-Infrastruktur. Sie betreiben in Azure virtuelle Serversysteme und betreiben dort Exchange Server Systeme. Diese Systeme können auch in einer Hybrid-Anbindung mit Exchange Online betrieben werden. 
   
• Exchange On-Premises
  Dies entspricht einer klassischen Exchange Organisation mit Exchange Server Systemen, die Sie auf Ihren eigenen Serversystemen, virtualisiert oder physikalisch, betreiben.

IT-Responsibility	Exchange Online	Exchange Hybrid	Azure IaaS	On-Premises
Data Governance und Rechtemanagement
Client Endpunkte
Benutzerkonten- und Zugriffsverwaltung
Identitäten und Active Directory Infrastruktur
Netzwerk
Applikationen
Betriebssystem
Physikalische Host-Systeme
Physikalisches Netzwerk
Physikalische Rechenzentren

 = kontrolliert durch Microsoft
 = kontrolliert durch Kunden

• Exchange Server-Unterstützbarkeitsmatrix
• Exchange Server build numbers and release dates
• Exchange-Processor Query Tool: PowerShell Edition
• Exchange Server 2016 Role Requirements Calculator
• Processor Query Tool v1.1
• Outlook license requirements for Exchange features
• Modern public folder deployment best practices

Installation

• Exchange Server 2019 Installationsvoraussetzungen
  Unterstützt sind immer jeweils das aktuelle CU und die beiden vorherigen CUs)
  • Übersicht der Voraussetzungen
  • Visual C++ Redistributable Packages for Visual Studio 2013
  • Microsoft .NET Framework 4.7.2 (Offline-Installer) (RTM, CU1, CU2, CU3)
  • Microsoft .NET Framework 4.8 (Offline-Installer) (CU2 +)
  • Microsoft Unified Communications Managed API 
    • Bestandteil des Exchange Server 2019 Installationsmediums

• Exchange Server 2016 Installationsvoraussetzungen
  Unterstützt sind immer jeweils das aktuelle CU und die beiden vorherigen CUs)
   
  • Übersicht der Voraussetzungen
  • Visual C++ Redistributable for Visual Studio 2012
  • Visual C++ Redistributable Packages for Visual Studio 2013
  • Microsoft .NET Framework 4.5.2 (Offline-Installer)
  • Microsoft .NET Framework 4.6.1 (Offline Installer) (CU2 - CU7)
    • Hotfix-Rollup 3146715 für.NET Framework 4.6 und 4.6.1 in Windows (Windows Server 2012R2)
  • How to temporarily block installation of the .NET Framework 4.7 
  • Microsoft .NET Framework 4.7.1 (Offline Installer) (CU8, CU9, CI10, CU11, CU12)
  • Microsoft .NET Framework 4.7.2 (Offline-Installer) (CU11, CU12, CU13, CU14)
  • Microsoft .NET Framework 4.8 (Offline-Installer) (CU13 +)
  • Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
    • Exchange Server 2019 ISO beinhaltet einen angepassten UCMA-Installer
       

Betrieb

Der Betrieb und die vollständige Verwaltung von Exchange Server erfordern die Verwendung der Exchange Management Shell (EMS). Mit Hilfe des browserbasierten Exchange Admin Center (EAC) können Sie Gelegenheitsaufgaben durchführen. Dies gilt für Exchange Server 2019 ebenso wie für Exchange Online.

• Exchange PowerShell auf Microsoft Docs
• Exchange Online PowerShell Modul mit MFA (Click-to-Run Installation, erfordert für den ausführenden Rechner eine direkte Verbindung ins Internet)
• Sammlung an PowerShell-Skripten für Exchange Server und Exchange Online
• Exchange Server 2019 - Das Handbuch für Administratoren
   
• Exchange Berechtigungen
• Exchange Empfängerobjekte
• Clients und mobile Geräte
• Nachrichtenfluss und Transport-Pipeline
• E-Mail-Adressen und Adressbücher
• Hohe Verfügbarkeit und Ausfallsicherheit

Exchange Online

• Exchange Online Protection IP Addresses

Hybrid Betrieb

• Exchange Hybrid Deployments
• Hybrid Deployment Procedures

Administration

• Add-Ins
  • Specify the administrators and users who can install and manage add-ins for Outlook
  • Add-ins for Outlook in Exchange Online
  • Manage deployment of Office 365 add-ins in the Microsoft 365 admin center

Präsentationen

Migrationswege zu Exchange Server 2019

Exchange Server 2019 MetaCache Datenbank und BIgFunnel

Viel Spaß mit Exchange Server 2019 und Exchange Online.

Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server Installation? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu

Exchange Server besteht aus zwei Kernkomponenten. Zum einen ist es die Bereitstellung von Postfächern, mit all den benötigten Client-Zugriffsprotokollen und Postfach-Funktionen. Die zweite Komponente ist der Nachrichtenfluss, also der Empfang, die Verarbeitung und der Versand von E-Mail-Nachrichten.

Was sich so einfach und trivial anhört, ist ein zentraler und komplexer Baustein in der Exchange Architektur. In diesem Artikel versuche ich ein wenig Licht ins Dunkel des Exchange Nachrichtenflusses zu bringen. Lassen Sie uns mit einem kurzen Rückblick auf die Exchange Server Architektur beginnen.

Die Exchange Server Architektur

Wer sich den Nachrichtenfluss von Exchange Server anschaut, muss sich immer den Funktionsaufbau eines Exchange Servers und die empfohlene Implementierung im Rahmen der Preferred Architecture (PA) in Erinnerung rufen. In der PA wird Exchange Server immer in einer Konfiguration aus mehreren Exchange Servern, die als Datenbankverfügbarkeitsgruppe (DAG) zusammengefasst sind, betrieben. Hierdurch wird eine hochverfügbare Bereitstellung von Postfachfunktionen und Nachrichtentransport erreicht.

Jeder Exchange Server besteht aus einer Frontend- und Backend-Komponente. Eingehende Verbindungen von Drittsystemen erfolgen immer über die Exchange Frontend-Komponenten. Die Kommunikation mit den Backend-Komponenten erfolgt im Regelfall nur Exchange-intern.

Das folgende Diagramm zeigt den schematischen Aufbau der Verbindungen in einer DAG.

Die Konfigurationen für den Nachrichtenfluss unterteilen sich in organisationsweite und serverbezogene Einstellungen. Die organisationsweiten Einstellungen gelten, wie der Name es schon sagt, für die gesamte Exchange Organisation, ganz unabhängig davon wie viele Exchange Server oder  DAGs Sie betreiben. Ob und wie ein Exchange Server diese Einstellungen verarbeiten kann, hängt von der Produktversion ab. Diese Einstellungen sind vollständig in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Sendekonnektoren.

Serverbezogene Einstellungen wirken sich nur für ein bestimmtes Serversystem aus. Diese Einstellungen werden hauptsächlich ebenfalls in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Empfangskonnektoren. Einige wenige Einstellungen werden jedoch auch in der lokalen Systemregistrierung gespeichert.

Für den sicheren und stabilen Betrieb von Exchange Server ist eine funktionierende Active Directory Replikation unerlässlich. Hierzu gehört auch eine korrekte Konfiguration der Active Directory Sites. Sie ist gerade in größeren Exchange Organisationen unerlässlich.

Ebenso wichtig ist die korrekte und einheitliche Konfiguration der TLS-Einstellungen auf allen Exchange Servern. Ohne solch eine Konfiguration ist nicht sichergestellt, dass verschlüsselte Verbindungen durch die Empfangs- und Sendekonnektoren aufgebaut werden können. Exchange Server vertraut hier auf die Konfiguration des lokalen Windows Server Betriebssystems und die Bereitstellung gültiger TLS-Zertifikate.

Kommen wir nun zum eigentlichen Thema, dem Exchange Nachrichtenfluss und beginnen mit dem Empfang von E-Mail-Nachrichten.

Der Empfang von Nachrichten

Exchange Server nehmen eingehende E-Mail-Nachrichten über unterschiedliche Wege entgegen. Der bekannteste Weg ist der Empfang über das Protokoll SMTP. Ein Exchange Server unterscheidet hierbei drei unterschiedliche Quelltypen. Im Frontend-Transport erfolgt die Annahme von Verbindungen anderer Server über den Standard TCP-Port 25. Zu den Servern, die sich über diesen Standard SMTP-Port verbinden, zählen:

• Externe E-Mail-Server fremder E-Mail-Domänen, die E-Mail-Nachrichten über das Internet an Ihren Exchange Server senden
• Interne Applikationsserver, die E-Mail-Nachrichten an interne und externe Empfänger senden und einen Exchange Server als sog. Relay-Server verwenden
• Andere interne Exchange Server anderer Produktversionen oder Exchange Server, die in anderen Active Directory Sites platziert sind

Diese Verbindungen erfolgen über den Default Frontend Konnektor, der in seiner Standardkonfiguration nur Nachrichten, die an bekannte Empfänger eigener Domänen entgegennimmt. Die Zustellung von Applikationsnachrichten an externe Empfänger erfordert die Erstellung eines separaten Frontend-Empfangskonnektor.

Zusätzlich zu den Empfangskonnektoren stehen zwei weitere Wege über das lokale Dateisystem des Exchange Servers zur Verfügung, das Pickup- und Replay-Verzeichnis. Beide Verzeichnisse werden vom Backend-Transportdienst, den Sie aus früheren Exchange Versionen sicher noch als Hub-Transport kennen, permanent überwacht und sobald eine Datei dort abgelegt ist, wird sie aufgenommen und verarbeitet. Das Pickup-Verzeichnis dient der Ablage von neuen E-Mail-Nachrichten durch Applikationen. Das Replay-Verzeichnis können Sie nutzen, um Nachrichten, die Sie aus einer Warteschlange exportiert und entfernt haben, erneut in die Verarbeitung zu übergeben.

Zum Schutz vor unberechtigten Verbindungen verwendet Exchange Server unterschiedliche Formen der Authentifizierung. Ergänzend verfügen die Eingangswege über eine Header-Firewall, mit der unberechtigte Informationen aus einer E-Mail-Nachricht herausgefiltert werden.

Der Frontend-Transport verfügt über keine komplexe Business-Logik. Daher ist es wichtig, das Zusammenspiel zwischen Frontend-Transport und Transportdiensten im Backend zu verstehen und sich immer wieder in Erinnerung zu rufen, wenn es zu Problemen kommt. Der Empfangskonnektor im Frontend-Transport nimmt die Verbindung entgegen und führt die Authentifizierung durch. Anschließend wird eine Proxyverbindung zum Transportdienst per TCP-Port 2525 aufgebaut. Hierbei entscheidet nun die Konfiguration Ihrer Exchange Umgebung darüber, wie diese Proxyverbindung erfolgt. Bei einem Einzelserverbetrieb erfolgt die Verbindung zum Transportdienst des gleichen Servers. In einer DAG-Konfiguration wählt der Frontend-Transport den Transportdienst des DAG-Mitgliedservers aus, auf dem in diesem Moment die Datenbankkopie mit dem Postfach des Empfängers aktiv eingebunden ist.

Das folgende Diagramm zeigt das Zusammenspiel zwischen Frontend und Backend beim Empfang von Nachrichten per SMTP.

Beim Empfang einer Nachricht per SMTP versucht Exchange Server die Nachricht ausfallsicher entgegenzunehmen. Zu diesem Zweck erstellt Exchange Server eine Kopie der empfangenen Nachricht und speichert sie als Schattenkopie im Transportdienst eines anderen Exchange Servers. Erst nach dem erfolgreichen Speichern der Schattenkopie und der Speicherung in der lokalen Warteschlange des Backend-Transportdienstes, meldet der empfangende Exchange Server dem sendenden Server eine OK-Meldung.

Auf einem Exchange Server können mehrere Empfangskonnektoren für den gleichen Port konfiguriert werden. Wenn Sie weitere Konnektoren für den gleichen Port erstellen, müssen Sie festlegen, wie Exchange Server einen Konnektor auswählen soll. Am einfachsten ist hier die Konfiguration der IP-Adressen des absendenden Systems als Remote IP-Adresse am Konnektor.

Im Backend des Exchange Servers befinden sich zwei Transportdienste. Der wichtigste Dienst ist der Transportdienst, den manche von Ihnen sicher noch als Hub-Transport aus älteren Versionen von Exchange Server kennen. Diesen Dienst schauen wir uns im nächsten Abschnitt einmal genauer an. Der zweite Dienst ist der Postfachtransportdienst. Dieser Dienst hat die Aufgabe, eingehende Nachrichten in Postfächern lokal eingebundener Datenbanken zu speichern und Nachrichten, die versendet werden sollen, aus Postfächern lokaler Datenbanken zu lesen und zur weiteren Verarbeitung an den Transportdienst zu übermitteln. Diesen Dienst beschreibe ich in einem zukünftigen Artikel.

Der einfach erscheinende Empfang einer E-Mail-Nachricht ist, aus Gründen der Nachrichtensicherheit und zum Schutz vor dem Ausfall eines Systems, eine komplexe Aufgabe. Nach dem Empfang der Nachricht muss sie verarbeitet werden.

Die Verarbeitung von Nachrichten

Die gesamte Verarbeitung von E-Mail-Nachrichten erfolgt im Transportdienst und ist Warteschlangen-basiert, mit der Betonung auf „Warte“. Eine empfangene E-Mail-Nachricht wird in der Submission-Warteschlange gespeichert und wartet dort darauf, zur sog. Kategorisierung aufgegriffen zu werden. In der Categorizer-Komponente erfolgt die Hauptarbeit des Transportdienstes. Zu den Aufgaben gehören:

• Auflösung der Empfängeradressen
• Entscheidung über das Routing der Nachricht, auf Basis der in diesem Moment geltenden Topologie-Informationen
• Konvertierung des Nachrichteninhaltes
• Aufteilung der Nachricht in weitere Nachrichten
  • Aufteilung der Nachricht an mehrere Empfänger
  • Auflösung der Empfänger einer adressierten Verteilerliste
• Paketierung der Nachricht oder Nachrichten zur Zustellung
• Erstellung von Delivery Status Notifications (DSN)

Nach der Verarbeitung im Categorizer ist die Nachricht bereit zur weiteren Zustellung und wird hierzu in einer passenden Warteschlange gespeichert. Der Transportdienst legt für jedes Zustellungsziel eine separate Warteschlange an. Dies ist der Grund, warum Sie immer eine unterschiedliche Anzahl an Warteschlangen auf einem Exchange Server sehen. Die Warteschlangen gliedern sich in unterschiedliche Kategorien:

• Lokale Zustellung an eine aktive Postfachdatenbankkopie, die das Postfach des Empfängers beinhaltet
• Remote Zustellung an eine aktive Postfachdatenbankkopie in der gleichen DAG, die das Postfach des Empfängers beinhaltet
• Remote Zustellung an einen beliebigen Mitgliedsserver einer anderen DAG zur weiteren Zustellung an Postfächer in dieser DAG
• Zustellung an einen konfigurierten Exchange Server eines Sendekonnektors eines Zieladressraumes
• Zustellung an Remote-Domänen über einen definierten Smarthost
• Zustellung an Remote-Domänen mit DNS-basierter MX-Auflösung für die Ziel-Domäne

Zur Speicherung der Warteschlangen verwendet der Transportdienst auf jedem Exchange Server eine eigene Datenbank. In dieser Datenbank werden alle Nachrichten mit ihrem jeweiligen Verarbeitungs- und Zustellungsstatus gespeichert. Der Transportdienst kümmert sich eigenständig um den Funktionsstatus der Datenbank. Kommt es zu einem nicht behebbaren Fehler, wir eine komplett neue Datenbank erstellt und die korrupte Datenbank in einen neuen Ordner verschoben.

Das folgende Schaubild zeigt die Hauptkomponenten zur Verarbeitung von E-Mail-Nachrichten im Exchange Transportdienst.

Leider steht uns für die aktuelle Version Exchange Server kein detailliertes Diagramm des Transportdienstes offiziell zur Verfügung. Im Microsoft Download Center steht das Diagramm von Exchange Server 2010 zur Verfügung und bietet einen guten konzeptionellen Überblick über den Transportdienst. Achten Sie auf die Unterschiede zu modernen Exchange Server Versionen.

Das Routing von Nachrichten

Anwender leben in der Illusion, dass die Zustellung von E-Mail-Nachrichten eine einfache Sache ist und haben meist kein Verständnis für eine verzögerte Zustellung von Nachrichten. In Zeiten von Gigabit-Leitungen und schier unerschöpflicher Computer-Ressourcen hat man sich daran gewöhnt, dass Nachrichten nahezu in Echtzeit übertragen werden.

Einen wesentlichen Beitrag zu einer schnellen und fehlerfreien Verarbeitung leistet das korrekte Routing einer E-Mail-Nachricht. Damit eine Nachricht von Exchange Server fehlerfrei verarbeitet und zugestellt werden kann, ist eine fehlerfreie Active Directory Gesamtstruktur unerlässlich. Die im Exchange Transportdienst aktiven Routing-Agenten arbeiten mit den Informationen, die im Active Directory gespeichert sind. Dies sind u.a.:

• Adressen von Exchange Empfängerobjekten
  • Inkonsistente, fehlerhafte Einträge und identische Einträge an mehreren Objekten sind eine häufige Fehlerquelle
  • Verwaiste Objekte von E-Mail-aktivierten Öffentlichen Ordner gehören ebenso zu den Fehlerquellen
• Konfiguration der Exchange Organisation
  • Verwaiste Server- und Konnektoreinstellungen durch nicht korrekt durchgeführte Deinstallationen können zu Fehlern und Verzögerungen beim Routing führen
• Active Directory Site-Konfiguration
  • Eine fehlerhafte Konfiguration der AD-Sites kann zu Fehlern bei der Zustellung und bei der Nutzung von Schattenkopien führen

Beim Routing einer Nachricht spielt auch die Nachrichtengröße eine Rolle. Exchange zieht mehrere Konfigurationen zu maximalen Nachrichtengröße in Betracht, um so zu bewerten, ob die Nachricht auch wirklich zugestellt werden kann. Kann eine Nachricht nicht zugestellt werden, erhält der Absender einen sog. Non-Delivery Report (NDR). Der Transportdienst betrachtet für die Ermittlung der erlaubten Nachrichtengröße die Konfigurationen auf Organisationsebene, die aller Sende- und Empfangskonnektoren der internen Verbindungsstrecke und die Einstellungen des Zielpostfaches.

Der Versand von Nachrichten

Sendekonnektoren arbeiten die Nachrichten in den Warteschlangen ab und versuchen das jeweilige Zielsystem mit den Konnektoreinstellungen zu erreichen. Eine korrekte DNS-Namensauflösung ist der Schlüssel zu einer fehlerfreifunktionierenden Exchange Infrastruktur. Die interne Namensauflösung ist selten eine Fehlerquelle. Anderes sieht es aus, wenn es um die DNS-Auflösung externer Domänen geht. Stellen Sie sicher, dass Ihre Exchange Server auch externe Domänen effizient und sicher auflösen können, um einen fehlerfreien Nachrichtenfluss mit externen Empfängern zu gewährleisten.

Kommt es beim Versuch einer Zustellung zu einem Fehler, wird der Fehler in der Warteschlange festgehalten. Im Regelfall erkennen Sie Zustellfehler am Anwachsen einer oder mehrerer Warteschlangen. Die Überwachung der Warteschlangengröße ist unerlässlich für einen stabilen Betrieb der Exchange Organisation.

Bedenken Sie, dass die Datenbank des Transportdienstes im Installationspfad eines Exchange Servers platziert ist. Wenn Ihre Exchange Server eine hohe Anzahl von Nachrichten verarbeiten muss, sollten Sie die Datenbank auf einem separaten und ausreichend dimensionierten Laufwerk platzieren.

Zusammenfassung

Der Exchange Server Nachrichtenfluss ist, wenn man unter die Motorhaube schaut, ein komplexes Gebilde. Mit einem richtig konfigurierten Active Directory sind keine Probleme beim Betrieb von Exchange Server zu erwarten. Die Herausforderungen für den Exchange Nachrichtenfluss beginnen mit der Anpassung der Exchange Konfiguration.

Gerade im Hinblick auf die Konfiguration von zusätzlichen Empfangskonnektoren müssen Sie sich immer fragen, ob Sie einen neuen Konnektor wirklich benötigen. Das Troubleshooting des Exchange Nachrichtenflusses ist nicht schwierig, jedoch zeitaufwendig. Gerade in Exchange Umgebungen, die seit einigen Jahren betrieben werden und mehrere Exchange Versionen gesehen haben, besteht ein Risiko, dass veraltete Einträge in der Konfigurationspartition den Betrieb stören. Gleiches gilt für die Exchange Empfängerobjekte. Eine regelmäßige Pflege vermeidet Störungen im Nachrichtenfluss.

Der tägliche Betrieb Ihrer Exchange Organisation wird durch ein proaktives Monitoring, in dem nicht nur der Nachrichtenfluss überwacht wird, einfacher. Neben der Überwachung der Warteschlangen, empfehle ich auch die Überwachung der Transportdienste selbst. Exchange Server verfügt mit der Funktion der Managed Availability zwar über eine integrierte Monitoring Lösung mit automatischen Recovery-Aktionen, jedoch möchten Sie sicher nicht von automatisch neustartenden Diensten überrascht werden.

Links

• Microsoft Exchange Server 2010 Transport Server Role Architecture Diagrams
• Message size and recipient limits in Exchange Server
• DNS and Report Types
• Exchange 2016 + 2019 Mail Flow with Ports

Viel Spaß mit Exchange Server.

Mailscape 365 - Überwachung von Hybrid Exchange und Office 365: Viele Unternehmen verwenden eine lokale Exchange Organisation und Exchange Online in einer Hybrid-Konfiguration, um die Anforderungen ihrer Mitarbeiter zu erfüllen. Der Betrieb einer hybriden Exchange Organisation seine ganz eigenen Herausforderungen für das Monitoring der Dienstverfügbarkeiten. Beginnen Sie noch heute einen unverbindlichen 14-Tage Test von Mailscape 365.

Migration and consolidation projects in the IT field face technical challenges that are individual to each infrastructure. Internal IT projects can be executed following well established organizational processes and requirements.

Projects related to M&A programs face additional and very unique requirements and constraints. These constraints tend to be agile and require to work outside of the well-established processes valid for internal projects. Especially the constraints provided by the M&A process itself might require immediate adjustments or major changes.

Our real-world experiences from global M&A IT consolidations can help you to lead your M&A program to success. Whether it is an internal infrastructure consolidation handling get-well activities in preparation for a takeover or merging of global IT landscapes in the context of a corporate takeover, our professional program team will assist you from establishing the technical design to project planning, execution, and monitoring.

Some of our experiences have been summarized in a PowerPoint slide deck. The scenario shows

• Internal consolidation of a global IT infrastructure
  • Active Directory landscape which included more than 20 Active Directory domains and more than 7,000 accounts
  • Exchange landscape which included more five different Exchange organizations (partially hosted at an external provider) in preparation of an Office 365 Migration

• Merging of two global IT infrastructures as part of a global M&A program
  • Migration of all user accounts to a new single Active Directory domain
  • Migration of more than 13,000 Exchange mailboxes to Office 365
  • Launch of a new single email Domain across seven Exchange organizations
  • Migration of regional file server data to central data centers
  • Rollout of network infrastructure to each acquired regional Office, including new VPN Solutions
  • Rollout of new client hardware for all employees in the acquired enterprise
  • Rollout of a global data backup solution, including cloud storage
  • Consolidation of regional service desks into a single global service desk team

The following pictures demonstrate the situation pre-merger:

We are keen to share our experiences to help you to bring your migration activities to success. Ask for a workshop today: info@granikos.eu

Was bedeutet Exchange Server Hybrid?

Eine lokale Exchange Organisation eines Unternehmens kann mit Exchange Online, einer der Kernbestandteile von Microsoft 365, verbunden werden. Diese Verbindung erfolgt durch die sog. Hybrid-Konfiguration und ist eine besondere Vertrauensstellung zwischen zwei technisch getrennten Exchange Umgebungen.

Diese besondere Vertrauensstellung zwischen der lokalen Exchange Organisation und Exchange Online ist notwendig, damit E-Mail- und System-Nachrichten, die zwischen beiden Umgebungen unsgetauscht werden, als interne E-Mail-Nachrichten erkannt und verarbeitet werden. Nur so ist es möglich, die korrekte Funktion aller Exchange Komponenten, unabhängig vom Bereitstellungsort der Benutzerpostfächer, zu gewährleisten.

Welche Vorteile ein Exchange Hybrid-Betrieb für die Exchange Umgebung in Ihrem Unternehmen hat, erfahren Sie in diesem Microsoft Docs Artikel.

Das folgende Schaubild verdeutlicht die Hybrid-Konfiguration und die besondere Vertrauensstellung (gepunktete grüne Linie).

Eine Exchange Hybrid-Konfiguration richten Sie mit Hilfe des Hybrid Confguration Wizard (HCW) ein. Während der HCW-Einrichtung müssen Sie sich für eine der zur Verfügung stehenden Möglichkeiten für den Hybrid-Betrieb entscheiden.

Welche Optionen für den Hybrid-Betrieb gibt es?

Für den Hybrid-Betrieb einer lokalen Exchange Organisation mit Exchange Online gibt es mehrere Möglichkeiten. Wir unterscheiden zwei grundlegende Betriebsvarianten, den klassischen und den modernen Hybrid-Betrieb. Für diese beiden Varianten stehen je bis zu drei Betriebsmodi zur Verfügung.

Das folgende Schaubild verdeutlich die unterschiedlichen Betriebsmodi für die beiden Betriebsvarianten einer Hybrid-Konfiguration.

Nun stellt sich automatisch die Frage, welchen Betriebsmodus soll ich für Hybrid-Konfiguration meiner Exchange Organisation verwenden?

Schauen wir uns zuerst an, welche technischen Voraussetzungen die beiden Betriebsvarianten haben.

Klassischer Hybrid-Betrieb

Der klassische Hybrid-Betrieb erfordert, dass interne Exchange Server aus dem Internet über das Protokoll HTTPS erreichbar sind. Über diese Verbindung erfolgt die Kommunikation von Exchange Online zur internen Exchange Organisation für Hybrid-Funktionen. Damit einher geht die Anforderung für eine aus dem Internet erreichbare IP-Adresse und die Verwendung eines offiziellen TLS-Zertifkates.

Moderner Hybrid-Betrieb

Der moderne Hybrid-Betrieb erfordert keinerlei eingehende HTTPS-Verbindung von Exchange Online zur internen Exchange Organisation. 

Die Verbindung zwischen der lokalen Exchange Organisation und Exchange Online erfolgt über den Exchange Hybrid Agent. Die Software für den Exchange Hybrid Agent ist als Dienst auf einem Server installiert und verbindet sich über eine ausgehende HTTPS-Verbindung mit Exchange Online. Die Konfiguration durch den HCW steuert hierbei das Verhalten von Exchange Online. Mit Blick auf den Hybrid-Betrieb von Exchange ist dies die bevorzugte und schnellste Betriebsvariante, da keinerlei zusätzliche Komponenten für eingehende HTTPS-Verbindungen benötigt werden. Wenn Ihr Unternehmen jedoch Microsoft Teams verwenden möchte und weiterhin Postfächer von Teams-Anwendern auf lokalen Exchange Servern betrieben werden sollen, können Sie diese Betriebsvariante nicht nutzen. Microsoft Teams unterstützt für dieses Betriebsszenario nur den klassischen Hybrid-Betrieb.

Klassicher und Moderner Hybrid-Betrieb

• Beide Betriebsvarianten benötigen für den hybriden Nachrichtenfluss ein- und ausgehende SMTP-Verbindungen zwischen der lokalen Exchange Organisation und Exchange Online.
   
• Beide Betriebsvarianten erfordern ausgehende HTTPS-Verbindungen zu Exchange Online von den internen Exchange Server Systemen.

Für welches Betriebs- und Migrationsszenario passen die fünf Betriebsmodi?

		Vollwertige, klassische Hybrid-Konfiguration mit direkter Veröffentlichung der Exchange Organisation ins Internet (SMTP/HTTPS) Dauerhafter Hybrid-Betrieb Postfächer On-Premises und in Exchange Online
		Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online Temporärer Hybrid-Betrieb über wenige Monate Ziel: Migration aller Postfächer zu Exchange Online
		Hybrid-Konfiguration, inkl. Azure AD Connect Express Setup, zum einmaligen Verschieben aller Postfächer zu Exchange Online Temporärer Hybrid-Betrieb über wenige Tage oder Wochen Ziel: Migration aller Postfächer zu Exchange Online
		Vollwertige, klassische Hybrid-Konfiguration für neue Konfigurationen mit Hilfe des Exchange Hybrid-Agenten, jedoch mit Funktionseinschränken Dauerhafter Hybrid-Betrieb Postfächer On-Premises und in Exchange Online
		Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online mit Hilfe des Exchange Hybrid-Agenten Temporärer Hybrid-Betrieb über wenige Monate MIgration aller Postfächer zu Exchange Online

Herausforderungen

Die Implementierung eines Hybrid-Betriebes stellt Ihr Unternehmen vor technische Herausforderungen. Daher muss die Einrichtung des hybriden Exchange Betriebes gut geplant werden.

Für den klassischen Hybrid-Betrieb benötigen Sie externe IP-Adressen für die beiden Protokolle HTTPS und SMTP, während für den modernen Hybrid-Betrieb nur eine IP-Adresse für das Protokoll SMTP benötigt wird. Ebenso benötigen Sie TLS-Zertifikate. Für den Nachrichtenfluss zwischen der lokalen Exchange Organisation und Exchange Online empfehle ich, ein separates TLS-Zertifikat zu verwenden, das nicht für das E-Mail-Internet-Gateway verwendet wird. 

Die Absicherung der internen Exchange Server vor direkten Zugriffen aus dem Internet hat höchste Priorität. Sichern Sie den E-Mail-Nachrichtenfluss der hybriden Verbindung zwischen der lokalen Exchange Organisation und Exchange Online mit Exchange Edge-Servern ab. Der HTTPS-Zugriff zu den internen Exchange Server von Exchange Online wird über Reverse-Proxies abgesichert.

Bei einem dauerhaften Hybrid-Betrieb ist die lokale Exchange Organisation für die Verwaltung der zu Exchange Online verschobenen Exchange-Objekte zuständig. Im Zusammenspiel mit dem lokalen Active Directory bleibt sie die Source of Authority (SOA). Aus diesem Grund benötigen Sie mindestens einen verbleibenden lokalen Exchange Server, der als sog. Koexistenz-Server betrieben wird. Hierzu sollten Sie einen System mit Exchange Server 2016 oder Exchange Server 2019 verwenden.

Fazit

Mit einer Auswahl von zwei Betriebsvarianten und insgesamt fünf Betriebsmodi fällt es nicht leicht, die passende Wahl zu treffen. Die wichtigste Frage, die Sie sich zuerst stellen müssen ist, wie soll die Bereitstellung von Exchange Funktionen in Zukunft für das Unternehmen aussehen und welche Anforderungen hat das Unternehmen im Hinblick auf die Absicherung von E-Mail-Nachrichten? Sind Anwender-Postfächer in der lokalen Exchange Organisation bereitgestellt und in Ihrem Unternehmen soll Microsoft Teams genutzt werden, so ist die klassische Voll-Hybrid-Variante die einzige Option.

Die größte Flexibilität erreichen Sie mit dem klassischen Hybrid-Betrieb, jedoch ist dies auch die Variante mit den meisten Anforderungen zur Einrichtung und den dauerhaften Betrieb.

Mit dem modernen Hybrid-Betrieb erreichen Sie schnell eine Hybrid-Konfiguration und können zügig Postfächer zu Exchange Online migrieren. Bei Nutzung von Microsoft Teams und Anwender-Postfächern in der lokalen Exchange Organisation ist dies jedoch keine Option. 

Links

• Exchange Server Hybridbereitstellungen
• Voraussetzungen für die Hybridbereitstellung
• Einschränkungen für den Exchange Hybrid Agent
• Tech Talk 3: Exchange Hybrid (Video)

Viel Spaß mit einem sicheren Exchange Online.