Jump to content

Parallelmigration von NT4 auf 2003 AD


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Ahoi,

 

So wie du siehst versuche ich mich nur bestens auf das Projekt vorzubereiten,

 

Sehr ordentlich :D :D So sollte jeder denken :D

 

alle NT4-Server auf W2k3 oder W2k updaten

 

... solltest Du nochmal drüber schlafen ... bin ich wirklich kein Fan davon ... :suspect:

 

 

Gut, dann lass uns beim Passwort Export Server weitermachen...

 

Ich gehe mal davon aus, daß folgende Vorarbeiten schon erledigt sind:

 

- Aufbau Trust / Deaktivieren des SID-Filters

- Verschachtelunng der Gruppen / Vergabe der Berechtigungen

- Installation und Konfiguration ADMT

- Erstellen einer lokalen Gruppe in der NT4-Umgebung mit dem Domänennamen und drei $ hintendran

- Einschalten des Auditing (Überwachung)

 

Wenn dazu noch Fragen auftauchen, einfach Meldung machen, O.K ?

 

Gut, dann Passwort Export Server:

 

- NT4 PDC:

Unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA den Wert "TcpipClientSupport" als "REG_DWORD:0x1" hinzufügen, Neustart des Servers

 

- Auf dem NT4 PDC und dem BDC, auf dem der Passwort-Export Server landen soll, müssen die administrativen Freigaben (C$ usw.) bestehen...

 

- 128 Bit Verschlüsselung muss aktiv sein (notfalls den IE 601 SP1 auf PDC und BDC installieren)

 

- Encryption key:

Eine leere Diskette ins Laufwerk des W2K3 DCs einlegen, auf dem ADMT installiert wurde.

Folgenden Befehl in einer DOS-Eingabeaufforderung absetzen:

"admt.exe key %SourceDomainNetBIOSName% Zielpfad\Zieldatei

Beispiel: admt.exe key nt4dom a:\key\

Dieser Befehl speichert den Key für die Domäne „NT4DOM“ auf dem Laufwerk a:\key\*.pes des W2K3-DCs

 

- Installation PWMig-Server auf einem BDC in der NT4-Domäne (bestenfalls extra dafür einen neuen BDC installieren, wenn es Probleme gibt)

- Ausführen der Datei Pwdmig.exe aus dem Unterverzeichnis "PWDMIG" des ADMT 2.0-Installationsverzeichnisses

- Diskette einlegen, Name der Encryption Key-Datei von oben angeben.

- BDC neu starten

- Danach Kontrolle: Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

muss unter dem Eintrag "AllowPasswordExport" der Wert "1" gesetzt sein. Witzigerweise steht der meistens auf "0" ... no comment...

 

- W2K3 DC:

Benutzer "Jeder" und "Anonymous" zur Gruppe Prä-Windows 2003 kompatibler Zugriff" hinzufügen.

 

- Default Domain Policy öffnen:

Unter „Computerkonfiguration“ => „Windows-Einstellungen“ => „Sicherheitseinstellungen“ => „Kontorichtlinien“ => „Kennwortrichtlinien“ im rechten Feld die Richtlinie „Kennwort muss Komplexitätsvoraussetzungen entsprechen“ deaktivieren.

 

- Ist übrigens ein guter Zeitpunkt, die neue Domäne jetzt in den native mode zu schalten, falls noch nicht passiert ...

 

Danach dann Benutzermigration mit dem ADMT, natürlich incl. SID-History und Kennwörtern.

 

Sooo, geh das erstmal durch und meld Dich wieder, O.K ?

Dann machen wir an unserer Monsterdoku weiter ... :D

 

Grüsse

 

schroeder750

Link zu diesem Kommentar

Sooo, Du hattest jetzt über 20 Minuten Zeit. Wird Zeit weiterzumachen :D :D :D Harrr ...

 

- Mit dem ADMT zuerst die Gruppen rüberholen, dann die Benutzer:

 

