NTDSUtil AD Stamm in Textdatei auslesen

[Alex20 10]

So hallo,

 

habe als erstes mal gesucht und schon einiges über dieses Tool gefunden aber leider noch nicht das was ich suche.

So ein ehemaliger bei mir hier in der Firma (schon gut her deshalb kann ich den nicht mehr fragen) hat es mit dem Tool geschafft die Struktur des ADs auszulesen und es auf nem anderen Server einfach aus dem generierten Textfile wieder herzustellen. Hat das von euch schon mal jemand gemacht? Komme mit dem Tool noch nicht so ganz klar kenne auch schon die einschlägigen Artikel der Knowledgebase. Was ich hier sehe ist dass die meisten mit dem Tool z.b. die FSMO Rolle "Schemenmaster" bzw. die anderen Rollen neu auf nen anderen DC übertragen falls der Schemenmaster ausgefallen ist.

Danke schon mal für die Antworten

 

Gruß Alex

[grizzly999 11]

Ich bezweifle, dass das mit ntdsutil passiert sein soll.

Eher LDIFDE oder CSVDE, aber selbst damit muß man mit Filtern arbeiten.

Was hast du genau vor? Dann können wir dir vielleicht weiterhelfen.

 

grizzly999

[Alex20 10]

Also im Prinzip gings da rum einen "Server" der momentan auf einem APC aufgesetzt ist auf ne Servermaschine zu bekommen sprich mal ganzes Betriebssystem sichern und neu draufziehen wäre Schwachsinn weil das nicht rund laufen würde weil komplett andere Hardware verbaut ist inkl. anderem Raid usw.

Und da hat angeblich n Vorgänger von mir mal richtig schön das AD in ein Textfile rausgezogen und auch in einen frisch aufgesetzten DC wieder einspielen können deswegen hab ich das gefragt.

Im Prinzip ist unsere Aufgabe für die nächste Zeit dass wir mehrere Domäneninsellösungen migrieren und einem Schemenmaster unterordnen der nur die diese Funktion verwalten soll. Bisher hatten wir diese Insellösungen weil wir über ein rießiges Gelände mit zig Gebäuden verteilt sind und da teilweise 25 Rechner über ne 2Mbit Strecke angebunden sind/waren und dort mit servergespeicherten Profilen zu arbeiten bzw. den Nutzern klar zu machen auf ihren Homedrives bzw. auf den verknüpften Netzlaufwerken zum Server.

Jetz sollen die einzelnen DCs dem Schemenmaster ungeordnet werden und die Domäne z.b. Apfel.local heissen der erste DC hat dann seine untergeordnete Domäne darin zu verwalten die dann z.b. Birne.Apfel.local heissen würde und so weiter. Darauf will ich eigentlich hinaus das andere mit dem AD in Textfile auslesen wäre nur so mal interessant gewesen das hinzubekommen.

 

Gruß Alex

[woiza 10]

Wenn ich das richtig verstehe, willst du mehrere Gesamtstrukturen in eine konsolidieren. Dann würde es nicht viel bringen, die gesamte AD-Struktur mit LDIF oder was auch immer zu exportieren und wieder zu importieren. Bestimmte Konten und Gruppen wären sonst in den einzelnen Import-Files ja doppelt und dreifach vorhanden.

 

Ich würde den Content der Domänen mit ADMT in die zentrale Struktur migrieren.

 

 

 

Auch für das Szenario "Umzug von Server1 nach Server2" würde ich diesen Weg nicht wählen. Lieber die zweite Maschine als zusätzlichen DC aufnehmen, die Replikation abwarten und dann die Rollen und DNS umziehen.

 

 

Ansonsten zur Info:

 

http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/howto/bulkstep.mspx

[Alex20 10]

Mit ADMT läuft das ja so ab dass ich dann meine Objekte aus dem AD (Nutzer Gruppen Computer) in eine OU einer Zieldomäne verschiebe. Das is dann so gewollt? Ich möchte dass die jetztigen einzel Domänencontroller die alle für sich alleine arbeiten sprich alle FSMO Rollen beinhalten unter einen Schemenmaster unterordnen. Der Schemenmaster wird dann die AD Struktur verwalten seh ich das richtig? Die untergeordneten DCs werden sich diese dann replizieren?

