Parallelmigration von NT4 auf 2003 AD

[Christoph35 10]

Hi, Coyote,

 

bei Clustern in VMWare gibts n paar VMWare Specials die man beachten muß. Da kann Dir sicher auch Schröder zu Rate stehen. Ich will das auch noch mal austesten, habs schon mal begonnen, bin aber irgendwo gescheitert. Wenns dann soweit ist, reden wir drüber. Ich komme erstmal nicht dazu das nochmal zu probieren. Andere Dinge haben erst mal Priorität (VCP, MCSE+S).

 

Die Migration Exchange 5.5->2003 hab ich schon hinter mich gebracht, sowohl test als auch produktiv. Ich werde hier also immer mal wieder reinschauen und meine Kommentare abgeben ;).

 

Ach so: euch ist schon bekannt, das NT4 nicht mehr supportet wird, es keine Patches etc. mehr geben wird?

 

Christoph

[schroeder750 10]

@christoph:

 

Ich werde hier also immer mal wieder reinschauen und meine Kommentare abgeben .

... und das ist gut so ... :D Ich bitte darum !! ;)

 

 

@coyote:

Zum Clustern unter VMWare:

 

natürlich kann man unter VMWare einen Cluster abbilden, hierbei ist folgendes (grob beschrieben) zu beachten:

 

- Die (System-)Festplatten der virtuellen Maschinen müssen IDE-Platten sein, es muss angegeben werden: "Persistent: Changes are immediately and permanently written to disk"

 

- Die gemeinsam genutzten Platten (Quorum usw...) müssen SCSI-Platten sein, es muss angegeben werden "Allocate Disk Space now" und auch wieder "Persistent: Changes are immediately and permanently written to disk"

 

- Anschließend muss in der vmx-Datei der virtuellen Maschinen der Wert "dis.klocking=false" angegeben werden, damit beide Maschinen potentiell Zugriff auf die Platten haben können. Den Rest regeln dann später die Clusterdienste.

 

Das können wir gerne später vertiefen, die Frage ist aber, ob es in der virtuellen Umgebung wirklich ein geclusterter Exchange sein muss...

Das der Exchange 2003 sich prima clustern lässt, wissen wir, das brauchst Du nicht zu testen. Und bei der Migration auf einen Cluster gibt es eigentlich keinen Unterschied zur Migration auf einen Standalone-Exchange... Ist wirklich die Frage, ob Du Dir das in der Testumgebung geben willst.

Ausser natürlich, Du möchtest generell mal Erfahrung mit nem 2003er Exchange-Cluster sammeln. Das würde ich dann aber wieder in einer eigenen Testumgebung machen...

Wie dem auch sei, gib Bescheid, wenn Du genauere Infos brauchst... ;)

 

Zu den servergespeicherten Profilen hatte ich ja weiter oben schonmal was geschrieben. Ich denke, da gibt es soooo viele Stolperfallen nicht... die Clientversionen bleiben ja gleich, d.h. Du migrierst ja nicht von "\Winnt\Profiles" nach "Dokumente und Einstellungen\...", sprich von NT4 auf XP-Profile oder etwas in der Art.

Die grundsätzliche Struktur der Profile bleibt ja erhalten.

Da ist eigentlich nur darauf zu achten, daß die Clients, egal in welcher Domäne sie sich jetzt anmelden, an ihre Profile kommen und die Berechtigungen haben.

In diesem Kontext einfach darauf achten, daß die Einstellungen in den Benutzerkonten / Logonscripten passen...

 

Clientmigration haten wir ja auch schon angerissen (movedom / netdom / manuell), wenn da spezifische Fragen auftauchen, lass es uns wissen, dann können wir drüber diskutieren.

 

Zur Exchangemigration werde ich demnächst was schreiben, habe jetzt momentan nicht die Zeit, das schiebe ich asap nach, O.K ?

 

Was generelles:

Auch wenn die eigentliche Migration erst für später geplant ist, läuft das mit der Testumgebung denn jetzt relativ fix an ?

Wird für Dich nicht sehr einfach werden, wenn Du jetzt alle Infos theoretisch von uns bekommst und einfach nur so in Deine Planung einfügst, ich denke, das wäre besser, wenn Du das evtl. jetzt alles direkt mal live testen könntest... :D

