Solution Accelerator für die Konsolidierung und Migration von Domänenservern von Windows NT 4.0 nach Windows Server 2003

Auf dieser Seite

	Einführung
	Vorbereitende Tests
	Prozesstests
	Nachträgliche Tests
	Testergebnisse
	Zusammenfassung des Kapitels

Einführung

In diesem Dokument werden die Tests beschrieben, die durchgeführt wurden, um die Anleitungen zur Migration und Konsolidierung von einer flachen Domänenumgebung unter Windows NT® 4.0 zu einer Active Directory®-Umgebung unter Windows Server™ 2003 zu überprüfen. Das Dokument besteht aus den folgenden drei Abschnitten:

Zum Seitenanfang

Vorbereitende Tests

Die vorbereitenden Tests bestanden aus einer Folge von Buildüberprüfungen, um festzustellen, ob das Labor den Spezifikationen zum Testen der definierten Szenarien entsprach. Außerdem wurden Grundfunktionalität und Basiskonfiguration von Netzwerk-, Server- und Clientressourcen überprüft. Sowohl die Quell- als auch die Zielcomputer wurden genau untersucht, um sicherzustellen, dass alle Voraussetzungen für den Konsolidierungs- und Migrationsprozess vorhanden und einsatzbereit waren.

Die Prozesse für die Migration und Konsolidierung von Domänen wurden unter Verwendung freigegebener Ressourcen in derselben Laborumgebung durchgeführt. Daher wurden die vorbereitenden Tests nicht dienstspezifischer Bereiche zwischen beiden Testreihen gemeinsam genutzt, um einen doppelten Aufwand zu verhindern.

Tests der Netzwerktopologie

Die Überwachung der Computerressourcen, die für den Prozess der Domänenmigration und -konsolidierung vom Labor bereitgestellt wurden, wurde vor den Tests auf Dienstebene durchgeführt. Während der Überwachung wurden die folgenden Elemente überprüft: physischer Computerbestand, visuelle Computeridentifizierung, Funktionen der Netzwerkkonnektivität und richtige Zuweisung von Rollen pro Computerressource.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 161-166 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Abbildung 1: Modell der Windows NT 4.0-Domäne bei der Woodgrove National Bank (Ausgangsstatus)
Bild maximieren

Tests der Netzwerkdienste

In einer umfangreichen Folge von Tests wurde die Netzwerkkonnektivität sowie die Konfiguration von Domänen- und Netzwerkdiensten bei jedem Client und Server in der Umgebung überprüft. Um die korrekte Konfiguration der Testumgebung sicherzustellen, wurde jeder Computer auf die folgenden Punkte getestet:

Die Überwachung der Client- und Servereinstellungen erfolgte entsprechend der Abbildung Infrastruktur der Windows NT Server 4.0-Domäne bei der Woodgrove Bank (Ausgangsstatus) im Kapitel "Testlaborumgebung" des vorliegenden Testhandbuchs sowie entsprechend dem Arbeitsblatt "Configuration Matrix" (nur auf Englisch verfügbar), das im Testkit enthalten ist. Alle festgestellten Widersprüche wurden behoben.

Mithilfe schneller Pingtests über die Befehlszeile wurden die Basisnetzwerkkonnektivität und die entsprechenden IP-Adresszuweisungen bei jedem Computer und der Unterstützungshardware (Router) überprüft. Eventuell nicht erkannte Probleme wurden identifiziert und behoben.

Alle Server wurden zusätzlich überwacht, um zu überprüfen, ob die richtigen Netzwerkdienste vorhanden waren und erwartungsgemäß funktionierten. Server mit DHCP-, DNS- oder WINS-Diensten wurden auf Dienstkonfiguration und erfolgreiche Replikation hin untersucht. Anschließend wurde jeder Server heruntergefahren und erneut gestartet. Nach dem Start wurden die Dienstliste und -protokolle auf eventuelle Fehler oder Probleme überprüft, die behoben werden mussten.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 167-169, 173, 176, 177, 181, 186-190 und 282 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Microsoft® Exchange Server 5.5

Im Umfang des Projekts war die Migration und Konsolidierung der Domäne für die Messagingdienste nicht enthalten. Es wurden jedoch Tests durchgeführt, um das Vorhandensein, die Funktionalität und die richtige Konfiguration des Exchange Server 5.5-Dienstes zu überprüfen.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 170 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Tests der Datei- und Druckdienste

Bei den Tests der Datei- und Druckdienste wurde deren Funktionalität auf allen entsprechenden Servern und von allen Clients aus überprüft. Außerdem wurden die Sicherheitseinstellungen für jede Datei- und Drucksystemressource überprüft.

Sicherheitstests

Bei den Sicherheitstests für die Datei- und Druckdienste wurden die Berechtigungen für den Zugriff auf Ordner-, Datei-, Druckeranschluss- und Netzwerkressourcen (Freigaben) überprüft, um vor Beginn des Domänenmigrations- und -konsolidierungsprozesses sicherzustellen, dass alle Datei- und Druckobjekte über die entsprechenden Berechtigungen verfügten.

Um zu überprüfen, ob die festgelegten Kontogruppen über den geeigneten Zugriff zur Ausführung von Aufgaben für die jeweilige Sicherheitsstufe verfügten, wurden verschiedene Aktionen ausgeführt, während die Tester an einem lokalen Administratorkonto, einem Domänenbenutzerkonto und einem Domänenadministratorkonto angemeldet waren. Während der Kontensicherheitstests wurde überprüft, ob Folgendes zutraf:

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 172, 175, 204, 212, 213 und 216 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Clienttests

