ADMT

Das „Active Directory Migration Toolkit“ ist das Universalwerkzeug von Microsoft zur Umstrukturierung von Domänen. Es unterstützt bei der Migration und Übernahme von Benutzern, Computern, Dienstkonten und Diensten, in dem es die Security Principals von einer Domäne in eine andere Domäne des gleichen oder anderen Forests migriert. Dabei werden optional SID in die SIDHistory und das Kennwort übertragen. Zudem kann ADMT Gruppen und deren Mitgliedschaften verwalten.

Sobald bei der Migration auch Exchange oder ein anderer Verzeichnisabgleich (z.B. Microsoft Identity Manager, DirX, Quest Migration Manager) zum Einsatz kommt, müssen die Prozesse aufeinander abgestimmt werden, da ADMT und das Metadirectory im schlimmsten Fall gegenseitig Daten zerstören. Es sollte daher immer sichergestellt sein, dass nur ein System eine Funktion ausübt.

ADMT kann interaktiv per GUI ausgeführt werden, um alle oder eine Teilmenge der Objekte zu migrieren oder per Skript gesteuert werden. Oft übersehen wird die Funktion, mit ADMT immer wieder die Objekte zu migrieren und damit die Zielobjekte einfach nur zu aktualisieren. Damit ist mit ADMT in Grenzen sogar eine Art „Verzeichnisabgleich“ möglich. ADMT pflegt dabei sogar Gruppenmitgliedschaften. Allerdings sind die Möglichkeiten einer Konflikterkennung und Lösung begrenzt. ADMT überschreibt die Daten im Ziel durch die Informationen aus der Quelle. Wenn also kleinere Einheiten migriert werden, dann sollten nach der Umstellung diese Objekte nicht mehr aus der Quelle in das Ziel übertragen werden.

Was kann ADMT ?

Der Leistungsumfang von ADMT ist sehr große. ADMT unterstützt bei der Migration und Umstellung folgender Objekte:

Gerade die Daten, die übernommen aber wenig hilfreich sind, sind später dann wieder gerade zu ziehen.

Achtung: Wenn Sie keine Felder ausschließen, übernimmt ADMT alle Felder, die er in das Ziel übertragen kann. Das kann störend sein, weil z.B. per ADMT migrierte User in der Exchange 2007/2010 Umgebung als "LegacyMailbox" erscheinen, die auf dem alten Server liegen. Hier hilft dann nur die manuelle Korrektur/Löschung der störendenden Felder.

ADMT speichert alle migrierten Objekte in einer Datenbank. Damit wird es möglich, z.B. zuerst die Gruppen zu migrieren und erst in einem zweiten Schritt die Benutzer und danach die Workstations. ADMT erkennt immer wieder die bereits migrierten Objekte und weist die korrekten Daten zu.

Wichtig:
Installieren Sie nur EINE Instanz von ADMT. Die Datenbank liegt auf dem PC, auf dem ADMT installiert wird und sollte während der Migration auch regelmäßig gesichert werden.

ADMT kann genutzt werden, um diese Objekte von einer Domäne zur einer anderen vertrauten Domäne zu migrieren. Wenn beide Domänen innerhalb des gleichen Forest sind, kann allerdings das Quellobjekt nicht bestehen bleiben. Um die SID-History zu übernehmen, darf es im gesamten Forest nur genau ein Objekt mit der gleichen SID geben. Nur bei der Migration in einen anderen Forest oder von einer NT4-Domäne kann das Quellobjekt bestehen bleiben.

Versionen und Kompatibilität

Microsoft hat ADMT immer weiter entwickelt, aber sie bekommen immer noch ältere Versionen herunter laden. Das mag auf den ersten Blick unlogisch erscheinen aber hat natürlich etwas mit der Evolution Es gibt verschiedene Versionen von ADMT mit unterschiedlichen Kompatibilitäten:

Version Installierbar auf Export von Active Directory Import in Active Directory Unterstützung für Installation des Agent auf Clients
ADMT 2.0 Server 2000
Server 2003		 NT4 SP4
2000
2003		 2000
2003		 Workstation: NT4SP4, 2000,XP
Server: NT4SP4, 2000,2003
ADMT 3.0 Server 2003 NT4 SP4
2000
2003		 2000
2003		 Workstation: NT4SP4, 2000,XP
Server: NT4SP4, 2000,2003
ADMT 3.1 Server 2008 2000
2003
2008		 2000
2003
2008
2008R2		 Workstation: 2000,XP,Vista, Windows 7
Server: 2000,2003,2008,2008R2
PES 3.1 Server 2000
Server 2003
Server 2008		 Any entfällt Entfällt
ADMT 3.2 Server 2008 R2 2003
2008
2008 R2		 2003
2008
2008 R2		 Workstation: XP, Vista, Windows 7
Server: 2003, 2008, 2008R2

Sie sehen also, dass die ADMT-Version parallel mit dem Server weiter entwickelt wurde, auf dem ADMT selbst installiert wird und welche Quelle nicht mehr "supported" wird. Der Password Export Server 3.1 arbeitet aber mit allen Windows Server Versionen als Quelle, zumindest wenn man von NT4 absieht.