Hier als Beispiel mal die Benutzermigration:

 

- Ich erstelle mir ganz gerne in der AD-Struktur eine neue OU, z.B. "NT4-Importe", in die ich erst einmal die Benutzer reinmigriere. Verschieben kann man immer noch...

Wenn was nicht ganz sauber laufen sollte, kann ich die ganze OU killen und wieder neu erstellen. Dann habe ich nichts mit den im AD schon standardmäßig vorhandenen Usern am Hut und muss nicht groß raussuchen, was ich gerade evtl. falsch rübergeholt habe...

 

- Rechte Maustaste auf "Active Directory Migrationsprogramm"

 

- Auswahl "Assistent zum Migrieren von Benutzerkonten"

 

- "jetzt migrieren" auswählen (testen kann jeder, nix für Wikinger...)

Quelldomäne = NT4-Domäne / Zieldomäne = W2K3-Domäne …

 

- Mit "Hinzufügen" die zu migrierenden Benutzer auswählen

 

- Als Ziel die neue OU angeben, die oben erstellt wurde.

 

- "Kennwörter migrieren" angeben und auf den BDC verweisen, der den PWDMig-Server hat...

 

- Ziel- wie Quellkonten behandeln und Haken setzen bei "Benutzer SIDs migrieren"...

 

- Hier dürfte eine Meldung kommen, daß das Auditing nicht eingeschaltet ist (auch wenn man es vorher eingeschaltet hat), hier mit "Ja" bestätigen, daß es eingeschaltet werden soll.

 

- Die weiteren Fragen nach Geschmack beantworten und die Migration anstoßen...

 

- Ergebnisse im AD prüfen. (Wurden alle Einstellungen und Gruppenzugehörigkeiten übernommen ?)

 

Noch ne Anmerkung:

 

Einige vordefinierte Benutzer / Gruppen existieren bereits in der neuen AD-Struktur.

Diese Accounts führen bei der Ausführung des ADMT zu Fehlermeldungen.

Hier sei beispielhaft der Account des Administrators angeführt.

 

Auf Grund der Existenz dieses Benutzers in der neuen AD-Struktur wird hier nicht mit SID-History migriert.

 

Es sollten also nach der Migration mittels ADMT die Gruppen überprüft und entsprechend aktualisiert werden, speziell die Gruppen, in denen der Administrator Mitglied ist.

Gleiches gilt im späteren Verlauf für Postfächer von vordefinierten Konten. Hier muss manuell zusammengeführt werden.

 

... damit hast Du schonmal einen Stand, der sich sehen lassen kann. Die Benutzer können sich jetzt in beiden Domänen anmelden und arbeiten.

 

Der Migration der weiteren Ressourcen steht nun nicht mehr viel im Weg...

 

Weiter demnächst in diesem Kino, O.K ? :D

Mach einfach meldung, wenn es weitergehen soll.

 

Grüsse

 

schroeder750

Link zu diesem Kommentar

Wow, ich kann nicht mal so schnell lesen wie du schreibs :D

 

so habe meine Doku mit deinen Hinweisen erweitert, habe aber ein paar Fragen dazu.

 

1. Die Server werde ich nich mit dem Update-Assistenten updaten, sondern natürlich neu aufsetzen und parallel migrieren.

 

2. eins verstehe ich aber nicht, wenn ich die Domäne jetzt in den "native Modus" umstelle, kann ich noch Exchange migrieren, ich mein die NT4-Server haben doch keine Möglichkeit mehr mit der "native Domäne vom W2k3" zu kommunizieren, oder habe ich da einen Denkfehler.

 

3. Wenn sich die Benutzer jetzt in zwei Domänen anmelden können, ergibt es nicht einen Profilesalat (ich mein die Servergespeicherten Profile liegen doch noch auf dem alten Server) und wie ist die Domänenauswahl bei den Benutzern? Was ist default alt oder neu?

 

