Migration 2007 nach 2010

Eigentlich sind sich Exchange 2007 und Exchange 2010 sehr ähnlich, so dass eine Migration relativ einfach und überschaubar ist. Aber es gibt schon noch ein paar Besonderheiten, die hierbei beachtet werden sollten. Diese Seite beschränkt sich daher auf die kniffligeren Umstellung en.

Niemals Inplace

Auch wenn Exchange 2007 und 2010 aus der gleichen Familie sind und beide 64-bit nutzen, so sind die unterschiede bei den Rollen doch zu groß, um ein Inplace-Update zu erlauben. Das geht einfach nicht. Sie müssen also immer neue Exchange Server "daneben" installieren und dann die Inhalte, Connectoren, Postfächer verschieben. Natürlich können Sie das als "Rolling Update" durchführen, d.h. ein Exchange 2007, der ersetzt wurde, kann deinstalliert und als Exchange 2010 Server neu installiert werden.

Outlook Web App und LegacyURL

Genau wie bei Exchange 2003 ist auch Exchange 2007 eine "Legacy-Version" von Exchange und auch wenn ein Exchange 2010-CAS-Server in vielerlei Hinsicht auch Exchange 2007 Mailboxen bedienen kann, so trifft dies in den meisten Fällen nicht für OWA zu. Zwar sieht Microsoft bei der Migration nach der Bereitstellung der Exchange 2010 Server vor, den Zugriff auf die OWA-URL auf die neuen Exchange 2010 CAS-Server zu lenken aber diese haben nicht besseres zu tun, und Zugriffe von Exchange 2007 Mailboxen auf die Exchange 2007 CAS-Server zurück zu verweisen. Nur wenn in der AD-Site kein Exchange 2007 CAS-Server ist, agiert der Exchange 2010 CAS als Reverse Proxy auf einen Exchange 2007 CAS in einer anderen AD-Site.

Für den Verweis muss man der Exchange 2010 Umgebung natürlich mitteilen, unter welche URL die Exchange 2007 CAS-Server erreichbar sind, Das kann natürlich nicht mehr der gleiche Name wie die eigentliche OWA-URL sein. Insofern sind Sie genötigt, ein neues Zertifikat für den "Legacy-Namen" zu erwerben und die Exchange 2007 CAS-Server ebenso aus dem Internet erreichbar zu machen.

Mehr Glück haben nur Firmen, die OWA gar nicht "native" veröffentlichen. Wer z.B. eine Portal- oder Veröffentlichungslösung betreibt, an denen sich die Anwender vorab schon anmelden, der kann hier vielleicht eine Abfrage nach der Exchange Version einbauen. Viele diese Gateways (z.B. TMG) können abhängig von einer Gruppenmitgliedschaft bestimmte URLs veröffentlichen. Wer hier die Exchange 2007 Benutzer direkt zu den alten Exchange 2007 CAS-Servern lenkt, muss sich zumindest von extern nicht mit der Umleitung beschäftigen.

Viele andere Protokolle und Zugänge von Exchange sind hingegen "problemlos"; weil der Exchange 2010 Server auch Zugriff von Benutzern mit einem Postfach auf Exchange 2007 bedient oder an den Exchange 2007 Server weiter reicht. Dies betrifft z.B.

  • ActiveSync
    Ein Exchange 2010 CAS kann auch ein Exchange 2007 Postfach bedienen, so dass der Zugriff hierauf vor der Migration des ersten Postfachs umgestellt werden kann.
  • RPC/HTTP
    Gleiches gilt für den Zugriff per RPC/HTTP. Der Zugang einfach anfangs auf die funktionierenden CAS-Server leiten und dann Mailboxen migrieren.
  • MAPI
    Ein Exchange 2010 CAS bzw. CASArray ist auch nur ein Exchange Server. Sobald eine Mailbox auf Exchange 2010 verschoben wurde, verweist der alte Server den MAPI-Client auf den neuen Server. Outlook aktualisiert in der Regel sein lokales Profil. Knifflig kann hier aber die richtige Konfiguration von NLB oder des LoadBalancer sein. Die echte Funktion sehen Sie erst, wenn die Last zunimmt.
  • OAB, EWS, Autodiscover
    Auch diese virtuellen Verzeichnisse sind relativ unkritisch, da der Client per Service Connection Point nur einen CAS (2007 oder 2010) erreichen müssen, um die Daten zu erhalten. Natürlich wird man auch hier frühzeitig die neuen Server konfigurieren. für diese WebURLs ist die "LegacyURL"-Funktion nicht weiter relevant.