ADMT 3.2
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=20C0DB45-DB16-4D10-99F2-539B7277CCDB
Migration Guide
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=6d710919-1ba5-41ca-b2f3-c11bcb4857af

ADMT 3.1
http://www.microsoft.com/downloads/details.aspx?FamilyID=ae279d01-7dca-413c-a9d2-b42dfb746059&displaylang=en

ADMT 3.0
http://www.microsoft.com/downloads/details.aspx?familyid=6F86937B-533A-466D-A8E8-AFF85AD3D212&displaylang=en

Active Directory Migration Tool v.2.0
http://www.microsoft.com/downloads/details.aspx?familyid=788975B1-5849-4707-9817-8C9773C25C6C&displaylang=en

Password Export Server Version 3.1 für Windows 2003/2008 x64
64bit: http://www.microsoft.com/downloads/details.aspx?familyid=5B4E5C61-1C00-4DA7-9C0D-130200AED21A&displaylang=en
32bit: http://www.microsoft.com/downloads/details.aspx?familyid=F0D03C3C-4757-40FD-8306-68079BA9C773&displaylang=en

Download und Installation

Auch wenn ADMT auf jeder Windows 2000 und Windows 2003 Server CD enthalten ist, sollten Sie die passende Version (Siehe vorheriges Kapitel) nutzen. Vor allem weil ADMT für Windows 2008 und neuer auch in einer neueren Version mit kommt. ADMT 3.x benötigt mittlerweile eine SQL-Datenbank die bei der Installation gleich abgefragt wird.

Dies ist wichtig, da so auch eine verteilte Installation möglich ist. Da ADMT Konten migriert, muss es natürlich wissen, welche alten Konten und Gruppen zu welchen neuen Konten und Gruppen passen. Wer also mehrere ADMT-Instanzen installiert, sollte immer die gleiche SQL-Datenbank verwenden.

Achtung:
SQL-Express ist nur für die lokale Nutzung geeignet. Bei der Installation mehrerer ADMT-Instanzen muss eine voll SQL-Server-Version installiert werden
Bitte installieren Sie mehrere ADMT-Instanzen mit jeweils eigenen lokalen SQL-Datenbanken nur, wenn Sie genau wissen, was sie tun.

Nach der Installation können Sie ADMT über die Verwaltung starten und sehen eine recht unspektakuläre Oberfläche. Die Assistenten zur Migration erreichen Sie, indem Sie mit der rechten Maustaste auf den obersten Eintrag klicken. Alles andere ist dann allerdings durch einen Assistenten geführt. Sie könnten ADMT aber auch komplett per VBScript steuern. Dazu gibt es ein passendes Objekt und eine Beschreibung in der Hilfe.

Ehe Sie nun aber sofort los migrieren müssen Sie noch einige Vorarbeiten leisten, die sowohl im README, der OnlineHilfe und in kurzer Form auch hier noch mal aufgeführt sind.

Ich kann hier nur raten, die Dokumentation zu ADMT ausführlich zu lesen.

Von ADMT migrierte Felder

Natürlich überträgt ADMT Felder wie den SamAccountName und einige andere für Windows wichtige Felder. ADMT versucht bis auf wenige ausgeschlossene Felder sogar alle Daten zu übertragen, sofern dies möglich und sinnvoll ist. Dies betrifft auch Felder, die es für Exchange und OCS gibt. Voraussetzung ist aber dabei, dass auch im Ziel die Schemaerweiterungen bereits vorgenommen wurden. Ansonsten werden die Felder mit einer Warnung übersprungen. Interessant ist hier immer die Warnung, wenn Felder in der Quelle stehen, die im Ziel nicht im Schema definiert sind, z.B. Exchange, OCS oder benutzerdefinierte Erweiterungen. In der ADMT Doku Version 3.1 und 3.2 steht:

The first time that you run an ADMT user migration, ADMT generates a system attribute exclusion list, which it stores in its database. The system attribute exclusion list contains two attributes by default: mail and proxyAddresses. ADMT also reads the schema in the target domain, and adds any attributes to the list that are not part of the base schema. Attributes in this list are excluded from migration operations even if the attribute is not specified in the attribute exclusion list. An administrator can change the system attribute exclusion list only by using a script. This protects attributes that are important in order for server-based applications, such as Microsoft Exchange, to work. If the target domain schema is further extended after ADMT has generated the list, administrators must manually add the new attributes to the list, unless they are certain that copying the values of these attributes from the source domain will not interfere with server-based applications.

Insofern ist es also nicht 100% vorhersehbar, welche Felder ADMT im laufe der Migration vorlässt. Wenn Sie z.B. ADMT installieren und erst danach z.B. das Schema auf Exchange 2010 anheben, dann könnte es sein, dass eine Teil der Felder noch ausgeschossen ist, weil diese bei Exchange 2007 schon da waren und andere mitkommen. Offen ist auch, wie dies bei verschiedenen Zielforests zu betrachten ist.