Die Datei- und -Drucktests für Clients wurden unter Verwendung von Windows® 98-, Windows NT 4.0 Workstation-, Windows® 2000 Professional- und Windows® XP Professional-Clients durchgeführt, um sicherzustellen, dass sämtliche Netzwerkressourcen für jeden Clienttyp an jedem Standort angezeigt wurden. Durch zusätzliche Tests wurden die Konnektivität und die Zugriffsmöglichkeit auf anwendbare Datei- und Druckserver sowie deren jeweilige Ressourcen überprüft.

Bei den Sicherheitstests für Clients wurde überprüft, ob die festgelegten Kontogruppen von jedem Clienttyp aus ordnungsgemäß auf die Datei- und Druckressourcen zugreifen und diese bearbeiten konnten. Die Aktionen zum Zugreifen auf und Ändern von Ordnern, Dateien und Druckern wurden bei jedem der drei Clienttypen durchgeführt, während die Tester an einem lokalen Administratorkonto, einem Domänenbenutzerkonto und einem Domänenadministratorkonto angemeldet waren.

Clientmessagingtests wurden bei jedem Clienttyp durchgeführt, um die Konnektivität mit dem jeweiligen Exchange 5.5-Server zu überprüfen und sicherzustellen, dass Messagingfunktionen vorhanden waren.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 178-180 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Domänentests

Die Domänentests bestanden darin, die im Unternehmen vorhandenen Domänenobjekte zu überprüfen, bevor irgendwelche Prozesse ausgeführt wurden. Überprüft wurden vier Objektklassifizierungen: Gruppen, Benutzer, Computer und Gruppenmitgliedschaft.

Bei jedem Domänencontroller wurde durch die Domänentests überprüft, ob globale Gruppen, Benutzerkonten, Computerkonten und Gruppenmitgliedschaften mit den vom Entwicklungsteam aufgestellten Funktionsanforderungen übereinstimmten.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 182-185 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Zum Seitenanfang

Prozesstests

Die Prozesstests konzentrierten sich hauptsächlich darauf zu überprüfen, ob die in den angegebenen Kapiteln des Implementierungshandbuchs enthaltenen Anleitungen einwandfrei funktionierten und nicht zu undokumentierten Fehlern bei der betrieblichen Verfügbarkeit oder zu Sicherheitslücken führten. Diese Kapitel umfassten:

Jede Phase des Prozesses wurde entsprechend den bereitgestellten Anleitungen durchgeführt, um die Exaktheit und Vollständigkeit sicherzustellen. Programmfehler wurden mit den Anleitungen verglichen, wenn Widersprüche in der Dokumentation gefunden wurden oder Schritte des Prozesses unklar waren.

In der ersten Phase, "Aufgaben vor der Migration", wurde die Umgebung für den Migrationsprozess vorbereitet.

In der zweiten Phase wurde die Aktualisierung der primären Kontendomäne vom Betriebssystem Windows NT 4.0 Server auf das Betriebssystem Windows Server 2003 durchgeführt. Diese Phase umfasste auch ein vorgeschlagenes Fallbackszenario für Domänenaktualisierung, anhand dessen der vorherige Zustand wiederhergestellt werden kann.

Die dritte Phase konzentrierte sich auf die Migration der wichtigsten Netzwerkdienste (DHCP und WINS) in die neu erstellte Windows Server 2003-Umgebung, da DNS bereits in der vorhergehenden Phase migriert worden war.

In der vierten und fünften Phase wurde der größte Teil der Prozesse für die Domänenmigration und -konsolidierung durchgeführt. Dies betraf hauptsächlich die Migration der Domänenobjekte aus dem flachen Domänenbereich unter Windows NT 4.0 nach Windows Server 2003 Active Directory.

Die abschließende Phase umfasste die Außerbetriebnahme der nicht mehr benötigten Windows NT 4.0-Kontendomäne und die erneute Bereitstellung der Domänencontroller.

Aufgaben vor der Migration

Vor der Aktualisierung bzw. Neustrukturierung der Windows NT 4.0-Domänen in der Laborumgebung führte das Testteam bestimmte Aufgaben aus, um sicherzustellen, dass die Umgebung migrationsbereit war. Die ausgeführten Aufgaben vor der Migration bestanden aus Folgendem:

Kontendomänenaktualisierung

Bei der direkten Aktualisierung einer Windows NT 4.0-Domäne muss als erster Server der primäre Domänencontroller (PDC) aktualisiert werden. Vor dem Aktualisieren des PDCs auf Windows Server 2003 musste das Testteam entsprechend dem Migrationsplan der Bank einen neuen PDC konfigurieren, dessen Hardware das Betriebssystem Windows Server 2003 unterstützen konnte. Darüber hinaus musste die DNS-Infrastruktur zur Unterstützung dynamischer Aktualisierungen für die Active Directory-Installation neu konfiguriert werden.

Einführen neuer Hardware und Konfigurieren des DNS-Namespaces

Während der Aktualisierung des Windows NT 4.0-PDC auf Windows Server 2003 sucht der Assistent zum Installieren von Active Directory nach einem DNS-Server. Die Bereitstellung eines DNS-Servers unter Windows Server 2003 während dieses Prozesses ist nicht zwingend erforderlich, empfiehlt sich jedoch, da dieser Server sämtliche DNS-Dienste (z. B. SRV-Einträge und dynamische Aktualisierungen) unterstützt, die für die effiziente Ausführung von Active Directory benötigt werden. Das Testteam erkannte, dass der PDC während der Aktualisierung in die DNS-Datenbank schreiben musste, damit er die für Active Directory erforderlichen Zonen erstellen konnte.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 225-227 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Heraufstufen des neuen primären Domänencontrollers