[ChristianHemker 10]

Der Schemenmaster wird dann die AD Struktur verwalten seh ich das richtig? Die untergeordneten DCs werden sich diese dann replizieren?

 

Die Domänencontroller sind erstmal alle gleichberechtigt. Einzige Ausnahme bilden hier die FSMO Rollen, wie die Schemamaster Rolle.

Der Schemamaster ist der einzige DC, der etwas in das Schema schreiben darf. Mehr nicht.

 

Mir ist noch nicht so ganz klar was am Ende dabei rauskommen soll? Insgesamt nur weniger Domänencontroller? Weniger Domänen?

[woiza 10]

Mit ADMT läuft das ja so ab dass ich dann meine Objekte aus dem AD (Nutzer Gruppen Computer) in eine OU einer Zieldomäne verschiebe.

 

Korrekt...

 

Das is dann so gewollt?

 

Jagut, das weiß ich nicht. Das versuche ich ja herauszufinden...

 

Ich möchte dass die jetztigen einzel Domänencontroller die alle für sich alleine arbeiten sprich alle FSMO Rollen beinhalten unter einen Schemenmaster unterordnen. Der Schemenmaster wird dann die AD Struktur verwalten seh ich das richtig? Die untergeordneten DCs werden sich diese dann replizieren?

 

Nein.

 

Erstens geht das technisch nicht und zweitens ist das auch nicht ganz die Funktionsweise von AD. Ich hole mal etwas aus.

 

Bei NT war nur der PDC beschreibbar, die BDCs haben lediglich Read-Only Kopien. Das ist äußerst bescheiden, wenn ich eine große, geografisch verteilte Umgebung habe, die ich in einer Domäne unterbringen will. Der Benutzer im Hamburg müsste danns seine Benutzer auf dem PDC in München anlegen.

 

Daher sind im AD alle DCs beschreibbar und auch prinzipiell gleichberechtigt. Jetzt gibt es bestimmte Aufgaben, die auf keinen Fall mehrfach vorhanden sein sollten.

 

Man stelle sich vor, in Hamburg wird eine Schemaerweiterung durchgeführt und in München zur gleichen Zeit eine andere, inkompatible. Oder beide würden gleichzeitig den Exchange-Forrestprep durchführen.

Bei der nächsten Replikation rummst es gewaltig. Daher hat MS das Konzept der FSMO Rollen eingeführt. Diese können von Server zu Server verschoben werden (Flexible), dürfen aber pro Domain/pro Forrest nur einmal vorhanden sein (Single). Diese sind dann Chef für bestimmte Dinge, die nur sie dürfen.

 

Der Schemamaster hält nicht die Struktur des AD, sondern ist für das LDAP-Schema zuständig, sprich er hat als einziger Schreibrecht auf die Schemapartition. Im Schema wird beschrieben, welche Objekte angelegt werden dürfen, welche Attribute Pflicht sind usw. Alle Schemaänderungen müssen hier durchgeführt werden.

 

Die AD-Struktur verwaltet, wenn man so will, der Domain Naming Master. DIeser ist zuständig, wenn neue Domänen hinzugefügt werden.

 

Beide sind im Forrest einmalig.

 

 

Der RID-Master verwaltet die RIDs, d.h. er vergibt RID-Pakete an die einzelnen DCs, damit keine RID doppelt verwendet werden.

 

Dann gibt es noch Infrastruktur-Master und PDC-Emulator, die lasse ich jetzt mal weg.

 

 

Für deinen konkreten Fall heißt das, dass in dem Forrest, der dann später der zentrale sein wird, alle Rollen mindestens einmal vorhanden sind, falls Multidomain, dann gibt es die drei Domain-FSMOs entsprechend mehrfach.

 