Mein Rat: Lesen Sie aus, welche Felder ausgeschlossen und sind und passen Sie dies auf ihre Anforderungen an.

System Felder Felder
Windows Systemfelder
  • USNCreated
  • USNChanged
  • LastMOdifu
  • distinguishedName
  • MemberOf
 Können nicht übernommen werden, da diese Systemfelder vom Ziel verwaltet werden.
Windows
  • UserSID
 Landet in SIDHistory, wenn aktiviert
Windows
  • Password
 Kann über Password Export Server übertragen werden
Windows Gruppe
  • Member
 Die den Quellmitgliedern entsprechenden Zielobjekte werden addiert, wenn diese schon migriert wurden.
Windows Standardfelder
  • Displayname
  • sn (Surname)
  • und andere
 Werden nach meiner Erfahrung 1:1 übernommen
Exchange
  • mail
  • ProxyAdresses
  • HomeMDB
  • showInAddressbook
  • HomeMTA
  • und viele mehr
 ADMT sollte diese Felder NICHT übertragen, da er nur Felder übernimmt, die in der Quelle und im Ziel im "Base-Schema sind". Anscheinend gibt es aber Fälle, in denen diese Prüfung nicht funktioniert und die Felder nicht auf der Exclude-List gelandet sind oder mangels Exchange Schema im Ziel eine Warnung ausgegeben wurde. Prüfen Sie mit einem Testkonto, ob die Felder mitkommen.
Sie sollten NICHT übertragen werden, da der Wert für HomeMTA, HomeMDB etc in der neuen Organisation nicht zutreffen.
OCS
  • msRTCSIP-PrimaryUserAddress
  • msRTCSIP-TargetHomeServer
  • msRTCSIP-OriginatorSid
  • msRTCSIP-PrimaryHomeServer
  • msRTCSIP-UserEnabled
  • msRTCSIP-UserExtension
  • msRTCSIP-FederationEnabled
  • msRTCSIP-InternetAccessEnabled
  • msRTCSIP-ArchivingEnabled
 Vergleichbar zu Exchange ist es mehrfach vorgekommen, dass wohl im Ziel noch nicht OCS/Lync installiert war schon mit ADMT gearbeitet wurde. Wurde dann OCS/Lync im Ziel installiert, dann wurden auch diese Felder übertragen.

Allerdings können Sie per VBScript ermitteln, welche Felder auf ihrer Installation ausgeschlossen sind:

REM  Script GetADMT.VBS
Set objMigration = CreateObject("ADMT.Migration")
WScript.Echo "UserPropertiesToExclude:" & objMigration.UserPropertiesToExclude 
WScript.Echo "InetOrgPersonPropertiesToExclude :"& objMigration.InetOrgPersonPropertiesToExclude 
WScript.Echo "GroupPropertiesToExclude :"& objMigration.GroupPropertiesToExclude 
WScript.Echo "ComputerPropertiesToExclude :"& objMigration.ComputerPropertiesToExclude 
WScript.Echo "SystemPropertiesToExclude:"& objMigration.SystemPropertiesToExclude

Um per VBScript die Klasse "ADMT.Migration" instanziieren zu können, müssen Sie zum einen Als Administrator arbeiten (oder User Account Control abschalten) und auf 64bit-Systemen dürfen sie nicht den 64bit CScript nutzen, sondern müssen die 32bit-Version starten (c:\windows\syswow64\cscript.exe)

Bei meinen Installationen waren diese Ausschlusslisten aber immer leer, was mich zum dem Schluss verleitet, dass ADMT gerne alles mit nimmt und grade mal das Systemfeld "SID" auslässt bzw. auf Anforderung in die SIDHistory überträgt. Auf einem Windows 2008 R2 Server mit ADMT 3.2 sind aber schon einige Felder ausgeschlossen.

mail,proxyAddresses,msDS-PSOApplied, attributeCertificateAttribute, audio, carLicense, departmentNumber, employeeNumber, employeeType, gecos,
gidNumber, homePostalAddress, houseIdentifier, ipHostNumber, jpegPhoto, labeledURI, lo
ginShell, memberUid, msDFSR-ComputerReferenceBL, msDFSR-MemberReferenceBL, msDS-Obje
ctReferenceBL, msDS-SourceObjectDN, msExchAssistantName, msExchHouseIdentifier, msEx
chLabeledURI, msRADIUS-FramedIpv6Route, msRADIUS-SavedFramedIpv6Route, msSFU30Alias
es, msSFU30Name, msSFU30NisDomain, msSFU30PosixMember, msSFU30PosixMemberOf, networkA
ddress, nisMapName, otherMailbox, photo, preferredLanguage, registeredAddress, roomNum
ber, secretary, shadowExpire, shadowFlag, shadowInactive, shadowLastChange, shadowMax,
shadowMin, shadowWarning, textEncodedORAddress, uid, uidNumber, unixHomeDirectory, uni
xUserPassword, userPKCS12, userSMIMECertificate, x500uniqueIdentifier

Um zusätzlich z.B. HomeMTA, HomeMDB und andere Felder auszuschließen, reicht dann der einmalige Aufruf der folgenden Skriptdatei.