Bei der Beurteilung der Domänencontroller in der Domäne WNB-ACCT-A zeigte es sich, dass die PDC-Hardware die Aktualisierung auf das Betriebssystem Windows Server 2003 nicht unterstützen konnte. Deshalb entschloss sich das Testteam, den neu eingeführten Sicherungsdomänencontroller (Backup Domain Controller – BDC) mit Hardware, auf der Windows Server 2003 besser ausgeführt werden konnte, zum neuen PDC heraufzustufen.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 228-232 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Konfigurieren für Fallbacks bei Domänenaktualisierungen

Das Testteam führte eine vollständige Sicherung (Systemstatussicherung) des PDCs und des Offline-Ziel-BDCs (Fallback-BDC) durch, bevor es mit der Aktualisierung des PDCs begann. Bei einem Windows NT 4.0-Domänencontroller umfasst eine Systemstatussicherung das Sichern der Registrierung, der Betriebssystemdateien, der Freigabe NETLOGON sowie der SAM-Datenbank (Security Accounts Manager). Im Rahmen des Fallbackplans wählte das Testteam einen der Sicherungsdomänencontroller als Fallbackserver aus. Dieser Server wurde nach Durchführung der vollständigen Synchronisierung aus dem Netzwerk entfernt und an einem sicheren Standort platziert.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 233 und 241-245 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Aktualisieren des primären Domänencontrollers

Nach der Vorbereitung der DNS-Umgebung und dem umfassenden Testen des Fallbackplans bestand der nächste Schritt in der eigentlichen direkten Aktualisierung auf dem Windows NT 4.0-PDC.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 234-240 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Konfigurieren der Replikation für die DNS-Zone unter Windows Server 2003

Um sicherzustellen, dass alle vorhandenen Clients unter Windows 2000 und höher in der Domäne WNB-ACCT-A die DNS-Namen für die Domäne corp.woodgrovebank.com und deren Domänencontroller auflösen konnten, mussten die DNS-Server so konfiguriert werden, dass alle die DNS-Zone corp.woodgrovebank.com aufwiesen. Die DNS-Server unter Windows NT 4.0 (NYC-WR-DHCP-01 und NYC-WR-DHCP-02) wurden als sekundäre DNS-Server zum aktualisierten PDC konfiguriert, der als primärer DNS-Server fungierte.

Das Testteam überprüfte die Namenservereinträge für die DNS-Server unter Windows NT 4.0 in der DNS-Zone corp.woodgrovebank.com. Es überprüfte außerdem, ob die Namenservereinträge für die DNS-Server unter Windows NT 4.0 in DNS auf dem Windows Server 2003-PDC so konfiguriert waren, dass die einwandfreie Replikation der DNS-Zonen sichergestellt war.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 246-247 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Planen der Lbridge-Replikation

Während des Migrationszeitraums für die Domäne WNB-ACCT-A existierte eine Mischung aus Windows Server 2003-Domänencontrollern und Windows NT 4.0-Sicherungsdomänencontrollern. Da der LAN Manager-Replikationsdienst (LAN Manager Replication Service – LMRepl) unter Windows NT 4.0 auf einem Windows Server 2003-Domänencontroller nicht unterstützt wird, wurde eine Brücke zwischen dem LMRepl-Dienst und dem Dateireplikationsdienst (File Replication Service – FRS) unter Windows Server 2003 erstellt. Der herabgestufte PDC (NYC-WA-DC-01) wurde als letzter Windows NT 4.0-Domänencontroller in der Domäne ausgewählt; er hostete das Exportverzeichnis für Windows NT 4.0-LMRepl als PDC (und danach als BDC). Durch regelmäßiges Planen des Skripts Lbridge.cmd wurde erreicht, dass Daten zwischen LMRepl und FRS kopiert wurden. Die Häufigkeit des geplanten Auftrags wurde beim Windows Server 2003-Domänencontroller auf alle zwei Stunden festgelegt.

Das Testteam verwendete das Skript Lbridge.cmd und das Dienstprogramm xcopy.exe, damit die in Windows Server 2003 erstellten Dateien in der Freigabe NETLOGON zum Windows NT 4.0-Exportserver repliziert wurden. Schrittweise Anleitungen zum Erstellen des Dienstkontos für diese Aufgabe finden Sie im Abschnitt "Synchronize File Replication Services" im Windows Server 2003 Resource Kit Deployment Guide unter dem folgenden URL (nur auf Englisch verfügbar):

http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/.

Das Verfahren stellt sicher, dass eine geplante Aufgabe zum Kopieren der Dateien aus der Freigabe NETLOGON des Windows Server 2003-Domänencontrollers eingerichtet wird.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 248 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Erweitern des Active Directory-Schemas

Als die Woodgrove Bank die Aktualisierung auf Exchange Server 2003 plante, wurde das Active Directory-Schema gleich nach der Installation des ersten Active Directory-Domänencontrollers erweitert.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 249 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Aktualisieren der verbleibenden Sicherungsdomänencontroller

Entsprechend dem Migrationsplan musste der SID-Verlauf (Security Identifier – Sicherheitskennung) während der Migration der Sicherheitsprinzipale aus der zweiten Kontendomäne beibehalten werden. Zu diesem Zweck musste die Domäne auf die Funktionsebene von Windows Server 2003 umgeschaltet werden. Für den Übergang zur Funktionsebene von Windows Server 2003 muss auf allen Domänencontrollern Windows Server 2003 ausgeführt werden. Infolgedessen forderte der Migrationsplan eine schnelle Bereitstellung bzw. Aktualisierung aller verbleibenden Windows NT 4.0-Sicherungsdomänencontroller in der Domäne WNB-ACCT-A.

Das Testteam hatte festgestellt, dass einige Sicherungsdomänencontroller aufgrund von Hardwareeinschränkungen ersetzt statt direkt aktualisiert werden müssten. Der Ersatz für diese Domänencontroller wurde in eine Stagingsite integriert und sofort an den Zielort versendet. Der alte Sicherungsdomänencontroller für diesen Standort wurde offline geschaltet und sicher entsorgt.