4. Was meinst du mit den Benutzer und Gruppen wo z.B. der Administrator drinen ist mit aktualisieren, geht das nicht automatsich? wie soll ich das anstellen?

 

Du siehst Fragen über Fragen aber ich darf mir genau bei diesen Punkten keinen Denkfehler erlauben.

 

 

EDIT:

zu Punkt 3: habe selber jetzt falsch überlegt, die PC´s sind noch gar nicht migriert, d.h. nur die PC´s, die in der neuen Domäne hängen würden die Auswahl für beide Domänen kriegen, dass wird aber zu diesem Zeitpunkt nicht passieren. Und nach der Clientmigration (habe was vom movedom gehört) gebe es eh nur die neue Domäne für die Clients, dieses wirst du mir hoffenlich auch erklären. Somit ist auch nicht mit Profilsalat zu rechnen, da die Profile auch migriert werden sollen, was du aber bitte auch erklären könntest.

 

DANKE für so eine einmalige Unterstützung, habe bis jetzt noch nie so einen Kompetenten USER wie dich erlebt, der sich auch für die anderen Zeit nimmt und alles ausführlich (deppensicher, was supper ist) erklärt.

Link zu diesem Kommentar
Wow, ich kann nicht mal so schnell lesen wie du schreibs

 

Kein Problem, schreibe ich eben langsamer... :D

 

Die Server werde ich nich mit dem Update-Assistenten updaten, sondern natürlich neu aufsetzen und parallel migrieren

Hört sich schon wesentlich symphatischer an. :D Wie Du genau einzelne Ressourcen evtl. zwischenparkst, wenn Du die Server neu aufsetzt, gehen wir dann an, wenn es soweit ist.

 

eins verstehe ich aber nicht, wenn ich die Domäne jetzt in den "native Modus" umstelle, kann ich noch Exchange migrieren, ich mein die NT4-Server haben doch keine Möglichkeit mehr mit der "native Domäne vom W2k3" zu kommunizieren, oder habe ich da einen Denkfehler.

 

"Native mode" heißt schlicht und ergreifend nur, daß keine DOMÄNENCONTROLLER kleiner W2K oder W2K3 (je nach native mode) mehr in der neuen Domäne erlaubt sind. Und wir haben ja nicht vor, in die neue Struktur noch NT4 BDCs zu bringen, oder ? Genau deswegen machen wir ja ne Parallelmigration ;)

Man könnte sogar noch NT4 Memberserver in diese AD-Struktur bringen, wenn man denn wollte. Hat aber überhaupt gar nichts mit dem Zugriff aus einer getrusteten NT4-Domäne zu tun...

Den Exchange bringen wir später als Exchange 2003 auf einem Win2003 Server in die neue Domäne, achten aber darauf, daß er über den Trust hinweg mittels ADC usw. in die gleiche Organisation kommt, wie der jetzige Exchange 5.5 in der NT4-Domäne. Dann kann man prima öffentliche Ordner replizieren und Postfächer schubsen ...

 

3. Wenn sich die Benutzer jetzt in zwei Domänen anmelden können, ergibt es nicht einen Profilesalat (ich mein die Servergespeicherten Profile liegen doch noch auf dem alten Server) und wie ist die Domänenauswahl bei den Benutzern? Was ist default alt oder neu?

Per default melden sich die Rechner noch in der alten Domäne an. Wenn man in die neue will, muss man das explizit auswählen bei der Anmeldung. Man kann ja die Anmeldung in der neuen Domäne auch so lange verhindern, bis man die Profile sauber rübergeholt hat. Und erst dann werden auch die Clients in die neue Domäne gebracht. Erfahrungsgemäß ist es vorteilhaft, die Clients zu einem recht frühen Zeitpunkt in die neue Domäne zu bringen und die Server / sonstige Ressourcen dann in Ruhe nachzuziehen.

 

4. Was meinst du mit den Benutzer und Gruppen wo z.B. der Administrator drinen ist mit aktualisieren, geht das nicht automatsich? wie soll ich das anstellen?