Sonst sitzt Du irgendwann vor der Geschichte und merkst erst, was Du alles hättest fragen müssen ... :p

 

Bis später !!

 

Ciao

 

schroeder750

[Coyote 10]

Servus Schroeder

 

Zu den servergespeicherten Profilen hatte ich ja weiter oben schonmal was geschrieben. Ich denke, da gibt es soooo viele Stolperfallen nicht... die Clientversionen bleiben ja gleich, d.h. Du migrierst ja nicht von "\Winnt\Profiles" nach "Dokumente und Einstellungen\...", sprich von NT4 auf XP-Profile oder etwas in der Art.

Die grundsätzliche Struktur der Profile bleibt ja erhalten.

Da ist eigentlich nur darauf zu achten, daß die Clients, egal in welcher Domäne sie sich jetzt anmelden, an ihre Profile kommen und die Berechtigungen haben.

In diesem Kontext einfach darauf achten, daß die Einstellungen in den Benutzerkonten / Logonscripten passen...

 

Das hast das natürlich schon angesprochen, wollte nur wissen ob ich alle Benutzer einzeln anfassen muss um den neuen Pfad für Servergespeicherte Profile anzugeben oder ob es ein Scirpt für mich übernehmen könnte.

 

 

Clientmigration haten wir ja auch schon angerissen (movedom / netdom / manuell), wenn da spezifische Fragen auftauchen, lass es uns wissen, dann können wir drüber diskutieren.

 

OK, dann schaue ich mir movedom nochmals genauer an.

 

 

Dann bleibt nur noch die Exchangemigration, aber natürlich nur wenn du Zeit hast, eilt ja nicht.

Die virtuelle Umgebung werde ich wahrscheinlich erst in eins bis zwei Monaten anfangen, wenn jetzt vorhanden Projekte abgeschlossen sind.

 

Das Them Exchange-Cluster interessiert mich aber trotzdem, weil wir sicher einen zweiten DC aus Ausfahlgründen aufstellen würden und bevor dieser sich langweilt, sollte dieser doch gleich das ganze im Cluster hängen und den Exchange auch ausfallsicher machen, oder wie siehst du das? und in der VM werde ich sicher nach aus Erfahrungsgründen für Exchangecluster das auch ausprobieren wollen. Das einzige was gegen den Cluster spricht sind die Enterprise Lizenzkosten, sollte man evtl. doch nochmals abwägen, gibt es denn eine alternative für Exchange zum Cluster?

[hh2000 10]

xcopy /? ;)

 

 

oder vielleicht xcopy a:\ b:\ /h /e /i /c /o /y .....

[Coyote 10]

Hi hh2000,

 

ja ich weiß, leider habe ich bei den meisten Profilen als Domänadmin selber keine Rechte, sollte auch so bleiben, wie soll ich dann die Profile kopieren, gibt es ein Tool dafür?

[Coyote 10]

kann ich die Benutzer und Profile in die neuen Domäne in der Geschäftszeit (d.h. die User sind angemeldet) migrieren? Ich mein wenn der User angemeldet ist und ich diesen migriere, besteht der User noch in der alten Domäne und ich muss diesen nach der Migration aus der alten Domäne killen oder killt ADMT diesen aus der alten Domäne automatisch? Wenn dieser automatisch gekillt wird und der User angelmeldet ist was passiert dann beim User? Und das selbe gilt für die Profile, ich verschiebe diese auf den neuen Server passe den Pfad für den Servergeispeicherten Profil auf den neuen Server an, der User war in diesem Augenblick aber angemeldet. So jetzt meldet sich der User ab, was passiert, wo wird das Profil geschrieben (alter Server oder neuer Server)?

Oder soll ich die Migration der User und der Profile ausserhalb der Geschäftszeiten machen? d.h. am Wochenende arbeiten

[hh2000 10]

Hmmm,

 

Backup auf Band, Restore in neuen Ordner.

 

Früher gab es mal SCOPY für Windows NT (ich glaube aus einem Resource Kit, war original MS), das Tool hat alles kopiert, auch wenn keine Leserechte ( ) vorhanden waren.

 

