Grundsätzliche Frage zum Ablauf der Migration von Outlook Anywhere Clients

[fha 10]

Hallo Zusammen,

 

Ich habe hier die Situation, dass ein einzelner Exchange 2010 Server migriert werden soll auf eine hochverfügbare Umgebung (2* CAS/HT, 2*MB), ebenfalls mit Exchange 2010. Wir bleiben also in der selben Organisation, dem selben Netzwerk und auf der selben Version. TMG ist nicht im Einsatz, HTTPS geht gerade durch die Firewall auf den Exchange. Ich bitte Euch NICHT über den letzten Punkt zu schreiben, der war nur als Info gedacht.

 

Nun hat der Kunde eine sehr hohe Anzahl an Outlook Anywhere Clients und ich wollte einfach einmal fragen wie Ihr den Umzug angehen würdet!?

 

Mein Kollege hat den Umzug so geplant (ist nun leider nicht mehr bei uns), dass lediglich die Postfächer umgezogen werden. Zugriffspunkt im Internet etc. bleiben gleich. Ich bin mir aber nicht sicher ob die Outlook-Clients das auch so mitbekommen. Daher spiele ich mit der Überlegung einen neuen Internetzugriffspunkt anzulegen mit eigenem Autodiscover etc.

 

Wie wäre Eure grundsätzliche Herangehensweise?

[NorbertFe 2.041]

Ich würde keinen Windows LB mehr aufsetzen. Das gibt mehr Probleme als es löst. Aber ich gehe davon aus, dass ihr den Punkt schon überschritten habt, an dem man sich für eine Loadbalancer Lösung hätte entscheiden können. Lange Rede kurzer Sinn, wenn dein CAS-Loadbalancer das selbe Zertifikat hat wie jetzt der alte, dann gibt's da höchstens nen kurzen Schluckauf, wenn du den Router auf die Loadbalancing IP umswitcht. Vorausgesetzt alles andere läuft zu diesem Zeitpunkt einwandfrei.

 

Bye

Norbert

[RobertWi 81]

Moin,

 

da kann ich Norbert nur zustimmen. Auch empfiehlt Microsoft mittlerweile nicht mehr dedizierte Rollen, sondern Multi-Role-Server mit LB davor.

 

Schau Dir das Rollen-Konzept von Exchange an: Bis auf die Öffentlichen Ordner ist der Endpunkt immer die CAS-Rolle. Wenn Deine neuen Server also MBX sind und die Du Postfächer verschiebst, kannst Du anschließend auf dem alten Server die MBX-Rolle deinstallieren, ohne das jemand was merken sollte.

[fha 10]

Hallo!

 

Vielen Dank für Eure Antworten.

Ich habe mir etwas Zeit gelassen weil ich mir das Thema noch mal grundsätzlich angesehen habe.

 

Also es sind bereits vier Ex2010 installiert, 2* HT/CAS und 2* MBX, zusätzlich zum produktiven Multi-Role-Exchange. DAG ist eingerichtet, Datenbanken angelegt. NLB kommt nicht zum Einsatz, wir handeln das über die vorgeschaltete Firewall. Die sucht sich RoundRobin einen der beiden CAS aus, prüft ob auf dem angeforderten Port eine TCP-Session zustande kommt und wenn nicht versucht sie es beim anderen CAS. Das nur als Info zu Euren Einwänden bzgl. NLB.

 

AKtuell geht die PLanung zu einem zusätzlichen öffentlichen Zugangspunkt der durch einen HTTPS-Proxy mit Public-Certificate belegt ist. Dieser leitet weiter auf den CASARRAY der mit internen Zertifikaten bestückt ist. Allerdings gehe ich davon aus, dass ich damit die kompletten Zugänge auf Outlook Anywhere und ActiveSync neu anlegen darf.

 

Aber die interne Domäne bekomme ich nicht mehr in ein öffentliches Zertifikat.

[NorbertFe 2.041]

Dafür gibt's Split-DNS. Darf man fragen, welche Firewall ihr einsetzt? Und wenn tatsächlich ne Firewall als Loadbalancer"ersatz", warum dann dedizierte CAS/HT Server? Ist doch vollkommen überflüssig.

 

Bye

Norbert

[fha 10]

Hi Norbert,

 

Das Ganze ist als NLB-DAG Lösung mit vier Servern verkauft worden.

Allerdings ist nun erst bei der Realisierung unserem VMWare-Admin der Gedanke gekommen, dass seine Farm mit NLB Probleme haben könnte. Daher wurde von PL-Seite entschieden die Firewall (ein Barrcuda-Cluster) dafür zu nutzen. Die vier (virtuellen) Server stehen aber schon und sind so verkauft/vermietet.

 

Split-DNS war bisher wegen Einwänden des Kunden keine Option. Aufgrund der Aufwände sieht es aber so aus als ob sich die Einstellung geändert hat.

[NorbertFe 2.041]

Was gibt's denn für Einwände gegen Split-DNS? Das ist ja vollkommen "krank". ;) Aber ja, NLB in Virtualisierung und dann auch noch geclustert macht richtig Spaß. Es hat einen Grund, warum Microsoft und viele Exchange-Dienstleister inzwischen davon abraten. Viel zu viel Aufwand hinsichtlich der Netzwerkseite, auf die man oft keinen Einfluss hat.

 

Bye

Norbert