Du migrierst zuerst die Gruppen, dann die Benutzer. Danach wirst Du feststellen, daß alles sauber rübergenommen wurde, nur eben der Administrator der alten Domäne nicht. Die Gruppen, in denen der Administrator der alten Domäne vorher Mitglied war, werden überprüft und der Administrator der neuen Domäne dort wieder hinzugefügt. Am einfachsten ist es, sich den Administrator der alten Domäne anzusehen und nachzuschauen, wo der überall Mitglied ist. Dann rüber in die AD Struktur und dort den neuen Administrator eben wieder genau bei diesen Gruppen eintragen. Sache von wenigen Minuten, muss nur beachtet werden...

 

Grüsse

 

schroeder750

Link zu diesem Kommentar
zu Punkt 3: habe selber jetzt falsch überlegt, die PC´s sind noch gar nicht migriert, d.h. nur die PC´s, die in der neuen Domäne hängen würden die Auswahl für beide Domänen kriegen, dass wird aber zu diesem Zeitpunkt nicht passieren. Und nach der Clientmigration (habe was vom movedom gehört) gebe es eh nur die neue Domäne für die Clients, dieses wirst du mir hoffenlich auch erklären. Somit ist auch nicht mit Profilsalat zu rechnen, da die Profile auch migriert werden sollen, was du aber bitte auch erklären könntest.

 

Siehe oben... sobald ein Trust steht, können sich die Clients potentiell in beiden Domänen anmelden. Man kann es aber in der neuen Domäne verhindern, wenn man es nicht will.

 

Zum migrieren der Clients gibt es hier im Board einen Thread über das Tool "netdom", mit dem es gut zu gehen scheint. Den Computermigrationsassistenten des ADMT kann ich NICHT empfehlen. Ich habe die Dinger bisher immer manuell in die neue Domäne integriert. Kommt auf die Anzahl an. Ich traue generell erstmal nur meinen eigenen Pfoten ... wenn das nicht zu viele sind, dann lieber manuell. Ansonsten solltest Du den Thread über das moven mit netdom inhalieren ... :D

 

EDIT: Hier isser: http://www.mcseboard.de/showthread.php?t=75857

 

Zu den Profilen kommen wir später noch, O.K ?

 

Grüsse

 

schroeder750

Link zu diesem Kommentar

Moin Coyote,

 

einen habbich übrigens noch so nebenbei, ein Tip, den ich in solchen Fällen öfter gebe:

 

Da Du das alles sauber planst, solltest Du Dir evtl mal die Zeit nehmen, alles in einer Testumgebung durchzuspielen, dann ist das nachher ein "Heimspiel", wenn Du es in der produktiven Umgebung machst.

 

Besorg Dir einfach VMWare Workstation oder Virtual PC (von beiden gibt es Testversionen zum Runterladen, in beide hat man sich relativ fix eingearbeitet).

 

Ich habe den Aufbau so einer Testumgebung, abgesaugt aus der produktiven Umgebung in diesem Thread:

 

http://www.mcseboard.de/showthread.php?t=80790

 

mal beschrieben.

 

Kann auf keinen Fall schaden, an der "fast produktiven" Umgebung in Ruhe testen zu können... :D

 

Grüsse

 

schroeder750

Link zu diesem Kommentar

"Native mode" heißt schlicht und ergreifend nur, daß keine DOMÄNENCONTROLLER kleiner W2K oder W2K3 (je nach native mode) mehr in der neuen Domäne erlaubt sind. Und wir haben ja nicht vor, in die neue Struktur noch NT4 BDCs zu bringen, oder ? Genau deswegen machen wir ja ne Parallelmigration ;)

 

D.h. für mich dass über den Trust hinweg ich immer zwischen NT4-Domäne und einer reinen (native Mode W2k3) Domäne kommunizieren kann, ich mein mit dem Exchange?