Nachtrag:

SCOPY ist jetzt wohl in xcopy integriert siehe Schalter /o und /x

 

Gruß Kai

[Coyote 10]

hi hh2000

 

das mit xcopy und den Schaltern /X /O haut leider nicht hin -> Zugriff verweigert, da ich als Admin keine Rechte auf den Profilen habe.

 

Aber das mit der Bandsicherung ist eigentlich eine gute Idee, danke für den Tipp

[schroeder750 10]

Moin zusammen,

 

sorry, hab mich die letzten Tage etwas dünne gemacht, da is leider noch ein Job, in dem ich meine Brötchen verdienen muss :D

 

Habe ein paar Minuten zeit und dachte, ich mach mal ein bisschen weiter... :)

 

Habe mal durchgelesen, was in den letzten Tagen hier so passiert ist und kann hh2000 auf jeden Fall schon mal zustimmen. Die Möglichkeit mit dem Backup ist eine sehr gute Möglichkeit, die ich auch des Öfteren einsetze. Hier halt darauf achten, daß mitgenommen wird, was mitgenommen werden soll, also evtl. NTFS-Berechtigungen und Freigaben.

 

Das hast das natürlich schon angesprochen, wollte nur wissen ob ich alle Benutzer einzeln anfassen muss um den neuen Pfad für Servergespeicherte Profile anzugeben oder ob es ein Scirpt für mich übernehmen könnte.

 

Im NT4-Benutzermanager musst Du wohl jeden einzeln anfassen, in der W2K3 MMC jedoch kannst Du viele Benutzer auf einmal markieren und dann über die Rechte Maustaste und "Eigenschaften" solche Dinge bei vielen Objekten (Eigenschaften von mehrfachobjekten) gleichzeitig bearbeiten.

Solange sich die User also in der alten Domäne anmelden und auf den alten Fileserver zugreifen, keine Probleme. Wenn die User dann in die neue Domäne rüberkommen, werden ja die Einstellungen übernommen, d.h. auch die Infos zu den Profilpfaden. Da passt dann auch noch alles. Wenn nun der Server für die Profilpfade geändert wird, kann man das im AD ja bei allen Benutzern recht einfach ändern (siehe oben). Wenn also zuerst die Benutzer im AD sind und sich da auch anmelden und DANN erst der Profilserver und anschließend die Pfade geändert werden, geht das schlüssig auf.

Problematisch ist es nur, wenn dann immer noch User in der alten Domäne angemeldet werden. Da musst Du dann mühsam via Hand im NT4-Usermanager nachregeln. Lässt sich aber bei vernünftiger Planung umgehen.

 

ja ich weiß, leider habe ich bei den meisten Profilen als Domänadmin selber keine Rechte, sollte auch so bleiben, wie soll ich dann die Profile kopieren, gibt es ein Tool dafür?

 

... schlecht ... wie sollst Du als Admin administrieren, wenn Du keine Berechtigungen hast ? Wie wird denn hier ein Backup gezogen, wenn es keinen Account gibt, der die Berechtigungen hat ? :)

 

Ich würde mir die Berechtigungen verpassen, so viel Vertrauen in den Admin sollte sein...

 

Hierzu bedient man sich des Tools „subinacl“ aus dem Resource Kit:

 

“Subinacl /file \\NT4-Profilserver\share /grant=w2k3dom\administrator=f”

 

Dieser Befehl gibt dem Administrator der neuen Domäne (hier: w2k3dom) VOLLEN Zugriff (=f) auf die Daten.

 

Anschließend kann der xcopy-Befehl abgesetzt werden.

 

Achtung: mit subinacl werden dem Administrator der neuen Domäne Berechtigungen ZUSÄTZLICH zu den bereits bestehenden NTFS-Berechtigungen gewährt.

Wird versucht, über einen rechten Mausklick auf den jeweiligen Share die NTFS-Berechtigung für den Administrator zu vergeben, ist es schnell passiert, dass bestehende NTFS-Freigaben durch diese ERSETZT werden !!!!

Die vorherigen NTFS-Berechtigungen existieren dann nicht mehr !!!