Die einzelnen DCs stellen jeder für sich auch einen Forrest dar. Also gibt es dort einen Schemamaster, sowie einen DN-Master. DAher kann dieser auch nicht einem anderen Forrest beitreten.

 

Von daher: was spricht dagegen mit ADMT den Content u migrieren, das ist doch das einzig interessante aus den "Einzelmaschinen". Danach können diese DCs plattgemacht werden und in den neuen Forrest installiert werden.

[Alex20 10]

Die einzelnen DCs stellen jeder für sich auch einen Forrest dar. Also gibt es dort einen Schemamaster, sowie einen DN-Master. DAher kann dieser auch nicht einem anderen Forrest beitreten

 

Den Satz versteh ich jetz noch nich so ganz........

 

So also insgesamt soll rauskommen dass wir eine Domäne "Apfel.local" haben, unter diese Domäne werden dann untergeordnete Domänen geschoben (das muss so ein zwecks organisatorischen Gründen und des Willen des Unternehmens) sprich ich hab dann "Birne.Apfel.local", "Banane.Apfel.local"...usw. für die einzelnen untergeordneten Gruppen.

Wir haben das Problem dass wir über ein sehr großes Areal verteilt sind und teilweise nur 2Mbit SDSL Strecken zwischen den Anbindungspunkten haben.

 

Eine 2. Möglichkeit die ich mir überlegt habe wäre eine Domäne "Apfel.local" und fertig. Und dann eben 2-3 DCs verteilt im Bereich aufstellen nur wäre da dann das Problem zu kontrollieren wer sich wo anmeldet weil wie gesagt wir auf den Netzwerktraffic achten müssen.

 

Edit:

Da fällt mir noch was ein. Hat, wenn ich eine untergeordnete Domäne z.b. eben "Birne.Apfel.local" erstelle, diese dann auch einen eigenen Schemamaster? Wenn ich dich richtig verstanden haben dann hat jede dieser untergeordneten Domains die 3 wichtigen FSMO-Rollen jeweils einmal?!

Wäre es dann überhaupt möglich das ganze über den Schemamaster von "Apfel.local" so zu verwalten dass dieser praktisch zentralisiert für das Schema verantwortlich ist?

[woiza 10]

So also insgesamt soll rauskommen dass wir eine Domäne "Apfel.local" haben, unter diese Domäne werden dann untergeordnete Domänen geschoben (das muss so ein zwecks organisatorischen Gründen und des Willen des Unternehmens) sprich ich hab dann "Birne.Apfel.local", "Banane.Apfel.local"...usw. für die einzelnen untergeordneten Gruppen.

 

Wenn die Domain Birne.Apfel.Local unabhängig von Apfel.local installiert wurde, wenn also beim DCPromo ausgewählt wurde "Create new Domain in a new Forrest", dann stellt dieser DC für sich einen eigenen Forrest mit allen 5 FSMOs dar. Er hängt nur aus DNS-Sicht unter Apfel.local.

 

Wir haben bei uns ein ähnliches Konstrukt. Einige Abteilungen bestehen auf getrennten Forrests (zwecks Geheimhaltung), sind aber in einem gemeinsamen DNS-Namensraum angesiedelt. Unser zentraler DNS delegiert also die Zone Birne.Apfel.local an die unabhängige Domäne und bei Birne ist die Apfel.local als Stammhinweis eingetragen.

 

Eine 2. Möglichkeit die ich mir überlegt habe wäre eine Domäne "Apfel.local" und fertig. Und dann eben 2-3 DCs verteilt im Bereich aufstellen nur wäre da dann das Problem zu kontrollieren wer sich wo anmeldet weil wie gesagt wir auf den Netzwerktraffic achten müssen.

 

Beide Möglichkeiten haben Vorteile. Allerdings kommst du bei keiner von beiden um eine Neuinstallation der DCs herum. Der Anmeldetraffic hat übrigens nix mit der Domäne zu tun. Das wird über die im AD eingetragenen Subnetze gesteuert, die dann der entsprechenden Site zugeordnet werden. Das funktioniert bei Single- und Multidomain-Umgebungen. Wenn das Subnetz deines Clients nicht im AD eingetragen ist, meldet er sich unetr Umständen sonstwo an. Außerdem gibts dann ne Latte von Fehlermeldungen.

 

