NachbesprechungMigration von Exchange 5.5

Whitney Roberts

DAS PROJEKT

Das Bildungsministerium von Kentucky musste von seiner vorhandenen Implementierung von Microsoft ® Exchange Server 5.5 auf Exchange Server 2003 migrieren. Das System unterstützt in jedem Schuljahr ungefähr 600.000 Lehrer/Lehrerinnen, Personal und Schüler/Schülerinnen.

DIE BETEILIGTEN

Das Projekt wurde vom Office of Education Technology (OET) des Bildungsministeriums von Kentucky und mit der Unterstützung von Beratern von KiZAN Technologies geleitet. Das OET-Personal hat einen Verwaltungsüberblick über die bestehenden Exchange 5.5-Implementierungen bereitgestellt. Für die tägliche Verwaltung der Exchange-Server war das örtliche Personal in den Schulbezirken zuständig.

DIE HERAUSFORDERUNGEN

Dem Bildungsministerium unterliegt die technische Leitung der 178 Schulbezirke im Gemeinwesen von Kentucky. Diese Schulbezirke sind über eine WAN-Verbindung miteinander vernetzt, doch jeder Bezirk betreibt seinen eigenen lokal verwalteten Exchange 5.5-Server, und alle Server mussten einzeln aufgerüstet werden. Dieses Upgrade würde Support für Outlook® 2003-Clients im zwischengespeicherten Modus, eine verbesserte Erfahrung mit Outlook Web Access (OWA), ein standardisiertes E-Mail-Adressierungsschema und mehr mit sich bringen.

Zusätzlich zu einem neuen E-Mail-Server und einer neuen Clientinfrastruktur fügten viele Schulbezirke einen E-Mail-Support für Schüler hinzu. Sowohl staatliche als auch bundesstaatliche Richtlinien gaben vor, dass die Informationen über Schüler geschützt werden mussten und außerhalb des jeweiligen Bezirks nicht sichtbar sein durften.

DER PLAN

Da kein Active Directory® Connector (ADC) verwendet werden konnte, wurde eine neue Exchange-Organisation erstellt und die Migration auf diese Weise vorgenommen. Die Standardisierung von E-Mail-Adressen bedeutete, dass sowohl neue Identifizierungsunterdomänen für jeden Schulbezirk als auch über 400 neue Empfängerrichtlinien erstellt werden mussten. Der Schutz von Schüleradressen erforderte die Erstellung eines Systems von globalen Adresslisten (GAL) und benutzerdefinierten Adresslisten für jeden einzelnen Schulbezirk.

Die eigentliche Migration erforderte das Bereitstellen neuer Hardware, das Erstellen und Konfigurieren von Postfächern auf Grundlage von Bezirkszugehörigkeit und Benutzertyp sowie das Einstellen von Erweiterungsattributen auf Grundlage von Bezirkszugehörigkeit und Benutzertyp, sodass die Benutzer in den entsprechenden Adresslisten angezeigt werden.

Es wurde eine auf Visual Basic® basierende Anwendung erstellt, die falsch konfigurierte Kontenattribute oder Gruppenmitgliedschaften erkennt und neue Postfächer korrekt bereitstellt, um sicherzustellen, dass die Anforderungen an die Sichtbarkeit berücksichtigt wurden. Die Anwendung wurde allen 178 Bezirken bereitgestellt und auf einer zeitlich begrenzten Basis von den Schulbezirksservern ausgeführt.

Hintergrund

Oberflächlich betrachtet hört sich dies vielleicht nicht wie eine große Herausforderung oder ein technisch schwieriger Auftrag an. Geschäftsanforderungen geben jedoch den Ton an, und die Geschäftsanforderungen dieses Projekts hatten es in sich.

Im Laufe der Jahre hatten eine dezentralisierte Verwaltung und eine bunte Mischung von Standards zahlreiche Support-„Silos“ ins Leben gerufen, die meistens vom OET verwaltet werden mussten. Außerdem musste das OET sicherstellen, dass die Implementierung von Exchange 5.5 die Voraussetzungen der Schulbezirke und des Bildungsministeriums gleichermaßen erfüllt. Das bedeutete, dass in den Bezirken, die Schüler-E-Mails verwendeten, die Informationen über Schüler geschützt werden mussten und außerhalb des jeweiligen Bezirks nicht angezeigt werden durften – so wie von den staatlichen und bundesstaatlichen Richtlinien vorgegeben (siehe ed.gov/policy/gen/guid/fpco/ferpa/index.html).

