shop high quality replique rolex.

discover the luxury rolex imitacion online watch store.

replica watches are the best qulity online.

swiss replica watches owns a high factor within throughout the world watch business sector.

richard mille fakes are the perfect mix between italian design and swiss technology at the service of the passion for the sea.

de-DEen-GB
Search
Blog
rss

Granikos Technology Blog

Tech Talk - 2 - Migrationsmöglichkeiten zu Exchange Online

On Februar 24, 2020
Thomas Stensitzki | MVP
0 Kommentar
Exchange Online, Exchange Server, Office 365, TechTalk, Video
Deutsch, Exchange, Microsoft 365
988 Views
Tech Talk - 2 - Migrationsmöglichkeiten zu Exchange Online

Folge 2

Das zweite Video der 'Tech Talk'-Reihe ist bei YouTube verfügbar. 

Das Thema des Talks:

  • Migrationsmöglichkeiten von Exchange Server zu Exchange Online

Im Tech Talk 2 erhalten Sie einen Überblick über die unterschiedlichen Möglichkeiten, wie Sie eine lokale Exchange Organisation zu Exchange Online migrieren.

 

 

Links

 

Viel Spaß.

 

 

Verbundene Einträge

  • Thomas' Tech Talk - Übersicht
    Thomas' Tech Talk - Übersicht

    Thomas' Tech Talk YouTube-Kanal

     

    Tech Talk Folgen

     

    Weitere Links

     

    Geplante Themen

    • Power Plattform - On-Premises Data Gateway
    • Exchange Server und HealthChecker
    • ...

     

    Kurzlink zu dieser Seite: http://techtalk.granikos.eu

     

  • Exchange Server 2019 und Exchange Online
    Letzte Aktualisierung am 23. April 2021


    Exchange Server 2019 LogoExchange 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 Blue Arrow Blue Arrow Blue Arrow Blue Arrow
    Client Endpunkte Blue Arrow Blue Arrow Blue Arrow Blue Arrow
    Benutzerkonten- und Zugriffsverwaltung  Blue Arrow Blue Arrow Blue Arrow Blue Arrow
    Identitäten und Active Directory Infrastruktur Arrow Grey Blue Arrow Arrow Grey Blue Arrow Blue Arrow Blue Arrow
    Netzwerk Arrow Grey Arrow Grey Blue Arrow Blue Arrow Blue Arrow
    Applikationen Arrow Grey Arrow Grey Blue Arrow Blue Arrow Blue Arrow
    Betriebssystem Arrow Grey Arrow Grey Blue Arrow Blue Arrow Blue Arrow
    Physikalische Host-Systeme Arrow Grey Arrow Grey Blue Arrow Arrow Grey Blue Arrow
    Physikalisches Netzwerk Arrow Grey Arrow Grey Blue Arrow Arrow Grey Blue Arrow
    Physikalische Rechenzentren Arrow Grey Arrow Grey Blue Arrow Arrow Grey Blue Arrow

    Arrow grey = kontrolliert durch Microsoft
    Arrow blue = kontrolliert durch Kunden

     

     

    Installation

     

    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 Online

     

    Hybrid Betrieb

     

    Administration

     

    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

  • Möglichkeiten für Exchange Hybrid
    You can read the English version of this post at ENow ESE blog: What are your Exchange Hybrid options? 

     

    Logo Exchange Server 2019Was 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).

    Diagramm Hybrid-Konfiguration als Vertrauensstellung zwischen On-Premises Exchange and Exchange Online

     

    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.

    Grafik Übersicht der Optionen für einen Exchange Hybrid-Betrieb

     

    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?

    Grafik - Klassisch Grafik - Klassisch-Voll-Hybrid

    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
    Grafik - Klassisch-Minimal-Hybrid

    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
    Grafik - Klassisch-Minimal-Hybrid

    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
    Grafik - Modern Hybrid Grafik - Modern-Voll-Hybrid

    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
    Grafik - Modern-Minimal-Hybrid

    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

     

    Viel Spaß mit einem sicheren Exchange Online.

     

     

     

     

  • Blog Cumulative Update Oktober 2015

    Das Exchange Blog Cumulative Update für Oktober 2015 (CU1015) fasst interessante Themen rund um Exchange Server und Office 365 (Exchange Online), Azure und Skype for Business (aka Lync) des Monats Oktober 2015 zusammen.

    Exchange Server

    Office 365 & Exchange Online

    Skype for Business, Lync Server & Communication

    Windows Azure

    Allgemeine Themen & Sicherheit

    Replay

    Podcast Empfehlungen

    Tools / Software

     

    Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.

    Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und ausführlich über die Möglichkeiten der Office 365 Plattform.

    Sie möchten mehr über Exchange Server 2016 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Möglichkeiten für Ihr Unternehmen in einem persönlichen Workshop.

    Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder nehmen Sie direkt mit uns Kontakt auf: info@granikos.eu

     

     

     

  • Migration von Legacy Public Foldern zu Exchange Online
    The English version has been published at ENow's ESE Blog Migration of Legacy Public Folder to Modern Public Folder in Exchange Online


    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.

    Es sei an dieser Stelle erwähnt, dass es keine installationsfähige Exchange-Betriebsrolle "Hybrid Server" gibt. Wenn Sie zur Lizensierung eines lokalen Exchange 2016 Servers die von Microsoft im Office 365 Tenant bereitgestellte Exchange Server Lizenz einspielen, wird als Betriebsrolle "Hybrid" angezeigt.  

    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.

    Migrationswege für Legacy Public Folder und Mailbox Migrationen

    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. 

    Hinweis zum Diagramm 
    Zur besseren Lesbarkeit wurden notwenige Komponenten zur Veröffentlichung der internen Exchange Endpunkte im Internet nicht mit eingezeichnet.

     

    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

     

     

  • Die richtige Exchange Architektur
    Dies ist die deutschsprachige Version meines Blog Posts The Right Exchange Architecture im ESE Blog von ENow


     

    Warum gibt es die Preferred Architecture?

    Exchange Server ist ein sehr tolerantes Produkt und lässt sich in unterschiedlichste IT-Infrastruktur-Varianten installieren. Einige der möglichen Infrastruktur-Varianten sind gut geeignet für den Betrieb von Exchange Server, andere leider weniger gut. Daher ist es immens wichtig, bei der Planung einer Exchange Server Umgebung die notwendige Sorgfalt walten zu lassen.

    Basis für die Planung einer Exchange Server Implementierung ist der Hauptgrundsatz für moderne Exchange Server Versionen:

    Die Hochverfügbarkeit von Exchange Server wird auf der Applikationsebene umgesetzt.


    Dieser Hauptgrundsatz wird, wie die Erfahunrg zeigt, leider allzu häufig ignoriert. Dieser Ignoranz wird in vielen Fällen dadurch Vorschub geleistet, dass Hard- und Software-Hersteller ihre ganz eigenen Hochverfügbarkeitslösung (HA) verkaufen möchten. Zu diesen Lösungen gehören sowohl HA-Funktionen von Hypervisor-Plattformen, aber auch, und dies viel häufiger, HA-Lösungsansätze von Storageanbietern.

    Die Standardisierung einer Plattform wird nicht dadurch erreicht, indem eine unnötig komplexe Infrastruktur zum Standard erklärt wird, sondern das eine möglichst einfache Implementierung der Exchange Server Plattform zum Standard gemacht wird.

    Unzählige Supportanfragen bei der Exchange Produktgruppe (PG) haben die Preferred Architecture Empfehlung über die Jahre reifen lassen. Sie ist daher keine spontan entstandene Empfehlung. Sie ist entstanden aus den Anforderungen und Kenntnisgewinnen im täglichen Betrieb der hochverfügbaren Cloudinfrastruktur von Exchange Online.

    Sicherlich werden Sie nun einwenden, dass Sie keine Cloud-Plattform betreiben möchten. Sie dürfen nicht vergessen, dass eine moderne Exchange Server Version hochverfügbar betrieben werden möchte. Vergessen Sie daher nicht den Hauptgrundsatz für moderne Exchange Server Versionen ab Version 2013.

    Die Hochverfügbarkeit von Exchange Server wird auf der Applikationsebene umgesetzt.


    Auf der Microsoft Ignite Konferenz 2017 wurde in zahlreichen Vorträgen auf die Preferred Architecture Bezug genommen. Man konnte dem Eindruck erliegen, dass hier missioniert werden sollte. Am letzten Tag der Konferenz haben Boris Lokhvitsky und Robert Gillies eine sehr interessante Session zur richtigen Implementierung von Exchange Server gehalten. Hierbei wurde auch betrachtet, welche technischen Mindestanforderungen für eine Exchange Server Implementierung gelten und wie eine optimale Betriebsumgebung aussieht. Ein optimaler Betrieb einer On-Premises Implementierung folgt der Preferred Architecture. Ist dies nicht möglich sollte man sich für einen Wechsel zu Exchange Online entscheiden.

    Das nachfolgende Diagramm verdeutlicht die unterschiedlichen Design-Optionen für eine Messaging-Plattform auf Basis von Exchange Server 2016.

    Do Exchange Right

    Was bedeutet das nun im Detail für eine erfolgreiche Exchange Server Implementierung?

    • Standardisiert
      Exchange Online bietet eine standardisierte Nutzung von Exchange Server Funktionen im Rahmen des Software-as-a-Service Angebotes von Office 365. Hierbei nutzen Sie nur die Funktionen von Exchange und haben keinerlei direkten Zugriff auf die Server Systeme. Die gesamte Verwaltung des Betriebssystems und das Patchen von Exchange Server führt Microsoft für Sie durch. Sie können sich so ganz auf die Konfiguration Ihrer Exchange Online Organisation oder aber den Hybrid-Verbund mit Ihrer lokalen Exchange Organisation konzentrieren.
       
    • Strukturiert
      Die strukturierte Implementierung einer Exchange Server Plattform folgt der Preferred Architecture der Exchange Produktgruppe oder der Product Line Architecture, basierend auf den Empfehlungen und Erkenntnissen von Microsoft Architekten. Eine solche Implementierung ist, ebenso wie die Nutzung von Exchange Online, als Lösung für einen optimalen Betrieb anzusehen. Wie sich die Preferred Architecture im Detail darstellt wird weiter unten beschrieben.
       
    • Empfohlen
      Eine On-Premises Exchange Server Implementierung, die den Best Practices folgt, weicht in signifikanten Punkten von der Preferred Architecture ab und bietet trotzdem einen sicheren und stabilen Betrieb. Eine solche Abweichung ist z.B. der Betrieb auf einem Hypervisor, jedoch unter Anwendung der Betriebsparameter für den Betrieb von Exchange Server auf physikalischen Systemen (Stichwort: feste Ressourcenzuweisung). Der Exchange Server Best Practices Analyzer ist eine Click-To-Run Applikation, die direkt aus dem Exchange Admin Center einer On-Premises Implementierung heraus aufgerufen werden kann. Alternativ kann hierzu auch das Exchange Analyzer Script von Paul Cunningham aus der TechNet Gallery verwendet werden.
       
    • Unterstützt
      Eine unterstützte Implementierung von Exchange Server weicht in zahlreichen Punkten von der Preferred Architecture ab, bewegt sich aber immer noch im durch Microsoft unterstützten Betrieb. Solch ein unterstützter Betrieb folgt den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen. Diese Art der Implementierung ist als absolutes Mindestmaß anzusehen.
       
    • Funktioniert (irgendwie)
      Natürlich kann man Exchange Server auch irgendwie zum Laufen bringen. Dies ist die letzte Kategorie. In diese Kategorie fallen Einzelserver Implementierungen unter Verwendung von redundanten Speichersystemen oder der grundsätzlich Betrieb von Exchange Server mit nicht unterstützten Speichersystemen (siehe Exchange Server Speicherkonfigurationsoptionen). In diesem Bereich fallen aber auch Exchange Server Implementierung auf AWS oder Microsoft Azure ohne Premium Storage. Ihre produktive Exchange Server Plattform sollte nicht zu dieser letzten Kategorie gehören, da Sie ansonsten ein unnötig hohes Betriebsrisiko eingehen.

     

    Was ist die Preferred Architecture?

    Was ist nun die viel zitierte Preferred Architecture und was bedeutet sie für eine erfolgreiche On-Premises Implementierung und den sicheren Betrieb von Exchange Server.

    Die Preferred Architecture ist kein starres Gebilde. Vielmehr passt sie sich regelmäßig den technischen Gegebenheiten an. Zuletzt wurde z.B. die Empfehlung für den maximalen Arbeitsspeicher je Server von 96GB auf 192GB angehoben.

    Nachfolgend werden die vier Bereiche der Preferred Architecture beschrieben. Ich empfehle aber dringend, immer auf den aktualisierten EHLO Blog Artikel Bezug zu nehmen und sich noch einmal mit der Exchange Server 2016 Architektur vertraut zu machen.

    Die Preferred Architecture gliedert sich in die folgenden vier Bereiche:

    • Namensraum-Design
    • Rechenzentrumsdesign
    • Server-Design
    • DAG-Design

    Namensraum-Design

    Der Exchange Namensraum (Namespace) beschreibt die DNS Hostnamen, die erforderlich sind, damit sich Clients (z.B. Outlook, Browser oder mobile Endgeräte) mit den Exchange Servern verbinden können. Im Rahmen des Data Center Designs (s.u.) wird davon ausgegangen, dass diese Verbindungen auf zwei Standorte verteilt werden. 

    Bei der Planung der Exchange Server Namensräume (Namespaces) unterscheidet man zwischen gebundenen (bound) und ungebundenen (unbound) Namensräumen für Exchange Server in zwei Rechenzentren.

    Bei einem gebundenen Namensraum besitzt jedes Rechenzentrum einen eindeutigen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen erfolgen somit immer zu dem Rechenzentrum, in dem sich auch die aktive Datenbankkopie des angefragten Benutzerpostfaches befindet.

    Bei einem ungebunden Namensraum verfügen die Rechenzentren über keine eigenen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen werden bei jeder Anfrage durch den Load Balancer in eines der beiden Rechenzentren geleitet. Eine Ausnahme bilden hier die Office Online Server (OOS), die immer einen gebundenen Namensraum erfordern.

    Das nachfolgende Beispiel für eine Preferred Architecture Namespace Design benötigt vier Namen:

    1. AutoDiscover Endpunkt: autodiscover.varunagroup.de
    2. Client Endpunkt für alle Exchange Dienste: mail.varunagroup.de
    3. Office Online Server Endpunkt Rechenzentrum A: oos-a.varunagroup.de
    4. Office Online Server Endpunkt Rechenzentrum B: oos-b.varunagroup.de

    Exchange Server Preferred Architecture Design
     

    Rechenzentrumsdesign

    Eine hochverfügbare und ausfallsichere Architektur erfordert den Betrieb von mindestens zwei Rechenzentren. Ob es sich nun um vollwertige und eigenständige Rechenzentren oder um lokale Serverräume in getrennten Brandabschnitte im gleichen Gebäude handelt, lasse ich hier bewusst offen. Die Anforderungen zur Verfügbarkeit von IT-Basisdiensten hängen schließlich nicht nur von einer Exchange Server Implementierung ab.

    Eine wichtige Anforderung ergibt sich aber für den Betrieb des Active Directory in der Preferred Architecture.

    Der über zwei Rechenzentren gestreckte Betrieb einer einzelnen Active Directory Site wird zwar technisch unterstützt, für die Preferred Architecture ist es aber empfohlen, dass jedes Rechenzentrum in einer eigenen Active Directory Site abgebildet wird. Die Gründe dafür sind:

    • Die Funktionen für einen ausfallsicheren Betrieb des E-Mail Transports mit Shadow Redundancy und Saftety Net
    • Der Active Directory Design Empfehlung folgend müssen Netzwerkesegmente mit einer Gesamtlaufzeit von mehr als 10ms in separaten Active Directory Site platziert werden

    Server-Design

    In der Preferred Architecture werden alle Exchange Server mit Postfachrolle als physikalische Systeme betrieben. Die Hauptgründe hierfür sind:

    • Jeder Server ist für eine 80% Auslastung bei größtmöglichem Ausfallszenario berechnet
    • Virtualisierung stellt eine zusätzliche Komplexität im Falle einer Wiederherstellung dar, die keinerlei Vorteil bringt (siehe auch Hauptgrundsatz von Exchange Server)

    Die physikalischen Server, die für eine Preferred Architecture Implementierung verwendet werden, haben keine allzu besonderen Anforderungen. Solch ein Standard-Server besteht aus:

    • 2HE Server, Dual-Sockel mit 20-24 Prozessorkernen
    • Maximal 192GB Arbeitsspeicher
    • Festplattencontroller mit Batterie-abgesichertem Schreib-Cache
    • 12 oder mehr Festplatteneinschübe im Servergehäuse

    Die weiteren Konfigurationen des Servers sind:

    • Einzelner RAID1 Verbund aus zwei Festplatten für das Betriebssystem, Exchange Server Installation, Protokolldateien und Transportdatenbanken
    • Alle weiteren SAS Festplatten sind als JBOD konfiguriert
    • Dateisystem für Datenlaufwerke ist ReFS
    • Schutz der Daten durch BitLocker Festplattenverschlüsselung
    • Absicherung gegen Festplattenausfall durch DAG AutoReseed

     

    DAG-Design

    Um eine optimale Nutzung der Systemressourcen im ungebundenen Namensraummodell zu gewährleisten, werden die aktiven Kopien der Datenbanken gleichmäßig (symmetrisch) über alle Mitgliedsserver der Database Availability Group (DAG) verteilt. Die maximal 16 Mitgliedsserver einer DAG werden ebenfalls symmetrisch, mit einer geraden Anzahl an Servern je Rechenzentrum über alle Rechenzentren verteilt.

    Durch mehr Mitgliedsservern in einer DAG wird eine bessere Redundanz und Nutzung der Ressourcen sichergestellt. Die Preferred Architecture sieht vor, dass eine DAG aus mindestens acht Mitgliedsservern besteht. Bei einem steigenden Ressourcenbedarf wird die DAG um weitere Mitgliedsserver erweitert. 

    DAG Netzwerkdesign

    In der Preferred Architecture benötigt Exchange Server für einen sicheren Betrieb nur eine einzelne Netzwerkschnittstelle. Diese Netzwerkschnittstelle wird ohne Teaming betrieben. Diese vereinfachte Netzwerkanforderung erleichtert den Betrieb und auch die Wiederherstellung im absoluten Fehlerfall. Eine separate Heartbeat-Netzwerkschnittstelle für die Cluster-Kommunikation ist nicht erforderlich.

    Witness Server

    Der Witness Server einer DAG gewährleistet das korrekte Verhalten der DAG bei einem automatischen Failover, sollte es zu einem Ausfall eines Rechenzentrums kommen. Im Idealfall wird der Witness Server an einem dritten Standort in einer anderen Active Directory Site platziert. Sollte kein dritter Standort zur Verfügung stehen, so kann der Witness Server auch in Microsoft Azure betrieben werden.

     

    Zusammenfassung

    Was ist nun die richtige Exchange Server Architektur?

    Wenn Sie der Preferred Architecture (Blauer Kreis) oder aber der Best Practice Empfehlung (Lila Kreis) folgen, können Sie einen sicheren Betrieb der E-Mail Plattform in Ihrem Unternehmen gewährleisten, ohne unnötige technische Risiken einzugehen. Jenseits einer Nutzung von Exchange Online stellen diesen beiden Design-Optionen das Optimum für einen zuverlässigen Betrieb dar. Je weiter Sie sich von der Preferred Architecture für Exchange Server entfernen, um so mehr steigt das Betriebsrisiko.

    Wenn Sie den vollmundigen Produktversprechen von Drittherstellern für Speicherlösungen oder anderen faszinierenden Lösungen zur Hochverfügbarkeit von Exchange Server folgen, so verabschieden SIe sich in eine individuelle "funktioniert irgendwie" Implementierung. Tritt bei solch einer Implementierung ein Fehlerfall auf, so liegt das Problem nicht beim Produkt Exchange Server. Die Erfahrung hat leider gezeigt, dass in solchen Fällen immer von Unzulänglichkeiten in der Implementierung abgelenkt wird.

    Als absolute Mindestempfehlung gilt eine Exchange Server Implementierung, die den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen folgt.


    Abkürzungen

    • PA | Preferred Architecture
    • PLA | Product Line Architecture

    Links

     

    Viel Spaß beim Betrieb von Exchange Server.

     



Kommentare sind geschlossen

Anzeigen 0 Kommentar

Autoren

Cover - Microsoft Exchange Server 2019 - Das Handbuch für Administratoren

Cover - Microsoft 365 Business Premium Migration und Konfiguration

0123movie.net