Novell Migration mit ADMT und netIQ IDM

Vor einigen Wochen stand ich vor dem Problem ca. 5.000 PC-Arbeitsplätze von Novell OES mit eDirectory in eine Active Directory Domäne zu überführen. Alle Arbeitsplätze waren nicht Mitglied einer NT- oder AD-Domäne.

Die Benutzer, OUs und Gruppen ließen sich mit dem netIQ IDM, welcher beim Kunden im Einsatz ist, gut übertragen. Würde man jetzt hingehen und den Client einfach in die AD-Domäne „joinen“, geht das natürlich, aber der Anwender bekommt ein neues Profil. Bei 5.000 PC-Arbeitsplätzen macht das keinen Spaß 5.000 Personen zu erklären, dass ihr Desktop und andere Dinge wieder schön ordentlich sind – nämlich nicht mehr da.

Da es sich um ein reines „Novell-Netzwerk“ handelte, waren alle Clients ohne AD-Domäne installiert. Jeder Client nutzte die Novell DLU-Policy die dafür sorgt, dass jeder Anwender beim Novell-Login dynamisch auf dem Client lokal angelegt wird. Also bestand für uns die Aufgabe, jeden einzelnen Benutzer auf jeden einzelnen Arbeitsplatz mit dem entsprechenden Anwender in der AD-Domäne zu ersetzten.

Am Markt gibt es eine Reihe von Werkzeugen mit denen es möglich ist Profile zu übertragen. Diese Vorgehensweise erschien uns zu komplex und zu störungsanfällig. Genauso gibt es am Markt verschiedene Migrationswerkzeuge, die mir eine solche PC-Migration erleichtern. Das dumme war, diese Werkzeuge kosten viel Geld und wir wollten nur ein Werkzeug für die Client-Migration.

Im Bereich einer AD zu AD Migration, beispielsweise bei einer Domänen-Konsolidierung, arbeiten wir häufig mit dem ADMT-Werkzeug von Microsoft. Dieses ist eigentlich für die Migration von Arbeitsplätzen von einer AD-Domäne in eine andere AD-Domäne gedacht.

Genau betrachtet machen solche Werkzeuge immer das Gleiche. Es werden auf dem Arbeitsplatz die SIDs aus der alten Umgebung mit den SIDs der neuen Umgebung (AD-Domäne) getauscht. Bei einer AD zu AD Migration habe ich normalerweise ein Mapping-File für die Migration. In diesem speziellen Fall habe ich aber auf jedem Client ein eigenes Mapping-File, da jeder Client sozusagen seine eigene Domäne ist.

Also habe ich mir gedacht, ich lese alle lokalen Benutzer-SIDs auf dem Client aus, ermittle anhand des Benutzernamens des lokalen Benutzers die SID aus der Domäne und füttere den ADMT-Service entsprechend einzeln mit den Mapping-Files für jede Workstation. Dem ADMT-Service kann ich das jeweilige Mapping-File für eine Workstation mitgeben. Der sogenannte „ReACLing“-Prozess funktioniert genauso gut oder schlecht, wie ich das von einer AD-Migration gewöhnt bin.

Je nach Einstellung des ADMT kann ich mich nach der Migration (Joining und ReACLing) mit dem „alten“ lokalen Benutzer (DLU-Novell) oder mit dem neuen AD-Benutzer an der Workstation anmelden.

Ich kann diese Vorgehensweise jedem empfehlen, der eine gewisse Erfahrung mit Migrationen hat. Es funktioniert genauso stabil, wie mit speziellen kostenpflichtigen Migrationswerkzeugen. Die meisten Störungen die auftreten können sind Werkzeug unabhängig, wie Namensauflösung und DNS-Einstellungen.