In Exchange 5.5 führten diese Richtlinien dazu, dass die Informationen über Schüler innerhalb eines Bezirks in anderen Schulbezirken oder anderen staatlichen Einrichtungen, die globale Adresslistendaten freigaben, nicht repliziert werden konnten. Folglich war ein manueller Export-/Importprozess für jeden der 178 Exchange 5.5-Standorte erforderlich: Ausblenden der Schüler, Replizieren der Liste, Einblenden der Schüler und schließlich Importieren der Adressliste. So würden andere Bezirke nur die Personaldaten sehen, und der die Daten besitzende Schulbezirk würde alle eigenen Daten, aber nur die Personaldaten anderer Schulbezirke sehen.

Angesichts der Stärken und Schwächen des vorhandenen Systems musste das Aufrüsten der Messaginginfrastruktur bestimmten Kriterien gerecht werden. Zuerst wünschte das Bildungsministerium von Kentucky eine Standardisierung nach einer gemeinsamen, lesbaren SMTP-Namensgebung für das gesamte Unternehmen. Die Namensgebung musste getrennte SMTP-Adressräume für Fakultät und Schüler bereitstellen.

Das neue System musste außerdem einen zentral verwalteten Dienst bereitstellen, der den Bezirk von der Messagingverwaltung und der Verantwortung für die Verfügbarkeit entlasten würde. Mit anderen Worten, die Verwaltung der Notfallwiederherstellung, der E-Mail-Verkehr und die Helpdeskaufrufauflösung mussten zentralisiert werden. Das neue System als solches musste eine zentralisierte Methode für die Standardisierung der Benutzerkonfiguration in allen Bezirken, ohne Rücksicht auf den geografischen Ort oder die Bezirksangliederung des jeweiligen Benutzers, bereitstellen.

Des Weiteren musste das neue System einen sicheren webbasierten Zugriff und einen Mobilgerätzugriff auf E-Mails über einen gemeinsamen, einheitlichen Namespace für alle Bezirke bereitstellen.

Bei diesen Anforderungen, von denen viele im bereits vorhandenen Exchange 5.5-System fehlten, sah die Aktualisierung auf Exchange 2003 nicht sehr verheißungsvoll aus.

Lösungsansätze

Um die Geschäftsanforderungen zu erfüllen, wurden für die Bereitstellung mehrere Exchange-spezifische Optionen ausgewählt.

Aufgrund des Mangels von Standardisierung und der Größe der Exchange 5.5-Umgebung sollte kein ADC verwendet werden. Stattdessen wurde eine neue Exchange-Organisation erstellt und die Migration auf diese Weise vorgenommen.

Das Aufräumen und Standardisieren von E-Mail-Adressen für das Personal und die Schüler in jedem Bezirk führte dazu, dass über 400 neue Empfängerrichtlinien erstellt wurden. Die Anforderungen schrieben eine einmalige Identifizierungsunterdomäne für jeden Bezirk vor, einschließlich einer Identifizierungsbezirksbezeichnung für Schüler. Im Fall des Shelby-Bezirks zum Beispiel lautete die primäre Unterdomäne shelby.kyschools.us. Die Schüler in jedem Bezirk erhielten die Unterdomänenbezeichnung „stu.“. Also lauteten die Adressen der Schüler im Shelby-Bezirk stu.shelby.kyschools.us.

Eine andere Einschränkung bestand darin, dass die Adressen von Schülern nur innerhalb ihres Bezirks angezeigt werden durften, während die Adressen des Personals in allen Bezirken angezeigt werden sollten. Es musste also ein umfangreiches System von globalen und benutzerdefinierten Adresslisten aufgestellt werden, siehe Abbildung 1 und Abbildung 2. Ein Vorteil, den die Migration auf Exchange 2003 hatte, bestand darin, dass die Adresslisten durch Berechtigungen abgesichert werden konnten und dass der Zugriff auf die einzelnen Adresslisten durch eine Gruppenmitgliedschaft gesteuert werden konnte. Diese Funktion wurde sinnvoll genutzt, indem zwei Sicherheitsgruppen (eine für das Personal und eine für Schüler) auf Bezirksebene erstellt und dann die entsprechenden Bezirkspersonal- und Schüler-GALs und Adresslisten gesichert wurden, damit nur Benutzerkonten innerhalb eines bestimmten Bezirks Zugriff auf bestimmte Adresslisten hatten. Durch Entfernen der Standard-GALs und Adresslisten und durch die Gewährleistung, dass die Benutzergruppen „Alle“ und „Authentifizierte Gruppen“ auf der Zugriffssteuerungsliste (ACL) der einzelnen Adresslisten nicht aufgelistet werden, konnten wir die Adressliste vorgeben, die ein bestimmter Benutzertyp in einem bestimmten Bezirk anzeigen kann.

