Win Server 2003 Migration mit ADMT3

[jauer 10]

Hi,

 

Ich möchte das AD von einem Win2003 Server auf ein neues System mit Windows Server 2008 übertragen. Im Praxisbuch ActiveDirectory für Windows Server 2008 wird die Migration mithilfe von ADMT beschrieben.

 

Allerdings hakt es an folgender stelle:

Der Windows Server 2003 findet die neu erstelle Domäne nicht. Sie wird im ADMT auch nicht angezeigt. Gibt man die Domäne manuell an erhält man folgende Meldung: "Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. Fehlercode 1355". Google konnte mir leider nicht weiterhelfen, auch nicht MSDN.

 

Hat einer eine Idee, was das Problem sein könnte?

 

mfg

[Daim 12]

Hola,

 

Der Windows Server 2003 findet die neu erstelle Domäne nicht. Sie wird im ADMT auch nicht angezeigt. Gibt man die Domäne manuell an erhält man folgende Meldung: "Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden.

 

eine Namensauflösung (z.B. eine "bedingte Weiterleitung") hattest du aber eingerichtet?

Ansonsten, hast du auch auf dem Windows Server 2008 DC folgenden Registry-Eintrag erstellt?

 

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters

Registry value: AllowNT4Crypto

Type: REG_DWORD

Data: 1

 

 

Überprüfe auf jedenfall die Vorrausetzungen anhand des Whitepapers.

 

Download details: ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains

[jauer 10]

danke für deine antwort,

 

jetzt habe ich noch eine grundsätzliche Frage zum ADMT.

Werden die Dateien direkt umgezogen, sodass die Quelldomäne danach leer ist. Oder werden die Daten kopiert?

 

Kann man das evtl sogar einstellen?

 

mfg

[NilsK 2.961]

Moin,

 

ADMT legt in der neuen Domäne "Kopien" der Objekte an. In der alten Domäne werden sie nicht gelöscht. Man kann aber einstellen, dass die Objekte nach der Migration deaktiviert werden, sodass man sich nur noch an die neue Domäne anmelden kann.

 

Gruß, Nils

[Daim 12]

Werden die Dateien direkt umgezogen, sodass die Quelldomäne danach leer ist. Oder werden die Daten kopiert?

 

Lass mich raten: Du hast dir das Whitepaper zu ADMT - NICHT - durchgelesen?

 

Wenn eine INTRA-Forest Migration durchgeführt wird, also z.B. sollen alle Subdomänen in die Root-Domäne innerhalb einer Gesamtstruktur migriert werden, dann wird standardmäßig das Benutzerobjekt aus der Quell-Domäne entfernt.

 

Bei einer INTER-Forest Migration (zwischen zwei Gesamtstrukturen) bleibt das Objekt in der Quell-Domäne weiterhin bestehen. Teste das doch mit einem Test-Benutzer, dann siehst du es und vorallem, lies das Whitepaper und führe eine Test-Migration in einer Testumgebung durch.

 

Wenn es ein kommerzielles Werkzeug sein darf, dann ist hier der "Migration Manager for Active Directory" von Quest sehr zu empfehlen. Mit diesem Werkzeug, bleibt auch das Bentzerobjekt bei einer INTRA-Forest Migration in der Quell-Domäne bestehen. Hier kann vieles im Hintergrund, ohne das die Benutzer etwas davon merken, durchgeführt werden.

[NilsK 2.961]

Moin,

 

Wenn eine INTRA-Forest Migration durchgeführt wird, [...]dann wird standardmäßig das Benutzerobjekt aus der Quell-Domäne entfernt.

 

oha. Sowas habe ich noch nie migriert, daher war mir das nicht bewusst.

 

Wenn es ein kommerzielles Werkzeug sein darf, dann ist hier der "Migration Manager for Active Directory" von Quest sehr zu empfehlen. Mit diesem Werkzeug, bleibt auch das Bentzerobjekt bei einer INTRA-Forest Migration in der Quell-Domäne bestehen. Hier kann vieles im Hintergrund, ohne das die Benutzer etwas davon merken, durchgeführt werden.

 

Naja. Genau in dem Bereich hat das Quest-Tool leider auch seine Schwächen: Im Unterschied zu ADMT kann es den "gesperrt"-Status eines Objekts nicht übertragen. Man kann nur alle beim Migrieren sperren oder keine, aber den Status nicht so setzen, wie er beim Original war. So war es zumindest vor ca. einem Jahr. Wir haben dann für den Kunden ein zusätzliches Skript gebaut, das den Status überträgt. (Quest hätte 10 TEUR haben wollen, um die Funktion irgendwie hinzubasteln.)

 