Set objMigration = CreateObject("ADMT.Migration")
WScript.Echo " --PRE----- SystemPropertiesToExclude ---:" & vbcrlf _
   & objMigration.SystemPropertiesToExclude

objMigration.SystemPropertiesToExclude = objMigration.SystemPropertiesToExclude _
   + "HomeMDB,HomeMTA,mailnickname,showInAddressBook,msExchHomeServerName, msExch*"

WScript.Echo " --POST--- SystemPropertiesToExclude ---:" & vbcrlf _
   & objMigration.SystemPropertiesToExclude

Ein paar Felder können Sie aber auch innerhalb von ADMT auf der GUI ebenfalls während der Migration ausschließen.

Eine gute Quelle für den Einsatz von ADMT mit Skripten ist die Datei "TemplateScript.vbs", welche in das Verzeichnis C:\Windows\ADMT mit installiert wird.

Grenzen von ADMT

Es gibt sogar einige wichtige Einschränkungen im Hinblick auf Exchange:

Wie Sie sehen ist ADMT ein sehr leistungsfähiges Tool aber besonders im Hinblick auf Exchange bei weitem nicht ausreichend. Für die Migration der Postfächer können Sie mit MailMig arbeiten, aber sehr viele Informationen sind von Hand oder mit eigenen Skripten zu übernehmen.

Einen gewissen Teil der Exchange spezifischen Felder kann aber z.B.: der ADC mit übernehmen. Dies ist der Fall, wenn Sie von Exchange 5.5 nach Exchange 2000/2003 innerhalb der gleichen Organisation migrieren. Mit ADMT können Sie dann die Konten in die neue Domäne übernehmen und ADC übernimmt die Exchange Eigenschaften und Verteiler.

SID und SID History

Sie haben nun schon mehrfach den Begriff der SID und der SID-History gelesen. Was hat es damit auf sich und warum ist das wichtig ?. Sie nutzen zwar einen Anmeldenamen und das dazu gehörige Kennwort, um sich anzumelden, aber für die verschiedenen Dienste des Netzwerks sind diese Daten nur sekundär. Intern arbeiten Computer mit Nummern oder Kennungen und so kommt es, dass jedes Objekt mit Berechtigungen eine eindeutige Kennnummer, die SID (Security IDentifier) hat. Alle Berechtigungen, z.B.: Auf Postfächer, Freigaben,  Dateien und Ordner werden immer anhand dieser Nummer zugewiesen. Daher ist es auch kein Problem, einen Benutzer umzubenennen etc. Die Rechte bleiben erhalten.

Eine SID funktioniert natürlich nur dann, wenn diese eindeutig und einmalig ist. Daher besteht die SID aus einem domänenabhängigen Teil und einem relativen Teil. Der relative Teil ist beim Administrator immer eine -500. Auch andere besondere Gruppen und Objekte wie Gäste, LocalSystem etc. haben fest vorgegebene SIDs. Normaler Anwender starten mit einer 1000 und werden hoch nummeriert.

Wird nun ein Benutzer von einer Domäne zu einer andere Domäne migriert, so kann er seine SID nicht mitnehmen, da der erste Teil die Nummer der Domäne selbst ist. Wird ein Benutzer daher migriert, so wird immer ein neues Konto mit einer neuen eindeutigen SID am Ziel angelegt. Dieses neue Konto hat dann natürlich erst einmal nicht mehr die gleichen Berechtigungen wie das alte Konto, selbst wenn es gleich heißt und das gleiche Kennwort hat. Natürlich kann das neue Konto nun auch in die bisherigen Gruppen aufgenommen werden und erhält damit einen Großteil der Berechtigungen. Es ist aber für die alten Server nicht das gleiche Konto.

Seit Windows 2000 gibt es nun die Möglichkeit, die bisherige SID eines Kontos einem neuen Konto "zusätzlich" zu geben. Über die SID-History ist es damit möglich, dass ein migriertes Konto neben seiner neuen primären SID auch die früheren SIDs weiter erhält. Beim Zugriff auf eine Ressource werden dem Server alle SIDs (dazu gehören auch die SIDs der Gruppen, in denen der Benutzer Mitglied ist) präsentiert. Er kann also gar nicht unterscheiden, das der neue Benutzer ein "anderer" Benutzer ist. So ist es dem Anwender auch nach der Migration möglich, alle Dienste zu nutzen, die das alte Konto nutzen konnte.

ADMT nutzt für den Export der SID immer den PDC-Emulator der Quelldomäne, auch wenn Sie im ADMT einen anderen DC als Quelle eintragen.

Grenzen der SIDHistory

Damit diese Funktion möglich ist, muss zumindest die alte Domäne der neuen Domäne vertrauen. Sobald solch ein Trust eingerichtet ist, besteht natürlich auch ein Risiko des Missbrauchs. So könnte der Administrator der Zieldomäne bei seinem Konto in die SID-History eines wichtigen Accounts in der Quelldomäne zuweisen und dann so arbeiten, als wäre er dieser Anwender. Damit dies nicht passiert, kennt Windows 2000 eine Funktion namens "SID Filterung". Damit können Sie steuern, welche SIDs der SID-History über einen Trust überhaupt genutzt werden können. Bei einer Migration mittels ADMT müssen Sie daher eventuell an dieser Stelle noch drehen-