Abbildung 1** Benutzerdefinierte rollenbasierte Adresslisten **(Klicken Sie zum Vergrößern auf das Bild)

Die Berechtigungen haben jedoch nur einen Teil des Sichtbarkeitsproblems gelöst. Es musste eine Lösung gefunden werden, um steuern zu können, wer in welcher Adressliste angezeigt wird. Dazu wurde ein LDAP (Lightweight Directory Access-Protokoll) erstellt, mit dem wir die Sichtbarkeit von Personal und Schülern abfragen konnten; anschließend wurde die Abfrage für jede Adressliste und GAL leicht angepasst. Zum Beispiel so, dass die LDAP-Abfrage für die Shelby-Personal-GAL nur das entsprechende Personal und die Schüler in Shelby und das gesamte Personal (aber keine Schüler) in den anderen Bezirken des Bundesstaats anzeigten. Die Shelby-Schüler-GAL sollte also nur das Personal und die Schüler von Shelby und kein anderes Personal bzw. Schüler in einem beliebigen anderen Bezirk des Bundesstaats anzeigen. Diese Abfrage wurde für alle Bezirke in der Organisation wiederholt. Abbildung 3 zeigt Beispiele für einige LDAP-Abfragen, die bei dieser komplexen Migration verwendet wurden.

Figure 3 LDAP-Abfragen für Adressliste

LDAP-Abfrage für Personal-GAL

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14))))) 

LDAP-Abfrage für Bezirksadressliste

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))

LDAP-Abfrage für Bezirksschüleradressliste

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))

LDAP-Abfrage für Offline-Adressliste des Bezirkspersonals

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))

Abbildung 2** Trennung von Personal und Schülern durch GALs **(Klicken Sie zum Vergrößern auf das Bild)

Benutzerdefinierte Werte für die Exchange-Benutzereigenschaften „extensionAttribute14 (Custom Attribute 14)“ und „extensionAttribute15 (Custom Attribute 15)“ stellten den kennzeichnenden Mechanismus der LDAP-Abfragen dar. Das gesamte Personal und alle Schüler im Bundesstaat verwenden einen bestimmten Wert für „extensionAttribute14“, um den Benutzertyp zu bestimmen, und einen einmaligen Wert in „extensionAttribute15“, um die Bezirksangliederung anzuzeigen. Mithilfe eindeutiger Werte für jeden Bezirk und gleicher Werte für jeden Benutzertyp konnten die Adresslisten genau die Informationen anzeigen, die für jeden Benutzertyp in den einzelnen Bezirken erforderlich waren.

Diese Adresslisten eigneten sich gut für Benutzer, die über Outlook im nicht zwischengespeicherten Modus oder über OWA auf E-Mails zugreifen. (Die einzelnen Benutzer wurden mithilfe des Attributs „msExchQueryBaseDN“ zur richtigen Adressliste in OWA geleitet.) Allerdings warfen Benutzer, die Outlook im zwischengespeicherten Modus ausführen, ein anderes Problem auf. Da Outlook keine benutzerdefinierte GAL als das vorgegebene Offline-Adressbuch (OAB) akzeptiert, mussten wir zusätzliche Adresslisten erstellen, die Duplikate der GALs waren. Jeder Bezirkspostfachspeicher wurde dann mit der passenden OAB-Adressliste für seine den Zwischenspeichermodus verwendenden Benutzer konfiguriert. Alles in allem kam diese Lösung auf über 1.500 Adresslisten, mit denen verschiedenen Benutzertypen in allen 178 Bezirken eine volle Funktionalität geboten wurde.

Gewährleistung der Kompatibilität

Um sicherzustellen, dass die Struktur, die erstellt wurde, auch richtig funktionieren würde, kam es entscheidend auf die Einhaltung der neu festgelegten Standards an. Es gab mehrere High-Level-Aufgaben, die für jeden einzelnen Exchange-aktivierten Benutzer in der Organisation stattfinden mussten. Der Grund dafür ist, dass jeder Benutzer in allen Exchange-Servern des Bezirks korrekt platziert sein und in den zutreffenden Adresslisten angezeigt werden muss.

