Solution Accelerator für die Konsolidierung und Migration von Domänenservern von Windows NT 4.0 nach Windows Server 2003
Testplanungshandbuch
Auf dieser Seite
EinführungDieses Handbuch ist ein Teil von Solution Accelerator für die Konsolidierung und Migration von Domänenservern von Microsoft® Windows NT® Server 4.0 nach Windows Server™ 2003. Es bietet einen Überblick über den Testplan zur Überprüfung der Konsolidierung und Migration mehrerer Windows NT Server 4.0-Domänen mit WINS (Windows® Internet Name Service), DNS (Domain Name System), DHCP (Dynamic Host Configuration Protocol), Exchange sowie Datei- und Druckdiensten nach Windows 2003 Active Directory. Außerdem wird darin die Laborumgebung von Microsoft beschrieben, die zum Ausführen des Testplans verwendet wurde. Die Migration von Exchange sowie der Datei- und Druckdienste unter Windows NT Server 4.0 wird in diesem Solution Accelerator nicht behandelt. Zielgruppe für dieses DokumentDieses Dokument wurde für IT-Experten geschrieben, die für das Testen der Domänendienste in einer Unternehmensumgebung zuständig sind. Es richtet sich insbesondere an das Migrationsprojektteam und die an dem Migrationsprojekt beteiligten Berater. Vorausgesetzte KenntnisseDie Leser dieses Dokuments sollten den Umgang mit Windows NT Server 4.0-Domänen und dem Windows Server 2003 Active Directory-Dienst verstehen sowie über Kenntnisse zu dem in den anderen Handbüchern dieses Solution Accelerators beschriebenen Prozess der Konsolidierung und Migration von Domänen verfügen. Die in den Testlabors von Microsoft verwendeten Testprozesse sollten ihnen bekannt sein. Außerdem sollten die Leser die dafür erforderlichen Tools und Anwendungen kennen, wie z. B. das Dienstprogramm Ghost von Symantec, WinPE und die Anwendung Virtual Server. TestplanungIn diesem Abschnitt werden die Testziele, der Umfang, die Strategie und die Methodik sowie die Eingangs- und Freigabekriterien für die Tests beschrieben. TestzieleDie Tests in diesem Handbuch wurden entwickelt, um die bestehende Unsicherheit im Hinblick auf die Realisierbarkeit des vorgeschriebenen Migrations- und Konsolidierungsprozesses zu reduzieren oder ganz zu beseitigen. Mithilfe der Tests wurden fundamentale Umgebungs- und Prozessprobleme vor Veröffentlichung der Lösung erkannt und behoben. Durch die Verwendung eines etablierten, bewährten und getesteten Prozesses können Lösungsimplementierer den eigenen Migrations- und Konsolidierungsaufwand einfacher und bedenkenloser planen und dabei gleichzeitig Zeit und Geld sparen. Die Testziele lauteten:
TestumfangDas Testziel war die Überprüfung eines dokumentierten Prozesses für die Migration und Konsolidierung mehrerer Windows NT 4.0-Domänen in einem Unternehmen in eine Windows 2003 Active Directory-Domäne. Der Testumfang umfasste die folgenden Aufgaben:
Im Testumfang waren folgende Aufgaben nicht enthalten:
TeststrategieDas Testteam begann in Zusammenarbeit mit anderen Mitgliedern des Projektteams, komplexe Pläne zu formulieren, Schätzwerte zu planen und eine Strategie zu erstellen, die auf der Dokumentation zum Projektumfang und identifizierten Kundenszenarien basierte. Im Verlaufe des Projekts wurden diese Elemente an aktualisierte technische Informationen, Umfangsänderungen und betriebliche Realitäten angepasst. Anhand der Dokumentation zu Umfang und Szenarien entwarfen und definierten die Test- und Entwicklungsteams eine repräsentative Firmennetzwerkumgebung unter Windows NT 4.0 mit regionalen Niederlassungen und Zweigstellen. Nachdem diese Umgebung festgelegt worden war, wurde sie zum Referenzmodell für den Ausgangsstatus. Anschließend erstellten die Teams ein Modell für den Endstatus, indem sie festlegten, wie die Umgebung am Ende des Konsolidierungs- und Migrationsprozesses aussehen würde. Ferner wertete das Testteam Szenariodaten zusammen mit dem Anfangsprozess und den Anleitungen aus, um die Test- und Laboranforderungen festzulegen. Es wurde ermittelt, dass nur eine Teilmenge der in die Referenzmodelle einbezogenen Server für Testzwecke tatsächlich benötigt wurde. Aus Prozesssicht waren ein Drittel (oder mehr) Serverinstanzen lediglich in eine Wiederholung des Prozesses für eine zweite Serverinstanz einbezogen. Daher wurden maximal zwei Instanzen eines Servertyps benötigt, um den Prozess für eines der definierten Szenarien zu beweisen. Im nächsten Schritt stellte das Laborteam die erforderliche Hardware und die Basisbetriebssysteme gemäß den ihm vorliegenden Hardware- und Softwarespezifikationen bereit. Diese Spezifikationen enthielten eine Teilmenge des Referenzausgangs- und -endstatus. Nach der ersten Bereitstellung konfigurierten die Entwickler zusammen mit dem Testteam die Server für den Ausgangs- und Endstatus auf einen Status vor der Migration. Das Testteam führte verschiedene Überwachungen und Ablaufüberprüfungen (Build Verification Tests – BVTs) durch, um die Funktionalität der bereitgestellten Systeme sicherzustellen. Anschließend erstellte das Laborteam ein Image der Systeme für spätere erneute Bereitstellungen. Als Nächstes führten die Entwickler mit Unterstützung des Testteams Tests der Einführungseinheit und End-to-End-Prozessdurchläufe durch. Sobald die Entwickler von den Prozessen und Programmen überzeugt und die Eingangskriterien für offizielle Tests erfüllt worden waren, wurde das Labor an das Laborteam zurückgegeben, damit dieses eine imagebasierte erneute Bereitstellung durchführte. Nach Überprüfung einer erneut bereitgestellten und funktionierenden Umgebung begann das Testteam mit der offiziellen Testphase, die im Abschnitt "Testmethodik" dieses Dokuments beschrieben wird. Die Serversysteme wurden mehrmals während des gesamten offiziellen Testvorgangs unter Verwendung von imagebasierten Wiederherstellungen auf dem Status vor der Migration erneut bereitgestellt, um das wiederholte Testen des Konsolidierungs- und Migrationsprozesses zu beschleunigen. Zusätzliche Testläufe wurden durchgeführt, bis der Prozess und die Dokumentation das erforderliche Qualitätsniveau erreicht hatten, das im Abschnitt "Freigabekriterien für die Tests" dieses Dokuments definiert wird. Außerdem durfte die Rate neuer Programmfehler im Hinblick auf Menge und Schweregrad nur minimal sein, bevor die offiziellen Tests als beendet galten. Entwicklung von TestfällenUnabhängig davon, ob es sich um das Testen einer Architektur oder eines Prozesses handelt, liegt ein abgeschlossener erster Entwurf der Lösung in den meisten Fällen erst kurz vor dem Beginn der offiziellen Tests vor. Allerdings ist das Definieren einer umfassenden Reihe von Testfällen bis zur geeigneten Tiefe ein zeitaufwändiger und komplizierter Prozess. Zur Erreichung der Testziele muss die Entwicklung von Testfällen in einer frühen Phase beginnen und parallel zu einem großen Teil der Entwicklungsarbeiten stattfinden. Die Testfallentwicklung begann kurz nach der ersten Festlegung der Server und Dienste für den Ausgangs- und Endstatus. Die Spezifikation für Testfälle wurde fortlaufend weiterentwickelt, während vom Entwicklungsteam weitere Details der Konsolidierungs- und Migrationsprozesse festgelegt und dokumentiert wurden. Nach Überprüfung der verfügbaren Projektdokumentation begannen die Tester mit dem Erstellen erster Testfallspezifikationen für jeden der Komponentenbereiche. Diese Spezifikationen bestanden aus Skizzen der Bereiche, die getestet werden mussten. Viele der frühen Arbeiten basierten auf früheren Erfahrungen mit dem Komponentenbereich, da zu diesem Zeitpunkt nur eine rudimentäre Prozessdokumentation entwickelt worden war. Diese Skizzen wurden aufgrund des Feedbacks anderer Teammitglieder sowie der kontinuierlich reifenden Prozessdokumentation erweitert. Sobald sich die einzelnen Testfallskizzen zu stabilisieren begannen, wurden sie vom Tester zusammen mit dem zuständigen Entwickler überprüft und erforderliche Änderungen auf der Basis des empfangenen Feedbacks vorgenommen. Anschließend wurden die ersten Testfälle erstellt und in eine interne Überwachungsdatenbank für Programmfehler und Testfälle eingegeben, um jeden in den Testfallskizzen angegebenen Unterabschnitt zu berücksichtigen. Die entstehende Prozessdokumentation wurde überprüft und erneut überprüft, als sie den Status zur Entwicklung weiterer Fälle erreichte. Die Dokumentation wurde ausgewertet, um festzulegen, welche Ansprüche an sie gestellt werden sollten und für welche Ansprüche spezifische Tests seitens des Testteams erforderlich wären. In der Woche vor dem geplanten Beginn des offiziellen Testlaufs wurden die tatsächlichen Testfälle zusammen mit den zuständigen Entwicklern überprüft. Während der Ausführung des offiziellen Testlaufs wurden einige Fälle nach Bedarf geändert, gelöscht oder hinzugefügt. TestmethodikIn diesem Abschnitt wird die gesamte Testmethodik für Solution Accelerator für die Konsolidierung und Migration von Domänenservern von Windows NT Server 4.0 nach Windows Server 2003 beschrieben. Zunächst werden die verschiedenen Testtypen definiert, und anschließend wird die Abfolge von Testausführungen und Testzyklen beschrieben. TesttypenDer Schwerpunkt der Tests wich von den typischen MSA-Tests und Produkttests ab. MSA-Tests konzentrieren sich in der Regel auf Systemintegrationen sowie Interoperabilität und Koexistenz von Produkten. Produkttests konzentrieren sich auf das einzelne Produkt und dessen Funktionen. Im Gegensatz dazu lag der Schwerpunkt der Domänentests auf Prozessen und deren Auswirkungen auf die vorhandenen und neu eingerichteten Systeme eines Unternehmens. Dabei wurde besonderer Wert auf die Überprüfung der Sicherheit, Stabilität und Koexistenz von Systemen während der Konsolidierungs- und Migrationsprozesse gelegt. Das Testteam berücksichtigte die folgenden Testtypen für jeden betroffenen Bereich:
DokumentüberprüfungenDiese Tests wurden vor allen anderen offiziellen Tests durchgeführt, um sicherzustellen, dass die Prozesse den bekannten optimalen Methoden sowie den wichtigsten Dokumentationen mit sich teilweise überschneidenden Bereichen entsprachen. Die Überprüfung der Dokumentation begann mit einer kritischen Prüfung der Planungs- und Prozessdokumentation im Hinblick auf die Identifizierung von Fehlern bei der Genauigkeit, Einheitlichkeit, Lesbarkeit oder Übersichtlichkeit. Überwachungen, Ablaufüberprüfungen und BasisfunktionstestsBei diesen Tests wurde die Konfiguration und Basisfunktionalität der Systeme und Dienste überprüft. Damit wurde gewährleistet, dass die Bereitstellung den Spezifikationen entsprach und dass die Systeme funktional blieben und während der Konsolidierungs- und Migrationsprozesse die erwarteten Eigenschaften aufwiesen. Diese Tests waren besonders zweckmäßig zur Offenlegung von Benutzerfehlern, die während des Bereitstellungs-, Konsolidierungs- und Migrationsprozesses auftraten. ProzesstestsDiese Tests umfassten die Anwendung eines dokumentierten Prozesses genau nach der Beschreibung im Hinblick auf die Erkennung eventueller Dokumentationsfehler, technischer Fehler, Ungenauigkeiten bei Abfolgen und Zeiten sowie Problemen mit der Verwendbarkeit oder Übersichtlichkeit. Die Tests der Domänenkonsolidierung und -migration begannen erst, nachdem die Server für den Ausgangs- und Endstatus eingerichtet und die Beispieldaten auf den Servern für den Ausgangsstatus gespeichert waren. Am Ende des Prozesses waren die Dienste und Daten konsolidiert und auf die Server für den Endstatus migriert worden. Alle während des Prozesses auftretenden Probleme wurden als Programmfehler gegenüber der Prozessdokumentation gespeichert. Stabilitäts- und KoexistenztestsWährend eines Migrations- oder Konsolidierungsprozesses werden viele Änderungen an den Arbeitssystemen vorgenommen. Es ist wichtig, dass nicht nur die neuen Systeme einwandfrei funktionieren, sondern dass auch die vorhandenen Systeme weiterhin erwartungsgemäß funktionieren. Außer dass alte und neue Systeme unabhängig voneinander funktionieren, müssen sie in einem erwarteten Ausmaß als eine Einheit funktionieren. Zu diesem Zweck wurden die Systeme mithilfe von Überwachungen und Funktionstests auf Stabilität und Koexistenz getestet. VerfügbarkeitstestsDer Schwerpunkt dieser Tests ist bei einem Prozess anders als bei einer Architektur. Architekturtests konzentrieren sich in erster Linie auf Elemente, wie z. B. Einzelpunktversagen. Ein Prozesstest dagegen konzentriert sich darauf sicherzustellen, dass die Dienste verfügbar bleiben, obwohl während des Prozesses Änderungen an den Systemen vorgenommen wurden. Die Verfügbarkeit sollte während des gesamten Konsolidierungs- und Migrationsprozesses in mehreren Phasen gewährleistet werden. WiederherstellbarkeitstestsSogar bei einer optimal geplanten Konsolidierung und Migration können unerwartete Schwierigkeiten auftreten; deshalb ist es wichtig zu überprüfen, ob Phasen innerhalb einer Konsolidierung und Migration bei Bedarf rückgängig gemacht werden können. Das Hauptaugenmerk bei der Konsolidierung und Migration von Domänen lag darauf, keine doppelten Tests von bereits etablierten Sicherungs- und Wiederherstellungsprozessen durchzuführen. Gleichzeitig musste aber sichergestellt werden, dass der Prozess selbst genau angab, welche Vorsichtsmaßnahmen und Wiederherstellungsszenarien in jeder Schlüsselphase des Prozesses erforderlich waren. Darüber hinaus war es wichtig, alle Sicherungs- und Wiederherstellungselemente, die für den vorgeschriebenen Prozess eindeutig waren, vollständig zu testen. VerwaltbarkeitstestsWährend des Prozesses der Domänenkonsolidierung und -migration wurde diese Testform darauf begrenzt sicherzustellen, dass Verwaltungs- und Berichterstellungstools sowie Informationen vorhanden waren, damit ein Administrator den Erfolg oder Misserfolg von Schlüsselphasen des Prozesses überprüfen konnte. Diese Testform war als natürliches Nebenprodukt des Prozesses, mit dem der Konsolidierungs- und Migrationsprozess durchgeführt und getestet wurde, größtenteils indirekt. SicherheitstestsDiese Tests konzentrierten sich hauptsächlich darauf sicherzustellen, dass der Zugriff jedes Benutzers auf die Systeme für den Endstatus während des Migrationsprozesses und im Anschluss daran auf derselben Stufe wie vor dem Prozess möglich war. Die Zugriffsrechte sollten durch Konsolidierungs- und Migrationsprozesse nicht geändert werden, außer wenn dies explizit geschah. TestabfolgeDas Testteam durchlief zunächst eine inoffizielle Entwicklungstestphase, in der die Entwickler Ad-hoc-Tests der Einführungseinheit durchführten, um kleine Teile der zu entwickelnden größeren Prozesse zu untersuchen oder zu bestätigen. Die Tests der Einführungseinheit wurden von den Entwicklern sowohl mit als auch ohne Unterstützung des Testteams durchgeführt. Am Ende dieser Phase fand ein vollständiger schrittweiser Test der entwickelten Prozesse statt, um zu überprüfen, ob die Lösung für den Beginn der offiziellen Testphase bereit war. Sobald die offizielle Testphase begonnen hatte, führte das Testteam für Solution Accelerator mehrere Zyklen von Testläufen aus. Der erste Testlauf bestand aus einer Folge von sechs verschiedenen Testphasen: Einrichten der Server für Ausgangs- und Endstatus, Überwachung und Ablaufüberprüfungen, Auffüllen des Systems mit dem Beispieldataset, stufenweiser Konsolidierungs- und Migrationsprozess, stufenweise Überwachungen und Funktionstests sowie Funktions- und Belastungstests nach der Migration. Einrichten der Server für den Ausgangs- und Endstatus
Überwachung und Ablaufüberprüfungen
Auffüllen des Systems mit dem BeispieldatasetWährend des ersten offiziellen Testlaufs wurden die Domänenserver, Exchange-Server und Dateiserver unter Windows NT Server 4.0 für den Ausgangsstatus vorab mit Beispieldaten gefüllt, die zum Testen von Massenkonsolidierung und -migration sowie zum Überprüfen der wichtigsten technischen Punkte, wie z. B. Benutzer-, Gruppen-, Gruppenmitgliedschafts- und Berechtigungsübertragungen, verwendet wurden. Am Ende dieser Phase wurde erneut ein Image aller Systeme erstellt. Diese Images wurden als Erste verwendet, um alle Systeme vor jeder nachfolgenden Konsolidierungs- und Migrationstestphase zurückzusetzen. Stufenweiser Konsolidierungs- und MigrationsprozessMithilfe der in den Prozessen der Domänenkonsolidierung und -migration dieser Lösung beschriebenen genauen Schritte wurden Dienste auf den Servern für den Ausgangsstatus konsolidiert und auf die Server für den Endstatus migriert. Diese Testphase wurde zusammen mit der stufenweisen Überwachung und den stufenweisen Funktionstests durchgeführt. Alle im Hinblick auf Abfolgen, Übersichtlichkeit oder Genauigkeit der Anleitungen aufgetretenen Probleme wurden als Programmfehler dokumentiert. Stufenweise Überwachungen und FunktionstestsViele Überwachungen, Ablaufüberprüfungen und Funktionstests überschnitten sich mit dem Prozess der Domänenkonsolidierung und -migration, um den Prozess selbst sowie die Koexistenz der Dienste für den Ausgangs- und Endstatus zu überprüfen. Der Prozess wurde also getestet, um sicherzustellen, dass er nicht nur funktionierte, sondern auch während seiner Ausführung zu keiner Unterbrechung führte. Die Konsolidierungs- und Migrationsprozesse wurden in einzelne Schritte und Phasen aufgeteilt. Die Tests wurden dann während des gesamten Prozesses in identifizierten Punkten und Phasen durchgeführt. Funktions- und Belastungstests nach der MigrationNach der erfolgreichen Beendigung des Konsolidierungs- und Migrationsprozesses wurden verschiedene Last erzeugende Tools für den Endstatus ausgeführt, um die Systeme testen. Diese Belastungstests und verschiedene andere Funktionstests dienten dazu, die Funktionalität, Zuverlässigkeit und Stabilität der neuen Systeme weiter zu überprüfen. In nachfolgenden Testläufen wurden geänderte Versionen von zwei der ersten drei Phasen verwendet, an die sich Wiederholungen der vierten bis sechsten Phase anschlossen. Alle Server wurden unter Verwendung der in Phase 3 erfassten Images wiederhergestellt. Anschließend wurde eine verkleinerte Gruppe von Ablaufüberprüfungen aus Phase 2 erneut ausgeführt, um zu bestätigen, dass die Systeme ordnungsgemäß wiederhergestellt worden waren. Danach wurden die Schritte 4 bis 6 wiederholt. Zusätzliche Testläufe wurden durchgeführt, bis die Prozessdokumentation einen stabilen Zustand ohne die Entdeckung wesentlicher Programmfehler erreichte, wobei sämtliche Programmfehler vom Schweregrad 1 und 2 vollständig behoben waren. TestzyklusDas Testteam führte mehrere vollständige Testzyklusläufe durch, die sich an die im vorherigen Abschnitt beschriebenen Abfolgen anschlossen. Zu Beginn jedes Testlaufs waren die Computer für den Ausgangs- und Endstatus aus den Systemimages wiederhergestellt worden. Während es in allen Testläufen gemeinsame Testaktivitäten gab, konzentrierte sich jeder Testlauf auf einen bestimmten eindeutigen Punkt:
Vor Beendigung jedes Testlaufs wurden alle Änderungen, die als Ergebnis behobener Programmfehler vorgenommen worden waren, hinsichtlich der Wahrscheinlichkeit ausgewertet, dass sie zuvor getestete Systeme destabilisiert oder früher ausgeführte Testfälle ungültig gemacht hatten. Bei einer mittleren oder höheren Wahrscheinlichkeit derartiger Vorkommen wurden Regressionstests der früheren Fälle durchgeführt. Eingangskriterien für offizielle TestsDie folgenden Anforderungen dienten als Eingangskriterien für den Beginn der offiziellen Tests:
Freigabekriterien für die TestsDie primären Freigabekriterien zum Testen dieser Lösung waren mit dem Schweregrad der während der Testphase gefundenen Programmfehler eng verbunden. Solution Accelerator wurde erst freigegeben, nachdem die erfolgreiche Behebung aller wesentlichen Programmfehler sichergestellt worden war. Die Kriterien für die Freigabe umfassten folgende Punkte:
Erfolgs- und Misserfolgskriterien für TestfälleEin Testfall galt als erfolgreich abgeschlossen, wenn die tatsächlichen Ergebnisse mit den erwarteten Ergebnissen, die für den Fall dokumentiert waren, übereinstimmten; wenn diese Ergebnisse nicht übereinstimmten, wurde der Fall als "fehlgeschlagen" gekennzeichnet, und ein Programmfehler wurde dokumentiert. Ein fehlgeschlagener Fall bedeutete nicht unbedingt einen Mangel der Funktion, da z. B. eine falsche Auslegung der Projektdokumentation, eine unvollständige oder ungenaue Dokumentation ebenfalls Fehler verursachen können. Jeder Fehler wurde sorgfältig analysiert, um die Ursache herauszufinden. Ein erfolgreich abgeschlossener Testfall musste die folgenden Kriterien erfüllen:
Skala für den Schweregrad von ProgrammfehlernDer Schweregrad von Programmfehlern wurde auf einer Skala von 1 bis 4 gemessen; dabei stellte der Wert "1" den höchsten und der Wert "4" den niedrigsten Schweregrad dar. Die Richtlinien, anhand derer ein Schweregrad zugewiesen wurde, sind in Tabelle 1 aufgeführt.
Tabelle 1: Zuweisungsrichtlinien für den Schweregrad von Programmfehlern TestlaborumgebungIn diesem Abschnitt wird die physische und logische Auslegung der Umgebung beschrieben, in der die erste Implementierung der Lösung getestet wurde. Zunächst erhalten Sie einen Überblick über die Laborausstattung, die Mitarbeiter und die Prozesse, die mit den Tests verbunden waren. Anschließend wird die Konfiguration der Netzwerk-, Server- und Clientressourcen für das Testlabor beschrieben. Eine Laborumgebung kann keine hundertprozentig genaue Simulation eines echten Systems bereitstellen, kann aber bei richtiger Planung und mit den entsprechenden Ressourcen eine gute Annäherung bieten. AusstattungDie Tests der Domänenkonsolidierung und -migration wurden im CIS-Labor (Core Infrastructure Solutions) von Windows Engineering Services durchgeführt, das Platz und Dienste für zahlreiche CIS-Entwicklungs- und Testprojekte bietet. Das Labor wird durch eine Klimaanlage für Computerräume gekühlt, weist L6-30-Overheadleistung auf und stellt eine Netzwerkinfrastruktur bereit, die sowohl Isolation für unterschiedliche Projekte als auch (bei Bedarf) Unternehmenskonnektivität ermöglicht. Neben dem CIS-Labor lagen Arbeitsräume mit Arbeitsstationen, die über analoge Cat5 KVM-Schalter (Keyboard/Video/Mouse) mit den Laborservern verbunden waren. Darüber hinaus sorgten Terminal Server-Gateways für RAS-Konnektivität innerhalb des Firmennetzwerks. MitarbeiterDie folgenden Mitarbeiter waren am Projekt "Solution Accelerator für die Konsolidierung und Migration von Domänenservern von Windows NT Server 4.0 nach Windows Server 2003" beteiligt:
BereitstellungsprozesseDas Team für die Domänenkonsolidierung und -migration verwendete mehrere definierte Prozesse, um die Laborsysteme zuerst bereitzustellen und dann zu warten. Die folgenden Abschnitte bieten eine allgemeine Übersicht über diese Prozesse. Bereitstellung und Überprüfung der HardwareDer Prozess zum Erstellen des Testlabors begann mit einer Überprüfung der vom CIS-Laborteam aufgestellten Hardwareanforderungen durch das Entwicklungs- und Testteam für die Domänenkonsolidierung und -migration; diese Anforderungen wurden durch eine Gruppe physischer Diagramme sowie eine Konfigurationsmatrix angegeben, die Details der verschiedenen Systemeinstellungen und -konfigurationen enthielt. Unter Verwendung der vorhandenen Ressourcen sorgte das CIS-Laborteam dann für die Bereitstellung und Einrichtung eines Labors zur Domänenkonsolidierung und -migration. Nach erfolgreichem Abschluss einer sehr einfachen Ebene von Ablaufüberprüfungen durch das CIS-Laborteam begann das Entwicklungs- und Testteam, die Entwicklungseinführungseinheit mit der Laboraustattung zu testen. Am Ende dieser Phase übernahm das Testteam den Besitz des Labors. Zu diesem Zeitpunkt führte das Testteam eine Gruppe von strengeren Überwachungen, Ablaufüberprüfungen und Funktionstests der Umgebung durch, bevor es mit offiziellen Tests des eigentlichen Konsolidierungs- und Migrationsprozesses begann. Alle Hardwarewidersprüche wurden als Programmfehler gespeichert, die vom CIS-Laborteam behoben werden mussten. SoftwarebereitstellungDas CIS-Laborteam begann den Prozess der Softwarebereitstellung, indem es die folgenden Schritte ausführte:
Das Testteam führte eine umfassendere Reihe von Überwachungen, Ablaufüberprüfungen und Funktionstests durch, um sicherzustellen, dass die Systeme in betrieblicher Hinsicht fehlerfrei waren, bevor es mit offiziellen Tests der Konsolidierungs- und Migrationsprozesse begann. 1 Hinweis: Da SUS auf Computern unter dem Betriebssystem Windows NT 4.0 nicht funktioniert, mussten diese Computer nach der Installation von SP 6a mit Windows Update verbunden werden. Erstellen von SystemimagesDrei verschiedene Arten des Erstellens von Systemimages erleichterten die Labor- und Testprozesse:
ÄnderungskontrolleUm das Labor auf einem bekannten Status zu halten und die Anzahl der Systemwiederherstellungen zu reduzieren, wurde ein strikter Änderungskontrollprozess eingehalten. Alle an der Umgebung vorgenommenen Änderungen wurden mithilfe eines Systems zur Programmfehlerverfolgung aufgezeichnet. Die erste Systemeinrichtung, Anforderungen zur Erstellung von Images sowie eventuelle Programmfehler oder Änderungsbefehle im Hinblick auf die physischen Systeme wurden verfolgt und über eine Datenbank des CIS-Labors gesichtet. In einer separaten Datenbank, MSA SA, wurden Programmfehler, Testfälle und Testfallergebnisse, die mit der Lösung verbunden waren, verfolgt und verwaltet. Die Datenbank MSA SA wurde auch zum Verwalten von Testfällen und Ergebnissen verwendet. Bei allen vorgenommenen Änderungen wurde das System zur Verfolgung von Programmfehlern mit Informationen aktualisiert, die das geänderte Element und den Zeitpunkt der Änderung anzeigten. Das CIS-Laborteam sichtete neue und offene Einträge regelmäßig in der Datenbank des Labors, während die leitenden Test-, Entwicklungs- und Programmmanager des Projekts Programmfehler in der Datenbank MSA SA sichteten. Konfiguration des TestlaborsEin Windows NT Server 4.0-Domänenmodell wurde implementiert, um Solution Accelerator für die Konsolidierung und Migration von Domänenservern von Windows NT Server 4.0 in die Windows Server 2003-Umgebung zu testen. Dieses Modell verwendete ein geografisch angelegtes Multimaster-Domänenmodell mit zwei Master-Benutzerdomänen (Master User Domain – MUD): eine für Nordamerika (New York) und eine weitere für den Rest der Welt (London). Ressourcendomänen wurden eingerichtet, um Anwendungsressourcen wie Datei- und Druckdienste, Microsoft Exchange 5.5 sowie die Arbeitsstationskonten aufzunehmen. NetzwerkdiensteZur Unterstützung der Anforderungen des Domänenmodells wurden zusätzliche Netzwerkdienste wie DNS, DHCP und WINS implementiert. DNSDNS wurde implementiert, um interne und externe Namespaces bereitzustellen. Die DNS-Server befanden sich in New York, Sydney, Genf und Johannesburg. DHCPAm Standort New York wurde DHCP mit geteilten Bereichen implementiert, um größere Verfügbarkeit für die Adresszuweisungsdienste zu gewährleisten. Der Standort New York stellte DHCP für kleinere Niederlassungen wie Johannesburg bereit. Größere Niederlassungen wie Sydney verfügten über einen eigenen DHCP-Server für die Adresszuweisung zu den IP-Knoten in der Niederlassung. WINSWINS wurde eher dezentral eingesetzt; es gab zwei WINS-Server für die NetBIOS-Namensauflösung für New York und die anderen Niederlassungen in den USA sowie für die kleineren Zweigstellen wie Johannesburg und Genf. Die größeren Niederlassungen wie Sydney verfügten über einen einzigen WINS-Server für die NetBIOS-Namensauflösungsdienste. Die Replikationstopologie der WINS-Datenbanken wurde so konfiguriert, dass die NetBIOS-Auflösung für das gesamte Unternehmen sichergestellt war. ServerhardwareServer wurden im Testlabor bereitgestellt, um eine Infrastruktur für das Windows NT Server 4.0-Domänenmodell, die grundlegenden Netzwerkdienste sowie die Datei- und Druckdienste zur Verfügung zu stellen. In diesem Abschnitt werden die Server beschrieben, mittels derer die Infrastruktur für die Domänenkonsolidierung und -migration im Labor bereitgestellt wurde.  Abbildung 2: Infrastruktur der Windows NT Server 4.0-Domäne bei der Woodgrove Bank (Ausgangsstatus)  Abbildung 3: Infrastruktur der Windows Server 2003-Domäne bei der Woodgrove Bank (Endstatus) Infrastruktur der ComputerMithilfe einer Kombination aus Windows NT Server 4.0- und Windows Server 2003-Computern wurde die Domäneninfrastruktur für den Ausgangs- und Endstatus des Labors bereitgestellt. Tabelle 2 enthält eine Liste der einzelnen physischen Server.
* Nur Computer für den Endstatus Tabelle 2: Physische Server zur Bereitstellung der Domäneninfrastruktur Computer für UnterstützungsdiensteDie folgende Tabelle enthält eine Liste der physischen Server, die für die Bereitstellung von Unterstützungsdiensten, wie z. B. DNS, DHCP, WINS, Exchange sowie Datei- und Druckdiensten, im Labor eingesetzt wurden. Außerdem waren Server als zusätzliche Infrastrukturserver zur Unterstützung der Clientcomputer erforderlich.
* Nur Computer für den Endstatus Tabelle 3: Physische Server zur Bereitstellung von Unterstützungsdiensten Die Server NYC-WR-DHCP-01 und NYC-WR-DHCP-02 stellten die Basisnetzwerkdienste für alle Clients im Netzwerk für den Ausgangsstatus bereit. Im Rahmen des Migrations- und Konsolidierungsprozess wurden diese Server jedoch entfernt und ihre Dienste durch den DHCP- und WINS-Cluster (NYC-WA-MSP-01 und NYC-WA-MSP-02) ersetzt. NYC-WA-VS-01 und NYC-WA-VS-02 waren virtuelle Server zum Hosten virtueller Computer, die als Clients ausgeführt wurden. Die folgende Tabelle enthält eine Liste der virtuellen Computer, die für die Bereitstellung von Client- und Infrastrukturdiensten eingesetzt wurden.
Tabelle 4: Physische Server zur Bereitstellung der Domäneninfrastruktur Alle virtuellen Computer stellten Infrastrukturdienste bereit und fungierten als Testclients. Zusammenfassung des KapitelsDieses Handbuch enthielt eine Testplanübersicht für die empfohlene Implementierung von Solution Accelerator für die Konsolidierung und Migration von Domänenservern von Windows NT Server 4.0 nach Windows Server 2003, das in den Testlabors von Microsoft erstellt und getestet wurde. In diesem Dokument wurden Testziele, Umfang, Strategie und Methodik zusammen mit den Eingangs- und Freigabekriterien beschrieben, anhand derer die erfolgreiche Beendigung der Testphase ermittelt wurde. Außerdem wurde die Laborumgebung zum Testen der Lösung beschrieben.
|
In diesem Beitrag
|