Netdom TRUST <TrustingDomain> /domain:<TrustedDomain> /quarantine:No /userD:<domainadminAcct> /passwordD:<domainadminpwd>

Aber auch denn die SIDHistory mit übertragen wird, sind ein paar Fallstricke zu beachten. Das folgende Beispiel soll das etwas verdeutlichen:

Wir haben zwei Domains ALT und NEU, die per Trust verbunden sind und die Benutzer aus ALT sollten mit ADMT nach NEU migriert werden. Um die Sache etwas zu erschweren, gibt die Benutzer aus ALT schon in NEU. Weil es früher vielleicht keinen Trust gab, wurden also während der Koexistenzphase alle Benutzer doppelt gepflegt. Es kann also sein, dass z.B. das Konto NEU\USER1 natürlich in der Gruppe NEU\DomainUser ist und diese Gruppe vielleicht in einer andere Gruppe (häufig TerminalServerUser) aufgenommen ist. NEU\USER1 kann sich also auf NEU\TSServer anmelden.

Nun wird der Benutzer ALT\User1 nach NEU\User1 migriert. Dabei wird durch ADMT das Konto "gemachted", das Kennwort übertragen und die SID von ALT\User1 in die SIDHistory bei NEU\User1 kopiert. Damit das nun "rund" wird, müssen natürlich auch auch aus ALT die Gruppen samt der SID der Gruppe als SIDHistory in die Zielgruppe übertragen werden. Da in dem Schritt auch die Mitglieder gepflegt werden sollten, hat dann der Benutzer NEU\User1 nicht nur seine neue SID und die SIDs der neuen Gruppen, in denen er in NEU drin ist, sondern auch die SIDHistory seines alten Kontos und über die neuen Gruppen auch die SID-History der alten Gruppen.

Achtung: BuildIn Accounts und Gruppen
ADMT kann keine "eingebauten" Gruppen und Benutzer übertragen. Administrator aber auch Administratoren, Domänenbenutzer etc. bleiben bei der Migration außen vor. Sicher war es schon immer eine schlechte Idee, diese Gruppen für die weitere Vergabe von Berechtigungen zu nehmen, aber hier müssen Sie dann manuell Hand anlegen.

Gerade die Besonderheit mit der BuildIn-Gruppe "Domänen-Benutzer" führt oft zu Problemen, die sich aber vermeiden ließen:

Daher ist es ungeschickt Rechte an Buildin Gruppen fest zu machen.

ADMT und Kennworte

ADMT V2.0 kann mittlerweile auch Kennworte migrieren. Allerdings ist es damit erforderlich, dass auf einem DC der Quelldomäne eine DLL (PWDMIG) installiert wird und einige Einträge in der Registrierung getätigt werden.

Allerdings ist darauf zu achten, dass ADMT auch wirklich die Kennworte schreiben kann. Oft ist in der Zieldomäne eine Richtlinie aktiv, die komplexe Kennworte erfordert. Das betrifft auch ADMT.

Aber selbst wenn ADMT die Kennworte migrieren kann, dann wird der Windows 2003 Active Directory Controller den Benutzer auffordern, das Kennwort bei der ersten Anmeldung zu ändern.

Um diese Flag zu löschen, gibt es nun mehrere Möglichkeiten:

set cont = GetObject("WinNT://msxfaq.local")
cont.filter = Array("user")

for each oUsr in cont
  oUsr.Put "passwordExpired", CLng(0)
  oUsr.SetInfo
next

import-module ActiveDirectory
get-ADUser | Set-ADUser -ChangePasswordAtLogon $false

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\System\Curr­entControlSet\Control\Lsa]
SamRestrictOwfPasswordChange=dword=0,1 oder 2

0 - old behavior, client can change password through OWF password change API, and the new password remains unexpired.

1 - .NET Server default behavior, client can change password through OWF password change API (SamrChangePasswordUser), but the password expires immediately.

2 - more secure behavior, client can''t use OWF password change API. This API (SamrChangePasswordUser) will be totally disabled and return STATUS_ACCESS_DENIED for all clients except for LocalSystem and members of builtin administrators group.

Mit ADModify 1.5 können Sie leider nicht diese Einstellungen durchführen.

ADMT und "Matchen"

Sehr oft finden sich Konfigurationen, bei denen ein Benutzer sowohl in der Quelle als auch in der Zieldomäne schon ein Konto haben. Natürlich ist das nicht "schön" und über Trusts kann das sogar vermieden werden. Aber wenn diese Fall existiert, dann haben wir natürlich ein Interesse daran, dass es ein zusammengeführtes Konto gibt, welches alle Rechte in sich vereint. Und das kann ADMT sogar. Leider habe ich keine Quellen, die die genauen Arbeitsweisen beschreiben aber bislang konnte ich folgendes erkennen