Der Benutzer musste ein Mitglied der zutreffenden Sicherheitsgruppe innerhalb der Bezirksdomäne sein, weil die Sicherheitsgruppe die Berechtigungen dazu verteilt, die entsprechende Adressliste zu öffnen. Außerdem musste das Attribut „msExchQuerybaseDN“ des Benutzers, je nach Zugehörigkeit zu Bezirk und Organisationseinheit, richtig eingestellt sein. Die Organisationseinheit des Benutzers wurde durch den Benutzertyp bestimmt.

Im nächsten Schritt wurde das Postfach des Benutzers, je nach Bezirkszugehörigkeit und Benutzertyp, im richtigen Speicher auf dem richtigen Server erstellt. Dadurch waren die Dienstebenen, Beschränkungen der Postfachgröße und Offline-Adressbuchlisten betroffen, sodass Outlook im Zwischenspeichermodus richtig funktionieren konnte. Die Erweiterungsattribute wurden je nach Bezirkszugehörigkeit und Benutzertyp festgelegt, sodass die Benutzer nur in den zutreffenden Adresslisten angezeigt wurden.

Schließlich musste eine Lösung bereitgestellt werden, damit die Attribute eines Kontos oder Gruppenmitgliedschaften automatisch korrigiert werden konnten, wenn sie durch die Verwendung unzutreffender Werte falsch konfiguriert bzw. geändert wurden. Wenn ein Benutzer innerhalb der Bezirksdomäne von einer Organisationseinheit zu einer anderen verschoben wird, stellt dies eine Benutzerklassifizierungsänderung dar. Der Postfachort, die GAL-Auswahl und die Adresslistensichtbarkeit müssen dann entsprechend aktualisiert werden.

Dafür wurde ein Bereitstellungssystem benötigt, das diese Aufgaben erledigen und die Konsistenz und Genauigkeit von Active Directory sicherstellen würde. Folglich wurde eine konsolen- und Visual Basic-basierte Anwendung erstellt, die auf einer zeitlich begrenzten Basis vom Exchange 2003-Server des Schulbezirks ausgeführt wird. Die Anwendung, die die Einhaltung der Richtlinien und Standards überwacht und außerdem die Erstellung und Bereitstellung neuer Objekte bearbeitet, wurde in allen 178 Bezirken bereitgestellt.

Die vorliegenden Aufgaben schienen zu kompliziert zu sein, als dass sie von einer Reihe von Skripts schnell und zuverlässig hätten ausgeführt werden können. Demzufolge wurde die auf Visual Basic basierte Anwendung als die geeignete Lösung angesehen, da sie effizient war, über einen strukturierten Fehler- und Ausnahmebehandlungssupport verfügte und da ihr interner Code in Zukunft durch minimale Umarbeitung leicht an den MIIS-Erweiterungscode (Microsoft Identity Integration Server) angepasst werden konnte.

Da wir zu einer neuen Organisation migrierten, musste eine bestimmte Methode zur Koexistenz gefunden werden. Es gab mehr als 178 ältere SMTP-Domänen, die in der neuen Umgebung unterstützt werden mussten. Einige Bezirke verfügten über bereits vorhandene Schüler-E-Mail-Domänen und andere nicht, doch glücklicherweise konnten Bezirke nacheinander migriert und die älteren Nachrichten und Adressen auf das neue System übertragen werden, ohne die anderen Bezirke zu stören. Bei der Migration von Exchange 5.5 auf Exchange 2003 musste jedoch darauf geachtet werden, dass der E-Mail-Fluss nicht unterbrochen wurde. Das bedeutete, dass eine Art Verzeichnissynchronisierung zwischen Exchange 2003 Active Directory und dem älteren Verzeichnis von Exchange 5.5 implementiert werden musste. Microsoft gewährte dem Bildungsministerium von Kentucky die begrenzte Verwendung von MIIS für die Dauer der Migration, damit der individuelle Erweiterungscode entwickelt und für die über MIIS erfolgende Synchronisation der beiden Exchange-Organisationen vor, während und nach der Migration verwendet werden konnte.

Die Migration auf eine neue Exchange-Organisation betrifft von Natur aus die MAPI-Clientkonfiguration. Das Bildungsministerium sah sich mit der Tatsache konfrontiert, dass es buchstäblich Zehntausende von MAPI-Profilen auf Bezirksebene gab, die während der Migration konfiguriert werden mussten. Erfreulicherweise veröffentlichte Microsoft das Exchange Profile-Tool (ExProfRe.exe), das für die Profilmigration in den Bezirken verwendet wurde. Es wurde ein verpacktes Installationsprogramm zur Ausführung von ExProfRe.exe mit vorgeladenen Werten erstellt, damit Profilmigrationen auf Bezirksebene automatisch durchgeführt werden konnten. Das Programm wurde über die Gruppenrichtlinie aufgerufen. Dieser Ansatz zeigte eine 100-prozentige Erfolgsrate bei automatisierten Profilmigrationen zwischen Organisationen.