Also mit Gefühl drangehen und vorher sauber testen... :D

 

... weiter im nächsten Thread...

[schroeder750 10]

Mal was generelles zu Profilen und Freigaben und Daten auf Fileservern usw...

 

Ich habe mir angewöhnt (auch wenn es anderslautende Meinungen gibt, was ja absolut legitim ist), sämtliche Berechtigungen auf NTFS-Ebene zu setzen und die Freigaben dann einfach nur zu geben, d.h. für alle Vollzugriff.

Von der Freigabe her kann dann jeder drauf zugreifen, wer dies aber nicht können soll, bekommt dann von den NTFS-Berechtigungen auf die Finger gehauen.

So kann man sich ein Script erstellen, mit dem ich relativ fix wieder die Freigaben setzen kann und alles mit xcopy

( xcopy \\nt4fileserver\share \\w2k3fileserver\share /E /C /H /O /Y )

incl. NTFS-Berechtigungen auf den neuen Server rüberkopieren. Anschließend das Script für die Freigaben wieder drüber und fertig.

 

Das Script für die Freigaben kann man sich relativ einfach zusammenbauen:

 

- Net share Befehl absetzen und in eine Textdatei schreiben lassen

 

- Textdatei bereinigen, so daß nur noch Namen der Verzeichnisse und Freigabenamen auftauchen

 

- Excel öffnen, die Spalten mit den Verzeichnissen und Freigabenamen aus der Textdatei einfügen

 

- Den Rest "drumherumbauen", also in der Form:

net share Freigabename=Laufwerk:Pfad

Hierzu an den richtigen Stellen Spalten einfügen und die Dinge wie "net share" einbauen.

 

- Anschließend den Inhalt der Excel-Tabelle in eine Textdatei exportieren und zum Schluss umbenennen in *.cmd. Fertig ist das Script.

Spiel damit mal rum und teste ein wenig in der VMWare-Umgebung...

 

 

Ach ja da war noch die Frage, ob Du die Profile migrieren kannst, wenn die User angemeldet sind... meiner Meinung nach solltest Du solche Aktionen am Wochenende oder abends machen... stress Dich nicht. Bei der Migration wirst Du eh einige Abende und Wochenenden in der Firma verbringen...

 

So, das wars erstmal dazu, als nächstes wäre dann der Exchange dran.

Das schaffe ich aber heute wahrscheinlich nicht mehr.

 

Später mehr dazu, O.K ?

 

Grüsse

 

schroeder750

[schroeder750 10]

Hy coyote,

 

habe gerade ein paar Minuten und fange jetzt mal einfach mit der Exchange-Migration an, O.K.?

 

Schaun mer mal:

 

Der Exchange 5.5 hat, wie schon erwähnt, drei Datenbanken:

 

A] Priv.edb (Privater Informationsspeicher) ==> Inhalte werden später als Postfächer auf den 2003er verschoben

 

B] Pub.edb (Öffentliche Ordner) ==> Werden später auf beide Exchange repliziert, die Replikate dann vom 5.5er entfernt.

 

C] Dir.edb (Verzeichnis) ==> Gibt es beim 2003er nicht mehr, ist dann das Active Directory.

 

Um die Dinge sauber rüberschieben / rüberreplizieren zu können, sollten wir beide Exchangeserver in die gleiche Exchange-Organisation bringen, auch wenn bei einer Parallelmigration zwei unabhängige, vertrustete Domänen zu Grunde liegen.

 

Um das zu schaffen, wird der Active Directory Connector (ADC) benötigt.

Wenn der einmal steht und die entsprechenden Verbindungsvereinbarungen erstellt wurden können folgende Ressourcen rübergeschoben werden:

 

Exchange 5.5: Postfächer mit verbundenen NT4-Benutzerkonten =wird zu=> Exchange 2003: EMail-aktivierte Benutzerkonten im AD mit verbundenen Postfächern

 

Exchange 5.5: Verteilerlisten =wird zu=> Exchange 2003: Universale Verteilergruppen im AD

 

Exchange 5.5: Benutzerdefinierte Empfänger =wird zu=> Exchange 2003: Kontakte im AD

 

Ein paar Vorarbeiten sind da aber noch zu machen:

=================================

 

Postfächer:

Im Exchange 5.5 ist es möglich, mehrere Postfächer einem NT-Benutzeraccount zuzuordnen.

Unter Windows 2003 AD / Exchange 2003 existiert ein Benutzer im Active Directory, der, sobald er mailaktiv geschaltet wird, eine Email-Adresse und ein Postfach auf dem Exchange 2003-Server hat.

Es ist nun möglich, diesem Benutzer weitere Email-Adressen zuzuweisen, es ist jedoch NICHT möglich, ein zweites Exchange-Postfach mit diesem Benutzer zu verknüpfen.

In letzter Konsequenz heißt dies, dass es Probleme bei der Migration der Exchange-Daten geben wird, wenn im Exchange 5.5-Server mehrere Postfächer mit einem NT-Account verknüpft sind.

Hierzu sollte VOR der Migration der Exchangedaten auf den neuen Exchange 2003-Server eine Überprüfung des Exchange 5.5-Servers mittels NTDSNoMatch-Utility stattfinden.

Dieses Tool findet NT-Accounts, auf die mehrere Postfächer verknüpft wurden und stellt diese in einer *.csv-Datei dar.

 

Das Tool NTDSNoMatch Utility befindet sich im Service Pack für den Exchange Server 2000 im Unterverzeichnis \temp\server\support\utils\i386\ntdsatrb.

Einfach auf einem W2K3-Server installieren, gegen den Exchange 5.5 laufen lassen ("ntdsatrb Name des Ex5.5"), damit doppelte Postfächer pro Benutzer in der NT4-Umgebung erkennen und entsprechend gegenarbeiten. Meiner Meinung nach am Besten manuell, das Tool selber bietet keine große Hilfe bei der Fehlerbeseitigung...

 

Genauere Erläuterungen hier: http://support.microsoft.com/default.aspx?scid=kb;DE;274173#appliesto#appliesto

 

Ach ja: Bei der Installation vom NTDSNoMatchUtility erscheint evtl. eine Fehlermeldung, die besagt, das die Datei "msvbvm50.dll" nicht gefunden wurde.

Diese Datei kann von einer Windows XP-Workstation ins Verzeichnis \windows\system32 des Servers kopiert werden.

Des Weiteren ist es auch möglich, die Datei „msvbvm60.dll“, die sich im Unterverzeichnis \System32 befindet, zu kopieren und umzubenennen zu „msvbvm50.dll“ …

 

 

Weiter im nächsten Thread...

[schroeder750 10]

Aufbau des Active Directory Connectors

 

DC der W2K3-Domäne, ADC installieren:

(Exchange2003-CD bzw. Exchange Service Pack CD)

Setup.exe starten aus dem Unterverzeichnis ADC und standardmäßig durchinstallieren...

 

ADC starten.

 

Empfängerverbindungsvereinbarung:

 

Rechte Maustaste auf den Active directory connector, "Neue Empfängerverbindungsvereinbarung" auswählen.

 

Tab "Allgemein":

Name der Vereinbarung eingeben, "In beide Richtungen" auswählen, Meldung bestätigen.

 

ACHTUNG !!!!!

 

„In beide Richtungen“ bedeutet, dass Objekte, die in der W2K3-Umgebung gelöscht werden auch in der NT4-Domäne gelöscht werden !!!

 

Sollte also beim ersten Test der Migration etwas schief gehen, ist man versucht, die OU, in die man importiert hat, einfach zu löschen und neu anzulegen.

Steht die Verbindungsvereinbarung zu diesem Zeitpunkt auf „beide Richtungen“, hat man für weitere Importe keine Ressourcen mehr in der NT4-Umgebung, da alle Benutzer, Postfächer, Verteilerlisten u.ä nach einer kurzen Replikationszeitspanne gelöscht wurden !!!!!

In der produktiven NT4-Umgebung ist dies natürlich der „worst case“ !!!!!

 

Es empfiehlt sich daher, die Verbindungsvereinbarung vorerst nur von Exchange (5.5) zu Windows (2003) zu konfigurieren.

 

