Migration NT 4.0 auf Windows 2003

[Wolke2k4 11]

Gibt es für ADMT auch einen brauchbaren Guide, der einen Schritt für Schritt durch die Migration führt???

 

Momentan scheint eine Migration mit ADMT nahezu unmöglich. Wir haben mal eine Testumgebung aufgebaut und das erste, was wir von den Wizards mitgeteilt bekommen ist ein "Zugriff verweigert" Fehler.

Die ADMT Hilfe wird in diesem Zusammenhang ihrem Namen auch nicht gerecht...

 

Sowas wie ein "Windows Server NT4.0 Migration auf Windows Server 2003 mit ADMT for Dummies" wäre wirklich nicht schlecht.

[grizzly999 11]

Dem ADMT liegt nach der Installation ein Readme bei, ist zwar englisch, aber erklärt das Vorgehen.

Whrscheinlich fehlen aber ein paar Voraussetzungen, die gegeben sein müssen, normalerweise meldet die das Tool und setzt die Einstellungen.

Ich schließe mich aber meinen Vorednern an, was das angeht, sich ein wenig über die Mirgrationsmethoden schlau zu machen. Dazu empfehle ich das grüne MS-Press Buch für die 70-222: http://www.edv-buchversand.de/mspress/search.asp?s1%5B%5D=deutsch&cnt=search&s0=70-222

 

 

grizzly999

[schroeder750 10]

... und genau deswegen halte ich für unsere Kunden die Schulungen mit EIGENEN Unterlagen.

 

Sich mal eben so ein Buch von Microsoft zu schnappen und innerhalb von einigen Tagen Studium fit für die Migration zu sein, halte ich für nicht gerade wahrscheinlich ...

 

Da ich nicht alles gerne doppelt schreibe sei hier nur kurz der Tip gegeben, in diesem Forum nach "schroeder750" zu suchen, die meisten Beiträge, die ich bisher gepostet habe, beziehen sich auf dieses Thema.

 

Man merkt leider sehr oft, daß die Leute zwar MCSE-mäßig geschult wurden, aber dann in der Praxis recht fix sehen, daß bei der Schulung eben nur die Hälfte gezeigt wurde... gerade beim Thema Parallelmigration ...

 

Ich habe mir das ganze als Systemberater sehr intensiv geben müssen, da ich die Migrationen bei unseren Kunden durchführe. Und das wäre nur mit MS-Schulungen oder ein paar Büchern nie vernünftig gelaufen.

Bin selber oft genug auf die Klappe gefallen und möchte hier verhindern, daß es andern auch passiert...

 

Ruckzuck ist was falsch gemacht und die Hälfte der Daten ist im Nirvana ...

 

Grüsse

 

schroeder750

[Wolke2k4 11]

Mir wäre es auch lieber die Geschichte ausführlich zu testen aber das ist leider einfach nicht drin.

 

Wir haben unsere Köpfe noch mal rauchen lassen und sind unter anderem auf einen interessanten Lösungsansatz gestoßen .

 

Im Grunde könnte man daraus folgende Vorgehensweise für unser Szenario ableiten:

 

1. Installation eines temporären NT4 PDCs mit Migration nach W2K3. Wobei sich die Frage stellt, was mit dem vorhandenen PDC passiert, sobald der temp PDC in das Netz gebracht wird.

 

2. Installation des (eigentlichen) W2K3 auf der neuen Serverhardware mit Übernahme der Betriebmaster Funktionen des temporären AD DC. Einrichtung der entsprechenden Dienste (DHCP und DNS)

 

3. Entfernen des temp AD DC aus der Domain.

 

4. Gegebenenfalls herabstufen der alten BDCs.

 

Die Frage ist, ob das Herabstufen der BDCs Sinn macht bzw. überhaupt notwendig ist, wenn diese sowieso mit dem neuen W2K3 DC kommunizieren können. Ziel ist ein W2K3 DC mit drei BDCs und davon ein BDC mit Exchange 5.5 am laufen zu haben.

 

Was passiert, wenn der W2K3 DC aktiv wird, wird dieser dann für die BDCs sowas wie ein "PDC"? Theoretisch müssten durch die Migration sämtliche Computerkonten übernommen werden (was ja auch Sinn der Migration ist) und somit die Einrichtung der Server und Clients in die W2K3 Domain entfallen (sprich die Aufnahme der Computerkonten in die W2K3 Domain).

 

Über diesen Weg müsste dann, theoretisch, sichergestellt sein, dass weiterhin jeder Nutzer auf die ihm in der alten NT4 Domain zugewiesenen Ressourcen und Dienste zugreifen kann (egal ob W2K3 oder NT)????

 