Dies geschah, weil der offline geschaltete Sicherungsdomänencontroller nicht mehr benötigt wurde. (Als Fallback-Sicherungsdomänencontroller diente dagegen derjenige Controller, der offline geschaltet und sicher aufbewahrt worden war. Siehe den Abschnitt "Konfigurieren für Fallbacks bei Domänenaktualisierungen" weiter oben in diesem Kapitel.) Da nun Windows Server 2003 auf jedem Domänencontroller in der Domäne WNB-ACCT-A ausgeführt wurde, entfernte das Testteam das geplante FRS-Skript, das für den täglichen Export von Skripts zum LMRepl-Exportserver sorgte, vom Domänencontroller.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 250-252 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Heraufstufen der Gesamtstruktur- und Domänenfunktionsebene

Da die Ausführung aller Domänencontroller in der Active Directory-Domäne und -Gesamtstruktur jetzt unter Windows Server 2003 erfolgte, wurde die Funktionsebene zu Windows Server 2003 heraufgestuft. Das Testteam verwendete Active Directory-Domänen und -Vertrauensstellungen, um die Domänen- und Gesamtstrukturfunktionsebene auf Windows Server 2003 zu ändern.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 253 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Migrieren der Netzwerkdienste

Gültige IP-Adressen und eine gültige Namensauflösung sind eine der wichtigsten Anforderungen an eine Client/Server-Infrastruktur mit TCP/IP-Netzwerken. Obwohl DNS die primäre Methode der Namensauflösung in Windows Server 2003 darstellt, gab es bei der Woodgrove Bank noch verschiedene Anwendungen, für die eine NetBIOS-Namensauflösung über WINS erforderlich war. DNS war bereits nach Windows Server 2003 migriert worden, während die DHCP- und WINS-Dienste noch unter Windows NT 4.0 gehostet wurden. Im Folgenden wird der Prozess beschrieben, mit dem das Testteam die DHCP- und WINS-Dienste nach Windows Server 2003 migrierte.

Verkürzen der DHCP-Leasedauer

Um den Administratoren der Woodgrove Bank eine schnellere Außerbetriebnahme der vorhandenen DHCP-Server zu ermöglichen, wurden die Leasedauern der DHCP-Bereiche verkürzt. Clients empfingen die neuen DHCP-Leasedauern bei der nächsten DHCP-Erneuerung.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 254 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Konfigurieren des Windows Server 2003-Clusters

Die Bank beabsichtigte, DHCP und WINS in einer Clusterkonfiguration bereitzustellen, um die Verfügbarkeit zu erhöhen. Sowohl der DHCP- als auch der WINS-Dienst würden Windows Clustering bei einer aktiven/passiven Konfiguration mit zwei Knoten verwenden. Abbildung 2 zeigt die DHCP- und WINS-Clusterserver der Woodgrove Bank. NYC-WA-MSP-01 wäre der aktive DHCP- und WINS-Server und NYC-WA-MSP-02 der Sicherungsserver.

Abbildung 2: DHCP/WINS-Cluster der Woodgrove Bank
Bild maximieren

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 255-257 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Hinzufügen der neuen DHCP-Bereiche

Das Testteam aktivierte die DHCP-Konfliktbehebung als ein Mittel zum Migrieren der DHCP-Bereiche auf den neuen DHCP-Server unter Windows Server 2003. Obwohl es möglich gewesen wäre, die Bereichsinformationen von den DHCP-Servern unter Windows NT 4.0 mithilfe des Tools DHCPExIm zu exportieren, wurde der manuelle Prozess als ausreichend angesehen.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 258 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Autorisieren der DHCP-Bereiche

DHCP-Server in einer Active Directory-Domäne müssen autorisiert werden, um zu verhindern, dass Rogue-DHCP-Server online geschaltet werden und so einen DHCP-Server autorisieren.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 259 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Aktivieren von Bereichen

Die Bereiche mussten aktiviert werden, bevor sie DHCP-Adressen für Clients bereitstellen konnten.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 260 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Deaktivieren der DHCP-Bereiche unter Windows NT 4.0

Sobald die Bereiche auf dem DHCP-Clusterserver aktiviert worden waren, wurden die DHCP-Bereiche unter Windows NT 4.0 deaktiviert.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 261-262 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Migrieren von WINS nach Windows Server 2003

Die Push/Pull-Replikation von WINS war die einfachste, effektivste Möglichkeit zum Migrieren der WINS-Datenbank auf den neuen Windows Server 2003-Cluster.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 263 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Neustrukturieren zusätzlicher Kontendomänen

Nach Abschluss der direkten Aktualisierung und nach dem Umschalten der Domäne corp.woodgrovebank.com auf die Windows Server 2003-Funktionsebene konnten zusätzliche Windows NT 4.0-Masterbenutzerdomänen in der Active Directory-Domäne neu strukturiert werden.

Da in mehreren Ressourcendomänen auf die Sicherheitsprinzipale der Domäne WNB-ACCT-ROW verwiesen wurde, konnte diese Benutzerdomäne erst dann außer Betrieb genommen werden, nachdem sämtliche Ressourcen migriert und deren Sicherheitsverweise konvertiert worden waren. Außerdem wurde erwartet, dass Änderungen an nicht migrierten Benutzerobjekten während des Migrationsprozesses weiterhin in der Domäne WNB-ACCT-ROW vorgenommen würden. Um sicherzustellen, dass die Domäne WNB-ACCT-ROW und die Active Directory-Domäne corp.woodgrovebank.com eine einheitliche Darstellung von Benutzer- und Gruppenobjekten aufwiesen, wurde das Active Directory Migration Tool, Version 2, (ADMT v2) so geplant, dass die Aktualisierung der Active Directory-Domäne mit eventuellen Änderungen über Nacht erfolgte.