Anders hätte ich doch gar keine Möglichkeit später wenn die neue Domäne im "native Mode" ist auf die Postfächer von Exch5.5 aus der NT4Domäne zuzugreifen, oder?

 

Man könnte sogar noch NT4 Memberserver in diese AD-Struktur bringen, wenn man denn wollte.

 

Das klingt aber interessant! Wenn das echt der Fall ist, dann würde ich mir mind. ein Update auf W2k3-Memberserver auf einem jetzigen NT4-Server sprarren (auch externe Dienstleistung, für diese spezielle Migration der Anwendung (FiBu, KoRe und Pers) würde somit auch wegfallen -> Kosten sparren, da wird sich der Chef freuen :D .

Kannst du das mir evtl. etwas näher erläutern?

 

Den Exchange bringen wir später als Exchange 2003 auf einem Win2003 Server in die neue Domäne, achten aber darauf, daß er über den Trust hinweg mittels ADC usw. in die gleiche Organisation kommt, wie der jetzige Exchange 5.5 in der NT4-Domäne. Dann kann man prima öffentliche Ordner replizieren und Postfächer schubsen ...

 

Was kann ich da falsch machen, ich mein den Trust haben wir doch (früher in diesem Thread) aufgebaut und nicht aufgelöst. Oder soll ich noch was anderes Beachten? Der neue Exchange hat ja auch einen anderen/neuen Domännamen als der alte.

 

Per default melden sich die Rechner noch in der alten Domäne an. Wenn man in die neue will, muss man das explizit auswählen bei der Anmeldung. Man kann ja die Anmeldung in der neuen Domäne auch so lange verhindern, bis man die Profile sauber rübergeholt hat. Und erst dann werden auch die Clients in die neue Domäne gebracht. Erfahrungsgemäß ist es vorteilhaft, die Clients zu einem recht frühen Zeitpunkt in die neue Domäne zu bringen und die Server / sonstige Ressourcen dann in Ruhe nachzuziehen.

 

Wie kann ich es verhindern, dass die Clients sich schon in der neuen Domäne anmelden? Ich mein die sollen sich erst in der neuen Domäne anmelden wenn die Profilpfade angepasst wurden und die Profile migriert worden sind. Und warum ist es vorteilhaft die Clients frühzeitig in der neuen Domäne anmelden zu lassen? Wie sieht es eigentlich damit aus, wenn die Clients sich schon in der neuen Domäne anmelden auber der Exchange noch nicht migriert wurde, können die sich noch auf dem alten Exchange anmelden?

 

 

Du migrierst zuerst die Gruppen, dann die Benutzer. Danach wirst Du feststellen, daß alles sauber rübergenommen wurde, nur eben der Administrator der alten Domäne nicht. Die Gruppen, in denen der Administrator der alten Domäne vorher Mitglied war, werden überprüft und der Administrator der neuen Domäne dort wieder hinzugefügt. Am einfachsten ist es, sich den Administrator der alten Domäne anzusehen und nachzuschauen, wo der überall Mitglied ist. Dann rüber in die AD Struktur und dort den neuen Administrator eben wieder genau bei diesen Gruppen eintragen. Sache von wenigen Minuten, muss nur beachtet werden...

 

Jetzt habe ich das geschnallt, danke nochmals für die Erläuterung.

Link zu diesem Kommentar

Zum migrieren der Clients gibt es hier im Board einen Thread über das Tool "netdom", mit dem es gut zu gehen scheint.

 

Was hälst du eigentlich von "movedom", so wie ich das Verstanden habe müssen alle Clients bei "netdom" an seien, dass kann ich aber nich gewährleisten, deswegen möchte ich auch noch nach Wochen (bevor die NT4-Domäne aufgelöst wird) die nicht Clients migrierten Clients erwischen und automatisch migrieren.

 

Besorg Dir einfach VMWare Workstation oder Virtual PC (von beiden gibt es Testversionen zum Runterladen, in beide hat man sich relativ fix eingearbeitet).

 

Das habe ich mir auch schon überlegt, aber da braucht mein ca. 4GB-RAM :( und ich dachte gerade bei einer Parallelmigration ich auf der sicheren Seite bin, vorallem wenn ich das hier richtig durchplane, was soll da schief gehen? Wollte mir eigentlich die virtuelle Umgebung aus Zeitgründen sparren, was hälst du davon?

Link zu diesem Kommentar

Hi, Coyote,

 

4 GB Ram ist für VMWare zwar was feines, aber nicht nötig. Ich setze mit 2 GB für Testzwecke auch schon mal 5-6 VMs ein. Ist dann zwar nicht mehr so richtig performant, aber noch erträglich.

 

Testen ist immer gut, du weißt nie, auf welche Probleme du stößt, an die Du jetzt noch gar nicht denkst ;).

 

NT4 Domain Members:

Wenn Du NT4 Rechner in die AD 2003 Domain einbringst, musst Du eventuell an den Sicherheitsoptionen rumschrauben. Wir kommen darauf zurück, wenn s soweit ist.

 

Christoph

Link zu diesem Kommentar

4 GB Ram ist für VMWare zwar was feines, aber nicht nötig. Ich setze mit 2 GB für Testzwecke auch schon mal 5-6 VMs ein. Ist dann zwar nicht mehr so richtig performant, aber noch erträglich.

 

Mal sehen, ob ich den RAM genehmigt kriege, was meinst du was soll unbedingt in die VM für Testzwecke rein. (BDC, PDC, Exchange5.5, Clients???)

Habe irgendwo gelesen einen weiteren BDC in die VM für Migrationzwecke integrieren, welche Gründe stehen dafür und welche VM´s brauche ich noch für die Migration.

 

NT4 Domain Members:

Wenn Du NT4 Rechner in die AD 2003 Domain einbringst, musst Du eventuell an den Sicherheitsoptionen rumschrauben. Wir kommen darauf zurück, wenn s soweit ist.

 

Da bin ich mal gespannt, spricht eigentlich was dagegen, die NT4-Memberserver überhaupt noch in einer reinen AD-Umgebung einzusetzen? Sicherheitsproblem in der AD, Kompatibilität, Störung?

Link zu diesem Kommentar
4 GB Ram ist für VMWare zwar was feines, aber nicht nötig. Ich setze mit 2 GB für Testzwecke auch schon mal 5-6 VMs ein. Ist dann zwar nicht mehr so richtig performant, aber noch erträglich.

 

Hy Christoph !! Danke fürs reinschauen und mithelfen !

Damit ist eigentlich schon alles gesagt. Ich führe Migrationsschulungen durch, in denen ich live auf einem Rechner mit teils noch weniger als 2 GB Ram Migrationen vorführe.

 

Was benötigt man in der Testumgebung ?

- Hostbetriebssystem z.b. WinXP = 128 MB RAM

- NT4 PDC = 96 MB RAM

- NT4 BDC = 96 MB RAM

- NT4/Exchange 5.5 = 128 MB RAM

- W2K3 Server (DC+Exchange 2003) = 256 MB RAM

- Testclient (W2K oder XP) = 128 MB RAM

 

summa summarum nicht mal ganz ein Gigabyte... Alle Maschinen zwecks Performance evtl. noch ein bisschen mehr mit RAM ausgestattet, da reichen 1,5 - 2 Gig locker aus...

Testspielereien wie Fileserverdaten, Profile usw. incl. Berechtigungen aus der alten in die neue Domäne bringen kann man auf den oben genannten Servern zusätzlich abfackeln, ebenso wie Drucker usw... soll ja zum Testen sein und nicht produktiv...

 

Weiter im nächsten Thread...

 

schroeder750

Link zu diesem Kommentar
D.h. für mich dass über den Trust hinweg ich immer zwischen NT4-Domäne und einer reinen (native Mode W2k3) Domäne kommunizieren kann, ich mein mit dem Exchange?

 

Ja ...

 

Anders hätte ich doch gar keine Möglichkeit später wenn die neue Domäne im "native Mode" ist auf die Postfächer von Exch5.5 aus der NT4Domäne zuzugreifen, oder?

 

??? Verstehe ich jetzt nicht ganz... Du kannst Dich anmelden, wo Du willst und wirst auf beide Exchangeserver den Zugriff haben...

Wenn die User allerdings noch in der NT4-Umgebung arbeiten und die Postfächer schon auf dem neuen Exchange 2003 liegen, kann es da gewisse Berechtigungsprobleme geben. Also am Besten zuerst User in die neue Domäne und dann erst die Postfächer rüber...

 

Da Du mit einem Trust arbeitest, ist es für den Exchange absolut egal, ob die Domäne im native mode ist, oder nicht.

Früher hat man bei Firmen mit mehreren Aussenstellen auch einzelne Domänen aufgebaut und die darin laufenden Exchangeserver in die gleiche Organisation gebracht. Hier machen wir es genauso. Der neue Exchange 2003 läuft in der AD-Struktur, wird aber bei der Installation in die gleiche Organisation gebracht, wie der alte.

 

Weiter im nächsten Thread ... :D

Link zu diesem Kommentar

Was benötigt man in der Testumgebung ?

- Hostbetriebssystem z.b. WinXP = 128 MB RAM

- NT4 PDC = 96 MB RAM

- NT4 BDC = 96 MB RAM

- NT4/Exchange 5.5 = 128 MB RAM

- W2K3 Server (DC+Exchange 2003) = 256 MB RAM

- Testclient (W2K oder XP) = 128 MB RAM

 

in unserer Produktiv-Umgebung ist aber der Exchange5.5 auf dem PDC, d.h. die Exchange VM fällt aus der Testumgebung raus, und der Exchange5.5 kommt zum PDC dazu, natürlich mit 256MB, oder siehtst du das etwas problematischer?

Link zu diesem Kommentar
Das klingt aber interessant! Wenn das echt der Fall ist, dann würde ich mir mind. ein Update auf W2k3-Memberserver auf einem jetzigen NT4-Server sprarren (auch externe Dienstleistung, für diese spezielle Migration der Anwendung (FiBu, KoRe und Pers) würde somit auch wegfallen -> Kosten sparren, da wird sich der Chef freuen .

 

... das war mehr so theoretisch... :suspect: ich würde keine NT4 Memberserver mehr in die neuen Strukturen bringen. Deswegen machst Du ja unter anderem eine Parallelmigration. Die beiden Domänen können von mir aus sehr lange nebeneinander existieren, die NT4-Domäne wird erst dann ausgeknipst, wenn alle Ressourcen in die neue Struktur migriert wurden. Spar da nicht am falschen Ende... Sonst hast Du später eine W2K3 AD-Struktur mit alten NT4-Gurken drin. Wo ist da der Sinn der Migration ? ;)

 

Was kann ich da falsch machen, ich mein den Trust haben wir doch (früher in diesem Thread) aufgebaut und nicht aufgelöst. Oder soll ich noch was anderes Beachten? Der neue Exchange hat ja auch einen anderen/neuen Domännamen als der alte.

 

... man könnte z.B. auch den neuen Exchange mit einer eigenen, neuen Organisation aufbauen. Dann ist eben nix mit mal eben öffentliche Ordner replizieren und Postfächer rüberschubsen...

Der Trust bleibt so lange stehen, bis wir in der alten NT4-Domäne das Licht ausknipsen und das ist erst der Fall, wenn ALLES drüben ist...

 

Wie kann ich es verhindern, dass die Clients sich schon in der neuen Domäne anmelden? Ich mein die sollen sich erst in der neuen Domäne anmelden wenn die Profilpfade angepasst wurden und die Profile migriert worden sind. Und warum ist es vorteilhaft die Clients frühzeitig in der neuen Domäne anmelden zu lassen? Wie sieht es eigentlich damit aus, wenn die Clients sich schon in der neuen Domäne anmelden auber der Exchange noch nicht migriert wurde, können die sich noch auf dem alten Exchange anmelden?

 

... indem man die Useraccounts in der neuen Domäne z.B. so lange deaktiviert, bis man WILL, daß sie sich in der neuen Domäne anmelden. Also erst nach erfolgreichen Tests mit Profilen usw. usw. Man sollte sich immer Gruppen von Usern schnappen, denen man die PCs in die neue Domäne bringt, nachdem man die Profile rüberkopiert hat und z.B. die Postfächer rübergeschoben hat. Das kann man sehr übersichtlich gestalten...

 

Weiter im nächsten Thread... :)

