Gerber 15 Geschrieben 30. Juni 2020 Melden Geschrieben 30. Juni 2020 Hi zusammen, ich habe eine kurze Verständnisfrage in Bezug auf einen Exchange Server 2010 und das CAS Array. Das CAS Array wird im Exchange 2010 benötigt um vom lokalen FQDN des Exchange Servers wegzukommen und die Outlook Verbindung auf z.B. den Servernamen mail.domain.de zu konfigurieren. Oder natürlich um Lastenausgleich zu konfigurieren. Nun ist ein Exchange 2010 Server vorhanden, welcher kein CAS Array und kein SPLIT DNS konfiguriert hat und somit auf den lokalen FQDN "server1.domain.local" verweißt. Es soll eine Migration von Exchange 2010 auf 2016 durchgeführt werden und danach auf 2019. Fragen hierzu: 1.) Nach welcher Reihenfolge geht ihr in Bezug auf die DNS Einstellungen vor, wenn noch kein SPLIT DNS konfiguriert ist und ihr migrieren müsst? Also z.B. zuerst SPlitDNS auf EX2010 + CAS Array konfigurieren, neue Outlook Profile und dann die Migration angehen? 2.) Muss für eine Migration das Cas Array auf dem alten Exchange 2010 konfiguriert werden, bzw. für eine Koexistenz? 3.) Angenommen es werden alle Dienste auf "autodiscover.domain.de" und "mail.domain.de" konfiguriert und kein CAS Array erstellt. Gibt es dann Probleme mit dem Zertifikat im Outlook? Es wird natürlich ein neues Zertifikat für die beiden genannten Domains erstellt, allerdings verbindet sich Outlook ja noch auf den lokalen FQDN. Der SCP würde man in diesem Fall dann vorerst auf dem lokalen FQDN lassen und erste wenn die Postfächer auf dem EX2016 sind auf mail.domain.de konfigurieren. Es handelt sich um 15 Postfächer. Vorerst soll autodiscover und mail.domain.de auf den neuen Exchange 2016 zeigen, welcher Proxy für die auf Postfächer auf dem Exchange 2010 spielt. Am Wochenende werden dann die Postfächer auf einen Rutsch auf den Exchange 2016 migriert und der lokale SCP vom lokalen FQDN auf mail.domain.de umgestellt. Danke euch Grüße Phil Zitieren
NorbertFe 2.208 Geschrieben 30. Juni 2020 Melden Geschrieben 30. Juni 2020 Man benötigt kein rpc cas Array. Jedenfalls nicht für die Migration und wie der Name schon sagt, wärs eh ungünstig, wenn da der Name des https zugriffspunktes verwendet würde. Zitieren
Gerber 15 Geschrieben 30. Juni 2020 Autor Melden Geschrieben 30. Juni 2020 Hey Norbert, danke dir. Okay kannst du mir vllt noch die Frage beantworten wie du dann in so einem Fall vorgehst, wenn der Ex2010 kein SPLITDNS konfiguriert hat und du migrieren willst? Also welche Reihenfolge du wählst? SplitDNS Konfiguration auf dem Ex2010 -> Koexistenz aufbauen -> Postfächer migrieren -> Outlook Profil neu erstellen? Am 30.6.2020 um 12:13 schrieb NorbertFe: und wie der Name schon sagt, wärs eh ungünstig, wenn da der Name des https zugriffspunktes verwendet würde. Mehr Was meinst du hiermit genau? Cas Array benötige ich doch, wenn ich vom lokalen FQDN des Exchange Servers wegkommen will und sich Outlook z.B. mit mail.domain.de verbinden soll. Grüße Phil Zitieren
Dukel 465 Geschrieben 30. Juni 2020 Melden Geschrieben 30. Juni 2020 Wieso musst du das mit dem Exchange 2010 machen? Neuen Exchange mit neuer "Split DNS Adresse" aufsetzen. Wieso Outlook Profil neu erstellen? Das ist nicht nötig. Zitieren
Gerber 15 Geschrieben 30. Juni 2020 Autor Melden Geschrieben 30. Juni 2020 (bearbeitet) Ich dachte immer um eine Koexistenz zwischen Exchange 2010 und 2016 herzustellen müssen beide Exchange Server die gleichen URls + Zertifikate besitzen? Und weil in vielen Migrationsanleitungen beschrieben wird, dass vor einer Migration auf Split DNS umgestellt werden sollte. Und aus diesem Grund frage ich ja auch nach eurem genauen vorgehen in solch einer Situation: Bedeutet also: 1.) Exchange 2016 aufsetzen 2.) Split DNS mit Autodiscover und mail.domain.de konfigurieren 3.) Einträge auf den Exchange2016 zeigen lassen (oder sollten diese bis zur Migration auf den EX2010 zeigen, obwohl dort die URLs nicht konfiguriert sind?) 4.) Authentifizierung der virtuellen Verzeichnisse mit dem EX2010 abgleichen Die Postfächer sollen dann bis zum Wochenende noch auf dem EX2010 liegen bleiben, weswegen auch der EX2016 Proxy spielen soll. 5.) SCP vom neuen EX 2016 auf Null setzen -> ist dies notwendig? 6.) Nach der MIgratoin den SCP auf autodiscvoer.domain.de setzen Outlook Profil wird vom Lokalen FQDN automatisch an mail.domain.de angepasst? Grüße Phil bearbeitet 30. Juni 2020 von Gerber Zitieren
Beste Lösung NorbertFe 2.208 Geschrieben 30. Juni 2020 Beste Lösung Melden Geschrieben 30. Juni 2020 Am 30.6.2020 um 14:23 schrieb Gerber: SplitDNS Konfiguration auf dem Ex2010 Mehr Korrekt. Und zwar NICHT mittels RPC Client Access Array. Das vergißt du einfach, weil das wie der Name sagt für RPC/MAPI ist und Exchange 2016 spricht nunmal nur noch https. Deswegen wäre es "fatal", da jetzt eine Hürde einzubauen, die man bisher ja gar nicht hatte. Du brauchst einen Namen bspw: outlook.deineexternedomain.tld Der Name ist im "internen" DNS als A-Record eingetragen und zeigt auf die IP deines Exchange 2010 Servers. Mehr erstmal nicht! Der Name wird im "externen" DNS als A-Record eingetragen und zeigt auf die IP deiner Firewall/Reverseproxys Üblicherweise gibts den externen Namen ja schon, also schonmal die halbe MIete. Zertifikat für extern und intern muß natürlich alle notwendigen Namen beinhalten. Angenommen dein Exchange hat keinen Reverse Proxy, brauchst du also ein Zertifikat im Exchange, was autodiscover.deineexternedomain.tld sowi outlook.deineexternedomain.tld beinhaltet. Solltest du bereits einen anderen Namen verwenden, dann den ggf. auch noch. Im Exchange 2010 konfigurierst du jetzt _alle_ virtuellen Verzeichnisse auf outlook.deineexternedomain.tld und sorgst dafür, dass die Clients im LAN/WLAN/VPN diese Adresse direkt "INTERN" erreichen und nicht ggf. über einen Proxy müssen. Dann mittels set-clientaccessserver den SCP auf outlook.deineexternedomain.tld konfigurieren. Jetzt sorgst du dafür, dass deine Outlooks sich alle per https und nicht mehr per Mapi/RPC verbinden (geht per Outlook Provider) Dann Exchange 2016 CU17 installieren und dort ALLE _internen_ und _externen_ URLs auf outlook.deineexternedomain.tld konfigurieren und das Zertifikat (siehe oben) installieren. SCP mittels set-clientaccessservice ebenfalls auf outlook.deineexternedomain.tld konfigurieren DNS intern outlook.deineexternedomain.tld auf die IP vom Exchange 2016 ändern (flushdns und ttl überlasse ich mal der Einfachheit halber deiner Fantasie) Wenn jetzt alles geht, bist du fast fertig, denn dann fehlt das nur noch in der Firewall, dass du dort eingehende Anfragen an den neuen Exchange schickst. Eigentlich könnte man auch einfach mal das MS Whitepaper für sowas lesen! Bye Norbert Am 30.6.2020 um 14:23 schrieb Gerber: Cas Array benötige ich doch, wenn ich vom lokalen FQDN des Exchange Servers wegkommen will und sich Outlook z.B. mit mail.domain.de verbinden soll. Mehr Nein RPC Client Access Array benötigte man bei Exchange 2010, damit bei RPC/Mapi der Servername egal war! Für https Zugriffe war das NIE NIE NIEMALS zuständig. Am 30.6.2020 um 14:36 schrieb Gerber: Bedeutet also: Mehr Lies dir lieber die MS Whitepaper durch bzw. auch mein Geschreibsel oben. Am 30.6.2020 um 14:36 schrieb Gerber: Authentifizierung der virtuellen Verzeichnisse mit dem EX2010 abgleichen Mehr Üblicherweise macht mans andersrum und konfiguriert den Exchange 2010 richtig, denn meist ist der falsch konfiguriert. Am 30.6.2020 um 14:36 schrieb Gerber: Die Postfächer sollen dann bis zum Wochenende noch auf dem EX2010 liegen bleiben, weswegen auch der EX2016 Proxy spielen soll. Mehr Das ist doch vollkommen egal, wann und wie lange. WEnn der Zugriff über den Exchange 2016 läuft, gibts Zeit ohne Ende in Ruhe (sogar tagsüber) die Postfächer zu migrieren. Davon bekommt der Nutzer bei vernünftiger Planung und Konfiguration nichts mit, ausser einem Neustart von Outlook. Am 30.6.2020 um 14:36 schrieb Gerber: Outlook Profil wird vom Lokalen FQDN automatisch an mail.domain.de angepasst? Mehr Wenn mans richtig macht. ;) 1 Zitieren
Gerber 15 Geschrieben 30. Juni 2020 Autor Melden Geschrieben 30. Juni 2020 Danke für die ausführliche Antwort Das CAS Array hat mich irgendwie durcheinander gebracht ... Am 30.6.2020 um 14:48 schrieb NorbertFe: Nein RPC Client Access Array benötigte man bei Exchange 2010, damit bei RPC/Mapi der Servername egal war! Für https Zugriffe war das NIE NIE NIEMALS zuständig. Mehr Aber das bringt bei mir Licht ins dunkle. Wenn ich mich auch richtig erinnere durfte das Cas Array (Falls eingerichtet) auch gar nicht den gleichen Namen wie z.B: Annywhere besitzen, da es sonst zu Problemen geführt hatte. Danke für die Antworten. Grüße Phil Am 30.6.2020 um 14:48 schrieb NorbertFe: Üblicherweise macht mans andersrum und konfiguriert den Exchange 2010 richtig, denn meist ist der falsch konfiguriert. Mehr Alles klar. Am 30.6.2020 um 14:48 schrieb NorbertFe: Das ist doch vollkommen egal, wann und wie lange. WEnn der Zugriff über den Exchange 2016 läuft, gibts Zeit ohne Ende in Ruhe (sogar tagsüber) die Postfächer zu migrieren. Davon bekommt der Nutzer bei vernünftiger Planung und Konfiguration nichts mit, ausser einem Neustart von Outlook. Mehr Hast du natürlich Recht. Am 30.6.2020 um 14:48 schrieb NorbertFe: Dann mittels set-clientaccessserver den SCP auf outlook.deineexternedomain.tld konfigurieren Mehr Hier schreibst du den SCP an outlook.domain.de anpassen. Nutzt du hierfür nicht autodiscover.domain.de ? Zitieren
NorbertFe 2.208 Geschrieben 30. Juni 2020 Melden Geschrieben 30. Juni 2020 Wozu denn? erst zu autodiscover schicken, wenn du dann sowieso zu outlook.... willst? Die Autodiscover Domain gibts nur, weil man einem NICHT-Domain Mitglied ja den SCP nicht vorgeben kann. ;) Zitieren
Gerber 15 Geschrieben 30. Juni 2020 Autor Melden Geschrieben 30. Juni 2020 (bearbeitet) Am 30.6.2020 um 15:32 schrieb NorbertFe: Wozu denn? erst zu autodiscover schicken, wenn du dann sowieso zu outlook.... willst? Die Autodiscover Domain gibts nur, weil man einem NICHT-Domain Mitglied ja den SCP nicht vorgeben kann. ;) Mehr Auch hier hast du natürlich Recht. Man findet es halt oft in Tutorials oder Anleitung, dass der SCP auf autodiscover.domain.de konfiguriert wird bearbeitet 30. Juni 2020 von Gerber Zitieren
NorbertFe 2.208 Geschrieben 30. Juni 2020 Melden Geschrieben 30. Juni 2020 Ja kann man machen, ist halt egal. ;) 1 Zitieren
testperson 1.794 Geschrieben 30. Juni 2020 Melden Geschrieben 30. Juni 2020 Am 30.6.2020 um 15:46 schrieb Gerber: Man findet es halt oft in Tutorials oder Anleitung, dass der SCP auf autodiscover.domain.de konfiguriert wird Mehr Man kann halt auch alles auf "autodiscover.<domain.tld>" konfigurieren. Dann kann man ggfs. auch noch beim Zertifikat sparen. ;) 1 Zitieren
NorbertFe 2.208 Geschrieben 30. Juni 2020 Melden Geschrieben 30. Juni 2020 War in Anfangszeiten von Exchange 2007/2010 durchaus eine übliche Umgehungslösung. ;) Da haben Zertifikate aber auch noch deutlich über 200€ gekostet. Zitieren
MrCocktail 204 Geschrieben 1. Juli 2020 Melden Geschrieben 1. Juli 2020 Ich persönlich würde nie die Funktion Zugriffsendpunkt und Autodiscover auf die gleiche URL setzen, ich mag es, wenn ich unterscheiden kann und im Zweifel sogar eigene Server für bestimmte Funktionen definieren kann... Okay, heute bei Multirole vielleicht nicht mehr so üblich, aber zwischendurch macht es immer noch Sinn. 1 Zitieren
NorbertFe 2.208 Geschrieben 1. Juli 2020 Melden Geschrieben 1. Juli 2020 Naja es gibt nur sehr wenige Szenarien, denen ich bisher begegnet bin, wo das nicht sowieso auf dem selben Server terminierte. Und bei denen funktionierte es dann meist sowieso nicht. ;) Zitieren
Gerber 15 Geschrieben 1. Juli 2020 Autor Melden Geschrieben 1. Juli 2020 Gut ist das ja beides funktioniert und nicht falsch ist. Somit kann jeder machen wie er es für richtig hält Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.