Die Unternehmen entwickeln sich und ihre Produkte weiter. Stetig müssen sich die Firmen an die Marktansprüche und an die Kundenwünsche anpassen, um ihr Business zu betreiben. So wie sich die Unternehmen an die Marktansprüche anpassen müssen, so muss sich auch die IT innerhalb eines Unternehmens anpassen, um den wirtschaftlichen Interessen des Unternehmens auch aus der IT-Sicht gerecht zu werden.
Die Firmen die bereits schon seit längerem eine Active Directory-Umgebung betreiben, denken vielleicht darüber nach ihre Gesamtstruktur zu verändern. Ihre schon in die Jahre gekommene Struktur spiegelt evtl. die heutigen Ansprüche des Unternehmens nicht wieder. Für die damalige Zeit war das gewählte Multidomänenmodell vielleicht notwendig und das richtige Domänenmodell. Aber heute ist das damals gewählte Domänendesign in die Jahre gekommen und genügt evtl. weder den heutigen Ansprüchen, noch ist es zeitgerecht.
Es kann viele Gründe dafür geben, warum eine Umstrukturierung der Gesamtstruktur sinnvoll wäre. Ein weiterer Grund für das Re-Design der Umgebung wäre z.B. der Domänenname. Eine Migration in eine neue Gesamtstruktur ist in vielen Umgebungen sinnvoller, als den Domänennamen zu ändern. Oder wenn Firmen fusionieren und die eine Firma in die andere migriert werden soll.
Ist erst mal die Entscheidung getroffen den Schritt einer Umstrukturierung zu gehen, sei es innerhalb einer Gesamtstruktur (Intra-Forest) oder in eine neue Gesamtstruktur zu migrieren (Inter-Forest, zwischen zwei Gesamtstrukturen), so gilt es als einer der nächsten Schritte das richtige Migrationswerkzeug zu wählen.
Auf der Suche im Internet nach einem Migrationstool stößt man recht schnell auf das kostenlose Werkzeug von Microsoft. Das Tool nennt sich Active Directory Migration Tool - ADMT. Aber neben dem ADMT stolpert man unter anderem über das kommerzielle Werkzeug aus dem Hause Quest. Der Quest Migration Manager for Active Directory (kurz QMMAD) ist das Pendant zu ADMT und kann einiges mehr als das wohlgemerkt kostenlose Tool von Microsoft. Aber neben Quest wäre noch das Migrationswerkzeug von NetIQ zu erwähnen (was hier jedoch nicht berücksichtigt wird).
Migrationsmöglichkeiten
Eine Domänenmigration kann auf verschiedene Wege mit verschiedenen Werkzeugen erfolgen. Viele Unternehmen nehmen eine Domänenmigration auch zum Anlass, ihre Daten neu zu organisieren. Denn durch die Jahre entstand auf manchen Fileservern evtl. diverser Daten-Wildwuchs, den es neu zu strukturieren gilt. Die Migration muss natürlich ohne größere Auswirkungen auf die produktiven Einheiten und möglichst unauffällig verlaufen.
1. Die Migration mit Hilfe von Skripten
Einige Unternehmen migrieren ihre Benutzer-, Gruppen- sowie Computerkonten mit ADMT in die neue Domäne. Die File- bzw. Ressourcenserver fügen sie händisch der Ziel-Domäne hinzu und führen anschließend das sogenannte Re-ACLing (=Rechte neu setzen) ihrer Netzwerkressourcen (Dateien, Drucker etc.), mit Skripten durch. Dabei kommt oft ein Computer-Startupskript zum Einsatz.
2. Die Migration mit der SIDHistory
Je nach Größe bzw. Dauer der Migration ist es evtl. notwendig, dass die bereits migrierten Benutzer noch auf die Ressourcen in der Quell-Domäne zugreifen können. Damit während der Migrationsphase die bereits migrierten Benutzer, sei es bei einer Intra- oder Inter-Forest Migration, weiterhin Zugriff auf die Ressourcen der alten Domäne haben, wäre einer der gängigsten Varianten die während einer Migration zum Einsatz kommen, die Migration mit der SIDHistory. Dadurch kann das neue Benutzerkonto aus der neuen Domäne, auf die Ressourcen der alten Domäne zugreifen. Das Attribut SIDHistory ist ein mehrwertiges Attribut in dem eine Liste der SIDs, die zuvor einem Benutzer oder einer Gruppe zugewiesen wurden, eingetragen wird.
Mit den entsprechenden Migrationswerkzeugen, wie z.B. den im weiteren Verlauf vorgestellten Tools, können die Benutzer- und Gruppenkonten mit ihrer SID migriert werden. Dabei wird ein neues Sicherheitsprinzipal (Benutzer- oder Gruppenkonto) in der neuen Domäne erstellt und die SID des alten Sicherheitsprinzipals an das neue Konto der neuen Domäne im Attribut SIDHistory hinzugefügt. Dadurch wäre das neue Benutzerkonto in der Lage, die alte SID als "Ausweis" vorzuzeigen, wenn die neue SID des Benutzerkontos keinen Zugriff bekommt. Möchte also das "neue" Benutzerkonto aus der neuen Domäne, auf die Ressourcen der "alten" Domäne zugreifen, tritt hier die SIDHistory in Aktion.
Wird ein Benutzer von einer Domäne in eine andere migriert, so wird seine SID nicht mit übernommen, denn der mittlere Part der SID ist die Nummer der Domäne. Bei der Benutzer-Migration mit den herkömmlichen Migrationswerkzeugen wird jedesmal ein neues Benutzerkonto mit einer neuen SID in der Ziel-Domäne eingerichtet. Da das neue Benutzerkonto eine neue SID bekommen hat, bekommt das Konto nicht die gleichen Berechtigungen wie es das alte Benutzerkonto hatte, auch wenn der Benutzername gleich lautet. Denn bekanntlich sind Namen in der IT "Schall und Rauch". Dank der SIDHistory aber, müssen die Berechtigungen in der alten Domäne nicht gleich angepasst werden, denn dadurch hat das neue Benutzerkonto Zugriff auf die Ressourcen der alten Domäne.
Die SIDHistory funktioniert sogar wenn die alte Domäne nicht mehr existiert! Wenn die Verbindung zur alten Domäne aufgelöst wurde (Domäne wurde entfernt oder die Verbindung ist getrennt), werden die Berechtigungseinträge auf den Ressourcen nicht mehr im Klartext als Namen angezeigt, sondern es erscheint die SID (S-1-5-21-…). Die Berechtigungen funktionieren aber wie bereits erwähnt weiterhin. Dafür erschwert sich aber die Administration, da man nicht mehr so einfach beurteilen kann, um welches Konto es sich dabei handelt. Wie denn auch, wenn niemand mehr weiß wie die Konten hießen.
Wenn die Migration abgeschlossen ist, wäre es ohnehin empfehlenswert die SIDHistory zu bereinigen. Nach dem bereinigen der SIDHistory kann der Benutzer lediglich mit der "neuen" SID auf die Ressourcen zugreifen. Die ACL-Umsetzung sollte natürlich zu diesem Zeitpunkt bereits abgeschlossen sein.
Denn wenn sich nämlich ein Benutzer anmeldet, bekommt er ein Access-Token in dem seine richtige SID, die SIDs der SIDHistory (samt der SIDHistory aller Gruppen) und die SID's aller Gruppen, denen der Benutzer angehört (direkt oder verschachtelt), enthalten ist. Das Access-Token kann aber max. 1024 Einträge enthalten und von daher, sollte nach einer Migration die SIDHistory stets bereinigt werden. Ansonsten könnte es bei zukünftigen Migrationen zu Problemen kommen.
Zum entfernen der SIDHistory kann dazu das folgende VBSkript verwendet werden.
How To Use Visual Basic Script to Clear SidHistory
Leider ist die Handhabung mit dem Skript eher umständlich, denn die Objekte bei denen die SIDHistory entfernt werden soll, müssen einzeln angegeben werden. Aber mit etwas Skriptingkenntnisse lässt sich das Skript an die eigenen Bedürfnisse anpassen. Alternativ lässt sich die SIDHistory auch mit ADModify entfernen.
3. Die Migration mit Dual-ACL
Neben der Variante mit der SIDHistory, kommt als weitere gängige Migrationsvariante Dual-ACL häufig zum Einsatz. Auch hierbei können während der Migrationsphase die bereits migrierten Benutzer, sei es bei einer Intra- oder Inter-Forest Migration, weiterhin auf die Ressourcen der alten Domäne zugreifen. Dadurch kann das neue Benutzerkonto aus der neuen Domäne, auf die Ressourcen der alten Domäne zugreifen.
Die in diesem Artikel erwähnten Migrationstools können auch die vorhandenen Berechtigungen auf Clients oder Servern bearbeiten. Die bereits migrierten „neuen“ Benutzer- und Gruppenkonten können zusätzlich zu den vorhandenen Berechtigungen eingetragen werden (Dual ACL) oder die alten Berechtigungen auf den Ressourcen ersetzen. Mit ADMT kann das der Assistent zur Computermigration durchführen, während im QMMAD das Ressource Updating dafür zuständig ist.
Weitere hilfreiche Tools für die Migration
Je nachdem welche Migrationsstrategie und welches Migrationswerkzeug man gewählt hat, können im Nachhinein die Tools wie SUBINACL oder SIDWALK dabei helfen, die Berechtigungen zu bereinigen. Auch das ADModify kann bei Massenänderungen, die bei einer Migration notwendig sein könnten, hilfreich sein.
Die SID-Filterung bei der Inter-Forest Migration
Die SID-Filterung ist dazu gedacht, die Benutzer an der Nutzung der im Attribut SIDHistory eingetragenen SIDs daran zu hindern, um auf Ressourcen einer separaten Gesamtstruktur zuzugreifen. Die SID-Filterung zu deaktivieren stellt aber ein gewisses Sicherheitsrisiko dar, denn ein Angreifer mit Administratorrechten könnte administrative SIDs in der vertrauenden Gesamtstruktur dem Attribut SIDHistory eines Sicherheitsprinzipals in der vertrauten Gesamtstruktur hinzufügen. Damit ist es dem Konto möglich, administrativen Zugriff auf die vertraute Gesamtstruktur zu erlangen.
Mit der SID-Filterung kann die Verwendung des Attributs SIDHistory in der gesamten Gesamtstrukturvertrauensstellung bzw. externen Vertrauensstellung blockiert werden. Wenn aber das neue Benutzerkonto auf die Ressourcen der alten Domäne zugreifen möchte, muss bei einer Inter-Forest Migration die SID-Filterung ausgeschaltet sein. Die SID-Filterung sollte aber nur für einen begrenzten Zeitraum deaktiviert werden.
Die SID-Filterung lässt sich mit NETDOM, welches sich in den Windows Support Tools befindet, deaktivieren. Der Befehl lautet wie folgt:
Netdom Trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /userD:Domänen-Administrator /passwordD:Domänen-Admin-Kennwort
Disable SID filter quarantining
Es wäre auch möglich, die auf die Gesamtstrukturvertrauensstellung angewendete Standard-SID-Filterung mit der Option /enablesidhistory:yes abzuschwächen.
Der genaue Befehl lautet folgendermaßen:
Netdom Trust TrustingDomainName /domain:TrustedDomainName /enablesidhistory:Yes /usero:Domänenadministratorkonto /passwordo:Domänenadministratorkennwort
Was sind die Voraussetzungen für eine Migration mit ADMT oder dem QMMAD?
- Natürlich muss zuerst auf IP-Ebene das Routing zwischen der Quell- und Ziel-Domäne funktionieren.
- Als nächstes muss die Namensauflösung zwischen der Quell- und Ziel-Domäne sichergestellt sein. Dazu könnte man im DNS entweder eine sekundäre Zone der jeweils anderen Domäne einrichten oder ab Windows Server 2003 eine bedingte Weiterleitung einrichten. Neben der DNS-Namensauflösung könnte man zusätzlich noch die NetBIOS-Namensauflösung z.B. durch eine WINS-Replikation sicherstellen.
- Idealerweise sollte eine (einseitige oder bidirektionale) Vertrauensstellung zwischen der Quell- sowie Ziel-Domäne existieren.
- Die Ziel-Domäne muss sich sowohl bei einer Intra-Forest als auch Inter-Forest Migration im einheitlichen Modus befinden. Der Grund dafür ist, da das Attribut SIDHistory in Benutzer- sowie Gruppenkonten nur im einheitlichen Modus verfügbar ist. Nur wenn sich die Ziel-Domäne im Domänenfunktionsmodus „Windows 2000 pur“, „Windows Server 2003“ oder „Windows Server 2008“ befindet, kann die SIDHistory mit Werten gefüllt werden. Wobei eine Inter-Forest Migration auch ohne die SIDHistory stattfinden kann, jedoch stellt die SIDHistory eine Art doppelter Boden dar. Denn die Migration an sich ist kompliziert und aufwändig genug, wenn man da nicht an jede Berechtigung denkt erhöht sich der administrative Aufwand im nachhinein unnötig.
Die Migration mit dem Active Directory Migration Tool - ADMT
Das ADMT existiert in der Version 2.0, 3.0 sowie 3.1. Die Installation des ADMT v2.0 kann auf Windows 2000 Server oder Windows Server 2003 erfolgen. Wobei das ADMT v3.0 nur auf Windows Server 2003 und die ADMT v3.1 nur auf Windows Server 2008 (aber nicht auf einem RODC oder Server Core) installiert werden kann.
Während der Installation von ADMT wird auch die Microsoft SQL Server Desktop Engine (MSDE) mit installiert. Das Tool kann aber so konfiguriert werden, dass es entweder die MSDE oder einen bereits bestehenden SQL-Server verwendet. Das ADMT besteht aus einer Reihe von Assistenten, die für die Migration der Objekte verwendet werden können.
Nach der Installation steht das Tool als MMC unter Start-Programme-Verwaltung-Active Directory Migration Tool zur Verfügung.
Das Benutzerkonto mit dem das ADMT ausgeführt wird, sollte Administratorrechte in der Quell-sowie Ziel-Domäne haben. Es muss bei der Migration der Computerkonten ein Agent auf den Clients installiert werden und das funktioniert natürlich nur, wenn das Konto lokale Adminrechte hat.
Das ADMT kann für eine Intra-Forest (innerhalb der Gesamtstruktur) oder Inter-Forest (zwischen zwei Gesamtstrukturen) Migration eingesetzt werden. Das Werkzeug kann über die grafische Oberfläche oder als Kommandozeilentool eingesetzt werden. Es stellt auch eine Skriptingschnittstelle bereit.
Bevor es an die produktive Migration mit ADMT geht, gilt es unbedingt vorher das Whitepaper zum Tool zu lesen und idealerweise eine Testmigration in einer Testumgebung durchzuführen.
Active Directory Migration Tool v.2.0
Active Directory Migration Tool v3.0
ADMT v3 Migration Guide
Active Directory Migration Tool version 3.1
ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains
How to troubleshoot inter-forest sIDHistory migration with ADMTv2
You find that several custom attributes are missing when you use ADMT to migrate users between two forests
Quest Migration Manager for Active Directory - QMMAD
Der Hersteller wirbt mit den Worten Zero Impact für sein Werkzeug und in der Tat fallen einem je nach Migration die Vorteile recht fix ins Auge. Das Tool welches zur Zeit in der Version 8.3 zur Verfügung steht, lässt sich einfach bedienen und es fällt schnell auf das sich vieles bei einer Intra- oder Inter-Forest Migration im Hintergrund bereits migrieren lässt, ohne dass die Benutzer etwas davon merken. Egal welche Migration durchgeführt wird, die Arbeiten können weitestgehend und ohne große Auswirkungen auf die Benutzer, im laufenden Betrieb erfolgen.
Natürlich möchte Quest bei seinen Migrationswerkzeugen sicherstellen, dass ihre Werkzeuge nur von Fachleuten, am liebsten aber (verständlicherweise) von seinen eigenen Consultants oder qualifizierten Partnern eingesetzt wird. Letztenendes aber möchte Quest seine Software schließlich an den Kunden bringen. Daher kommt es auf das Gespräch mit Quest an. Quest verkauft seinen QMMAD auch ohne Dienstleistung, möchte vorher aber vom Kunden schriftlich bestätigt bekommen, dass dieser das Werkzeug ausgiebig getestet hat. Es ist auch möglich, mit dem Hersteller einen privaten interaktiven Webcast über das Werkzeug zu veranstalten.
Damit man das Tool einsetzen kann, wird ein Lizenzfile benötigt. Das Lizenzfile kostet pro zu migrierender Benutzer 13 Euro. Je nach Anzahl sind ca. 10% Rabatt möglich. Es zählen nur die zu migrierenden Benutzerkonten. Gruppen- bzw. Computerkonten sind davon nicht betroffen. Nach einer Registrierung auf der Quest-Webseite kann man sich ein Test-Lizenzfile (begrenzt für einen bestimmten Zeitraum und für eine begrenzte Anzahl an Benutzer) zumailen lassen.
Der QMMAD setzt eine Active Directory Application Mode (ADAM)-Instanz und den IIS für ausführlichere Statistiken voraus. Bei der Standardinstallation wird ADAM gleich mit installiert und konfiguriert. Wird bei der Installation des QMMAD die benutzerdefinierte Variante gewählt, so kann eine bereits bestehende und vorbereitete ADAM-Instanz angegeben werden.
Das Quest-Tool kann sowohl bei einer Intra- als auch Inter-Forest Migration eingesetzt werden. Im Gegensatz zu ADMT kann dieses Werkzeug weitaus mehr Objekte migrieren und ist in der Anwendung komfortabler. Die ohnehin stressige Migration wird dadurch für den Administrator effizienter und flexibler. Bei den einzelnen Migrationsphasen kann ein entsprechendes Benutzerkonto das die benötigten Rechte für die jeweils auszuführende Aufgabe besitzt hinterlegt werden.
Active Directory Migration managed with Active Directory Migration Tools from Quest Software
ADMT vs. QMMAD
|
Funktion |
ADMT |
QMMAD |
Bemerkung |
|
Intra- und Inter-Forest Migration |
Bei einer Intra-Forest Migration werden die Objekte aus der Quell-Domäne entfernt. Das Objekt existiert nach der Migration nur noch in der Ziel- und nicht zusätzlich in der Quell-Domäne. Bei der Inter-Forest Migration bleiben die Objekte hingegen weiterhin in der Quell-Domäne bestehen, die deaktiviert werden können. |
Die Objekte bleiben sowohl bei einer Intra-als auch bei einer Inter-Forest Migration in der Quell-Domäne bestehen. Die Quell-Objekte können hier bei der Intra- sowie Inter-Forest Migration deaktiviert werden. |
Bei der Migration mit dem QMMAD ist man flexibler und kann vieles im Hintergrund bereits durchführen. |
|
Migration von Benutzer- und Gruppenkonten |
Ist bei einer Intra- sowie Inter-Forest Migration möglich. |
Das Quest-Tool kann ebenfalls beide Arten von Konten bei der Intra- als auch Inter-Forest Migration migrieren. |
Die Migration von Benutzer- und Gruppenkonten gehört bei beiden Tools zu den grundlegendsten Funktionen. |
|
Gesperrte Benutzerkonten migrieren |
Der Zustand eines gesperrten Benutzerkontos wird mit ADMT mit migriert. |
Nach der Migration eines gesperrten Benutzerkontos mit dem QMMAD ist das Konto anschließend nicht mehr gesperrt. |
Hierbei hat der QMMAD einen klaren Nachteil. |
|
SIDHistory |
Bei der Intra-Forest Migration ist die SIDHistory erforderlich und wird automatisch übernommen. Die SIDHistory ist bei der Inter-Forest Migration optional. |
Auch der QMMAD kann bei einer Intra- und Inter-Forest Migration mit der SIDHistory migrieren. |
Auch diese Funktion gehört zu den grundlegendsten Funktionen beider Tools. |
|
Entfernen der SIDHistory |
Das ADMT kann die SIDHistory von den Objekten nicht entfernen. |
Mit dem QMMAD kann recht einfach die SIDHistory von den Objekten entfernt werden. |
Mit dem QMMAD kann mit wenigen Mausklicks die SIDHistory von den Objekten entfernt werden (durch einen extra Durchlauf). |
|
Das lösen von Konflikten |
Mit ADMT ist die Konfliktlösung abhängig ob Intra- oder Inter-Forest Migration sehr beschränkt. |
Der QMMAD kann Konflikte z.B. durch hinzufügen eines Präfix lösen. |
Bei der Konfliktlösung (z.B. doppelter sAMAccountName) löst der QMMAD gegenüber dem ADMT einen Konflikt eleganter durch hinzufügen eines Präfix. |
|
Migration von Computerkonten |
Die Migration von Computerkonten ist bei der Intra- und Inter-Forest Migration möglich. |
Auch der QMMAD kann Computerkonten bei einer Intra- und Inter-Forest Migration migrieren. |
Auch die Migration von Computerkonten ist bei beiden Tools eines der grundlegendsten Funktionen. Beide Tools können Clients und Mitgliedsserver migrieren, aber KEINE DCs. DCs müssen aus der alten Domäne herunter- und in der neuen Domäne heraufgestuft werden. |
|
Migration der OU Hierarchie |
Das ADMT kann die OU Hierarchie aus der Quell-Domäne nicht migrieren. Die OUs müssen in der Ziel-Domäne manuell erstellt werden. Delegierungen müssten neu eingerichtet werden. |
Das Quest-Tool kann die OU Hierarchie, optional sogar mit dem Security Descriptor (sprich den Delegierungen), mit migrieren. |
Der QMMAD kann an dieser Stelle mehr als das ADMT. |
|
Verändern von Objekteigenschaften während der Migration |
ADMT kann während der Migration keine zusätzlichen Daten zu den Objekten einbinden. |
Der QMMAD kann während der Migration zusätzliche Daten zu den Objekten einbinden. |
Mit dem QMMAD könnten während der Migration zusätzliche Informationen z.B. in die Benutzerkonten eingepflegt werden. |
|
Migration der Active Directory Standort-Topologie |
AD-Standorte können mit dem ADMT nicht migriert werden. |
Mit dem QMMAD können AD-Standorte, Subnetze sowie Standortverknüpfungen migriert werden. |
Auch hier können mit dem Quest Werkzeug mehrere Objekte migriert werden. |
|
Migration der Benutzerkennwörter |
Die Kennwörter bleiben automatisch bei der Intra-Forest Migration erhalten, jedoch wird der Benutzer bei der ersten Anmeldung in der neuen Domäne aufgefordert, sein Kennwort zu ändern. Oder das Kennwort wird mit dem Password Export Server (PES) ebenfalls migriert, dann bleibt das alte Kennwort erhalten. Bei einer Inter-Forest Migration können die Kennwörter mit dem Password Export Server optional migriert werden. |
Die Benutzerkennwörter können mit dem QMMAD bei einer Intra- oder Inter-Forest Migration einfach migriert werden. |
Die Migration der Benutzerkennwörter lässt sich mit dem QMMAD einfacher als mit dem ADMT bzw. PES durchführen. |
|
Benutzerprofile |
Die Benutzerprofile bleiben erhalten. |
Die Profile der Benutzer bleiben auch hier ebenfalls erhalten. |
Die Profile werden bei der Migration der Clients übernommen. |
|
Komfortable Auswahl der Objekte |
Mit ADMT ist die Auswahl der Objekte eher eingeschränkt. |
Der QMMAD bietet starke Filtermöglichkeiten um die entsprechenden Objekte auszuwählen. |
Auch hier spielt das Quest-Werkzeug seine Stärken aus. |
|
Statistiken über Fortschritt |
Keine. |
Der QMMAD bringt ein Statistikportal mit. |
Mit dem QMMAD werden detaillierte Informationen über das Statistikportal geliefert. |
|
Undo Funktion |
Das ADMT kann nur den letzten Directory-Lauf rückgängig machen (Migration von AD-Objekten), aber nicht das Ressource Updating (RE-ACLing). |
Das Quest-Tool bietet komplette Undo-Funktionen. Jede Aktion kann rückgängig gemacht werden. |
Auch hierbei ist das Quest Werkzeug umfangreicher. |
|
Kontinuierliche Synchronisation |
Ist mit ADMT so nicht möglich. Höchstens aufwändig und eher umständlich mit Skripten und der ADMT-Skriptingschnittstelle. |
Mit dem QMMAD kann eine Synchronisation zwischen dem alten und neuen Objekt eingerichtet werden. Somit kann bei einer lang andauernden Migration ein Abgleich zwischen dem alten und neuen Objekt stattfinden. |
Gerade bei längeren Migrationsphasen ist die kontinuierliche automatische Echtzeitsynchronisation bei längeren Koexistenzphasen sehr wichtig. |
|
Konsolidiertes Ressourcen Updating |
Nicht möglich. |
Ist mit dem QMMAD möglich. |
Beim zusammenfügen von mehreren Quell-Domänen benötigt der QMMAD nur einen Durchlauf, während das ADMT pro Domäne einen Durchlauf benötigt. |
|
Client Update |
Eingeschränkt. |
Der QMMAD aktualisiert sogar die geplanten Tasks und Zertifikate auf dem Client. Zusätzlich wird die default Domäne für die Anmeldung umgestellt (im Anmeldefenster das Feld „Anmelden an“). |
Ein weiterer Vorteil bei dem Quest Werkzeug. |
|
Mitgliedsserver Aktualisierung |
Das ADMT kann das Ressource Updating für Exchange 5.5 durchführen. |
Der QMMAD kann die Berechtigungen von den folgenden Applikationen anpassen: Exchange 5.5/2000/2003. IIS. SQL 6.5/7.0/2000. SMS 2.3/2003. System Center 2007. NAS/SAN. Sharepoint 2003 und 2007. |
Das Quest-Tool kann die Berechtigungen von mehreren Applikationen anpassen. |
|
Test-Migration |
Seit ADMT 3.0 ist die Testmigration nicht mehr möglich. |
Mit dem QMMAD kann man die Migrationseinstellungen vor der produktiven Migration in einem Testlauf testen. |
Mit der Testmigration können Konfigurationsfehler aufgedeckt werden. Dies erleichtert die Fehlersuche. |
|
Auswahl von
Objekten |
Das ADMT bietet einen Standard Dialogfenster, in dem die Benutzer und Gruppen als flache Liste angezeigt werden. Die Filterung nach deaktivierten, abgelaufenen oder Systemkonten ist nicht möglich. |
Der QMMAD bietet erweiterte Filtermöglichkeiten bei der Auswahl der Objekte. Z.B. können deaktivierte und/oder abgelaufene Benutzerkonten von vornherein ausgeblendet werden. |
Gerade in größeren Umgebungen gestaltet sich die Auswahl der zu migrierenden Objekte einfacher als mit ADMT. |
|
Berechtigungen anpassen |
Das ADMT kann die folgenden Berechtigungen anpassen:
NTFS-Berechtigungen, Freigabeberechtigungen, Drucker, Registry, Profile. |
Der QMMAD kann folgende Berechtigungen anpassen:
Lokale Gruppenmitgliedschaften, Benutzer Berechtigungen, Dienste, Geplante Tasks, Registry, lokale und servergespeicherte Profile, Freigaben, Drucker, NTFS-Berechtigungen, DCOM, COM+ |
Die nötigsten Berechtigungen können beide Werkzeuge anpassen, wobei der QMMAD einiges mehr anpassen kann. |
|
Migration von Vertrauensstellungen |
Nicht möglich. |
Ist möglich. |
Ein weiteres nettes Feature des QMMAD. |
|
Fehler Analyse während der Migration |
Mit ADMT kann nach der Migration manuell ein Bericht über Konflikte erstellt werden. |
Der QMMAD gibt einen detaillierten Bericht über fehlgeschlagene Objekte, Verzeichnis Fehler, Konflikte, nicht aufgelöst Objekte (z.B. Gruppenmitglieder) sowie abgeschlossene Migrationen und Synchronisationen. |
Der detaillierte Bericht beim QMMAD erleichtert im Fehlerfall dem Administrator die Fehlersuche. |
Fazit
Mit dem ADMT lässt sich jede Umgebung, egal wie groß sie ist, sowohl bei einer Intra- als auch Inter-Forest Migration über jeden Zeitraum migrieren. Die einzelnen Migrationsschritte mit ADMT müssen insbesonders bei der Intra-Forest Migration genauer geplant werden. Zwar hat das ADMT gegenüber dem Quest-Werkzeug klar seine Einschränkungen, jedoch ist dafür das ADMT kostenlos! Die Restarbeiten können mit etwas Handarbeit (oder mit Skripten) durchgeführt werden.
Das Quest-Werkzeug bietet gerade in seinem Umfang mehr Vorteile als das ADMT. Es kann weitaus mehr Objekte migrieren als das ADMT und man kann vieles im laufenden Betrieb migrieren, ohne das die Benutzer etwas davon merken. Auch bei länger andauernden Migrationen spielt der QMMAD dank seiner Synchronisation seine Stärken aus. Des Weiteren kann dieses Werkzeug die Berechtigungen von mehreren Applikationen anpassen.
Weitere Informationen:
Microsoft Online Migration Toolkit
NetIQ Migration Suite
Wenn ein Domänencontroller (DC) ausgetauscht wird, ist darauf zu achten, dass alle Dienste sowie Daten von einem anderen Server bzw. DC übernommen werden. Das trifft auch für die FSMO-Rollen zu. Falls der FSMO-Rolleninhaber ausgetauscht werden sollte, gilt es die FSMO-Rollen entweder durch die grafische Oberfläche oder durch das im Betriebssystem enthaltene Kommandozeilentool NTDSUTIL manuell zu verschieben.
Das händische verschieben der Rollen hat den Vorteil, dass der Administrator bestimmen kann auf welchen DC die Rollen verschoben werden. Somit weiß der Administrator genau, auf welchem DC sich die Rollen befinden. Ein weiterer Vorteil des manuellen Verschiebens wäre, falls ein Unternehmen AD-lastig arbeitet und die FSMO-Rollen somit mehr beansprucht werden, kann der Administrator die Rollen auf eine leistungsfähige Maschine verschieben oder ggf. auf mehrere DCs verteilen.
Die Rollen müssen aber nicht beim Herunterstufen des Rolleninhabers zwingend manuell verschoben werden. Denn die FSMO-Rollen werden mit Ausführen von DCPROMO seit Windows 2000 RTM, also seit der Einführung des Active Directory, während des DCPROMO-Vorgangs automatisch auf einen anderen DC übertragen. Die Rollen können aber nur dann einem anderen DC übergeben werden, wenn das DNS ordnungsgemäß funktioniert, sowie der Rolleninhaber Verbindung zur Domäne und somit zu seinen Replikationspartnern hat. Dabei geht der Rolleninhaber folgendermaßen vor:
-
Wurden die FSMO-Rollen vor dem herunterstufen nicht manuell verschoben, wird das „Operational Attribute“ GiveAwayAllFsmoRoles gesetzt. Das veranlasst den Rolleninhaber dazu, andere DCs ausfindig zu machen damit die Rollen die er trägt, auf einen anderen DC übertragen werden können.
-
Für die Wahl des zukünftigen Rolleninhabers werden die folgenden Regeln angewendet:
- Bevorzugt wird ein DC am gleichen Standort ausgewählt.
- Es wird ein DC zu dem eine RPC-Verbindung besteht gesucht.
- Es wird ein Server verwendet, zu dem eine asynchrone Verbindung (z.B. über das SMTP-Protokoll) existiert.
-
Natürlich können dabei die drei domänenspezifischen Rollen RID-Master, PDC-Emulator sowie Infrastrukturmaster nur innerhalb der Domäne verschoben werden.
-
Die beiden gesamtstrukturweiten Rollen Schemamaster sowie Domänennamenmaster können auf jeden DC in der Gesamtstruktur verschoben werden. Dabei spielt es keine Rolle, in welcher Domäne sie sich befinden.
Erreicht der Rolleninhaber während des Herunterstufens keinen weiteren DC, so schlägt zum einen das automatische Verschieben der Rollen und zum anderen das Herunterstufen fehl.
Wird der Rolleninhaber durch die erzwungene Herabstufung mit DCPROMO /Forceremoval heruntergestuft, so erhält der Administrator ab Windows Server 2003 SP1 für jede Rolle die der DC inne hat, eine Warnmeldung. Diese Rollen müssen dann im Nachhinein auf einem anderen DC offline übertragen werden.
Der Nachteil des automatischen Verschiebens der Rollen ist die nicht Vorhersagbarkeit der Ziel-DCs auf die die FSMO-Rollen verschoben werden (Ausnahme es existieren nur genau zwei DCs).
Doch auch bei dieser Variante müssen die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen ab Windows Server 2003 (wie z.B. ForestDNSZones und DomainDNSZones) manuell auf einen anderen DC verschoben werden. Diese werden nicht automatisch auf einen anderen DC übertragen. Näheres dazu erläutert der folgende Artikel:
Die Infrastrukturmaster der Anwendungsverzeichnispartitionen
Weitere Informationen:
Die FSMO-Rollen verschieben
How Operations Masters Work: Active Directory
Flexible Single Master Operation Transfer and Seizure Process
Es gab einmal ein 32Bit Serverbetriebssystem…
Im Herbst 2009 erscheint das nächste Serverbetriebssystem (Codename Windows Server 7) aus dem Hause Microsoft Namens Windows Server 2008 R2. Somit bleibt Microsoft seiner Roadmap treu und veröffentlicht alle vier Jahre ein Major Release sowie dazwischen nach zwei Jahren ein Minor Release. Dabei wurden die R2-Versionen erstmals mit Windows Server 2003 R2 eingeführt, wobei damals das R2 auf zwei CDs ausgeliefert wurde und es im nächsten Serverbetriebssystem eine DVD ist.
Wie bereits im Vorfeld angekündigt, setzt Microsoft seine Ankündigung nun um. Es heißt: Ade 32Bit Serverbetriebssystem.
Das nächste Serverbetriebssystem Windows Server 2008 R2 wird es ausschließlich nur in der x64Bit Version geben. Die Administratoren müssen sich dabei aber keine großen Gedanken machen, denn die Hardware der letzten drei bis vier Jahre ist x64bittig.
Was sind die Active Directory-Neuerungen im Windows Server 2008 R2?
Welche Neuerungen es im Allgemeinen bisher im Windows Server 2008 R2 geben wird, kann bereits hier nachgelesen werden.
Windows Server 2008 R2 Reviewers Guide
Weitere Informationen:
Windows Server 2008: R2
Windows Server 2008 R2 Active Directory: What's Coming Up?
Der Kommandozeilen-Server, als Server Core bekannt, kann mit Bordmitteln nur über die Kommandozeile konfiguriert werden. Remote lässt sich der Server Core auch über die MMCs verwalten, natürlich nur, wenn dieser aus der Ferne erreichbar ist. Wie der Server Core manuell konfiguriert wird, zeigt der folgende Artikel:
Windows Server 2008 Core
Es gibt aber auch schon die ersten kostenlosen Tools im Internet (bis auf den CoreConfigurator), damit die Erstkonfiguration des Server Core einfach durchgeführt werden kann. Es müssen keine langen und aufwändigen Befehle mehr eingegeben werden. Dabei kommen auch die Freunde der Maus auf ihre Kosten.
Der Server CoreConfigurator
Über den Server CoreConfigurator werden sich die Administratoren freuen, die lieber mit der Maus arbeiten als mit der Tastatur. Die grafische Oberfläche lässt das konfigurieren der wichtigsten Einstellungen zu, damit anschließend die Administration weitestgehend remote erfolgen kann.
Die Konfigurationen die mit diesem Tool durchgeführt werden können, sind aus dem Screenshot ersichtlich.
Der CoreConfigurator steht leider nicht mehr kostenlos zum Download zur Verfügung.
Stattdessen kann das erweiterte Tool kostenpflichtig für 99 Dollar auf der folgenden Seite erworben werden:
Core Configurator
Das Tool: CoreConfig
Dieses Tool bietet ebenfalls eine grafische Oberfläche. Es lässt sich aber nicht mit der Maus, sondern mit dem Ziffernblock der Tastatur bedienen. Auch mit diesem Tool kann die Erstkonfiguration des Server Core recht einfach vorgenommen werden. Aber im Gegensatz zum CoreConfigurator ist dieses Tool nicht kompiliert. Es stellt eine Ansammlung an Skripten dar.
Dieses Tool steht zum einen als CAB-Datei und zum anderen als ISO-Datei zur Verfügung. Nach dem entpacken der CAB-Datei kann dieses Tool direkt von einem USB-Stick ausgeführt werden. Das Tool lässt sich mit dem Aufruf von Setup-Core.wsf starten.
Download: Windows 2008 Server Core Configurator
Das Kommandozeilentool: Core Configurator Console
Das Tool Core Configurator Console (CCC) ist ein Kommandozeilentool. Nach dem Download kann die Datei zuerst auf einen USB-Stick und anschließend auf den Server Core kopiert werden, wobei es auch direkt vom USB-Stick ausgeführt werden kann. Das Tool an sich ist eine einzige Batch-Datei, das es in der Kommandozeile mit ccc.bat aufzurufen gilt. Auch mit diesem Werkzeug lassen sich die elementaren Einstellungen vornehmen, damit der Server Core remote administriert werden kann.
Für Windows Server 2008: Core Configuration Console
Für Windows Server 2008 R2: CCC R2
Windows Server 2008 R2 Core Configurator 2.0
Das Open Source Tool "CoreConfig" wurde weiterentwickelt und steht nun in der Version 2.0 zur Verfügung.
Mit dieser Version lässt sich die Erstkonfiguration eines "Windows Server 2008 R2 Core" über eine grafische Oberfläche konfigurieren.
Download: Core Configurator 2.0
Das "on Bord" Skript Sconfig.cmd in Windows Server 2008 R2
Die Konfiguration des Windows Server 2008 R2 Core
Mit der Tombstone Lifetime (zu Deutsch Grabstein Lebenszeit) wird bestimmt, wie lange ein gelöschtes Objekt noch in der Active Directory-Datenbank (NTDS.dit) gespeichert wird. Wenn ein Objekt gelöscht wird, verschwindet es nicht sofort aus der AD-Datenbank. Stattdessen wird das Objekt als gelöscht markiert, in dem das Attribut is-Deleted auf True gesetzt wird. Des Weiteren werden die meisten Attribute entfernt und das Objekt wird wie folgt umbenannt:
CN=<alter RDN>\0ADEL:<Object-GUID>.
Nach dem umbenennen wird das Objekt in den versteckten Container Deleted Objects der entsprechenden Verzeichnispartition verschoben. Ab diesem Zeitpunkt wird das gelöschte Objekt als Tombstone (Grabstein) bezeichnet. Anschließend werden diese Änderungen auf alle anderen Domänencontroller (DC) repliziert. Erst wenn die Tombstone Lifetime (TSL) überschritten wurde, wird das Objekt endgültig aus der AD-Datenbank entfernt.
Dieser Prozess ist deshalb notwendig, damit sichergestellt ist das auch jeder DC bei einer aufwändigen (weltweiten) Replikationstopologie, von dieser Löschung informiert wird. Endgültig gelöscht wird das Objekt dann nach Ablauf der TSL von dem Garbage Collection Prozess, der standardmäßig auf allen Domänencontrollern (DC) alle 12 Stunden läuft. Diese Zeit kann zwar verändert werden, jedoch besteht in der Praxis i.d.R. kein Bedarf dies zu tun.
Weiterhin bestimmt die TSL auch, wann sich spätestens ein DC einmal mit seinen Replikationspartnern repliziert haben muss, ehe Replikationsprobleme entstehen.
Wann wird die Tombstone Lifetime festgelegt?
Die TSL wird mit dem Installieren des ersten DCs in einer Gesamtstruktur und zwar für alle Domänen festgelegt. Die TSL kann nicht pro Domäne konfiguriert werden. Der Wert der TSL kann aber jederzeit manuell verändert werden (wozu Organisations-Admins Rechte benötigt werden), was jedoch begründet sein sollte. Dabei spielt weder der Domänenfunktionsmodus, noch der Gesamtstrukturfunktionsmodus eine Rolle.
Der Active Directory-Installationsassistent DCPROMO erzeugt aus der Datei schema.ini die TSL für die Gesamtstruktur. Unter Windows 2000 sowie Windows Server 2003 befindet sich diese Datei im Verzeichnis %systemroot%\system32 und unter Windows Server 2008 im Verzeichnis
%systemroot%\winsxs\x86_microsoft-windows-d..rvices-domain-files_31bf3856ad364e35_6.0.6001.18000_none_9b0b0e3a43600e0c
Der DCPROMO-Assistent nutzt diese Datei als Vorlage und entnimmt daraus seine Angaben, um das Basisschema entsprechend dem Serverbetriebssystem zu erstellen.
Vor dem Heraufstufen des ersten DCs, kann man die TSL in der schema.ini kontrollieren. Der Eintrag in der Datei lautet: tombstoneLifetime=<Wert in Tagen>.
Die TSL beträgt unter:
-
Windows 2000 (mit allen SPs) = 60 Tage
-
Windows Server 2003 ohne SP = 60 Tage
-
Windows Server 2003 mit Service Pack 1 = 180 Tage
-
Windows Server 2003 R2 mit Service Pack 1, installiert mit beiden R2-CDs = 60 Tage
-
Windows Server 2003 R2 mit Service Pack 1, installiert nur mit der ersten R2-CD = 180 Tage
-
Windows Server 2003 mit Service Pack 2 = 180 Tage
-
Windows Server 2003 R2 mit Service Pack 2 = 180 Tage
-
Windows Server 2008 = 180 Tage
-
Windows Server 2008 R2 = 180 Tage
Überprüfen und Bearbeiten der Tombstone Lifetime
Kontrollieren kann man das Attribut tombstoneLifeTime mit Dsquery wie folgt. Der Befehl lautet:
Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" -attr tombstoneLifetime
Falls kein Wert angezeigt wird, dann gilt der Standardwert von 60 Tagen. Ansonsten gilt der angezeigte Wert in Tagen.
Die TSL lässt sich auch mit ADSIEdit überprüfen und bearbeiten. Dazu gilt es, zuerst zum folgenden Container zu navigieren:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Dort befindet sich in den Eigenschaften des Containers das Attribut tombstoneLifetime. Ist dort ein Wert gesetzt, beträgt die TSL den eingetragenen Wert in Tagen. Steht im Attribut als Wert hingegen <Not Set>, so beträgt die TSL den Standardwert von 60 Tagen.
Mit der AD-PowerShell kann man die TSL folgendermaßen überprüfen:
Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" -Properties tombstoneLifetime | Select tombstoneLifetime | FL
Mit diesem Befehl lässt sich die TSL in der AD-PowerShell bearbeiten:
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“tombstoneLifetime” = Wert}
Hinweis: Das installieren eines Service Packs oder das Aktualisieren des Serverbetriebssystems verändert niemals den Wert der Tombstone Lifetime!
Auf was ist zu achten?
-
Die TSL darf keinen niedrigeren Wert enthalten, als die Replikation benötigt um alle DCs über einen Löschvorgang zu informieren. Ansonsten entfernt der Garbage Collection Prozess das gelöschte Objekt endgültig aus der AD-Datenbank, bevor alle Replikationspartner von der Löschung informiert wurden. Dies würde zu Inkonsistenzen in der AD-Datenbank führen.
-
Eine System State-Sicherung die älter als die TSL ist, darf nicht mehr verwendet werden. Die TSL gibt das maximale Alter einer Systemstatus-Sicherung an. Wird ein DC während der TSL mit einer Systemstatus-Sicherung die das Benutzerobjekt Yusuf enthält wiederhergestellt, nachdem das Objekt Yusuf gelöscht wurde, so würde der gelöschte Status von dem Objekt Yusuf auf den wiederhergestellten DC repliziert werden. Das Benutzerobjekt Yusuf wäre weiterhin nicht vorhanden, da die Wiederherstellung während der TSL durchgeführt wurde. Falls der DC nach der TSL wiederhergestellt werden würde, wäre das Benutzerobjekt Yusuf jedoch vorhanden. Denn auf den anderen DCs wäre das Objekt bereits aus der AD-Datenbank vom Garbage Collection Prozess entfernt worden. Das Benutzerkonto würde aber nur auf dem wiederhergestellten DC existieren. Dieser Zustand führt zu Inkonsistenzen in der AD-Datenbank und das Benutzerobjekt Yusuf wäre ein Lingering Object (herumlungerndes Objekt).
-
Ein DC darf nicht länger als die TSL offline sein. Wenn dies der Fall sein sollte, bekommt der nicht erreichbare DC von den mittlerweile gelöschten Objekten nichts mit und so kommt es dann zu Lingering Objects.
Welche Auswirkung hat das Erhöhen der Tombstone Lifetime?
-
Eine Systemstatus-Sicherung hat eine längere Nutzungsdauer.
-
Das Heraufstufen eines Servers durch die IFM-Funktion (Install from Media) zu einem DC hat durch das erhöhen der TSL, ebenfalls eine höhere Nutzungsdauer.
-
Ein DC kann länger offline bleiben und kann dadurch, nach einer längeren Offlinezeit wieder erfolgreich zur Domäne hinzugefügt werden.
-
Die gelöschten Objekte (Tombstones) bleiben länger auf den DCs erhalten und können dadurch ab Windows Server 2003, länger wiederhergestellt werden. Dadurch erhöht sich aber auch die Größe der AD-Datenbank.
Fazit: Die TSL sollte wenn möglich nicht verändert werden. Falls ein triftiger Grund besteht die TSL doch zu ändern, sollte der Wert nicht allzu groß gewählt werden.
Weitere Informationen:
The default tombstone lifetime (TSL) value remains at 60 days instead of increasing to 180 days in Windows Server 2003 R2
The Active Directory database garbage collection process
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|