Welche Rolle spielt jetzt noch der "native" Mode, auch im Zusammenhang mit Exchange? Laut dem Link oben gibt es lediglich die zwei folgenden Möglichkeiten:

 

http://www.admins-tipps.net/software/microsoft/migration_nt4_w2k3/upgrade_pdc_to_w2k3/11.jpg

 

wobei "Windows 2003 interim" für unser Szenario richtig wäre....

[schroeder750 10]

Hy wolke2K4,

 

ich kann Dir echt nur den Tip geben, Dir mal die weiteren Threads anzuschauen, in denen ich was gepostet habe. Einfach auf Suche nach Mitgliedern, „schroeder750“ eingeben und die ganzen Threads in Ruhe durchlesen…

 

Ich müsste sonst alles immer wieder doppelt und dreifach schreiben…

 

Hier nur mal kurz ein paar Antworten auf Deine Vorgehensweise:

 

Zitat:

„Mir wäre es auch lieber die Geschichte ausführlich zu testen aber das ist leider einfach nicht drin.“

 

SCHLECHTESTE VORRAUSSETZUNGEN !!! Du SOLLTEST vorher testen !!!

Bei einer InPlace-Migration (und genau die beschreibst Du hier) werkelst Du in der PRODUKTIVEN Domäne rum !

Ein falscher Schritt und Deine User können ein paar Tage Urlaub machen…

Sorry, wenn ich hier so viel Grossschrift benutze, aber es ist wirklich wichtig !

Ist nur gut gemeint…will Dich vorm Horror bewahren ;-))

 

Zu 1) Einen „temporären PDC“ kannst Du nicht mal eben in die Domäne integrieren. Du bringst diesen Server unter NT4 als BDC rein und stufst ihn zum PDC hoch, wobei der jetzige PDC automatisch zum BDC herabgestuft wird. Diesen neuen PDC unterziehst Du einem Update auf W2K3, wobei Dir das schon gegen die Wand laufen kann, wenn Du hier vorher unter NT4 nicht schon das DNS richtig konfiguriert hast. Ist das DNS falsch konfiguriert, Du merkst es aber erst während des Updates, war es das schon … dann hängst Du mit dem halb upgedateten PDC in einer Updateschleife drin, kannst keinen sauberen DC draus machen, weil das DNS nicht stimmt, kannst aber auch das DNS nicht mehr sauber konfigurieren, weil Du in diesem Updatevorgang alles ausgeraut hast … habe ich alles schon gehabt.

Das was vorher beim NT4 unter den Netzwerkeinstellungen unter DNS eingetragen ist, taucht nämlich nachher beim W2K3 DC unter den Eigenschaften beim Arbeitsplatz als DNS-Suffix auf … das muss vorher alles stimmen…und ohne sauberen DNS-Suffix (fqdn) kein sauberer „dcpromo“ …

 

Zu2) Den Dienst DNS kannst Du nicht erst auf dem zweiten und somit späteren endgültigen DC einrichten, der muss schon vorher auf dem ersten (temporären) DC sauber laufen, sonst kriegst Du kein AD hin … DHCP ist hier erst einmal zweitrangig.

 

Zu3) Entfernen ist richtig, aber auf jeden Fall sauber mit „dcpromo“, sonst gibt es nachher im AD Replikationsleichen, die Dir in der Domäne ewig die Performance versauen…

 

Zu4) Herabstufen der alten BDCs… Tja, normalerweise ist es ja so: ein NT4-Server wird als Memberserver, BDC oder PDC ins Netz gebracht. Die Rollen des PDC und BDC kann man rauf oder runterstufen. Du wirst jedoch nie einen BDC zum Memberserver machen können …

Einmal DC, immer DC … jedenfalls normalerweise …

Was dieses Tool „UPromote“ kann, weiß ich nicht… wenn man jedoch unbedingt teuere Zusatztools kaufen will …

 

Wenn Du Exchange 5.5 auf einem BDC laufen hast, ist das bei einer InPlace-Migration die schlechteste Vorraussetzung, die Du haben kannst. Wenn Du den Exchange später auf 2K3 migrieren willst, musst Du aus den eventuell tief verschachtelten Verteilerlisten des Exchange 5.5 universelle Gruppen im AD machen. Die kannst Du erst anlegen, wenn die Domäne im native mode ist. In den native mode bringst Du die Domäne erst, wenn Du alle NT4-BDCs draussen hast. Den letzten NT4-BDC kriegst Du erst raus, wenn der Exchange 5.5 weg ist. Den Exchange 5.5 kriegst Du aber erst weg, wenn die Domäne für den Exchange 2k3 im native mode ist. Und spätestens hier beisst sich die Katze in den Schwanz…

