Jump to content

Win Server 2003 Migration mit ADMT3


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

Empfohlene Beiträge

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

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...