Hardwareupgrades

Da die neuen Exchange 2003-Server die geografisch verteilten Exchange 5.5-Server ersetzten, musste der Hardwareaspekt dieser Lösung die gleiche Anzahl von Benutzern unterstützen wie die Exchange 5.5-Bereitstellungen, und das zusätzlich zu den Schülerkonten. Die Server mussten lokal innerhalb des Bezirks gehostet werden, weil die WAN-Topologie so entworfen war, dass jeglicher Bezirksdatenverkehr (Internet und intern) über eine private T1-Leitung erfolgte (in einigen Bezirken wurden mehrere T1-Leitungen verwendet).

Aufgrund finanzieller, verwaltungs- und ausrüstungsbedingter Einschränkungen stand den Exchange-Servern kein SAN (Storage Area Network) zur Verfügung, sodass der gesamte Speicher entweder intern geregelt oder direkt angehängt werden musste. Da die meisten Bezirke keine Datencenter mit Regallagerung und Zentralkühlung haben, mussten die Server so eigenständig wie möglich sein. Glücklicherweise hatten die meisten Bezirke weniger als 5.000 Benutzer, sodass einzelne Server bereitgestellt werden konnten. Für die Bezirke, die mehr Benutzer aufwiesen, wurden leistungsfähigere Server (oder mehrere Server) und zusätzlicher Speicher eingesetzt; manchmal mit getrennten Front-End-Servern, um die Trennung des Schüler- und Personaldatenverkehrs zu verbessern.

In den meisten Bezirken konnten gut ausgestattete Dualprozessorserver bereitgestellt werden, die mit maximal 15.000 RPM Ultra320 SCSI-Laufwerken, mehrfachen RAID-Controllern und 4 GB Arbeitsspeicher konfiguriert wurden. Größere Bezirke erhielten ein oder mehrere Quad-Prozessorenserver, die bei Bedarf kleinere Front-End-Server verwendeten. Bei Benchmark- und Leistungstests vor der Bereitstellung wurden keine Nutzungs- oder Belastungsprobleme festgestellt. Der entscheidende Faktor für die Gesamtleistung des Servers war jedoch eindeutig in den unterschiedlichen Werten der lokalen Verwendungsmuster zu suchen.

Machbarkeitsstudie (Proof of Concept, POC)

Obwohl die Produktionsumgebung eine Active Directory-Gesamtstruktur mit 178 Domänen umfasst, wurde das Labor für die Machbarkeitsstudie auf 13 Bezirksdomänen und eine leere Stammdomäne reduziert. Alle Testdomänen wurden mit Exporten der Produktionsdomänen aufgefüllt. Virtual Exchange 5.5-Server wurden erstellt und mit Kopien der ausgewählten Bezirksdatenbanken konfiguriert, damit der Migrationsprozess und der Ausbau der geplanten Umgebung getestet werden konnte. Das gesamte POC-Testlabor wurde mit virtuellen Computern erstellt, sodass die Umgebung als Grundlage verwendet, eingefroren und bei Bedarf erneut bereitgestellt werden konnte.

Diverse Kombinationen von Skripts (unter Verwendung von VBScript), SMS (Systems Management Server)-Installationsprogrammpaketen und Konsolenanwendungen wurden erstellt, kodiert, getestet und abgeschlossen. Am Ende lagen Skripts vor, die die anfängliche Installation und Konfiguration von Exchange 2003, einschließlich Empfängerrichtlinien, GAL und benutzerdefinierte Adresslisten sowie Berechtigungen, ausführten. Von Skripts wurden außerdem die administrative Gruppenkonfiguration, die Bezirksdomänenkonfiguration (Erstellen von Sicherheitsgruppen und Delegieren von Berechtigungen) und die der Bereitstellung nachfolgende Konfiguration für die Migration bearbeitet.