Knifflig bei allen Diensten, die auf dem IIS basieren ist die Auswahl und Konfiguration der Zertifikate.

Unified Messaging

Wer eine Exchange 2007 Unified Messaging Rolle installiert hat, wird mit der Einführung von Exchange 2010 natürlich auch diese Rolle migrieren wollen. Hier ist zu beachten, dass ein Exchange 2010 UM-Server nur Exchange 2010 Postfächer bedient und Zugriffe durch Anwender auf Exchange 2007 auf einem Exchange 2007 UM-Server umleitet.

Umgekehrt kann ein Exchange 2007 UM Server keine Exchange 2010 Postfächer bedienen aber scheinbar die Anrufe nicht mal auf einen Exchange 2010 UM Server weiter geben. Damit ist schon erklärt, warum vor der Migration der ersten Postfächer die UM-Gateways die Exchange 2010 Server ansprechen.

Dazu gibt es zwei mögliche Fälle:

  1. Exchange 2010 UM bekommt den SIP INVITE mit der "Redirect-Nummer"
    Dann kann Exchange schon vor dem Aufbau der Audioverbindung die Mailbox "finden" und erkennen, ob es ein Exchange 2010 oder 2007 Postfach ist. ist es ein Exchange 2007 Postfach, dann macht Exchange 2010 einen Transfer mittels "302 SIP REDIRECT. Exchange beantwortet den Ruf also mit einem 302 SIP REDIRECT an das Gateway, welches anhand der "Kontaktadresse" dann den Exchange 2007 Server erreicht
  2. SIP INVITE ohne zusätzliche Information
    Hier muss Exchange 2010 UM den Ruf erst mal "annehmen" und seine Ansage abspielen. Der Anwender kann dann z.B. per DTMF das gewünschte Postfach auswählen worauf Exchange 2010 erneut die Version des Postfachs prüft. Eine Verbindung zu einem Exchange 2007 Postfach wird dann mit einem SIP REFER an Exchange 2007 weiter geleitet. Dies ist ein "Blinder Transfer", d.h. Exchange 2010 UM sendet das SIP-Paket zum Gateway zurück und kümmert sich nicht weiter darum.

Gerade die Weitergabe macht auf dem ein oder anderen Gateway Probleme, wenn es mit der Kontaktadresse oder dem Routing nicht zurecht kommt. Hier mal am Beispiel einer SIP-Meldung eines Exchange 2010 UM Servers, der den Ruf an ein Ferrari-Gateway zur Weitergabe an Exchange 2007 zurück gibt, nachdem die Verbindung schon bestanden hat und der Anwender die Zielmailbox per DTMF angegeben hat.