Erstellen der OU-Zielstruktur und -Delegierung

In der Domäne corp.woodgrovebank.com wurde eine temporäre OU-Struktur (Organizational Unit – Organisationseinheit) als Repository für die migrierten Objekte erstellt. Die Objekte wurden in eine temporäre Organisationseinheit migriert, damit die Benutzerkontenverwalter und Desktopkonfigurationsadministratoren bei der Woodgrove Bank eventuelle Namenskonflikte, die während der Migration auftraten, auf einfache Weise beheben konnten. Nach Behebung dieser Konflikte wurden die Objekte durch die Benutzerkontenverwalter in die jeweils richtige Organisationseinheit verschoben.

In dieser Phase des Migrationsprozesses wurde die temporäre OU-Struktur für die migrierten Objekte an die Benutzerkontenverwalter und die Desktopkonfigurationsadministratoren delegiert. Der Gruppe <Quelldomäne> Datenadministratoren wurde Vollzugriff auf Computerobjekte in der OU-Struktur Migrierte Objekte\<Quelldomäne>\Computer und Migrierte Objekte\<Quelldomäne>\Server gewährt. Vollzugriff auf Gruppenobjekte wurde auch der Organisationseinheit Migrierte Objekte\<Quelldomäne>\Gruppen gewährt. Die Benutzerkontenverwalter wurden der Gruppe <Quelldomäne> Datenadministratoren zugeordnet.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 264 und 272 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Identifizieren von Dienstkonten

Als spätere Hilfe bei den Computermigrationen war es wichtig, Anwendungen zu identifizieren, die ein Dienstkonto auf Mitgliedsservern und Domänencontrollern verwendeten. Bei einem Dienstkonto handelt es sich um ein Benutzerkonto, das explizit erstellt wurde, um einen Sicherheitskontext für diese Anwendungen bereitzustellen, und dem die Rechte "Anmeldung als Dienst" erteilt wurden. Der Migrationsplan beschrieb eine Liste von Servern mit Anwendungen, die als Dienste im Sicherheitskontext eines Dienstkontos ausgeführt wurden.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 265 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Migrieren globaler Gruppen

Die globalen Gruppen aus der Kontendomäne WNB-ACCT-ROW mussten als erste Sicherheitsprinzipale migriert werden, damit sie ihre Mitgliedschaft bei der im nächsten Schritt erfolgenden Migration der Benutzerkonten beibehielten. Der Migrationsplan der Woodgrove Bank forderte es, dass alle in der Domäne WNB-ACCT-ROW definierten Gruppen migriert wurden, statt das Risiko einzugehen, den Unternehmenszugriff auf zu migrierende Daten zu verlieren.

Durchführen einer Pilotmigration von Gruppen

Eine Pilotmigration wurde durchgeführt, um sicherzustellen, dass die ausgewählten Migrationsoptionen den erforderlichen Endstatus erzeugten; zu diesen Optionen gehörten die Benennung der Gruppen, die Ziel-OU, die Konfliktbehebung und die SID-Verlaufmigration. Die Migration war mit dem Auswählen von fünfzig globalen Gruppen und deren Migrieren aus der Domäne WNB-ACCT-ROW in das Active Directory der Domäne corp.woodgrovebank.com verbunden. Eine gründliche Auswertung der Pilotmigration wurde durchgeführt, um sicherzustellen, dass die Migration erfolgreich und wie erwartet verlaufen war. Diese Gruppen würden in die endgültige Gruppenmigration einbezogen, d. h., sie würden während der nächsten Gruppenmigrationsphase erneut migriert.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 266 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Gruppenmigration mithilfe der ADMT v2-Befehlszeilenoption

Da die Gruppenmigration mit einer großen Anzahl von Gruppenobjekten verbunden war, hielt es das Testteam für sinnvoll, die Gruppenkonten mithilfe der ADMT v2-Befehlszeilen- und -Skriptoptionen zu migrieren.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 267 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Migrieren von Benutzerkonten

Nachdem die Gruppen aus der Domäne WNB-ACCT-ROW migriert worden waren, konnten die Benutzer der Domäne mithilfe von ADMT v2 migriert werden. Das Testteam migrierte die Benutzerkonten unmittelbar nach dem erfolgreichen Abschluss der Gruppenmigration.

Durchführen einer Pilotmigration von Benutzerkonten

Eine Pilotmigration wurde durchgeführt, um sicherzustellen, dass die ausgewählten Migrationsoptionen den erforderlichen Endstatus erzeugten; zu diesen Optionen gehörten die Benennung der Benutzer, die Ziel-OU, die Konfliktbehebung und die SID-Verlaufmigration. Die Migration war mit dem Auswählen von fünfzig Benutzern und deren Migrieren aus der Domäne WNB-ACCT-ROW in das Active Directory der Domäne corp.woodgrovebank.com verbunden. Eine gründliche Auswertung der Pilotmigration wurde durchgeführt, um sicherzustellen, dass die Migration erfolgreich war und die Ergebnisse den Erwartungen entsprachen. Diese Benutzer wurden aus der endgültigen Migration der Benutzerkonten ausgeschlossen.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 268 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Benutzerkontenmigration mithilfe der ADMT v2-Befehlszeilenoption

Da die Benutzerkontenmigration mit einer großen Anzahl von Benutzerobjekten verbunden war, hielt es das Testteam für sinnvoll, die Benutzerkonten mithilfe der ADMT v2-Befehlszeilen- und -Skriptoptionen zu migrieren.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 269 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Zusammenführen von Konten