Das Bereitstellen der Exchange 2003-Server stellte eine erhebliche Herausforderung dar. Alle Exchange-Server mussten erfolgreich in allen 178 Domänen installiert und dies musste so geschickt ausgeführt werden, dass die restliche Migration nicht gefährdet wurde. Exchange 2003 weicht insofern von Exchange 2000 ab, als die domänenspezifische Exchange-Domänenservergruppe erst dann der Zugriffssteuerungsliste der Organisation hinzugefügt wird, wenn der erste Exchange 2003 Server in der Domäne installiert ist. (In Exchange 2000 wird die Gruppe hinzugefügt, wenn der DomainPrep-Prozess ausgeführt wird.) Um sicherzustellen, dass alle notwendigen Sicherheitsgruppen im Organisationsobjekt in Active Directory aufgelistet wurden, musste die Installation in einer vorgegebenen Domäne erfolgen, Active Directory manuell von der Domäne auf den Active Directory-Replikationshub repliziert und anschließend diese Replikation zur Installation zum nächsten Bezirk hinuntergezogen werden. Erst nachdem bestätigt wurde, dass die Exchange-Domänenservergruppe des vorherigen Bezirks in der Zugriffssteuerungsliste im Organisationsobjekt enthalten war, konnte die Installation des nächsten Bezirks auf sichere Weise beginnen. Wenn dieser Prozess in auch nur einer Domäne nicht planmäßig abgeschlossen wurde, musste jener Bezirk (zumindest) neu installiert werden. Anderenfalls hätten andere Bezirke aufgrund einer Organisationsobjekt-ACL, die nicht alle anderen Bezirke korrekt auflistet, nicht miteinander kommunizieren können.

Die gesamte Bereitstellung, Konfiguration, das Server-Staging und die Migration wurden so lange getestet, bis feststand, dass der Prozess innerhalb der POC-Umgebung gut funktionierte.

Migration und Anfangsschwierigkeiten

Nachdem die POC-Verfahren und -Ergebnisse vom Projektteam genehmigt wurden, konnte die Migration beginnen. Das OET entschied sich dafür, die Migration bei sich zuerst durchzuführen, um den Prozess und die Nachwirkungen direkt kennen zu lernen. Zum Zeitpunkt der Migration waren alle Server bereits bereitgestellt worden, und die anfängliche Umgebung war überprüft worden. Alle Front-End-Protokollserver und Postfachserver waren korrekt platziert und bereit, von Benutzern genutzt zu werden.

Die Ausführung des Migrationsplans gelang problemlos. Nach 21 langen Stunden, in denen der Inhalt von einem Server zum anderen übertragen wurde, stand Exchange 2003 dem OET zum sofortigen Einsatz bereit. Glücklicherweise gab es keine größeren Probleme bei der Migration von Outlook-Profilen von Exchange 5.5 auf Exchange 2003. Es wurde eine Batchdatei verpackt, von der ExProfRe.exe in verschiedenen Konfigurationen, aufgebaut auf einer einfachen Logik, aufgerufen wurde. Dann wurden die Batchdatei und die Datei ExProfRe.exe auf die Netlogon-Freigaben der Domänencontroller in den einzelnen Bezirken verteilt, und zum Abschluss der Migration wurde der Stapel mithilfe der Gruppenrichtlinie für alle Clients ausgeführt. Beim OET funktionierte dies problemlos, und wir waren uns sicher, dass der Prozess gut verlaufen würde.

Zu diesem Zeitpunkt wurde der Migrationsplan überprüft und aufgrund der Erfahrung mit der Bereitstellung beim OET erneut genehmigt. Im weiteren Verlauf der Migration wurden sechs Bezirke ausgewählt, die die ersten Produktionsstandorte sein sollten. Bevor jeder Bezirk migriert wurde, las MIIS die neuesten Informationen über die Postfächer des Bezirks von Exchange 5.5 ab und aktualisierte die zugehörigen Benutzer in der Bezirksdomäne. Der Exchange-Migrations-Assistent (Mailmig.exe) wurde dazu verwendet, um die Postfachdaten zwischen den Organisationen zu verschieben. Beim Verschieben der Postfachdaten durch den Assistenten wurden alle Proxyadressen übertragen und aufgrund dessen, was MIIS ursprünglich nach Active Directory exportiert hatte, aktualisiert. Während der Migration wurden die E-Mails an Front-End-SMTP-Servern aufgereiht und anschließend, nachdem die Migration, die Serverkonfiguration im Anschluss an die Migration und die Prüfung seitens der Benutzer abgeschlossen waren, an den Bezirk freigegeben. Der Bezirk war bereit, eine weitreichende Clientmigration unter Verwendung von ExProfRe.exe durchzuführen.

Der Empfängeraktualisierungsdienst (RUS)