Dann muss der Exchange 5.5 vorher wieder auf einen Memberserver verlegt werden …

Und das Runterstufen eines BDCs, auf dem Exchange 5.5 läuft mit diesem Tool „UPromote“ … Na ja, vielleicht funktionierts, vielleicht auch nicht… ich würde so was vorher Testen, aber die Zeit scheinst Du ja nicht zu haben … ;-))

 

... Box wird zu klein, weiter im nächsten Feld ... ;-))

[schroeder750 10]

Zum W2K3-DC: Natürlich übernimmt dieser die Funktion des ehemaligen PDC. Die Rolle des „PDC-Emulators“ ist eine der 5 fsmo-Rollen … Das funktioniert wunderbar, die BDCs sind der festen Überzeugung, sie würden mit einem NT4-PDC kommunizieren…

 

Und jetzt noch was zu diesem „interims-modus“: Ganz ehrlich ? – Ich habe den NIE gebraucht. Wo soll der Sinn sein, NT4-BDCs zuzulassen und W2K-DCs auszusperren ?

Was eventuell eine Möglichkeit wäre, ist die, dass im „interims-modus“ universelle Gruppen zugelassen sind, obwohl die Domäne nicht im native mode ist. Dann würde das Ganze halbwegs Sinn machen. Da kann ich Dir aber nix genaues drüber sagen, habe diesen Modus nie benutzt.

 

Mal ganz ehrlich ?

--- Warum baust Du Dir nicht auf der grünen Wiese eine Paralleldomäne auf und ziehst mit den normalen Migrationstools wie ADC und ADMT die Ressourcen rüber ? Dann schraubst Du nicht in der produktiven Domäne rum und lässt Leichen und Fehlkonfigurationen (verbogene policies oder ähnliches ) in der alten Domäne zurück.

 

Ich will den Weg, der in Deinem Link beschrieben wird, nicht schlecht machen, nur denke ich, dass man sich vorher schlau machen sollte. Die Jungs, die diesen Link geschrieben haben, werden auch was verkaufen wollen und schreiben nicht ALLES komplett rein…

Komm nicht auf die Idee, dass es ein Kochrezept ist, das Du nur abfahren musst … ist es nicht, kann ich Dir bestätigen.

 

Es wird immer viel erzählt, dass eine Parallelmigration ach sooo viel komplizierter ist als eine InPlace-Migration… ist sie meiner Meinung nach nicht unbedingt.

 

Man kann in Ruhe testen, ohne der produktiven Domäne weh zu tun, kann jederzeit neu anfangen, wenn man Mist gebaut hat, da man bis zu einem gewissen Zeitpunkt nur lesend in die NT4-Domäne eingreift und hat noch den Vorteil, dass man sauber bei Null anfangen kann.

 

Denk mal drüber nach, in diesem Fall wäre die spätere produktive Umgebung erst einmal Dein Testumfeld… da geht keine Arbeit verloren…

 

Mist, ist doch wieder so ein Roman geworden… sorry, ist schon immer mein Problem gewesen…

 

Grüsse

 

Schroeder750

[Velius 10]

Hier ist eine Übersicht, über die functional Levels, und deren Nutzen Domain and forest functionality

 

 

 

In-place Mirgrationen sind:

 

Meistens billliger, da weniger Hardware Resourcen beansprucht werden.

 

Können die Netzwerkfunktionalität beinträchtigen.

 

Altlasten werden meist 1:1 übernommen, also keine Konsolidierung möglich.

 

Bestimmte Migrationspfade müssen eingehalten werden (welche Server zuerst, und welche zuletzt migriert werden dürfen).

 

 

Neuen Forest erstellen bedeutet:

 

Höherer verschleiss der Resourcen, da (Server) Hardware beinahe doppelt benötigt wird.

 

Sauberer, da es sich um eine von Grund neu designeten Forest handelt.

 

Das Netz wird nicht beeinträchtigt.

 

Ausserdem sind die Mirgationspfade einfacher.

 

 

 

Gruss

Velius

 

 

P.S.: Mann kann die beiden Methoden auch mixen (in-place, dann Mirgration in einen neuen Forest).

[schroeder750 10]

Hy Velius,

 

danke für diese Zusammenfassung, hast Recht, ab einem bestimmten Zeitpunkt ist es absolut sinnvoll mal die grundlegenden Aussagen sprechen zu lassen. Ich verzettel mich da ganz gerne mal bei meinem Geschreibsel ...

 