Ein weiteres Skript haben wir gebaut, damit die Objekte in der neuen Domäne nicht alle im selben Container landen, sondern in einem Zielcontainer, der dem alten Speicherort entspricht. Da leistet Quest selbst leider auch nicht mehr als ADMT, eine Mapping-Funktion hat es nicht (auch wieder Stand vor einem Jahr, aber mich würde wundern, wenn die das geändert hätten).

 

Der große Vorteil des Quest-Tools ist, dass bei einer lang andauernden Migration ein Abgleich zwischen altem und neuem Objekt stattfindet. Außerdem kann Quest noch die Berechtigungen in ein paar Applikationen anpassen, die ADMT nicht berücksichtigt.

 

Ansonsten war ich davon weniger überzeugt, vor allem angesichts des Preises.

 

Gruß, Nils

[Daim 12]

Hola,

 

oha. Sowas habe ich noch nie migriert, daher war mir das nicht bewusst.

 

ja, dass Quellobjekt wird bei einer InTRA-Migration entfernt.

 

Im Unterschied zu ADMT kann es den "gesperrt"-Status eines Objekts nicht übertragen. Man kann nur alle beim Migrieren sperren oder keine, aber den Status nicht so setzen, wie er beim Original war. So war es zumindest vor ca. einem Jahr.

 

Es ist noch weiterhin so.

 

Ein weiteres Skript haben wir gebaut, damit die Objekte in der neuen Domäne nicht alle im selben Container landen, sondern in einem Zielcontainer, der dem alten Speicherort entspricht. Da leistet Quest selbst leider auch nicht mehr als ADMT, eine Mapping-Funktion hat es nicht (auch wieder Stand vor einem Jahr, aber mich würde wundern, wenn die das geändert hätten).

 

Nein, dass ist auch heute noch genau so. Alle Objekte können nur in einen Container migriert werden. Man kann z.B. nicht die Benutzer von den Gruppen trennen, leider.

 

Der große Vorteil des Quest-Tools ist, dass bei einer lang andauernden Migration ein Abgleich zwischen altem und neuem Objekt stattfindet. Außerdem kann Quest noch die Berechtigungen in ein paar Applikationen anpassen, die ADMT nicht berücksichtigt.

 

Ja, gerade bei einer längeren Migration spielt imho Quest seine Stärken aus.

Weitere Vorteile von Quest wären aber:

 

- Volle Undo-Funktionalität, bei AD-Objekten und auch beim Re-ACLing. ADMT kann nur letzten AD-Lauf, nicht das Re-ACLing zurückführen.

- Migration der AD-Standorte, Subnets, Sitelinks ist nur mit Quest möglich, nicht aber mit ADMT.

- Mit Quest kann die Quell-OU migriert werden, nicht aber mit ADMT.

- Mit Quest können während der Migration die Daten verändert werden (z.B. HR-Daten hinzufügen).

- Vertrauensstellungen können mit Quest migriert werden, nicht aber mit ADMT.

 

usw. usf.

 

 

Man darf eben eins dabei nicht vergessen, ADMT ist kostenlos und dafür kann es schon eine ganze Menge.

 

Aber auch (wie gerade bei mir, ich muss nämlich bei einem Kunden seine 20 Subdomänen in die Root-Domäne migrieren ;) ) bei einer InTRA-Forest Migration spielt Quest seine Stärken aus. Der Kunde hat sich eben zu Quest entschieden, da bei dieser Variante der Migration der Benutzer "kaum" etwas davon merkt. Natürlich hätte man das auch mit ADMT realisieren können, jedoch hätte dabei mehr nach Feierabend durchgeführt werden müssen oder am Wochenende. Bis zum Jahresende müssen 20 Domänen migriert werden. So bleiben die Ausfallzeiten der produktiven Einheiten, bei einer Intra-Forest Migration mit dem Quest Tool eben geringer als mit ADMT.

 

P.S. Das war auch der Grund, warum ich überhaupt keine Zeit hatte, mich beim Beta-Test von Josè zu beteiligen.

 

In Kürze pinsele ich ohnehin einen "ADMT vs. Quest" Artikel.

 

Ansonsten war ich davon weniger überzeugt, vor allem angesichts des Preises.

 

Also ich finde es nicht schlecht. Quest hat seine Vorteile. Man kann aber auch jede Größe einer Umgebung auch mit ADMT migrieren. Der Preis von Quest (13 Euro pro zu migrierender Benutzer, wobei je nach Anzahl der Benutzer ca. 10% Rabatt drin ist) ist auch nicht ohne.