Damit Outlook-Clients ordnungsgemäß funktionieren, musste sichergestellt werden, dass die Bereitstellungslösung die endgültige Instanz für das Einstellen von Attributen war. Es musste außerdem dafür gesorgt werden, dass der Empfängeraktualisierungsdienst (Recipient Update Service, RUS) den Auftrag sozusagen bei der Kontoeinrichtung abschließt, allerdings erst, nachdem das Bereitstellen beendet ist. Um dies zu erreichen, wurden die RUS-Instanzen für die Bezirke (alle 178 Bezirke) in Bezug auf ihre Zeitpläne auf „Nie“ eingestellt, und von der Bereitstellungslösung wurde Code verwendet, der den RUS auslöste, sodass er nach abgeschlossener Bereitstellung startete.

Die meisten Bezirke haben weniger als 5.000 Benutzer und weit weniger tägliche Aktualisierungen. Deshalb war der RUS schnell mit seiner Arbeit fertig, da das Bereitstellungssystem am Ende seines täglichen Pensums statt einer Neuerstellung eine Aktualisierung auslöste. Es gab jedoch mehrere Bezirke mit mehr als 10.000 Benutzern. Aktualisierungen in diesen Umgebungen durchzuführen, war zeitaufwändiger, und sollte eine vollständige RUS-Neuerstellung nötig sein, so würde sie eine Woche oder länger in Anspruch nehmen. Da der RUS bei der Ausführung alle Objekttypen bewertet, wirkt sich eine Neuerstellung in einer derart großen Domäne lähmend aus.

Obwohl sich keine Maßnahme zur Schadensbegrenzung finden ließ (trotz der Zusammenarbeit mit Mitgliedern der Exchange-Produktgruppe, um gemeinsam eine Lösung zu erarbeiten), wurde der Bereitstellungscode so verbessert, dass er viele der Standard-RUS-Aufgaben bearbeitet. Wenn sich Benutzer das erste Mal anmelden, werden die Attribute „showInAddressBook“ und „proxyAddresses“ geladen, sodass sie sich sofort anmelden können, ohne darauf warten zu müssen, dass der RUS seine Arbeit abschließt. Außerdem wurde eine manuelle Aufgabe erstellt, die auf einem der Front-End-Exchange 2003-Protokollserver ausgeführt wird. Sie erledigt einen zeitlich begrenzten LDIFDE-Import und löscht die RUS-GatewayProxy-Adresse. Das bedeutet, wenn eine Empfängerrichtlinie versehentlich in der Umgebung angewendet wird, erscheint sie nicht gleich auf der Aufgabenliste jedes RUS im Unternehmen.

Kategorisierungsprobleme

Einen interessanten Aspekt stellte die Aufgabe dar, dafür zu sorgen, dass die Schülerdaten nicht außerhalb des Schulbezirks gelangten. Dies wurde durch die Implementierung von Steuerungen erreicht, die verhinderten, dass Schüler E-Mails an Benutzer außerhalb ihres eigenen Bezirks oder an Internetadressen außerhalb des Systems schicken. Statt sich durch ein umfangreiches System von Connectors und zugehörigen Elementen durchzuarbeiten, wurde eine weniger bekannte Funktion von Exchange 2003 implementiert, und es wurden Connectoreinschränkungen für den vorhandenen Routinggruppenconnector vom Bezirk zum zentralen Hub verwendet, an dem sich die Front-End-Protokollserver befinden. In jeder Domäne wurden zwei Sicherheitsgruppen erstellt: eine für das Personal und eine für die Schüler. Und diese Gruppen wurden den Connectoreinschränkungen hinzugefügt.

Nachdem die Überprüfung der Connectoreinschränkung in der Registrierung aktiviert war, wurden einige sehr hinderliche Leistungsprobleme festgestellt. Nachrichten hingen stundenlang im Kategorisierungsmodul und in den lokalen Lieferwarteschlangen fest; sogar Nachrichten, die für Empfänger auf dem gleichen Server bestimmt waren. Diese Probleme verschlimmerten sich mit der Zeit, nachdem zusätzliche Bezirke migriert wurden. Als Übergangslösung wurde die Überprüfung der Connectoreinschränkung ausgeschaltet, und die Postlieferungsleistung verbesserte sich. Eine weitere Untersuchung ergab, dass das Kategorisierungsmodul bei der Nachrichtenübermittlung nicht nur die Gruppenmitgliedschaften der beiden Gruppen innerhalb seiner eigenen Domäne, sondern auch die Gruppenmitgliedschaften der gleichen zwei Gruppen in den anderen 177 Domänen überprüfte. Dies galt für jede Nachricht, die am Server ein- oder ausging.