Zu der Geschichte mit den wesentlich mehr benötigten Hardwareressourcen muss ich jedoch wiedersprechen.

 

Bei einer Parallelmigration reicht es, sich zuerst einmal eine ALDI-Workstation zu schnappen und da den ersten DC draus zu machen (halt immer eine Sicherung des Systemstate ziehen).

 

Ab diesem Zeitpunkt werden entweder

 

A) Server, die auch bei einer InPlace-Migration eh angeschafft worden wären, in die neue Domäne gebracht, anstatt in die alte

 

oder

 

B) Die bestehenden (NT4)-Server Stück für Stück aus der alten Domäne als W2K3-Server neu aufgesetzt in die neue Domäne gebracht. Und die hätte ich auch in der alten Domäne bei einer InPlace-Migration neu installieren müssen.

 

Ich kann aus meiner Erfahrung bestätigen (und das waren wirklich einige Migrationen), daß ich, wenn ich es richtig plane, zwei oder drei neue Kisten benötige, wovon einer oder zwei meistens moderne Workstations waren, die ich temporär einsetze ...

 

So gut wie keine neue Hardware benötige ich natürlich nur, wenn ich eine InPlace-Migration durchziehe und alle Server einfach update... aua aua ... wer das macht, braucht dann irgendwann einen langen Urlaubsschein ... ;-)) ... bloss die Finger weg davon ...

 

Grüsse

 

schroeder750

[Velius 10]

Ok, das mit der Hardware ist mit Vorsicht zu geniesen, aber am aller sichersten fährt man, wenn die Zieldomäne, - Forest schon komplett steht. So erparrt man sich stress bei Fehlern innerhalb der Mirgration.

 

 

Ausserdem hier: What Exchange Administrators Need to Know About the Active Directory Migration Tool

 

 

Original geschrieben von schroeder750

 

Wenn Du eine neue Domäne unter W2K3 AD nackt auf der grünen Wiese aufbaust, hat die vorerst mit der alten, produktiven NT4-Domäne nichts zu tun.

Es ist absolut egal, in welchem Modus (mixed oder native) sich diese Domäne befindet.

Sie wird anschließend über einen Trust mit der NT4-Domäne verbunden und die Gruppen der Domänen (Administratoren und Benutzer) entsprechend über Kreuz berechtigt.

 

 

 

Nicht ganz, denn.....

 

 

Important: The Target domain must be running in Native mode to use the Active Directory Migration Tool.

 

 

...sonst kann das Attribut "SID-History" gar nicht angefüllt werden. Geht nur im native Mode.

 

 

Gruss

Velius

 

 

Ich hatte den/die 070-222 MOC Kurs/Prüfung, und fand sie gar nicht so schlecht.... :wink2: :)

[schroeder750 10]

... hast mich erwischt, stimmt natürlich... ich bringe die Domäne auch immer vorher in den native mode...

 

hatte das nur geschrieben, um klar zu machen, daß die neue Domäne nicht so abhängig ist, wie die alte bei einer InPlace-Migration.

 

War definitiv so nicht richtig !! Hatte ich nicht genau überlegt... bin auch nur ein Mensch und hatte das nebenbei geschrieben, als ich bei einem Kunden draussen saß... da muss sowas immer fix gehen.

 

Danke !! ;-))

 

schroeder750

[Wolke2k4 11]

Hallo schroeder,

 

vielen Dank für Deine Mühe. ADMT hatten wir ja schon kurz am Wickel, leider wussten wir nicht einmal ob wir das Tool testweise auf dem NT PDC oder dem W2K3 DC installieren sollten. Wie Du siehst, ist es mit unserem Wissen in Bezug auf Migration von Domain nicht weit her. ..

 

Wir wären Dir sehr dankbar, wenn Du uns einen kleinen Exkurs zur Nutzung von ADMT schreiben könntest oder eine brauchbare Quelle zur Nutzung von ADMT kennst.

 

Wir hatten ADMT auf dem W2K3 DC installiert, haben mit einem Rechtsklick auf den obersten Eintrag den Eintrag "Report Wizard" ausgewählt, wobei wir nicht einmal wussten, was der Report Wizard tut. Als nächstes mussten wir Quell und Zieldomain angeben, wobei ADMT bereits die NT und W2K3 Domain erkannte. Beim Klick auf "weiter" erschien auch schon gleich der erste "Fehler 5 Zugriff verweigert" entgegen. Ich nehme mal an, dass dies etwas mit der Vertrauensstellung der Domains untereinander zu tun hat...

 