Die Benutzerkontenverwalter mussten möglicherweise mehrere Konten aus der Quelldomäne in einem einzigen Zielbenutzerkonto zusammenführen. Das Zusammenführen von Konten wäre erforderlich, wenn ein Mitarbeiter der Woodgrove Bank in jeder der beiden Domänen WNB-ACCT-A und WNB-ACCT-ROW über ein getrenntes Benutzerkonto verfügte. Zum Konsolidieren der Benutzerkonten in einem einzigen Active Directory-Benutzerobjekt würde ein zusätzliches Attribut sidHistory zum Objekt hinzugefügt.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 270 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Neustrukturieren von Ressourcendomänen

Durch die Neustrukturierung von Ressourcendomänen bei der Woodgrove Bank sollte deren Anzahl in der Windows Server 2003-Gesamtstruktur verringert werden. Dies bedeutete, dass die Ressourcen in den Windows NT 4.0-Ressourcendomänen in der Active Directory-Organisationseinheit der Domäne corp.woodgrovebank.com konsolidiert werden mussten. Normalerweise enthielten die Ressourcendomänen der Woodgrove Bank Arbeitsstationskonten, Serverkonten und eine begrenzte Anzahl von Dienstkonten. Im Woodgrove Bank-Szenario wurden die Domänen WNB-RES-A und WNB-RES-SYD in der Domäne corp.woodgrovebank.com konsolidiert. Die Exchange 5.5-Domäne, WNB-MESSAGING, wurde beibehalten, und in Plänen wurde gefordert, dass sie während eines zukünftigen Exchange Server 2003-Bereitstellungsprojekts in der Active Directory-Gesamtstruktur konsolidiert werden sollte.

Einrichten von Vertrauensstellungen

Zum Migrieren von Objekten zwischen einer Windows NT 4.0-Ressourcendomäne und der Windows Server 2003 Active Directory-Domäne mussten externe Vertrauensstellungen vorhanden sein. Da das Migrationsbenutzerkonto in der Ressourcendomäne vorhanden war, wurde eine bidirektionale Vertrauensstellung eingerichtet, um die Delegierung der Ressourcenorganisationseinheit in der Domäne corp.woodgrovebank.com zu ermöglichen. Das Einrichten der bidirektionalen Vertrauensstellungen in der Umgebung der Woodgrove Bank zur Migration der Ressourcendomäne war akzeptabel, da die Domänen gleich nach der Migration der Objekte außer Betrieb genommen wurden. Eine Alternative zum Einrichten der bidirektionalen Vertrauensstellung zwischen der Ressourcendomäne und der Domäne corp.woodgrovebank.com wäre die Migration mit einem Benutzerkonto in corp.woodgrovebank.com gewesen, das in der Ressourcendomäne und auf allen darin zu migrierenden Computern über Administratorrechte verfügte.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 271 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Migrieren von Arbeitsstationen

Der Prozess des Migrierens von Arbeitsstationen zur Domäne corp.woodgrovebank.com wurde von den Desktopkonfigurationsadministratoren nach Möglichkeit vor Ort durchgeführt. Dieser Prozess umfasste das Erstellen eines neuen Computerkontos in der Domäne corp.woodgrovebank.com, das Transformieren der Sicherheitsprinzipale auf der Arbeitsstation sowie das Ändern der Domänenmitgliedschaft des Computers. Auf einer Migrationsarbeitsstation vor Ort wurde ADMT v2 installiert, und die ADMT v2-Agenten wurden für jeden Computer remote bereitgestellt. Obwohl es bei ADMT v2 keine Einschränkungen hinsichtlich der Anzahl der Computer gibt, die auf einmal migriert werden könnten, entschloss sich das Testteam, die Menge der zu migrierenden Computer auf 500 zu begrenzen. Auf diese Weise konnten sie die migrierten Arbeitsstationen adäquat unterstützen, falls der vorherige Zustand hätte wiederhergestellt werden müssen. Das Dialogfeld Agentenüberwachung in ADMT v2 wurde zum Überprüfen der erfolgreichen Migration jeder Arbeitsstation verwendet.

Wenn an einem Standort der Woodgrove Bank keine Desktopkonfigurationsadministratoren anwesend waren, konnten die Arbeitsstationen remote migriert werden. Die Standorte für die Remotedurchführung einer Arbeitsstationsmigration enthielten in der Regel weniger als 20 Arbeitsstationen.

Generieren einer SID-Zuordnungsdatei

Bei der Konvertierung von Sicherheit verwendete ADMT v2 die in der Datei protar.mdb gespeicherten internen Informationen zu migrierten Konten, um zu entscheiden, welche Zugriffssteuerungslisten auf welche Weise konvertiert werden mussten. Mithilfe einer SID-Zuordnungsdatei hätten diese Informationen überschrieben werden können. Das Testteam verwendete SID-Zuordnungsdateien zum Konvertieren der Sicherheitsprinzipale in der Ressourcendomäne in die neuen Sicherheitsprinzipale der Domäne corp.woodgrovebank.com.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 273 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Durchführen der Pilotsicherheitskonvertierung bei Arbeitsstationen

An jedem Standort wurde vor der eigentlichen Migration eine Pilotmigration von ca. zehn Arbeitsstationen durchgeführt. Dabei musste der Standardmigrationsprozess für Arbeitsstationen eingehalten werden.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 274 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Sicherheitskonvertierung bei Arbeitsstationen mithilfe der ADMT v2-Befehlszeilenoption

Da die Sicherheitskonvertierung mit einer großen Anzahl von Arbeitsstationen verbunden war, hielt es das Testteam für sinnvoll, die Sicherheit auf den Arbeitsstationen mithilfe der ADMT v2-Befehlszeilen- und -Skriptoptionen zu konvertieren.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 275 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Ändern der Domänenmitgliedschaft von Arbeitsstationen