Link zu diesem Kommentar
Wie sieht es eigentlich damit aus, wenn die Clients sich schon in der neuen Domäne anmelden auber der Exchange noch nicht migriert wurde, können die sich noch auf dem alten Exchange anmelden?

 

... definitiv Ja. Die User wurden ja mit SID-History migriert, das passt dann...

 

Was hälst du eigentlich von "movedom", so wie ich das Verstanden habe müssen alle Clients bei "netdom" an seien, dass kann ich aber nich gewährleisten, deswegen möchte ich auch noch nach Wochen (bevor die NT4-Domäne aufgelöst wird) die nicht Clients migrierten Clients erwischen und automatisch migrieren.

 

Kurze Antwort: habe "movedom" bisher noch nicht getestet... :D

Habe da viel per Hand gemacht / machen lassen, da oft eh aus anderen Gründen die PCs angefasst wurden...

 

und ich dachte gerade bei einer Parallelmigration ich auf der sicheren Seite bin, vorallem wenn ich das hier richtig durchplane, was soll da schief gehen? Wollte mir eigentlich die virtuelle Umgebung aus Zeitgründen sparren, was hälst du davon?

 

Du wirst von mir KEINE Bestätigung hören, daß man sich eine Testumgebung sparen sollte ... sorry. In der Theorie ist das alles immer klar und wunderbar, in der Praxis spuckt Dir immer irgendwas in die Suppe...