Die Readmedatei von ADMT hilft uns nicht wirklich weiter.

 

Nach dem besagten Rechtsklick auf den obersten Eintrag in ADMT finden sich viele Einträge z.B. "User Migration", "Report Wizard" usw.

Müssen diese Punkte nacheinander abgearbeitet werden und fertig ist die Migration????

 

Wir fühlen uns bei dieser Problematik nicht besonders wohl :shock: , brauchen aber unbedingt fachmännische Hilfe!! ;)

Wenigstens sind wir ehrlich...

 

P.S. Die Problematik mit dem native Modus in Bezug auf Exchange hätte sich mit ADMT dann theoretisch aufgelöst, da die W2K3 Domain gleich als native installiert werden kann???

[schroeder750 10]

... Bei der Parallelmigration wird die neue Domäne direkt in den native mode geschaltet, daß ist richtig.

- Nach der Installation überprüfen, dümmstenfalls von Hand in den native mode bringen...

Somit können die Verteilerlisten also sauber vom Exchange 5.5 rübergeholt werden.

 

Mit dem ADMT, das ist so eine Sache... man muss halt vorher so einiges vorbereiten, bevor man das ADMT startet.

Die Berechtigungen des Accounts, unter dem das ADMT läuft, sollten halt in beiden Domänen richtig sein.

Daher kommt wohl der "Zugriff verweigert" Fehler...

 

Das ADMT bietet verschiedene Optionen. Die MÜSSEN natürlich nicht alle der Reihe nach abgefackelt werden.

Was man auf jeden Fall braucht sind folgende Wizzards:

- Usermigration

- Gruppenmigration

 

Hierbei ist die Reihenfolge auch nicht ganz unerheblich...

 

Habt Ihr schon einen BDC in der NT4-Domäne, auf dem der Passwort-Export-Server läuft ?

Sonst wird das nix mit Passwörtern rüberholen...

 

Ob man die Clients mit dem Wizzard vom ADMT in die neue Domäne hieft oder dies doch lieber händisch macht,

bleibt jedem selbst überlassen. Hierbei kommt es natürlich auch auf die BS-Version der Clients an...

Bei den Multimediaspielzeugen wie Win 9x ist da wohl eh nicht viel autmatisiert zu holen ...

 

Grüsse

 

schroeder750

[klar_denken 10]

Hy Wolke24,

Wenn Du eine neue Domäne unter W2K3 AD nackt auf der grünen Wiese aufbaust, hat die vorerst mit der alten, produktiven NT4-Domäne nichts zu tun.

Es ist absolut egal, in welchem Modus (mixed oder native) sich diese Domäne befindet.

Sie wird anschließend über einen Trust mit der NT4-Domäne verbunden und die Gruppen der Domänen (Administratoren und Benutzer) entsprechend über Kreuz berechtigt.

 

Hallo,

ich habe gleiches problem, mit migration.

Nun habe ich neuen Server mit W2k3 installiert (neue DOmäne) mit ohne trust kann nicht mit ADTM arbeiten, kann mir jemand weiter helfen wie kann ich beide domäne verknüpfen?!

 

danke

[Adrenalinpur 10]

Hallo miteinander,

 

@zu_klardenken:

du muß bei NT eine Vertrauensstellung zur W23K Domäne machen,

Start -Programme- Verwaltung - Benutzermanager -Richtlinien

und dort den Namen der anderen Domain angeben.

 

Unter W2k3

Start -Programme- Verwaltung - Active Directory Domänen und Vertrauensstellung

rechter Mausklick auf die Domäne - eingenschaften - Vertrauensstellung

 

dort den Namen der NT-Domäne angeben.

 

Gruß A.

und gleich hänge ich eine Frage an

[Adrenalinpur 10]

Hier die Frage an alle die fleissig von NT auf R2 migriert haben (specially R2 OEM Standard Version):

 

Wie habt ihr die Userdaten inklusive Rechte auf den R2-Server bekommen?

In meiner Testlandschaft ging das wunderbar mit NT-Backup, aber beim Kunden kann der Administrator des R2 nicht auf die Verzeichnisse am NT zugreifen, wenn dort Domänenadmins Zugriff haben. Mir ist das völlig schleierhaft, im Test sticht einfach der R2-Domänenadmin.

 

Wie die lokalen User-Profile?

Ich hätte sie zuerst als servergespeicherte erstellt, überkopiert und dann wieder zu lokalen gemacht.

 

Danke für euer Hilfe

Gruß A.