Arbeitsstationen und Mitgliedsserver besitzen eine eigene SAM-Kontendatenbank. Wenn sie zwischen Domänen verschoben werden, wird diese Datenbank immer mit verschoben. Würden Konten, die in der lokalen SAM-Datenbank gespeichert sind (z. B. lokale Gruppen), zum Erteilen des Zugriffs auf Ressourcen verwendet, würden sie immer zusammen mit dem Computer verschoben. Deshalb war eine Migration dieser Konten nicht erforderlich. In dieser zweiten Phase der Migration von Arbeitsstationen wurde die Domänenmitgliedschaft der Arbeitsstationen auf die Domäne corp.woodgrovebank.com geändert. Für die Domänenänderung der Arbeitsstationen musste ein Neustart durchgeführt werden, der zeitlich auf eine Minute nach Abschluss der Migration festgelegt war.

Durchführen der Pilotcomputermigration bei Arbeitsstationen

An jedem Standort wurde vor der eigentlichen Migration eine Pilotmigration von ca. fünf Arbeitsstationen durchgeführt. Dabei musste der Standardmigrationsprozess für Arbeitsstationen eingehalten werden.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 276 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Computermigration mithilfe der ADMT v2-Befehlszeilenoption

Da die Computermigration mit einer großen Anzahl von Arbeitsstationen verbunden war, hielt es das Testteam für sinnvoll, die Arbeitsstationen mithilfe der ADMT v2-Befehlszeilen- und -Skriptoptionen zu migrieren.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 277 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Migrieren der Mitgliedsserver

Der Prozess und die Tools zum Migrieren eines Mitgliedsservers, wie z. B. eines Datei- und Druckservers, waren mit dem Migrationsprozess für Arbeitsstationen identisch. Der Migrationsplan enthielt einige zusätzliche Vorsichtsmaßnahmen für den Sicherheitskonvertierungsprozess im Rahmen des Migrationsprozesses der Mitgliedsserver bei der Woodgrove Bank, um die Fallbackverfahren (zum Wiederherstellen des vorherigen Zustands) zu erleichtern. Darüber hinaus war zusätzlicher Aufwand für Änderungskontrollprozesse und Benutzerkommunikaton erforderlich, da die Mitgliedsserver ebenfalls neu gestartet werden mussten, um die Änderung ihrer Domänenmitgliedschaft abzuschließen.

Durchführen der Pilotsicherheitskonvertierung bei Mitgliedsservern

Für den Pilotprozess wurde eine Sicherheitskonvertierung eines einzelnen Mitgliedsservers ausgewählt. Damit konnte das Testteam die Auswirkungen der Sicherheitskonvertierung untersuchen, bevor diese bei anderen Mitgliedsservern in der Domäne durchgeführt wurde.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 278 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Durchführen der Sicherheitskonvertierung bei Mitgliedsservern

Die Sicherheitskonvertierung musste auf allen Mitgliedsservern in der Woodgrove Bank durchgeführt werden. Auf diese Weise wurde sichergestellt, dass eventuelle Verweise auf migrierte Sicherheitsprinzipale, wie z. B. die Druckerwarteschlangen und die Zugriffssteuerungslisten für das Dateisystem, aktualisiert wurden. Da bei der Sicherheitskonvertierung kein Neustart erforderlich war, wurde sie direkt vor der Änderung der Domänenmitgliedschaft der Mitgliedsserver durchgeführt. Weil sich die Mitgliedsserver der Woodgrove Bank in einer Ressourcendomäne befanden, wurden Verweise auf migrierte Konten auf dem Mitgliedsserver mithilfe einer SID-Zuordnungsdatei identifiziert. Die SID-Zuordnungsdatei enthielt alle migrierten Benutzerkonten und Gruppen der Domäne corp.woodgrovebank.com.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 279 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Ändern der Domänenmitgliedschaft von Mitgliedsservern

Mitgliedsserver besitzen eine eigene SAM-Kontendatenbank. Wenn sie zwischen Domänen verschoben werden, wird diese Datenbank immer mit verschoben. Würden Konten, die in der lokalen SAM-Datenbank gespeichert sind (z. B. lokale Gruppen), zum Erteilen des Zugriffs auf Ressourcen verwendet, würden sie immer zusammen mit dem Computer verschoben. Deshalb war eine Migration dieser Konten nicht erforderlich.

In dieser zweiten Phase der Migration von Mitgliedsservern wurde die Domänenmitgliedschaft der Mitgliedsserver auf die Domäne corp.woodgrovebank.com geändert. Für die Domänenänderung der Mitgliedsserver musste ein Neustart durchgeführt werden, der zeitlich auf eine Minute nach Abschluss der Migration festgelegt war.

Durchführen der Pilotcomputermigration bei Mitgliedsservern

An jedem Standort wurde vor der eigentlichen Migration eine Pilotmigration eines einzelnen Mitgliedsservers durchgeführt. Dabei musste der Standardmigrationsprozess für Mitgliedsserver eingehalten werden.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 280 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Durchführen der Computermigration bei Mitgliedsservern

Die Computermigration musste auf allen Arbeitsstationen der Woodgrove Bank durchgeführt werden. Auf diese Weise wurde sichergestellt, dass die Computerkonten für die Arbeitsstation in der Domäne corp.woodgrovebank.com erstellt wurden und dass die Domänenmitgliedschaft auf der Arbeitsstation ebenfalls aktualisiert wurde.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 281 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Außerbetriebnehmen der zusätzlichen Kontendomäne

