none
Migration Exchange 2010 (CAS.Array) zu Exchange 2016 mit Loadbalancer (KEMP) RRS feed

  • Frage

  • Hallo zusammen,

     

    Ich bräuchte einen Ratschlag wie ich folgende Umgebung migrieren kann und wäre über Hilfe/Tipps sehr dankbar.

     

    IST-Zustand

    Wir setzen derzeit Exchange 2010 SP (UR 16) ohne DAG bei uns ein und verwenden ein CAS-Array statt Loadbalancer. Das CAS-Array ist Intern über „exchange.domain.local“ erreichbar (RZ-Netz) und von Extern wird die Mail-Struktur für OWA, Active Sync und Outlook Anywhere über „webmail.domain.de“ angesprochen (vorgeschalteter TMG vorhanden).

     

    SOLL-Zustand

    Migration zu Exchange 2016 (derzeit ohne DAG aber später geplant) auf Server 2016 mit dem Einsatz von KEMP als Loadbalancer. Der Loadbalancer wird geplant eine LAN-Schnittstelle in der DMZ haben (Public) und die andere LAN-Schnittstelle (Farm) im RZ/Exchange Netz. Der gesamte Traffic sollte nach der Migration über den Loadbalancer laufen.

     

     

    Derzeit beschäftigt mich die Frage wie ich den Ablauf gestalte, damit beim Verschieben der Postfächer diese im Anschluss über den Loadbalancer sich verbinden und nicht mehr das CAS-Array. Des Weiterem habe ich das auf einigen Webseiten so verstanden, dass für die Migration ein neuer Namenspace gebraucht wird. Ich hatte hier an „outlook.domain.de“ für Intern und für Extern gedacht.

     

    Was die Ablaufreihenfolge bezüglich der Installation vom ersten Exchange Server und dem KEMP Loadbalancer angeht, bin ich wie gesagt etwas unsicher.

     

     

    Vom Gefühl würde ich das so planen.

    1. KEMP Loadbalancer grob in Betrieb nehmen (Puplic-LAN in der DMZ, Farm-LAN im RZ-Netz) und im DNS veröffentlichen (Host-A Eintrag von „outlook.domain.de“)
    2. Ersten (von mehreren) Server mit OS erstellen und Exchange 2016 installieren sowie Zertifikat (von der CA) hinterlegen
    3. Den Loadbalancer mit den neuen Exchange Server 2016 konfigurieren
    4. Routing anpassen da die Anwender etc. über die Schnittstelle vom Loadbalancer in der DMZ verbinden
    5. Testpostfach verschieben
    6. Etc.

     

    Vielen Dank vorab für eure Hilfestellungen

     

    MfG Paul


    • Bearbeitet Lexxitus Montag, 6. Februar 2017 09:36 Korrektur
    Montag, 6. Februar 2017 08:29

Antworten

  • Am 06.02.2017 um 22:49 schrieb Lexxitus:
    Hallo Paul,

    Ich hätte da aber noch ein par Rückfragen.

    1. Das mit Outlook Anywhere höre ich zum ersten Mal und hätte eher gedacht Du meinst Autodiscover. Derzeit wird per Script Outlook Anywhere überall deaktiviert und nur bei berechtigten Peronen wieder aktiviert. Des Weiteren wird dieser Personenkreis am TMG für den externen Zugriff mittels Outlook Anywhere alleinig berechtigt und das wollen Wir auch gerne beibehalten (wenn möglich über die KEMP gesteuert).

    Na gut, dass du dich so früh mit einem neu einzuführenden Produkt beschäftigst. ;) Stell dir vor, wäre dir das erst nach der Implementation gesagt worden. :P

    Wenn du OA im User deaktivierst, dann brauchst du zukünftig deutlich weniger Ressourcen, weil du ohne Outlook Anywhere oder Mapi/http keinen ZUgriff auf dein Exchangepostfach bekommst. Wenn du externe Prä-Auth fahren willst, brauchst du mehr Interfaces im Loadbalancer.

    2. das mit der separaten AD-Site kannte ich schon aber ein Kollege stellte sich die Frage, ob dort auch ein DC stehen muss.

    Ja.

    Ist denn für die Installation/Konfiguration nachfolgender Exchange Server dann das selbe vorgehen von Nöten?

    Ja.

    3. sofern Wir dennoch einen neuen Namen verwenden würden (Outlook.domain.de) für OWA, Active Sync etc. wäre das möglich? Die derzeitige Namenswahl wird in Frage gestellt.

    Ja neuer Name geht. Muß man halt bisschen mehr planen, weil du dann die User quasi zweimal unterbrichst. Aber geht.

    @Evgenji eine Koexistenz wird nicht zu vermeiden sein, da die Migration der Postfächer einige Zeit in Anspruch nehmen wird.

    Hast du ja jetzt. Aber mal davon abgesehen, wenn niemand OWA nutzt, braucht man auch keine Rücksicht drauf nehmen.

    HTH
    Norbert

    Dienstag, 7. Februar 2017 00:16

