AD - Benutzer exportieren und importieren

Ist es möglich, Benutzer aus einem ActiveDirectory herauszuziehen, eine neue Domäne mit gleichen Namen aufzubauen und die Benutzer dort zu importieren?

Ich habe öfter mal Aufträge, bei denen ein Netzwerk von irgendwelchen Hobby-Admins kaputtgespielt ist und komplett neu aufgebaut werden darf ("alte Zöpfe abschneiden!").

Allerdings hatte ich bis dato immer ziemlich viel Unglück mit der Migration der lokalen Profile.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 292471

Url: https://administrator.de/forum/ad-benutzer-exportieren-und-importieren-292471.html

Ausgedruckt am: 23.04.2025 um 17:04 Uhr

11 Kommentare

Neuester Kommentar

Hallo,

das sollte dir weiter helfen.

https://technet.microsoft.com/de-de/library/cc974332(v=ws.10).aspx

ADMT hilft dem TO da nicht viel, da er ja eine Domäne mit dem gleichen Namen erstellen will.

Ich habe öfter mal Aufträge, bei denen ein Netzwerk von irgendwelchen Hobby-Admins kaputtgespielt ist und komplett neu aufgebaut werden darf

Dazu setzt man aber nicht eine neue Domäne mit dem gleichen Namen auf. Diese Vorgangsweise unterscheidet sich auch nicht von einem Hobby-Admin. Denn in ganz seltenen Fällen ist das AD defekt.

Wenn dann migriert man das AD auf einen neuen Server in der gleichen Domäne oder erstellt eine neue Domäne. Dann gibt es keine Probleme mit den Profilen.

LG Günther

ohne Gruß,

also wenn´s wirklich nur um die Benutzer geht kannst Du auch in csv ex/importieren.
https://technet.microsoft.com/de-de/library/cc771621.aspx
mit csvde.exe

ohne gruß
kowa

Zitat von @GuentherH:

Denn in ganz seltenen Fällen ist das AD defekt.

In der Regel sieht das wie folgt aus:
- ein SBS-Server wurde als Fileserver genutzt
- irgendwann wurde der Laufwerk auf C: knapp
- der SBS-Server wurde gewaltsam "abgespeckt" (WSUS, Sharepoint, SQL, Exchange "weggebombt")

Was übrig bliebt ist ein File- und Printserver, der noch munter die Hälfte über das AD verteilt, die der Administrator nicht erwischt hat. Zum Beispiel diverse Gruppenrichtlinien...

Mein Bestreben ist, da einen "sauberen" Filter hinzustellen und diesen auf genau das zu reduzieren, was der Kunde haben möchte.

Wenn dann migriert man das AD auf einen neuen Server in der gleichen Domäne oder erstellt eine neue Domäne.
Dann gibt es keine Probleme mit den Profilen.

Aber die Profile sind doch über die SIDs fest mit der alten Domäne verbunden.

Woher soll der neue Server denn wissen, welche der alten SIDs er mit welchem Benutzerobjekt aus der neuen Domäne verknüpfen soll?!?

Einen neuen Server in die Domäne zu hängen und "einfach nur" die FSMO-Rollen rüberzuschieben scheidet meiner Meinung nach aus, da ich immer damit rechnen muss, dass das AD kaputtmanipuliert wurde (z.B. mit adsiedit). Wer z.B. Binaries aus den Windows-Systemordnern löscht um den Exchange abzuschalten, dürfte diesbezüglich wenig Hemmungen gehabt haben...

Nachtrag: Hat jemand Erfahrung mit diesem Tool? http://www.forensit.com/domain-migration.html

Eigentlich müsste es dann doch reichen, den Rechner in der neuen Domäne anzumelden und die Daten vom alten Profil auf das neu generierte Profil zu migrieren - oder?

Den Wunsch, dass die (neue) Domäne den gleichen Namen wie die alte haben sollte, könnte ich ggf. noch "wegdiskutieren"

Woher soll der neue Server denn wissen, welche der alten SIDs er mit welchem Benutzerobjekt aus der neuen Domäne verknüpfen soll?!?

Über die SID-History der Benutzerobjekte wenn du mit ADMT migrierst

, Les einfach mal den obigen Leitfaden, dazu dort steht das alles.

Gruß grexit

Zitat von @117471:

Nachtrag: Hat jemand Erfahrung mit diesem Tool? http://www.forensit.com/domain-migration.html

Eigentlich müsste es dann doch reichen, den Rechner in der neuen Domäne anzumelden und die Daten vom alten Profil auf das neu generierte Profil zu migrieren - oder?

Geht auch...Hier wird dem lokal vorhandenen Profil in der Registry einfach die User-SID der neuen Domain untergeschoben. Der User kann dann normal mit seinem alten Profil weiterarbeiten.

Zitat von @122990:

Über die SID-History wenn du mit ADMT migrierst

Ich meine mal gelesen zu haben, dass:
- ADMT eine Vertrauensstellung voraussetzt
- SBS-Server keine Vertrauensstellungen zulassen

Auch wäre noch zu erwähnen, dass es sich bei meinen Szenarien um maximal 20 Arbeitsplatzrechner handelt und der Installations- und Planungsaufwand nicht die Zeit übersteigen sollte, in der man alle Profile komplett neu baut

Ich bin da eher auf der Suche nach etwas "knackigem Intuitiven"...

Geht auch...Hier wird dem lokal vorhandenen Profil in der Registry einfach die User-SID der neuen Domain untergeschoben. Der User kann dann normal mit seinem alten Profil weiterarbeiten.

...und da die Dateiberechtigungen - z.B. in den ACLS - an der SID hängen, werden die auch komplett migriert - richtig?

Sehe ich das richtig, dass dann das Benutzerverzeichnis z.B. auf C:\Benutzer\manni.ALTEDOMAENE\ verbleibt und verwendet wird, wenn sich der mit NEUEDOMAENE\manni anmeldet? (Vorausgesetzt, die SID wurde mit dem Forensit-Tool verschoben)?

Zitat von @117471:

Geht auch...Hier wird dem lokal vorhandenen Profil in der Registry einfach die User-SID der neuen Domain untergeschoben. Der User kann dann normal mit seinem alten Profil weiterarbeiten.

...und da die Dateiberechtigungen - z.B. in den ACLS - an der SID hängen, werden die auch komplett migriert - richtig?

Ja.

Sehe ich das richtig, dass dann das Benutzerverzeichnis z.B. auf C:\Benutzer\manni.ALTEDOMAENE\ verbleibt und verwendet wird, wenn sich der mit NEUEDOMAENE\manni anmeldet? (Vorausgesetzt, die SID wurde mit dem Forensit-Tool verschoben)?

Ja, das Verzeichnis bleibt das selbe und die ACLs werden auf das neue Konto umgeschrieben, quasi ein SID-Replace durchgeführt.

Was sich übrigens auch manuell mit einem Einzeiler und Set-ACL machen lässt.
https://helgeklein.com/setacl/examples/managing-file-system-permissions- ...

- SBS-Server keine Vertrauensstellungen zulassen

Ist im Prinzip richtig. Es geht aber, wenn in beiden Domänen der Administrator den gleichen Namen und Passwort hat. Das reicht um eine Migration über ADMT durchzuführen.

dass es sich bei meinen Szenarien um maximal 20 Arbeitsplatzrechne

Also da reicht csvde.exe allemal oder anders rum, 20 - 30 User sind in 10 Minuten in der neuen Domäneauch angelegt. Und was anderes wird ja beim Erstellen einer neuen Domäne ohne die entsprechenden Tools auch nicht gemacht.