Sobald ADMT den Benutzer matched, dann legt es im Ziel kein neues Konto an, sondern nutzt das bestehende Zielkonto und ergänzt es um die Daten der Quelle, d.h. auch die SIDHistory und Kennwort können dann an das vorhandene Zielkonto angewendet werden. Über eine Steuerdatei ist es sogar möglich, auch Konten mit unterschiedlichem Namen in Ziel und Quelle zusammen zu führen.

Bereits gematchte Konten werden in der ADMT-Datenbank hinterlegt, so dass diese Informationen später bei der Migration der Profile, Computer, ACLs herangezogen werden können.

ADMT als Dirsync

ADMT ist sicher kein ideales Werkzeug zum Verzeichnisabgleich und zum Verbinden von Organisationen. Aber ADMT kann Benutzer und Gruppen nicht nur einmalig übertragen sondern auch immer und immer wieder aktualisieren. Da ADMT auch per Kommandozeile als auch als COM-Objekt ("ADMT.Migration") per VBScript steuerbar ist, können Sie damit z.B. Benutzer in zwei Forests unidirektional additiv abgleichen.

Unabhängig von diesen beiden Beschränkungen werden aber z.B. Kennwort natürlich übertragen, also eine Art Synchronisation, wenn gleich sicher mit größerem Verzug und sie können die Mitgliedschaft von Gruppen und Verteilern damit abgleichen lassen.

ADMT Best Practice

Es gibt massenhaft gute Dokumentationen zu ADMT. Zuallererst natürlich das README im Installationsverzeichnis und nach der Installation von ADMT auch die Online Hilfe. Trotzdem kann natürlich die Funktionsvielfalt des ADMT im ersten Moment für Verwirrung sorgen. Daher hier die einzelnen Schritte in der logischen Reihenfolge. Zuerst müssen Sie mal die Randbedingungen schaffen:

Ihr Migrationsplan könnte daher wie folgt aussehen:

Diese Beschreibung nimmt aktuell keine Rücksicht auf eine Migration über einen längeren Zeitraum oder sogar eine Migration nach Abteilungen. Solche komplexeren Umstellungen bedürfen einiges an Erfahrung und eine genaue Analyse der Quelle. Wenn Sie migrieren möchten, aber eine 0 auf 100 Migration vermutlich nicht durchführbar ist, dann sprechen Sie mich bitte an.

Die eigentliche Migration mit ADMT ist letztlich einfach, wenn Sie eine Reihenfolge einhalten. Folgender Ablauf hat sich in der Praxis bewährt aber soll nicht als "einzig richtig" verstanden werden. Abweichungen sind im Einzelfall durchaus möglich, da ADMT auch erneut migrieren kann, d.h. nachträgliche Änderungen mit Einschränkungen in der Quelle in das Ziel einpflegen kann.

Am besten einen Zeitpunkt "X" definieren, ab dem die Quelle nicht mehr verändert wird und alle Gruppen und Benutzer migriert werden. Die Quellkonten sollten gleich deaktiviert werden und alle PCs müssen eingeschaltet sein, um diese ebenfalls zu migrieren. Die Migration einzelner Benutzer oder Abteilungen oder die Streckung über mehrere Tage und Wochen ist genau zu überlegen. Dieser Parallelbetrieb ist unter Umständen sehr viel komplexer als eine schnelle Migration mit einer Nachbearbeitung der offenen Probleme.

"Der Fehler ist erst seit der Migration". Mit dieser Aussage werden Sie immer konfrontiert werden, auch wenn viele Probleme nicht auf die Migration zurückzuführen sind. Aber allein dies zu belegen schürt eher den Konflikt und Zwist. Allerdings können Sie viele Aktionen einfach vor der Migration durchführen, z.B. ein Aufräumen der Domäne, die Umbenennung von Konten etc. Das entspannt später den Druck.

Nun sollten all ihre Mitgliedsserver, Workstations, Benutzer und Gruppen umgezogen worden sein. Das ist aber nicht alles.

ADMT und Exchange

Aber auch bezüglich Exchange kann ADMT einige Aufgaben erledigen. ADMT kann aber keiner Postfächer migrieren. Dies ist eher eine Aufgabe von MailMig. ADMT kann für folgende Aufgaben genutzt werden:

Die Leistung von ADMT auch Exchange Felder wie HomeMDB und HomeMTA etc. zu übertragen, kann auch störend sein. Per VBScript lässt sich sehr einfach bestimmen, welche Felder ADMT ausschließen soll. (Beschreibung weiter unten)

ADMT und Sharepoint

Leider kann ADMT hier nicht wirklich "helfen", da Sharepoint zwar auch die Windows Anmeldeinformationen nutzt, aber intern eine eine Struktur verwaltet und nur auf die Active Directory Konten verweist. Wird also ein Anmeldekonto von einer Domäne in eine andere Domäne verschoben, migriert oder neu angelegt, dann müssen Sie in Sharepoint die Benutzerzuordnung zurecht rücken. Dazu gibt es eine Kommandozeile "STSADMIN", die gut dokumentiert und gebloggt ist:

ADMT, SAMBA und DumpSID

Man könnte nun auf den Gedanken kommen, mit ADMT auch einfach die Benutzer einer SAMBA-Domäne zu migrieren. Viele Domänen basieren aber auf einer mehr oder weniger alten Version von SAMBA. SAMBA macht einen sehr guten Job ein UNIX-System für Windows Clients wie ein Windows Server aussehen zu lassen. Und SAMBA kann sogar als Domain Controller einen NT4 PDC emulieren. Allerdings kann erst Samba 3 einen zweiten SAMBA Server als BDC betreiben (Ausfallsicherheit). Das liegt nahe, da andere Migrationswege mit SAMBA verbaut sind

Damit ist es nicht möglich, z.B. einen Windows NT4 als BDC zu installieren und dann zum PDC hoch zu stufen. Dann könnte man ja die Benutzer wieder mit ADMT migrieren oder direkt ein Inplace Update auf Windows 2000/2003 machen. Das geht nicht. 

Allerdings kann man in ADMT eine Textdatei bei der Nutzung des "Security Migration Wizard" angeben, in der die alte SID der Quelldomäne auf ein neues Domänenkonto gemappt ist. Alles was hierzu fehlt ist eben diese Liste

Einsatzbereich:
DumpSID hilft ihnen nur, wenn sie mittels ADMT die User, Computer und Gruppen in das Active Directory migrieren (ohne SID History, ohne Passwort, da das Samba als Quelle nicht kann) und dann mit ADMT „danach“ die ACLs im Zielsystem konvertieren wollen.

Ich sende Ihnen DumpSID gerne zu, wenn Sie mit ADMT migrieren wollen und eine Konvertierung der SIDs benötigen. Informationen, warum diese Skripte nicht öffentlich sind, finden Sie auf nicht public.
Ein ähnliches Skript liest aus einem Active Directory die SIDHistory aus und generiert eine entsprechende Datei. Dies ist ideal, wenn Sie früher einmal mit SIDHistory migriert und dann die ADMT verloren/deinstalliert haben. Mit dieser Datei können Sie auch nachträglich noch einmal ADMT installieren und Berechtigungen umschreiben.