SIPMSG:+++++ rec +++++ rec +++++ rec +++++ rec +++++ rec 
SIPMSG:REFER sip:+495251304600@192.168.1.10:5061;transport=tls SIP/2.0
SIPMSG:FROM: <sip:798@192.168.1.11:5065;transport=Tls>;epid=31D6B74D83;tag=adfe1fb41c
SIPMSG:TO: <sip:+495251304600@192.168.1.10:5061>;tag=23539-1318340130
SIPMSG:CSEQ: 1 REFER
SIPMSG:CALL-ID: sip_isdn-23545-1318340131
SIPMSG:MAX-FORWARDS: 70
SIPMSG:VIA: SIP/2.0/TLS 192.168.1.11:5065;branch=z9hG4bK2787a6de
SIPMSG:CONTACT: <sip:ex2010um.msxfaq.de:5065;transport=Tls;ms-opaque=fb6650f>;automata;text;audio;video;image
SIPMSG:CONTENT-LENGTH: 0
SIPMSG:EXPIRES: 600
SIPMSG:REFER-TO: <sip:798@ex2007um.msxfaq.de:5061;transport=tls>
SIPMSG:REFERRED-BY: <sip:ex2010um.msxfaq.de;v=1.0;Extension=1234;c=ms-ova-data>
SIPMSG:USER-AGENT: RTCC/3.5.0.0 MSExchangeUM/14.01.0339.001
SIPMSG:P-ASSERTED-IDENTITY: <sip:798@192.168.1.11:5065;transport=Tls>
SIPMSG:----- rec ----- rec ----- rec ----- rec ----- rec 

Die "+495251304600" ist der Anrufer, welcher die 798 als Pilotnummer angerufen hat und per DMT die Erweiterung "1234" eingegeben hat. Im "REFER-TO" steht nun die IP-Adresse zum Exchange 2007 UM-Server. 

ACL-Cleanup

Die wenigsten Beschreibungen behandeln die Deinstallation komplett. Exchange 2007 legt einige Sicherheitsgruppen an, welche dann auf den Domänen und OUs berechtigt werden. Mitglieder haben dann die Rechte direkt per LDAP diese Felder bei den Objekten zu bearbeiten. Das ist natürlich eine Lücke, die gerade mit Exchange 2010 geschlossen werden kann. Siehe auch RBAC.

Dazu sollten Sie aber die Benutzer aus den alten Exchange 2007 Sicherheitsgruppen nach und nach entfernen und in die Exchange 2010 Managementgroups addieren.

Erst dann können die die Gruppen im Active Directory löschen. Wer es natürlich perfekt machen möchte, entfernt noch die ACLs der Gruppen an den verschiedenen Stellen. In der Regel ist das nur die Wurzel jeder Domäne und der Exchange-Zweig in der Konfiguration-Partition. Damit wird sicher verhindert, dass jemand an RBAC vorbei weiterhin per LDAP direkt Felder ändern kann.

Microsoft Quellen

Microsoft selbst stellt einen Exchange Deployment Assistant bereit, in dem Sie auch die Migration auswählen können und letztlich eine Checkliste liefert.

Nach meiner Ansicht ist diese dann generierte Liste aber keine echte Checkliste und übergeht bzw. vergisst einige Dinge. Es fehlt etwas der Praxisbezug z.B.:

  • Connectoren
    Wie die Send und Receive Connectoren umgestellt werden, wird nur sehr oberflächlich und auf Exchange beschränkt beschrieben.
  • Unified Messaging
    Hier wird recht allgemein die Einrichtung beschrieben aber so fehlt z.B. der Hinweis, dass auch auf dem Gateway das Routing angepasst werden muss und dass man zum Test dies vielleicht nicht gleich für die ganze Firma sondern für bestimmte Quellrufnummern oder Ziele einrichtet.
  • CAS und LegacyURL
    Auch hier wird meiner Meinung nach nicht ausführlich genug eingegangen.

Zudem bin ich mit der Reihenfolge der ein oder anderen Migrationskomponente nicht zufrieden.

  • Public Folder am Ende
    Interessanterweise werden die öffentlichen Ordner als letztes migriert. Das kann ich nicht verstehen. Ich repliziere die Inhalte zuerst auf das Ziel. Das belastet erst mal schon das neue System und füllt die Datenbank, was auch bezüglich Antivirus und Backup von Vorteil ist. Noch sind ja keine Postfächer auf dem Ziel.

So schön der Ansatz eines Assistenten und Checklisten ist, die nach Beantwortung einiger Fragen einen Migrationsplan versprechen, so kann dies nie eine umsichtige Planung und entsprechenden Know-How ersetzen. Ich sehe also noch viel Arbeit für meine Kollegen und mich und andere Dienstleister zukommen.

Weitere Links