Edit:

Da fällt mir noch was ein. Hat, wenn ich eine untergeordnete Domäne z.b. eben "Birne.Apfel.local" erstelle, diese dann auch einen eigenen Schemamaster? Wenn ich dich richtig verstanden haben dann hat jede dieser untergeordneten Domains die 3 wichtigen FSMO-Rollen jeweils einmal?!

Wäre es dann überhaupt möglich das ganze über den Schemamaster von "Apfel.local" so zu verwalten dass dieser praktisch zentralisiert für das Schema verantwortlich ist?

 

Was ist untergeordnet?

Wenn du lediglich untergeordnet im Sinne von DNS-Subdomains meinst, dann sind diese ja eigenständige Forrest (s.o.)

Wenn du damit eine Subdomain aus AD-Sicht meinst, dann hat diese Subdomain keinen eigenen Schemamaster, da das Schema im ganzen Forrest gleich sein muss.

Anders ausgedrückt: Es gibt im Forrest nur eine Schemapartition (und eine Configuration, aber die lassen wir jetzt mal weg) und auf der kann nur der Schemamaster schreiben.

 

Die untergeordneten Domänen haben dann folgende 3 FSMOs:

-RID-Master

-PDC Emulator

-IS Master

[woiza 10]

Den Satz versteh ich jetz noch nich so ganz........

Eine 2. Möglichkeit die ich mir überlegt habe wäre eine Domäne "Apfel.local" und fertig. Und dann eben 2-3 DCs verteilt im Bereich aufstellen nur wäre da dann das Problem zu kontrollieren wer sich wo anmeldet weil wie gesagt wir auf den Netzwerktraffic achten müssen.

 

Kleiner Nachtrag zu Single-Domain vs. Multidomain.

Diese Entscheidung ist hauptsächlich eine Frage des Administrationsmodells, sprich habe ich Domainadmins, die alles betreuen sollen, oder will ich getrennte Domainadmin-teams haben.

 

Zusätzlich ist dies noch eine Security-Überlegegung. Habe ich in verschiedenen Bereichen andere (höhere) Anforderung an die Default Domain policy, etwa in Bezug auf Passwortrichtlinien usw.

 

Last but not least (leider) gibt es noch den Fall, dass sich bestimmte Einheiten "Sehen" wollen, so nach dem Motto "Wir hatten bis jetzt ne eigene NT Domäne, also wollen wir weiter ne eigene Domäne haben"

 

Im Falle eines Multidomain-Forrests sollte nach Möglichkeit die Rootdomäne leer bleiben, das bringt gewisse administrative Vorteile.

[Alex20 10]

Also wir haben ein Adminteam und die Defaultdomainpolicy sprich z.B. PW-Komplexität soll auch überall gleich sein. Also die Subdomains sollten schon voll integriert sein nich nur DNS-mäsig zusammenhängen. Dass soll dann so sein dass man das ganze dann zentral vom Schemamaster administrieren kann und auch die gesetzten Policies einheitlich sind.

In der AD Verwaltung kann ich jetzt immer nur eine Domäne ansehen bzw. bearbeiten hab jetzt momentan nicht die Möglichkeit das zu Testzwecken alles aufzusetzen, wie würde dass dann in der AD Verwaltung aussehen?

 

Der Anmeldetraffic hat übrigens nix mit der Domäne zu tun. Das wird über die im AD eingetragenen Subnetze gesteuert, die dann der entsprechenden Site zugeordnet werden. Das funktioniert bei Single- und Multidomain-Umgebungen. Wenn das Subnetz deines Clients nicht im AD eingetragen ist, meldet er sich unetr Umständen sonstwo an. Außerdem gibts dann ne Latte von Fehlermeldungen.

 