Das Endziel nach dem Migrieren aller Konten und Ressourcen aus der zusätzlichen Kontendomäne (WNB-ACCT-ROW) und nach dem Außerbetriebnehmen der Ressourcendomänen war die Außerbetriebnahme von WNB-ACCT-ROW und die erneute Bereitstellung der Domänencontroller. Die folgenden Voraussetzungen mussten erfüllt sein, um mit der Außerbetriebnahme der Domäne WNB-ACCT-ROW beginnen zu können:

Zum Seitenanfang

Nachträgliche Tests

Mit den nachträglichen Tests wurde der Erfolg der angewendeten Konsolidierungs- und Migrationsanleitungen überprüft, indem die Betriebsfunktionalität der konsolidierten und migrierten Server, Clients und Netzwerkressourcen bestätigt wurde.

Abbildung 3: Modell der Windows Server 2003 Active Directory-Domäne bei der Woodgrove National Bank (Endstatus)

Tests der Netzwerkdienste

Mit einer Teilmenge der vorbereitenden Tests wurde die Netzwerkkonnektivität sowie die Konfiguration von Domänen- und Netzwerkdiensten bei jedem Client und Server in der Umgebung überprüft. Um die korrekte Konfiguration der Umgebung für die nachträglichen Tests sicherzustellen, wurde jeder Computer auf die folgenden Punkte getestet:

Mithilfe schneller Pingtests über die Befehlszeile wurden die Basisnetzwerkkonnektivität und die entsprechenden IP-Adresszuweisungen bei jedem Computer überprüft.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 173, 176, 177, 181 und 186-190 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Exchange Server 5.5

Tests wurden durchgeführt, um das kontinuierliche Vorhandensein, die Funktionalität und die beibehaltene Konfiguration des Exchange Server 5.5-Dienstes zu überprüfen.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 170 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Tests der Datei- und Druckdienste

Nach Abschluss der Domänenmigration und -konsolidierung wurden die Berechtigungen für den Zugriff auf Datei-, Ordner-, Druckeranschluss- und Netzwerkressourcen erneut getestet, um sicherzustellen, dass dieser Prozess zu keinen Sicherheitslücken geführt hatte. Alle Datei- und Druckobjekte wurden auf die entsprechenden Berechtigungen überprüft. Die Tests bestätigten, dass durch den Migrations- und Konsolidierungsprozess keine Sicherheitsprobleme verursacht worden waren.

Mit Tests der Kontensicherheit wurde überprüft, ob alle angegebenen Kontogruppen über die richtigen Zugriffsstufen verfügten und Aufgaben ausführen konnten, die für die jeweiligen Sicherheitsstufen geeignet waren, doch keine Stufe überschritten. Verschiedene Aktionen zum Zugreifen auf und Ändern von Dateien und Druckern wurden durchgeführt, während die Tester an einem lokalen Administratorkonto, einem Domänenbenutzerkonto und einem Domänenadministratorkonto angemeldet waren. Mit anderen Tests wurde überprüft, ob die während des Migrations- und Konsolidierungsprozesses durchgeführte Sicherheitskonvertierung erfolgreich war und ob die Benutzer- und Gruppenkonten auf dieselben Ressourcen wie vor diesem Prozess zugreifen konnten.

Weitere Einzelheiten hierzu finden Sie unter den Testfall-IDs 172, 175, 213 und 216 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Clienttests

Clientmessagingtests wurden bei jedem Clienttyp durchgeführt, um die Konnektivität mit dem jeweiligen Exchange 5.5-Server zu überprüfen und sicherzustellen, dass Messagingfunktionen vorhanden waren.

Weitere Einzelheiten hierzu finden Sie unter der Testfall-ID 178 im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Zum Seitenanfang

Testergebnisse

In drei Testläufen wurde der Prozess der Domänenmigration und -konsolidierung überprüft. Alle Testläufe wurden mit derselben Konfiguration ausgeführt und Änderungen an den Prozessen nur aufgrund von Programmfehlern vorgenommen, die beim vorherigen Testlauf entdeckt worden waren.

Über den gesamten Testzyklus wurde die Qualität der Prozessdokumentation anhand von Dokumentprüfungen und der Behebung von Programmfehlern während der Tests verbessert. Bei jeder größeren Prozessänderung wurden zusätzliche Testläufe so lange durchgeführt, bis die Qualität bestätigt werden konnte. Beim abschließenden Testlauf für die Domänenmigration und -konsolidierung traten keine weiteren prozessbezogenen Fehler auf.

Weitere Einzelheiten zum abschließenden Testlauf finden Sie im Arbeitsblatt Domain Migration and Consolidation Test Cases and Results (nur auf Englisch verfügbar), das im Testkit enthalten ist.

Zum Seitenanfang

Zusammenfassung des Kapitels

Dieses Kapitel enthielt eine Beschreibung der Tests, die durchgeführt wurden, um die Anleitungen zur Konsolidierung und Migration von einer flachen Domänenumgebung unter Windows NT 4.0 zu einer Active Directory-Umgebung unter Windows Server 2003 zu überprüfen, die in den Kapiteln 6 - 11 des Implementierungshandbuchs zu finden sind. Die Tests bestanden aus vorbereitenden Tests, Prozesstests für die Konsolidierung und Migration von Domänen und Domänenobjekten sowie nachträglichen Tests.

Zunächst wurde mithilfe der vorbereitenden Tests sichergestellt, dass die Laborumgebung die Anforderungen für den Prozess der Konsolidierung und Migration von Windows NT 4.0-Domänen erfüllte. Danach wurden die Prozesstests anhand der Anleitungen in den angegebenen Kapiteln des Implementierungshandbuchs durchgeführt. Zum Schluss bestätigten die nachträglichen Tests den Erfolg des angewendeten Prozesses. Es wurden mehrere Testläufe durchgeführt, bis die erforderliche Prozessqualität erreicht war.

Zum Seitenanfang

7 von 7