Alle Antworten

  • Moin,

    das Thema lässt sich umfassend nicht in einem Forum darstellen und "Gefühle" sind dabei schlechte Ratgeber.

    Hier ist was zum Lesen:

    https://blogs.technet.microsoft.com/exchange/2015/10/26/client-connectivity-in-an-exchange-2016-coexistence-environment-with-exchange-2010/

    Zusammengefasst:

     - Das CAS-Array ist die Verbindung von internem Outlook ohne die Nutzung von Outlook Anywhere 

     - Für die Verbindung zum Ex 2016 braucht es zwingend Outlook Anywhere

     - Durch die Aktivierung von Outlook Anywhere in der bestehenden Umgebung wird das CAS-Array in Outlook absolet (vereinfacht ausgedrückt)

     - ein weiter Name ist nicht erforderlich, wichtig ist aber, dass Split DNS sauber funktioniert

    Die ungefähre Reihenfolge in Exchange sieht daher so aus:

     - Loadbalancer installieren und Konfigurieren

     - Outlook Anywhere auf für interne Nutzer einschalten -> "webmail.domain.de"

     - Exchange 2016 installieren (Installations-Site verwenden, URLs und Zertifikate installieren, Installations-Site auflösen)

    (Zum Testen kannst Du an dieser Stelle bei ausgewählten Clients den Namen "webmail.domain.de" in der HOSTS-Datei auf die VIP des LB umstellen und die Postfach Migration mit diesen Clients ausprobieren.)

     - DNS Auflösung von "webmail.domain.de" auf die neuen Server einstellen

     - Postfächer umziehen

    Wie gesagt: Das ist nur ein grober Umriss und ignoriert SMTP oder Öffentliche Ordner.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)


    Montag, 6. Februar 2017 19:12
  • Moin,

    ergänzend zu Robert: Einen zweiten FQDN brauchst Du evtl. für OWA, wenn beide Versionen koexistieren sollen. Für alle anderen Dienste macht Exchange 2016 einen Proxy auf 2010, falls das angesprochene Postfach noch dort ist, für OWA aber eine Weiterleitung.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Montag, 6. Februar 2017 19:23
  • Hallo Robert, Danke für deine Antwort.

    Ich hätte da aber noch ein par Rückfragen.

    1. Das mit Outlook Anywhere höre ich zum ersten Mal und hätte eher gedacht Du meinst Autodiscover. Derzeit wird per Script Outlook Anywhere überall deaktiviert und nur bei berechtigten Peronen wieder aktiviert. Des Weiteren wird dieser Personenkreis am TMG für den externen Zugriff mittels Outlook Anywhere alleinig berechtigt und das wollen Wir auch gerne beibehalten (wenn möglich über die KEMP gesteuert).

    2. das mit der separaten AD-Site kannte ich schon aber ein Kollege stellte sich die Frage, ob dort auch ein DC stehen muss. Ist denn für die Installation/Konfiguration nachfolgender Exchange Server dann das selbe vorgehen von Nöten?

    3. sofern Wir dennoch einen neuen Namen verwenden würden (Outlook.domain.de) für OWA, Active Sync etc. wäre das möglich? Die derzeitige Namenswahl wird in Frage gestellt.

    @Evgenji eine Koexistenz wird nicht zu vermeiden sein, da die Migration der Postfächer einige Zeit in Anspruch nehmen wird.

    MfG Paul



    • Bearbeitet Lexxitus Montag, 6. Februar 2017 21:52
    Montag, 6. Februar 2017 21:49
  • Am 06.02.2017 um 22:49 schrieb Lexxitus:
    Hallo Paul,

    Ich hätte da aber noch ein par Rückfragen.

    1. Das mit Outlook Anywhere höre ich zum ersten Mal und hätte eher gedacht Du meinst Autodiscover. Derzeit wird per Script Outlook Anywhere überall deaktiviert und nur bei berechtigten Peronen wieder aktiviert. Des Weiteren wird dieser Personenkreis am TMG für den externen Zugriff mittels Outlook Anywhere alleinig berechtigt und das wollen Wir auch gerne beibehalten (wenn möglich über die KEMP gesteuert).

    Na gut, dass du dich so früh mit einem neu einzuführenden Produkt beschäftigst. ;) Stell dir vor, wäre dir das erst nach der Implementation gesagt worden. :P

    Wenn du OA im User deaktivierst, dann brauchst du zukünftig deutlich weniger Ressourcen, weil du ohne Outlook Anywhere oder Mapi/http keinen ZUgriff auf dein Exchangepostfach bekommst. Wenn du externe Prä-Auth fahren willst, brauchst du mehr Interfaces im Loadbalancer.

    2. das mit der separaten AD-Site kannte ich schon aber ein Kollege stellte sich die Frage, ob dort auch ein DC stehen muss.

    Ja.

    Ist denn für die Installation/Konfiguration nachfolgender Exchange Server dann das selbe vorgehen von Nöten?

    Ja.

    3. sofern Wir dennoch einen neuen Namen verwenden würden (Outlook.domain.de) für OWA, Active Sync etc. wäre das möglich? Die derzeitige Namenswahl wird in Frage gestellt.

    Ja neuer Name geht. Muß man halt bisschen mehr planen, weil du dann die User quasi zweimal unterbrichst. Aber geht.

    @Evgenji eine Koexistenz wird nicht zu vermeiden sein, da die Migration der Postfächer einige Zeit in Anspruch nehmen wird.

    Hast du ja jetzt. Aber mal davon abgesehen, wenn niemand OWA nutzt, braucht man auch keine Rücksicht drauf nehmen.

    HTH
    Norbert

    Dienstag, 7. Februar 2017 00:16
  • Moin,

    zu 1. Wie Norbert schon schreibt, geht es ohne Outlook Anywhere nicht mehr:

    Exchange kennt folgende Protokolle für den Zugriff:

     - Exchange 2010: MAPI/RPC & MAPI/RPC/HTTPS (aka Outlook Anywhere)

     - Exchange 2013: MAPI/RPC/HTTPS && MAPI/HTTPS (ab CU 4)

     - Exchange 2016: MAPI/RPC/HTTPS && MAPI/HTTPS

    Wie man sieht, ist nur Outlook Anyhwere die meinsame Schnittmenge, daher muss es vor der Migration auf Ex 2010 aktiviert werden.

    Technisch ist das auch vollkommen unbedenklich.

    zu 2.

    Hier muss ich Norbert mal korrigieren: Wenn AD und Schema vorbereitet sind, braucht man für die Installationen KEINEN eigenen DC in der Install-Site. Der Zustand ist zwar offiziell unsupported, aber da er nur dazu dient, Outlook und User nicht zu verwirren, bevor die Konfiguration von Exchange durch ist, wird er geduldet. Nur "in Betrieb" gehen darf der Server nicht in der AD-Site:

    http://www.msxfaq.de/exchange/migration/exchange_install_site.htm

    https://blogs.technet.microsoft.com/exchange/2015/11/18/exchange-active-directory-deployment-site/

    zu 3 und zu Evgenji: Mir wäre es neu, dass OWA nicht per Proxy läuft. Bei 2007 brauchte man eine Proxy-Adresse, aber bei 2010 sollte das transparent laufen. Das ist auch im obigen Link so beschrieben.

    Warum willst Du also einen neuen Namen einrichten und alle Benutzer verwirren?


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Dienstag, 7. Februar 2017 08:35
  • Hallo Robert,

    das aktivieren von Outlook Anywhere sollte kein Problem darstellen sofern Wir mittels der KEMP (Loadbalancer) steuern können, welche Benutzer dies von Extern nutzen dürfen. Im Prinzip wie der TMG durch eine Abfrage einer AD-Gruppe sofern die Anfrage von Extern und nicht Intern kommt.

    Das Schema sowie AD/Forest wird bei uns im Vorfeld erweitert/vorbereitet da Wir ein Multi-Domain Modell fahren und die Replikation sauber durchlaufen muss/sollte bevor Wir weitere Schritte durchführen.

    Der Name "webmail.domain.de" ist aus früheren Zeiten und war für den externen Zugriff für OWA und Active Sync gedacht. Sofern dieser aber auch für intern (Split-DNS) genutzt werden soll, entspricht der Name halt nicht wirklich seiner eigentlichen Funktion. Wünschenswert wäre eigentlich "mail.domain.de" aber dieser ist durch einen anderen Dienst (Mailproxy etc.) bereits belegt. Auch wenn Namen "Schall und Rauch" sind (Aussage machner Leute) so ziehen Wir es in Betracht einen neuen Namen einzusetzen.

    MfG Paul

    Dienstag, 7. Februar 2017 11:50
  • zu 2.

    Hier muss ich Norbert mal korrigieren: Wenn AD und Schema vorbereitet sind, braucht man für die Installationen KEINEN eigenen DC in der Install-Site. Der Zustand ist zwar offiziell unsupported, aber da er nur dazu dient, Outlook und User nicht zu verwirren, bevor die Konfiguration von Exchange durch ist, wird er geduldet. Nur "in Betrieb" gehen darf der Server nicht in der AD-Site:hange Server)

    Hier muss ich mich korrigieren und Norbert recht geben. Ich habe eben in einer Testumgebung "Greenfield" einen neuen Ex 2016 installiert und vorher auf dem DC Schema, AD und Domain vorbereitet.

    Der Exchange-Server war in einer eigenen Site ohne DC. Das Setup-Programm musste nur noch Exchange installieren und hat sich leider geweigert, das ohne DC zu tun. Sogar die explizite Angabe eines DCs aus der "Hauptsite" führt zu einer Fehlermeldung (mit sehr fehlerhaften deutsche Text).

    Nach dem ich die Installation-Site gelöscht und der Exchange-Server wieder in der Site mit dem DC war, lief das Setup ohne weitere Änderungen und Probleme durch.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Sonntag, 12. Februar 2017 12:11
  • Am 12.02.2017 um 13:11 schrieb Robert Wille [MVP]:

    Hier muss ich mich korrigieren und Norbert recht geben.

    Das hör ich gern. ;)

    Bye
    Norbert

    Montag, 13. Februar 2017 08:40