Die Migration von Samba ist auch vom SAMBA-Team ein Stück weit beschrieben (Siehe http://samba.org/samba/docs/man/Samba-Guide/upgrades.html#id364040). Allerdings sind nicht alle Aussagen richtig. Aus einer eigenen Migration kann ich sagen:

Auch wenn ADMT eigentlich nicht für SAMBA gedacht ist und in der TechNet und Knowledgebase SAMBA nicht in diesem Zusammenhang erwähnt wird, so kann man doch auch hier mit ADMT relativ einfach die Objekte und Computer migrieren. Allerdings funktionieren die "How-To's" der Windows Anleitung natürlich nicht mehr.

Unterstützung durch Net at Work:
Profitieren Sie von unserer Erfahrung im Windows Umfeld und beim Einsatz von ADMT.

ADMT und Filer, NAS, NetApp und andere

Kommen wir noch zu einer anderen Gruppe von Servern im LAN, die für die Migration von Domänen interessant sind. Maßgeblich sind das Server die SMB anbieten aber nicht unter Windows laufen und damit z.B. nicht den ADMT-Agent starten können, welcher lokal alte SIDs durch neue SIDs ersetzt oder erweitert.

So ein Server ist, abgesehen von lokalen Tools" eigentlich nur über das Netzwerk zu erreichen und zu verwalten. Lokal werden meist gerade mal die "Freigaben" eingerichtet aber weniger im Dateisystem herum gearbeitet. Entsprechend gibt es drei Aufgaben zu bewältigen

Die beiden ersten Punkte sind bei einer Migration relativ gefahrlos sogar zu testen, wenn Sie keine Stichtagsmigration vorhaben. Sie können nämlich einfach eine neue "Testfreigabe" mit ein paar Dateien, Verzeichnissen, Quotas und Berechtigungen anlegen anlegen und dann die per ADMT erst mal ins Ziel kopierten Benutzer mit den von ihnen vorgesehenen Werkzeugen auf dem NAS-System anpassen.

Wenn Sie die Anwender samt "SIDHistory" kopieren, dann können Sie mit dem neuen Konto einfach prüfen, ob sie weiter auf alle Daten zugreifen können. Denn eigentlich sollte jeder SMB-Server bei einem Zugriff des Clients zwischen primärer SID, SIDs von Gruppenmitgliedschaften oder SIDs der SIDHistory unterschieden.

Aber irgendwann wollen Sie vielleicht die SIDHistory-Altlast entfernen oder Sie können damit nicht arbeiten, so dass der Wunsch einer ACL-Korrektur aufkommt. Hier gibt es wieder zwei Optionen:

Aber egal wie sie die Umstellung letztlich angehen, so werden Sie immer zuerst Benutzer und Gruppen schon mal migrieren müssen, damit die neuen SIDs im Ziel existieren. Und erst nachdem sich die Anwender sich wirklich mit dem neuen Konto auch anmelden, können die überhaupt daran gehen, die alten SIDs zu entfernen oder ersetzen. Wenn Sie also keine Stichtagsumstellung erreichen, dann sollten Sie die SIDHistory an dem Zielkonto mit addieren und erst nach der Umstellung der ACLs auf allen Ressourcen auf den Ressourcen und dann auf den Objekten entfernen.

Bild Beschreibung

Ausgangssituation

Wir haben eine alte Domäne mit Benutzern, Gruppen und einem SMB-Server mit Freigaben und ACLs

Diese sollen nun alle in die neue Domäne

Migration der Benutzer und Gruppen mit SID-History

Durch die SID-History kann der Anwender auch nach der Anmeldung im Ziel weiterhin auf seine Dateien in der Quelle zugreifen.

In dem Zug sollten Sie auch die Workstations und die Profile auf den PCs vielleicht in die neue Domäne migrieren. (nicht dargestellt)

Umstellung der ACLs auf den Ressourcen

Wenn alle Anwender sich nur noch im Ziel anmelden, dann können Sie bei den Ressourcen die alte SID durch die neue SID ersetzen. Wer vorsichtiger ist, addiert die neue SID und hebt sich das Löschen der alten SID für später auf.

Hinweis: Für diverse Tools die "Alt gegen Neu" ersetzen, muss der ausführende Client noch in der alten Umgebung sein, damit er auch den alten User "findet". In der neuen Umgebung verweist ansonsten die SIDHistory schon auf das neue Konto.

Aufräumen

Wenn nun alles umgestellt ist, dann darf die alte Domäne abgebaut werden. Und wenn Sie sicher alle alten Vorkommen der SIDs nicht mehr benötigen, dann können Sie auch die SIDHistory bei den Anwendern und Ressourcen entfernen.

Für die Umstellung der ACLs gibt es gleich mehrere Möglichkeiten, die alle ihre individuellen Vorteile/Nachteile haben. Wer hoffentlich schon in der Quelle überwiegend mit Gruppen zur Vergabe von Berechtigungen gearbeitet hat, sollte nicht all zu viele ACLs zu konvertieren haben.

Methode Bewertung und Links
ADMT Agent

ADMT bringt selbst einen Agenten mit, welcher vom ADMT-System aus auf alle anderen Server und Clients verteilt werden kann. Dieser "kennt" die alten und neuen Konten und kann die ACLs entsprechend umstellen.

Vorteil: Einfach und enthalten, GUI-Gestützt

Nachteil: Nur für Windows Systeme einsetzbar
SUBINACL
ICACLS

Diese Kommandzeilentools erlauben die Ersetzung von Berechtigungen "Alt gegen Neu". Sie sind sehr flexibel und erlauben nahezu jede Ersetzung. Da sie zum Teil auch über LAN mit UNC-Pfaden arbeiten, können Sie damit sogar Rechte auf dem ein oder anderen NAS-System ersetzen.

REM Ersetzen der alten Rechte durch neue
subinacl /subdirectories X:\* /migratetodomain=SOURCEDOM=TARGETDOM

subinacl /subdirectories X:\* /migratetodomain=SOURCEDOM=TARGETDOM


REM Rechte ausgeben
subinacl /subdirectories \\sharesfiler\adm$ /display

ICACLS Y:/ /substitue <SIDOld> <SIDNew>

Einige Tools haben vielleicht mit UNC-Pfaden Probleme. Oft hilft dann einfach das Verbinden eines Laufwerksbuchstaben und optional noch ein SUBST. Hinweise findet man besonders wenn man für Migrationen mit NetApp sucht
3rd Party

Gerade wenn sie ein NAS-System haben und die SMB-Inplementierung nicht komplett ist, können Sie oft nur darauf vertrauen, dass der Hersteller eigene Tools bereit stellt. Es gibt von Herstellern auch Tools, die z.B. schneller arbeiten oder Besonderheiten des NAS-Systems berücksichtigen.

Im Bezug auf das Dateisystem gebührt dem "Owner" eine gesonderte Betrachtung, da dieser auch Rechte ändern kann und einige Produkte dieses Recht auch für Backup/Restore oder Quotas heran ziehen. Spätestens wenn sich auch der Anwender mit dem neuen Konto anmeldet, sollten ihm seine Dateien auch weiter gehören.

Was sie noch bedenken sollten ...

Aber selbst wenn die Migration mit ADMT alles wie gewünscht umgestellt hat, so bleiben einige Dinge zu tun, die Sie auf anderem Weg lösen müssen. Hier eine Auswahl:

Einige dieser nach geschalteten Probleme könnten Sie natürlich durch eine entsprechende Vorbereitung reduzieren. Allerdings ist hierbei auch wieder Aufwand und Nutzen abzuwägen. Alle Unwägbarkeiten können Sie nicht erkennen und letztlich ist jede Migration individuell. Wenn Sie daher umfangreichere Migrationen planen, sollten Sie vielleicht die Hinzuziehung externer Dienstleister bedenken.

Weitere Links

Keywords:ADMT Migration MasterAccountSID