Doch hat der schon und zwar Stichwort servergespeicherte Profile wenn ich jetzt eine Domäne habe und dann 2-3 DCs verteile und einer von diesen ausfällt dürfen sich alle Rechner an den nächsten wenden der dann meinetwegen 2-3km weiter weg steht und nur über ne langsame Netzwerkanbindung verfügt. Das nächste wäre dann noch dass jederzeit überall die selben Profile sein müssten wenn die anderen DCs als Alternativen zur Verfügung stehen sollen.

Im AD eingetragene Subnetze? Was meinst du damit?

[ChristianHemker 10]

Im AD eingetragene Subnetze? Was meinst du damit?

 

Wenn ich das richtig interpretiere reicht für eure Anforderungen eine Domäne für alle aus. Wenn ich 2 Bereiche komplett trennen möchte brint es mir auch nichts 2 Domänen in einer Gesamtstruktur (egal ob Unter- und Überdomain oder 2 Strukturen) zu erstellen. Ich muss dann schon verschieden Gesamtstrukturen erstellen. Dann (und nur dann) habe ich auch getrennte Schemata und damit auch getrennte Schemamaster. Es wird aber alles unnötig kompliziert, warum das Ganze?

 

Um den Anmeldeverkehr zu steuern, richtet man Active Directory Standorte (Sites) ein. Diese wiederum basieren auf IP Subnetzen, die auch logisch in Active Directory abgebildet sein müssen (Subnetzobjekte).

[ChristianHemker 10]

Doch hat der schon und zwar Stichwort servergespeicherte Profile wenn ich jetzt eine Domäne habe und dann 2-3 DCs verteile und einer von diesen ausfällt dürfen sich alle Rechner an den nächsten wenden der dann meinetwegen 2-3km weiter weg steht und nur über ne langsame Netzwerkanbindung verfügt. Das nächste wäre dann noch dass jederzeit überall die selben Profile sein müssten wenn die anderen DCs als Alternativen zur Verfügung stehen sollen.

 

Man muss hier zwischen Anmeldetraffic und dem sonstigen traffic unterscheiden. Der reine Anmeldedatenverkehr besteht eigentlich nur aus DNS Namensauflösung und Kerberos Daten. Ist nicht so viel für einen User.

Die servergespeicherten Profile haben mit dem Anmeldeverkehr nichts zu tun. Dafür kann das schon ziemlich viel Traffic werden. Daher sollte man für die Profile auch einen extra Fileserver vorhalten, der vor Ort steht.

Dann ist es nämlich egal ob der DC vor Ort ausfällt, das Profil bekommt man immer noch von dem Server vor Ort.

[Alex20 10]

Wir haben hier mehrere Netze am Standort die getrennt bleiben müssen deshalb müssten wir schon mit Subdomains arbeiten aber von den Richtlinien im AD her haben die dann alle das gleich die dürfen nur nicht auf die selben Files zugreifen.

Also doch einen DC für Apfel.local und dann in jedes Netz einen eigenen DC mit Subdomain?

Gibts da gute Seiten zwecks AD Planung so n paar Begriffe sagen mir z.b. noch nichts bzw will mich da noch mehr reinfuchsen weil ich erst am Anfang des ganzen stehe. Z.B. das lenken des Anmeldeverkehrs über die Standorte. Danke schon mal!

[ChristianHemker 10]

Wir haben hier mehrere Netze am Standort die getrennt bleiben müssen deshalb müssten wir schon mit Subdomains arbeiten aber von den Richtlinien im AD her haben die dann alle das gleich die dürfen nur nicht auf die selben Files zugreifen.

Aber nur damit User einer anderen Abteilung (oder welche auch immer) nicht auf die Dateien einer anderen Abteilung zugreifen können sollen, muss ich doch nicht mit mehreren Domains arbeiten?

Das kann man doch viel besser mit Gruppen und Freigabe-/NTFS Berechtigungen lösen!

 

Wenn du dich in das AD Thema mehr einarbeiten möchtest würde ich dir Literatur zu den Prüfungen 294 (Administrieren und Implementieren von AD) und 297 (Planung von AD) empfehlen.