Sind alle Ressourcen erfolgreich aus der NT4-Domäne in die W2K3-Domäne migriert worden und es ist davon auszugehen, dass beide Domänen noch eine Zeit lang nebeneinander existieren, so kann später eine zusätzliche Vereinbarung in die Gegenrichtung erstellt werden, um den Abgleich der beiden Domänen für den Zeitraum der Koexistenz zu sichern…

 

Im unteren Feld den Server (DC) auswählen, der die Vereinbarung ausführen soll.

 

Tab "Verbindungen":

Server eingeben, administrative accounts angeben, LDAP-Port konfigurieren ( Im Zweifelsfall im Exchange 5.5 Administrator bei den Protkollen ==> LDAP nachsehen, welcher Port eingetragen ist)

 

Der Exchange 5.5 Server sollte übrigens über Service Pack 3 oder höher verfügen …

 

Tab "Zeitplan":

Im Zeitplan "Immer" angeben, den unteren Haken setzen. Dies gilt für den gesamten Zeitraum der Koexistenz der beiden Domänen.

 

Tab "Von Exchange":

Auf "Hinzufügen" klicken, die Container angeben, aus denen die Benutzer / Verteiler / Benutzerdefinierten Empfänger importiert werden sollen.

ACHTUNG !!! Hier NUR lokale Container angeben.

Sollten weitere Standorte in der Exchange-Organisation existieren, so sollte für jeden Standort (Site) eine neue Verbindungsvereinbarung definiert werden.

Unter "Standardziel" mittels des Buttons "Ändern" die OU aus dem AD auswählen, in die die Benutzer mit dem ADMT migriert wurden.

 

 

Tab "Von Windows":

Hier evtl. die OU im AD angeben, von der aus zurückrepliziert werden soll, wenn beide Domänen länger zusammen existieren (siehe oben)

Unter "Standardziel" wieder den Benutzercontainer des Exchange 5.5 auswählen.

Auch hier wieder NUR lokale Container angeben.

Sollten weitere Standorte in der Exchange-Organisation existieren, so sollte für jeden Standort (Site) eine neue Verbindungsvereinbarung definiert werden

 

Wenn der ADC mit dieser Verbindungsvereinbarung eine Zeit gelaufen ist, die Ergebnisse im AD überprüfen...

 

Als nächstes kommt die Verbindungsvereinbarung für öffentliche Ordner.

[schroeder750 10]

Verbindungsvereinbarung für öffentliche Ordner

 

Bevor die Verbindungsvereinbarung für öffentliche Ordner erstellt wird, muß in der

Windows 2003-Domäne das Schema erweitert sein.

Hierzu muss von der Exchange 2003-Server CD setup mit dem Paramater „/forestprep“ und anschliessend mit dem Parameter „/domainprep“ gestartet werden.

 

Starten des Active Directory Connectors

 

Neu => Öffentliche Ordner-Verbindungsvereinbarung

 

Name für Vereinbarung vergeben, "In beide Richtungen" auswählen, entsprechenden W2K3 DC angeben.

 

Im Tab "Verbindungen" wieder die Infos wie oben eingeben.

 

Zeitplan wieder auf "Immer"

 

Der Rest erklärt sich eigentlich von selber, bei Problemen einfach hier nachfragen...

 

==== Kurze Zusammenfassung ===========

 

Was haben wir bisher ?

 

Verbindungsvereinbarung für Empfänger:

=> Sorgt später dafür, daß wir die Postfächer über die Managementkonsole vom AD vom 5.5er auf den 2003er Exchange verschieben können.

Repliziert auch die benutzerdefinierten Empfänger usw...

 

Verbindungsvereinbarung für öffentliche Ordner:

=> Ist die "Autobahn" für die Replikation der öffentlichen Ordner zwischen den Exchangeservern.

 

Beide Vereinbarungen sollten eigentlich ununterbrochen laufen, gibt dann die wenigsten Probleme.

 

===========================

 

Konfiguration der ADC-Tools:

 

Im ADC müssen noch die ADC-Tools laufen gelassen werden, sonst gibt es nachher Meckermeldungen. Natürlich kann man alle oben beschriebenen Vorgänge über die ADC-Tools abfackeln, ich mache sowas jedoch lieber manuell. Jeder, wie er es braucht ... :D

 