Die neue, parallele Umgebung ist nur anfangs sowas wie eine Testumgebung. Sobald da der erste produktive Server oder Client drin ist, fährst Du da auch nicht mal eben locker alles runter und wieder rauf, weil Du testen willst.

 

Schnapp Dir einfach einen modernen Rechner (popeliges IDE-Teilchen) mit etwas mehr RAM und geh das da in Ruhe durch. Der Rechner wird ja nachher wieder frei und kann für einen User eingesetzt werden oder sonstiges. Wenn Cheffe da kein Geld für locker macht, obwohl Du ihm die Notwendigkeit fachlich erläutern kannst, dann ist er echt mutig ... :D

Das sollte schon sein...

 

in unserer Produktiv-Umgebung ist aber der Exchange5.5 auf dem PDC, d.h. die Exchange VM fällt aus der Testumgebung raus, und der Exchange5.5 kommt zum PDC dazu, natürlich mit 256MB, oder siehtst du das etwas problematischer?

 

... dann saug einen NT4 BDC aus der produktiven Umgebung als VM-Maschine ab und mach damit die "virtuelle Testumgebung" auf (Abnabeln von der Echtumgebung, Hochstufen zum PDC usw...). Anschließend bringst Du hier einen weiteren BDC rein, der so heißt wie der jetzige PDC. Den kannst Du hochstufen zum PDC und dann den Exchange 5.5 draufnageln. Schon passt das wieder, auch mit den Datenbanken :D

 

Puha, da hat sich jetzt einiges überschnitten... :D

 

Sind noch Fragen offen geblieben ? :cool: - Gibs mir ... :p

 

Grüsse

 

schroeder750

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.




×
×
  • Neu erstellen...