Schließlich richteten wir eine Supportanfrage an Microsoft. Nach einer Evaluierung ist Microsoft derzeit dabei, einen Hotfix für dieses Problems zu generieren, indem das Kategorisierungsmodul befähigt wird, in einem Modus mit einer verminderten Topologiekomplexität zu arbeiten. Weitere Details zu dem Hotfix sind zum Zeitpunkt der Veröffentlichung dieses Artikels nicht verfügbar. Ziel ist es jedoch, eine Einstellung bereitzustellen, die dem Kategorisierungsmodul ermöglicht, bestimmte Annahmen über die Routingtopologie zu machen, ohne die Gruppenmitgliedschaft in allen Connectors zu überprüfen.

Die gelernten Lektionen

Wenn es etwas gibt, das ich bei diesem Projekt wieder neu gelernt habe, dann ist es Folgendes: Geschäftsanforderungen steuern unsere gesamte Arbeit als Berater. Es gab viele Anlässe, bei denen die Durchführbarkeit der Geschäftsanforderungen gegen die Komplexität der Lösung abgewogen werden musste. Die Entscheidungen und die Wahlen, die ich in diesem Artikel beschrieben habe, waren angesichts unserer Umgebung (einschließlich derjenigen Elemente, die ich hier aus Zeitgründen nicht behandeln konnte), unserer Ressourcen und unserer Geschäftsanforderungen die passendsten. Sie treffen gegebenenfalls andere Entscheidungen, und ich hoffe, dass der vorliegende Artikel einen Denkanstoß bietet. Glücklicherweise boten Exchange 2003 und Active Directory mehr als genug Flexibilität, um alle Anforderungen dieser komplizierten Migration zu erfüllen. Nachdem der anfängliche Schreck über den Umfang der Migration für das Bildungsministerium von Kentucky überwunden war, erwies sich die tatsächliche Lösung als einfacher denn gedacht. Sie baut auf Funktionen von Active Directory und Exchange 2003 auf, die meiner Meinung nach nicht ausreichend genutzt werden.

Die zweite wertvolle Lektion lautet: Stehen Sie der Problembehandlung und der Risiko- bzw. Problemverwaltung offen gegenüber. Es gibt Zeiten, in denen sich eine lokale Problembehandlung anbietet, und Zeiten, in denen die erweiterten Ressourcen des Microsoft-Produktsupports herangezogen werden müssen.

Vorschau

Die Umgebung des Bildungsministeriums von Kentucky ist sicher einzigartig. Im Verlauf dieser Bereitstellung ist nahezu jede Funktion in Exchange verwendet oder angepasst worden, um die Anforderungen des Ministeriums zu erfüllen. Jetzt, da die gesamte Umgebung erfolgreich bereitgestellt und migriert wurde, kann zusätzliche Funktionalität implementiert werden. Schulbezirke haben beim Bildungsministerium bereits Interesse an der Windows Mobile®-Plattform angemeldet, und es wird erwartet, dass sich der Trend zur Nutzung mobiler Geräte fortsetzt.

Eine Serverkonsolidierung trägt zu einer beachtlichen Wertschöpfung bei. Das Bildungsministerium von Kentucky untersucht derzeit die Möglichkeiten zur Virtualisierung einiger Aspekte der Active Directory-Umgebung. Und nachdem sich Exchange 2007 bereits am Horizont abzeichnet, hat das Ministerium angefangen, sich über die Anforderungen für ein Upgrade ihrer Nachrichtensysteme zu informieren.

Außerdem untersucht es die zusätzlichen Angebote zur Zusammenarbeit im Live Communication Server, Live Meeting Server und so weiter. Abgesehen davon wird derzeit Microsoft Operations Manager 2005 zum Verwalten und Überwachen der Exchange- und Active Directory-Server bereitgestellt.

Die Ergebnisse

Jedes Kind im öffentlichen Schulwesen von Kentucky wird von der Qualität und der Verbreitung dieser Implementierung betroffen sein. Dazu gehören meine eigenen Kinder und die Kinder der Kollegen und Kolleginnen, mit denen ich an diesem Projekt gearbeitet habe. Diese Implementierung hat dem Bildungsministerium von Kentucky dazu verholfen, dass es seine Technologie auf eine sichere und standardisierte Weise schneller als je zuvor weiterentwickeln kann. Ich bin stolz, Teil einer solchen Unternehmung gewesen zu sein.

Whitney Robertsist ein leitender Berater bei KiZAN Technologies (www.kizan.com) und hat seit der Veröffentlichung von Exchange 4.0 mit Exchange gearbeitet.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.