Wenn die Verbindungsvereinbarungen manuell erstellt wurden, reicht es, bei den ADC-Tools die ersten beiden Schritte auszuführen und dann abzubrechen, dann gibt es später keine Meldung, daß die ADC-Tools nicht ausgeführt wurden...

Schadet aber nicht, die ADC-Tools nochmal komplett durchlaufen zu lassen ... ;)

 

Die Grundlagen sind jetzt geschaffen, später kann dann der Exchange 2003 in die gleiche Organisation installiert werden, wie der Exchange 5.5.

 

Hierzu später mehr... :p

 

Grüsse

 

schroeder750

[Coyote 10]

Hi Schroeder,

 

das nenne ich ausführlich, vielen Danke für deine ausführliche Unterstützung.

Werde mein Projektplan jetzt erweitern, hat jetzt schon neuen Seiten, wo gehts dahin, ich glaub ich brauch einen Inhalsverzeichnis :D , und werde mich bei Fragen hier in dem Thread melden. Obwohl ich sagen muss, das die Fragen speziel bei Exchange erst bei der Virtuallen Migration auftretten werden.

Ich glaube, das jetzt das schon alles war, oder gibt es noch weitere Punkte?

[schroeder750 10]

das nenne ich ausführlich, vielen Danke für deine ausführliche Unterstützung.

gerne ... :)

 

...hat jetzt schon neuen Seiten, wo gehts dahin, ich glaub ich brauch einen Inhalsverzeichnis

... schon neun Seiten is gut ... :D Wenn ich für einen mittelgroßen Kunden ein Projektdesign schreibe, hat so ein Ding zwischen 50 und 150 Seiten...

Es gibt Punkte, die müssen einfach rein. Ich denke, das was Du bisher hast, ist das, was bei mir als eigentlicher "Aktivitätenplan" im Projektdesign auftaucht.

Du solltest für eine nicht ganz triviale Geschichte (und das ist eine Migration ja nun mal leider) ein umfassendes Papier erstellen...

Denk mal einfach über ein paar Begriffe nach, die ich jetzt hier in den Raum werfe:

 

- Anforderungen / Projektziele

- Projektteam

- Terminrahmenplanung

- Änderungsindex

- Ist-Zustand (Hardware/Software/Struktur)

- Soll-Zustand (Hardware/Software/Struktur)

- Administrationsstruktur

- Testumgebung

- Aktivitätenplan

- Zeitliche Abhängigkeiten

- Rückwege bei Fehlern

- Lizenzen

- Vorteile durch Migration

- Backup vor/während/nach der Migration

- Checklisten

 

Klar, man KANN alles künstlich aufblähen, es sollte aber knackig und treffend alles erwähnt werden.

Lieber vorher etwas länger planen und schreiben, aber dann Samstags abends, wenn man langsam müde wird, einen klaren Plan haben, den man Stück für Stück abhakt und so die möglichen Fehler minimiert.

Wenn Du vorher in der Testumgebung alles sauber zum Laufen bekommen hast und dafür ewig rumgemacht hast, ist nichts ärgerlicher, als dann an der produktiven Umgebung zu sitzen und sich die Frage zu stellen "wie war das jetzt nochmal ?" ... :mad:

 

Wenn Du bisher keine projektleitenden Tätigkeiten gemacht hast, wirst Du spätestens nach der Migration wissen, worum es geht...

 

Ich glaube, das jetzt das schon alles war, oder gibt es noch weitere Punkte?

 

Wenn ich die Tage wieder Zeit habe, kommt noch die eigentliche Exchangegeschichte.

Installation Exchange 2003 -> Datenübernahme -> Bisschen was zur Administration -> Entfernen des alten Exchange und irgendwann auch der alten Domäne ...

 

Wie gesagt, wenn ich die Zeit habe...

 

Kümmer Du Dich inzwischen mal in Ruhe um ein Projektdesign und die Testumgebung.

 

Dann fährst Du in der Testumgebung die hier genannten Punkte ab, stellst wieder Fragen und dieser Thread wird nochmal so lang ... ;)

 

Bis später !!!

 

Grüsse

 

schroeder750