Daim

Servus,

Die Subadmins sollen nun die "Computerobjekte" in ihren Zweig verschieben können

- es muss das Recht DELETE CHILD (DC) in dem Quell-Container gesetzt werden.

- es muss das Recht WRITE PROPERTIES (WP) für die beiden Eigenschaften RDN sowie CN auf dem Quell-Container gesetzt werden.

- es muss das Recht CREATE CHILD (CC) auf dem Ziel-Container gesetzt werden.

Du solltest das ganze mit DSACLS durchführen.

sowie das "Beschreibungsfeld" der "Computerbojekts" bearbeiten können.

Schau dir dazu in diesem Artikel unterhalb von DSACLS den Befehl an:

Yusuf`s Directory - Blog - Objektdelegierungen einrichten

Servus,

SELTSAMERWEISE wird jetzt eine korrekte Delegierung eingerichtet.

nein, nicht "seltsamerweise", denn das ist unter Windows Server 2008 "by Design" so.

Dort wird eine Delegierung nun automatisch mit eingerichtet. Es ist ein neues Feature.

Nö Diam

Na was ein Glück. ;)

Wahrscheinlich ist dies genau das Problem und somiut der Grund warum die DMZ-Domäne nicht im GC vorhanden ist.

Genau so ist es. Ohne eine Vertrauensstellung kann das so nicht funktionieren.

Lassen sich diese Domänen sich nun auch in den GC mitaufnehmen?

Ein globaler Katalog kann nur die Informationen EINER Gesamtstruktur in der er selbst Mitglied ist enthalten. Alle Objekte aus einer Gesamtstruktur egal aus welchen Domänen, sind im GC enthalten. Somit ist es zwangsläufig notwendig, dass alle Domänen zur gleichen Gesamtstruktur gehören und unter diesen dann automatisch eine transitive bidirektionale Vertrauensstellung besteht.

Bitte bitte...... (vorsichtig formuliert...will nicht gegen die Nettikette verstoßen) sei unbedingt sehr vorsichtig.

 

Wenn du die Möglichkeit hast, stelle dir die Situation mit einer Testumgebung nach. Ich habe den Eindruck das du diese Arbeiten das erste Mal tun willst.

Du willst jetzt damit aber nicht den OP dazu bringen, die Domäne doch zu splitten?!

Hola,

WIe bekomm ich denn dann heraus ob der anvisierte ADC's nun einen GC bereit hält oder nicht, oder lässt sich per dnslookup eine Liste der GC's erstellen?

lies doch einfach hier ;) :

Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC)

...aber Sicherheit ist hier ausnahmsweise mal nicht das Problem. In der Praxis werde ich eh beide Domänen administrieren.

Sicherheit ist in der IT - IMMER - ein Thema!

Ich kann mich nur wiederholen. Sobald eine Domäne gesplittet wird, MUSS eine Migration und kein Pfusch betrieben werden!

Ich kann es dir nur ans Herz legen. Sobald ein Unternehmen sich trennt, erstelle für die eine Firma eine eigene Domäne, sonst könnte das später böse enden!

Servus,

lies dir diesen und die weiterführenden Artikel durch:

Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Soweit ich in verschiedenen Quellen nachlesen konnte, braucht man aber für Windows Server 2008 zwingend ADMT 3.1, und das gibt es noch nicht. Eine für 2008 nicht freigegebene Version 3.0 einzusetzen würde ich mich sehr unwohl fühlen.

Ein für Windows 2008 supportetes ADMT sollte Juni/Juli erscheinen. Aber trotzdem würde ich es mit dem 3.0 trotzdem versuchen. Zu Beta Zeiten habe ich erfolgreich auch unter 2008 mit dem ADMT 3.0 Migrationen durchgeführt. Aber wie gesagt, ADMT 3.1 müsste jeden Tag erscheinen.

Das erhält er jedes Mal, wenn er sich auf einem PC einloggt, auf dem er noch nie eingeloggt war.

Korrekt.

Es steht ihm frei, mit dem Defaultprofil zu arbeiten oder sein Hintergrundbild eben auch hier wieder einzupflegen.

Dann bleiben da noch die Dateien die auf dem Desktop abgelegt wurden oder Eigene Dateien usw...

Warum sollte ich das tun?

Weil im alten Profil evtl. noch Daten sind?

Wie dem auch sei, ich denke wir haben nun alles durchdiskutiert und DU musst dir den Weg zusammenstellen.

Ok, ich werde mich mit dem ASR genauer auseinandersetzen. Kennst Du eine Webseite, die die Vorgehensweise detailliert beschreibt?

Wenn du die Suchmaschine deines Vertrauen aufsuchst und ASR eingibst, wirst du jede Menge dazu finden.

Leider habe ich gerade keinen Link parat.

Wir haben insgesamt nur etwas über 100 Benutzer, und die sind ja auch nicht alle in derselben OU.

Aber wenn du z.B. eine Abteilung zusammenfasst, könnten evtl. 20 Benutzer in einer OU sein und wenn diese gelöscht wird, ist das auch mehr als ärgerlich. Was ich dir damit veranschaulichen wollte ist lediglich, dass du um das erstellen einer System State Sicherung nicht herum kommst.

Aber wenn wir jetzt mit 2008 was ganz Neues anfangen, dann wollen wir doch nicht so einen Dreck importieren!

Na mit dem ADMT kannst du doch auswählen, welche Objekte (Benutzer- sowie Computerkonten) migriert werden sollen und welche nicht. Leichen brauchst du natürlich nicht "mitnehmen".

Vieles wird klarer, wenn du es mal in einer Testumgebung testest.

[*] Die Berechtigungen sind bei uns fast alle auf Gruppenebene und nicht auf Benutzerebene vergeben.

Vorbildlich.

Es genügt also, die Gruppen neu einzurichten und die Benutzer beim Neuanlegen in ihre jeweilige Gruppe wieder einzutragen.

Scheinbar habt ihr aber nicht soo viel zu tun, da du weiterhin auf das neu anlegen der Benutzer beharrst. Ich sage dir, wenn du mit ADMT migrierst, sparst du dir eine Menge Arbeit und dabei nimmst du auch keinen alten Schrott mit, den du nicht möchtest. Ich kann es dir nur empfehlen. Wenn du eine ABM-Maßnahme (Arbeitsbeschaffungsmaßnahme) daraus machen möchtest, dann nur zu.

Die sind bei uns lokal.

Wenn du nun in der neuen Domäne den Benutezr neu einrichtest, erhält der User ein neues Profil. Also musst du dann das alte Profil umkopieren, mit all seinen Macken. Mit ADMT hast du diese Sorgen nicht.

Also wenn DU dich weiter so zierst und die Migration mit ADMT nicht durchführen möchtest, mache ich es bald für dich. ;)

Das mit den lokalen Profilen geht unter 2008 doch noch, oder?

Natürlich, sei es lokal oder servergespeichert.

SYSPREP und ASR müßte erst erarbeitet werden. Das kostet Zeit und Aufwand. Am Ende steht ein Wiederherstellungskonzept, das auch funktioniert, aber komplexer ist und länger dauert als das triviale Zurückspielen eines Images.

Völlig korrekt. Den Aufwand hättest du am Anfang. Aber wenn das Konzept dann mal steht, ist es einerseits die Variante die auch vom Hersteller empfohlen wird und jeden Wirtschaftsprüfer/IT-Revision stand hält. Du hast somit ein ordnungsgemäßes Bachup-Konzept. Du könntest ja mal einen fachkompetenten Dienstleister Fragen was er davon hält. Falls er dir auch zum Imaging rät, wechsele den Dienstleister. :p

Ich erhalte einen geradezu trivialen und dennoch voll funktionsfähigen Weg der Wiederherstellung. Image rein, zum DC machen, fertig. Was genau gibt es daran auszusetzen?

Sorry, aber nun halte ich mich zum Thema Imaging zurück. Zu diesem Thema ist mir jede Silbe zu schade. Wie gesagt, DU entscheidest.

Damit ist der Artikel nicht fehlerhaft, aber als Backup-Strategie bei Totalcrash unzureichend.

Auch das wird in dem Artikel bereits in den ersten drei Sätzen beantwortet, beachte dazu die rote Schrift:

Grundsätzlich ist ein Restore des AD in einer richtig aufgebauten Umgebung nur dann nötig, wenn versehentlich Änderungen oder Löschungen durchgeführt wurden. Sollte "nur" ein DC ausgefallen sein, reicht es, einen weiteren Server mit dcpromo zum DC zu befördern. Er repliziert dann automatisch das komplette AD.

Ist richtig, aber ASR enthält Fallstricke. Soweit ich der Microsoft-Dokumentation entnehmen konnte, wird bei ASR eine automatisierte Reinstallation des Betriebssystems nebst allen Daten vorgenommen. Hoffentlich vollständig,

Mit der ASR-Sicherung wird das System gesichert (samt System State), nicht die Daten. Diese müssen gesondert gesichert werden.

Das ist ein viel komplexerer, fehlerträchtigerer und auch zeitlich längerdauernderer Vorgang als das Zurückspielen eines Festplatten-Images.

Das ist mir schon bewußt, dass ein Image genau diese Verlockung hervor ruft, eben schnell nach einem Crash den gesamten Server samt Daten wiederherzustellen. Sehr viele andere Benutzer hier an Board würden dir in diesem Thema auch zustimmen. Es würde der Hinweis kommen darauf zu achten, ein Offline-Image zu erstellen. Da bist du aber bei mir fehl am Platz. Von mir hörst du so etwas nicht. Ich kann mich nur wiederholen, Imaging wird von Microsoft nicht supportet. Ende!

Fehlerquellen bei der Wiederherstellung gibt es praktisch nicht. Und Du sagst selbst, daß man solch Server nur als DC in die Domäne reinnehmen muß, und der Rest passiert von alleine. Weshalb sollte ich mich also auf den deutlich holperigeren Weg einlassen?

Moment, halt, stopp. Du sprichst vom Imaging eines frisch installierten Servers und nicht eines DCs? Dann sieht das anders aus, aber auch hierbei würde ich nicht Imagen, sondern ein mit SYSPREP bearbeitetes Master Image mir einmal erstellen und dieses jederzeit verwenden. Das kommt dann auf das gleiche raus, mit einem anfänglichen Mehraufwand aber dafür supporteten Variante von Microsoft.

Warum soll ich eine Wissenschaft aus dem Backup/Restore machen, wenn es so viel einfacher und dennoch zuverlässig geht?

Weil das Thema Backup nunmal eine Wissenschaft für sich ohnehin ist. Backup ist kein doing für eine Sekretärin oder den Hausmeister, sondern ein harter Job für die IT. Wirtschaftsprüfer oder eine IT-Revision würden dir bei dem Thema Imaging und "nicht supportet" des Herstellers auch gerne dazu etwas erzählen.

Was DU am Ende daraus machst, bleibt dir und jedem selbst überlassen.

Nur damit ich mir selber auf die Schulter klopfen kann, daß ich offizielle Microsoft-Werkzeuge verwende?

Nein, nicht weil du Microsoft-Werkzeuge verwendest, sondern, du eine unterstützte Vorgehensweise mit einem sehr hohen Funktionserfolg einsetzt.

Ist nicht böse gemeint, aber ich sehe beim besten Willen den Vorteil nicht.

Ist mir klar, wir diskutieren hier nur. Am Ende entscheidest du welchen Weg du gehst. Wenn du ein System irgendwann rückimagest und erhälst Wochen später eine Folgefehler und benötigst dann den Support von Microsoft, kannst du sehr schnell ohne Hilfe von Microsoft da stehen.

Ich muß meine Frage wiederholen: Was ist der Vorteil?

Weil du mit einem niedrigen Aufwand, ein laufendes System (OS+AD+DNS usw.) erhälst, was eben vom Hersteller supportet wird. Du musst keinen Computernamen nach der Installation vergeben oder die IP-Informationen bzw. irgendwelche Registry-Einstellungen. Alles wird nach der ASR-Rücksicherung wiederhergestellt.

... to be continued.

P.S. Hatte ich schon erwähnt, dass mich diese 4.000 Zeichengrenze nervt?

Moin,

auf welche IP-Adresse zeigt der Eintrag für den DNS-Server? Hoffentlich auf einen internen DNS-Server. Stehen Fehlermeldungen im Eventlog? Evtl. aktuelle Netzwerkkartentreiber installieren.

Ehrlich gesagt ist mir der Weg sogar sympathischer, als wenn ich ein Tool habe, bei dem ich auf den Knopf drücke, und dann macht es irgendwas, und hinterher weiß ich nicht genau, was es gemacht hat. Ich müßte mich also sorgsam in das ADMT eindenken.

Ich wiederhole mich gerne noch einmal, einmal mit ADMT migriert und du willst nichts anderes mehr. Bei der Migration mit ADMT wird eine Namensauflösung und eine Vertrauenesstellung zwischen alter und neuer Domäne benötigt. Das ADMT richtet dann ein neues Benutzerkonto in der neuen Domäne ein und fügt die SID des alten Benutzerkontos, aus der alten Domäne an das neuen Benutzerkonto der neuen Domäne als SID-History hinzu. Damit kann das neue Benutzerkonto die alte SID als "Ausweis" vorzeigen, wenn die neue SID des Benutzerkontos keinen Zugriff bekommt.

Wenn der Benutzer von einer Domäne in eine andere Domäne migriert wird, so wird seine SID nicht mitübernommen, denn der mittlere Part der SID ist die Nummer der Domäne. Bei der Benutzer-Migration mit ADMT wird jedesmal ein neues Benutzerkonto mit einer neuen SID in der Ziel-Domäne eingerichtet. Dadurch das das "neue" Benutzerkonto eine neue SID bekommen hat, bekommt das Konto nicht die gleichen Berechtigungen wie es das alte Konto hatte, auch wenn der Benuztername gleich lautet. Denn bekanntlich sind /Namen/ "Schall und Rauch" in der IT.

Und da ist die Frage, ob es nicht schneller geht, die neuen Gruppen händisch unter 2008 anzulegen und die Benutzer einzutragen.

Nie und nimmer. Was machst du denn mit den Benutzerprofilen?

Wenn ich alles von Hand anlege, dann weiß ich, was ich getan habe. Und alles, was ich nicht anfasse, ist auf dem Windows Server 2008-Default, was mir sympathischer ist als irgendeine NT4-kompatible Einstellung, die unbemerkt mit rübergekommen ist, obwohl sie für uns keinen Sinn macht.

Dann würde ich dir empfehlen, dass mal in einer Testumgebung zu testen. Da siehst du welche Variante die wenigste Arbeit bereitet und gibst mir dann am Ende Recht. ;)

Wie gesagt, es soll ein Neuanfang werden, also eine "Migration" und kein "Upgrade", bei dem alte Leichen mitgeschleppt werden, nur um eine Stunde Arbeit zu sparen.

Je nach Anzahl von Benutzern sowie Clients, erspart dir ADMT keine Stunden, sondern Tage an Arbeit.

Ein regelmäßiges Backup des AD würde ich dann aus Hardwaregesichtspunkten für unnötig halten. Nur ein Atomkrieg, der über mehrere 100km verstreut alle Niederlassungen gleichzeitig auslöscht, könnte das AD wirklich zum Erlöschen bringen.

Das ist zwar richtig, aber trotzdem kannst du auf eine System State Sicherung nicht verzichten. Was ist eben, wenn ein ausversehen gelöschtes Objekt oder eine Organisationseinheit (OU) mit 200 Benutzern ausversehen gelöscht wurde? Dann brauchst du entweder eine System State Sicherung oder das Zeitfenster der standortübergreifenden AD-Replikation ist so groß, dass sich diese Löschung noch nicht auf die DCs in den Standorten repliziert hat. Denn dann kannst du diese OU autoritativ kennzeichnen und wird somit nicht gelöscht.

Wäre ein Backup des AD notwendig, um menschliches Versagen aufzufangen?

Ja, sogar hauptsächlich dafür. Denn die Missgeschicke passieren nunmal oft durch menschliches Versagen.

Ich meine, ein paar verlorene Benutzer samt ihrer Rechte kann ich auch schnell wieder von Hand eintragen. Das rechtfertigt m.E. nicht den Aufwand, ein AD-Backup-Konzept zu erarbeiten und zu realisieren und die Ausführung des Backups kontinuierlich zu überwachen.

Beim löschen EINES Benutzers magst du recht haben, wobei du trotzdem Arbeit hast mit dem Profil, was eben nciht sein müsste. Was ist aber, wenn eine ganze OU mit 200 Benutzern auf einen Schlag gelöscht wurden?

Die Sicherung bezgl. des Hardwarecrashs benötigst du nicht unbedingt, dass stimmt. Es sei denn, du möchtest einen Server an einem Standort zum DC deklarieren und dabei soll der DC so schnell wie möglich startklar sein. Dann könntest du dank der System State Sicherung und der Install from Media (IFM) Funktion einen Server zum DC stufen:

Yusuf`s Directory - Blog - Domänencontroller-Installation von einer Sicherung

Oder könnte im AD durch menschliches Versagen noch mehr verlorengehen, was dann doch richtig weh täte?

Natürlich. Ich verstehe ehrlich gesagt nicht was die ganze Diskussion hier soll.

Ein Backup wird benötigt ohne wenn und aber. Punkt.

Möglicherweise habe ich da was durcheinandergebracht, ja.

Das Gefühl habe ich auch.

Trotzdem noch mal die Frage: Mit was für einem durchschnittlichen Datenverkehrsaufkommen muß ich auf den Fernleitungen rechnen, um das AD aufrechtzuerhalten, wenn überall DCs derselben Domäne stehen?

Wenn nicht AD-lastig gearbeitet wird, sondern lediglich Benutzer sich an der Domäne authentifizieren, kannst du das Replikationsaufkommen völligst vernachlässigen. Ansonsten nämlich, benötigt die AD-Replikation eben mehr Zeit. Denn schließlich würde für die AD-Replikation auch eine 56KB Leitung ausreichen, die Replikation würde dann eben länger benötigen.

Es werden ca. 4KB pro Benutzerauthentifizierung über die Leitung repliziert, bei AD-integriertem DNS.

Dann muß es aber wirklich sehr bald kommen, denn darauf warten werden wir mit unserer Umstellung wohl nicht. Andererseits bricht mir auch kein Zacken aus der Krone, wenn ich unsere gut 100 User händisch migriere.

Glaube mir, wenn du einmal eine Migration und sei es bloß für fünf Benutzer mit dem ADMT durchgeführt hast, willst du nichts anderes mehr. ;)

Abgesehen davon soll das ADMT 3.1 im Sommer diesen Jahres erscheinen. Aber auch mit ADMT 3.0 sollte es möglich sein:

Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

... to be continued.

P.S. Diese 4.000 Zeichengrenze nervt so langsam. ;)

Macht es unter diesem Umständen überhaupt noch Sinn, einen zweiten DC im Stammhaus zu haben?

Je nach Anzahl der Benutzer. Wenn der eine DC mit nur einer 1 Ghz CPU arbeitet, aber 2.000 Benutzer am Hauptstandort wären, dann würde ein zweiter DC in der Zentrale Sinn machen. Sind es bloß 400 User, dann reicht ein DC ALLEINE für die Benutzerauthentifizierung. Existieren aber noch weitere Applikationen die vom AD abhängig sind, wie z.B. Exchange etc. oder es wird AD-lastig gearbeitet, dann gilt es dies genauer zu prüfen.

Zuerst vorneweg, ich gehe nur noch auf deine Fragen ein, da wir ansonsten bis zum nächsten Jahrhundert philosophieren. Danke für dein Verständnis.

Es gibt aber dazu keine Alternative, sondern allenfalls Ergänzungen.

Natürlich gibt es eine Alternative, nämlich die, die jeder Softwarehersteller für zum sichern seiner Systeme empfiehlt sowie SUPPORTET! Diese Alternative stellt evtl. für dich keine Alternative dar, ändert trotzdem nichts an der Tatsache, dass z.B. das Imagen von Datenbanksystem basierenden Systemen aus dem Hause Microsoft mit dieser Sicherungsmethode nicht supportet wird.

Bei einem DC z.B. könnte man als Sicherungsmethode die ASR-Sicherung wählen.

Aber: z.B. der faq-o-matic-Artikel "Wie stelle ich das AD wieder her?" fängt an mit "DC im Restore-Modus starten". Selten so gelacht,

Sorry, aber dann hast du den Artikel nicht im geringsten verstanden.

Lies dir den Artikel evtl. nochmals durch und frage ggf. was du nicht verstehst. Aber der Artikel ist mit allen Ausführung 100% korrekt.

Ich rede davon, daß ich ein lauffähiges Offline-Image haben muß, damit ich überhaupt mal was in der Hand habe, wovon ich booten kann.

Ich persönlich halte von Imaging eines DCs nicht viel.

Fakt ist aber, egal ob du online oder offline einen DC imagest, es wird von Microsoft nicht supportet.

Wenn ich dann wieder einen laufenden Windows Server 2008 vor mir stehen habe, dann kann ich darüber nachdenken, wie ich ihn wieder vernünftig in die Domäne bekomme.

Wie gesagt, es führen viele Wege nach Rom, gerade in der IT-Welt.

Dann sind auch keine alten AD-Daten im Image, die später zu Problemen führen könnten.

Prinzipiell zwar korrekt, aber wie gesagt, eine ASR-Sicherung wäre z.B. eine Alternative. Aber was beim Thema Imaging unbedingt beachtet werden sollte, ist das Master-Image zu anonymisieren. Dieses macht man, in dem man SYSPREP anwendet.

Kann man aber auch bleiben lassen, weil der Server sich sowieso synchronisiert, wenn man ihn in die Domäne reinnimmt und zum DC macht.

Wenn es nur um das wiederherstellen eines DCs geht, dann ist das die einfachste Variante. Wenn aber ein Objekt autoritativ wiederhergestellt werden soll, so ist eine aktuelle SYSTEM STATE Sicherung Pflicht.

• In den Niederlassungen stehen DCs, die sich mit dem Stammhaus synchronisieren.

Und idealerweise wären das unter Windows Server 2008 - RODCs.

• Von jedem der Server gibt es ein Offline-Image aus einer Zeit, als er noch gar nicht in der Domäne war. Im Falle eines Crashes wird dieses wieder eingespielt und der Server wieder in die Domäne reingenommen. Anschließend brauche ich nur zu warten, bis das AD sich selber wieder repliziert hat.

Das ist eine Möglichkeit, aber denke an SYSPREP (und an ASR).

Wenn man das so machen würde, dann würde selbst ein Brand, der beide DCs im Stammhaus vernichtet, nicht zum Zusammenbruch des AD führen. Man könnte dort neue Server 2008 aufstellen, und die würden sich das AD dann aus den Niederlassungen ziehen. Richtig?

Das ist dann der Fall, wenn in den Standorten beschreibbare und keine RODCs stehen. Oder man holt sich eine aktuelle System State Sicherung die natürlich ausser Haus aufbewahrt wird und spielt diese dann zurück.

Aber ein solches Disaster Recovery Konzept muss sich jedes Unternehmen erarbeiten und erstellen.

Das würde aber bedeuten, daß die Niederlassungs-DCs keine RODCs sein dürfen, da sie sonst nicht als Replikationsgrundlage für das Stammhaus taugen würden. Richtig?

Exakto Mundo.

... to be continued.

Ich war mir nicht sicher gewesen, ob in der Grafik die besagten Standortverknüpfungen von Site C & D zur Site A fehlen.

Genau so würde ich das interpretieren, denn alles andere würde keinen Sinn ergeben. Der von mir zitierte Satz aus dem Artikel zeigt es deutlich, wobei in der Ausführung das Wort "können" verwendet wird:

...können Sie zusätzliche Standortverknüpfungen...

dabei müsste es m.E. "..müssen Sie.." lauten.

Aber wie gesagt, diese Seite existiert genau so seit der Beta des Windows Server 2008.

Es kann sehr gut sein, dass die Seite noch aktualisiert wird.

Der Vollständigkeitshalber noch dieser Link ;) :

Yusuf`s Directory - Blog - Read-Only Domain Controller (RODC)

ich danke Dir :)

Der Amerikaner würde jetzt sagen: You are welcome. ;)

Klar wird ordentlich getestet aber ein Recoverykonzept muss trotzdem sein.

Aber selbstverständlich. Nur das ein Recoverykonzept ohnehin in jedem Unternehmen existieren müsste, nicht nur wegen einer Änderung. ;) Aber wenn man wegen einer Änderung sich dann mal ein Recoverykonzept erarbeitet, umso besser.

Wollen ja bei einem Problem nicht rumlaufen wie die aufgescheuchten Hühner :D

Wer will das schon.

Also gibt es drei möglichkeiten:

1 - Werte wieder resetten, also neue Werte mit alten überschreiben

2 - alles user löschen und authorative wiederherstellung, replizierung laufen lassen und warten

3 - replikation für den zeitraum umbiegen und erst bei erfolg auf alle ausführen lassen (das sowieso wahrscheinlich)

Korrekt.

Es sind nur Änderungen an den Werten der Klasse User.

OK.

Getestet haben wir es sind aber noch nicht fertg.

Na dann testet es doch erstmal durch.

Auch wenn man es durch die Rücksicherung rückgängig machen kann, sollte es vorher komplett durchgetestet, bewertet und anschließend in der produktiven Umgebung technisch umgesetzt werden.

Wir haben eine Menge User und eine dezentrale Struktur.

Umso mehr solltet ihr es vorher druchgetestet haben.

Reicht die authoritative Wiederherstellung nicht auf unserem HauptDC?

Repliziert sich das wieder zurück?

Da ich erst jetzt weiß von was du konkret sprichst... ja, wenn alle Stricke reißen könnte man das Benutzerobjekt z.B. löschen und durch eine autoritative Wiederherstellung das Benutzerobjekt vor der Änderung wiederherstellen. Natürlich muss vor der Änderung sichergestellt werden, dass eine funktionierende sowie aktuelle SYSTEM STATE Sicherung existiert.

Abgesehen davon, bei einer Änderung am Benutzerobjekt ist die Gefahr sehr niedrig das Benutzerobjekt zu "zerschießen". Falls die Änderung nichts gebracht hat, löscht man i.d.R. den eingetragenen Wert einfach wieder raus.

Das können wir also nutzen klingt doch gut :)

Hajo, wäre zwar machbar, aber wie gesagt, vorher in einer VM testen und du kannst dir die Mühe sparen. ;)

Auf der einen Seite spricht das natürlich schon für die Ein-Domänen-Struktur.

Aber selbstverständlich tut es das. Du sprichst von Verwaltbarkeit udn das mit 2 EDVlern... da ist schon ein Single-Domänen Forest schon fast Pflicht.

Auf der anderen Seite können wir es uns nicht erlauben, in Features zu schwelgen und ein ausgefeiltes komplexes System mit vielen Objekten, Subobjekten und -berechtigungen, Abhängigkeiten und Virtualisierungen zu erstellen, das zwar genial durchdacht ist, aber nicht mehr überblickt und gewartet werden kann, wenn man sich mal 3 Monate nicht mehr damit beschäftigt hat.

Das musst du doch auch bei einer Umgebung mit nur einer Domäne nicht.

Keep it simple lautet die Devise und das ist es eben bei nur einer Domäne.

Und nur wenn du eine Domäne hast wird das System weder komplex, noch werden dadurch viele Objekte bzw. Subobjekte erstellt. Im Gegenteil, gerade wenn du mehrere Domänen erstellst, hat eben jede Domäne seine eigenen Objekte. Was die Berechtigungen anbetrifft, möchtest du also nichts im AD delegieren, dann brauchst du das auch garnicht. Alle Aufgaben in der Domäne werden dann von euch beiden ausgeführt. Somit sind die Aufgaben klar definiert und nichts großartiges zu Dokumentieren, was die Vergabe von Berechtigungen in der Domäen betrifft.

Das Thema Virtualisierung ist ein ganz anderes, was dir aber im übrigen ebenfalls Vorteile verschafft.

Denn die von uns abzudeckende Aufgabenpalette ist relativ breit gefächert. Vernünftiges Dokumentieren ist zwar immer sinnvoll und notwendig, aber nicht ausreichend, um diese Problematik abzufedern.

In vielen Unternehmen sind die EDV-Leute "Generalisten, adss ist ganz normal.

Damit unterscheiden wir uns deutlich von anderen Firmen mit einem EDV-Stab, bei dem sich 2 Leute nur um die Pflege des AD kümmern und dabei aus dem Vollen schöpfen können.

Keineswegs. Ihr seit nicht die einzigsten auf dieser Welt mit den vielen Aufgaben. Und die Aussage "nur um die Pflege des AD kümmern" ist doch total verkehrt. Das AD ist ein Mittel zur Netzwerkverwaltung, nicht mehr und nicht weniger. Es hilft einem Unternehmen dabei, sich die Arbeit zu organisieren. Du kannst eine AD-Domäne wie eine NT-Domäne administrieren. Aber wie in jeder Umgebung, sollte man die Besonderheiten kennen.

Auch das Konzept des RODCs ist mir nicht unsympathisch.

Ich persönlich halte das für genial. ;)

Wichtig ist aber meines Ermessens, daß es so wenig wie möglich Virtualisierungen gibt, denn die machen das Gesamtsystem immer undurchschaubar.

Virtualisierung ist ein interessantes, aber kein leicht zu nehmendes Thema. Denn zusätzlich gilt es dann noch eine virtuelle Schicht zu administratieren.

Und gerade bei dem Thema Virtualisierung gehört ein Konzept dazu.

Deswegen finde ich auch Windows Vista so furchtbar:

Du springst hier aber von einem Thema zum anderen.

Denkst Du, daß das realisierbar ist?

Na klar ist es das. Ich denke wenn du dir die Grundlagen angeeignet hast, wird einiges von ganz alleine klar.

Wenn das alles läuft, dann nehmen wir die XP-Clients unserer Anwender einfach aus den alten NT4-Domänen raus und fügen sie den/r neuen 2008-Domäne(n) hinzu.

Auch dabei hilft dir der Artikel, denn es wird auf das ADMT verwiesen mit dem du die Benutzer- sowie Computerkonten in eine neue Domäne migrieren kannst. Denn somit bleiben die Profile erhalten und der Benutezr bekommt von der ganzen Aktion nichts mit. Das ADMT für Windows 2008 wird bald erscheinen.

Es gibt aber in unserem Fall einige Gesichtspunkte, die zu berücksichtigen sind.

Das ist aber in vielen Unternehmen so, denn schließlich hat jedes Unternehmen seine eigenen Anforderungen.

Wenn ein Domänen-DC ausfällt, dann können sich die Benutzer immer noch mit cached credentials anmelden

Falls kein anderer DC (ab Windows 2000) mehr ereichbar wäre, ja. Wenn aber ein anderer DC in der Domäne noch verfügbar ist, egal an welchem Standort dieser steht, dann können sich die Benutzer an diesem DC authentifizieren.

(Image wieder eingespielt; notfalls Hardware getauscht).

Das Imagen eines DCs halte ich für keine gute Idee.

Yusuf`s Directory - Blog - Images als Sicherung ?

Es genügt, ein Festplattenimage der Systempartition zu haben, mit dem man den DC schnell wieder aufsetzen kann.

Zum Thema Images bitte o.g. samt weiterführenden Artikeln lesen.

Wenn danach 5 Benutzer händisch wieder eingepflegt werden müssen, dann ist das für eine Totalcrashsituation ein sehr überschaubarer Aufwand.

Ich kann es bei 5 Benutzern zwar nachvollziehen, trotzdem könnte man sich die "Mehrarbeit" (Benutzer einrichten, Profile herrichten etc.) sparen und somit könnten die Benutezr schneller für die Firma Geld verdienen.

Aber wenn ich das richtig verstanden habe, wird solch lokaler Fileserver dann in den AD-Baum wie ein virtuelles Unterverzeichnis reingehängt?

Nein, oder sprichst du evtl. von DFS?

Das bedeutet doch dann, daß jedesmal, wenn ein Benutzer sich durch diesen Baum browst, um nur auf die Dateiablage seiner eigenen Niederlassung zuzugreifen, stets auch Directory-Informationen über die Fernleitungen angefordert werden, um den Baum überhaupt darstellen zu können?

Wozu gibt es denn Login-Scripts mit dem die Benutzer ihre Laufwerke auf ihrem Server vor Ort die Verbindung zu den Dateien herstellen?

Rollenabhängige Berechtigungsstrukturen und Teiladminberechtigungen wird es hier wohl nicht geben. Das wäre für uns gar nicht wartbar.

Doch, wäre es sehr wohl. Gerade da ihr nur zwei Mann in der IT seit, könntet ihr gewieften Angestellten die sich für die EDV interessieren, Aufgaben wie z.B. das erstellen der Benutzer delegieren (das ist nur ein sehr einfaches Beispiel). Denn schließlich habt ihr wichtigeres zu tun.

Moin,

Die Frage ist wie man am besten zurückgeht auf den vorherigen Stand, falls was nicht klappt.

es kommt darauf an wieviele Werte in welchen Attributen ihr die Werte auf einmal ändern wollt. Tragt ihr z.B. Werte in den Attributen die zur Klasse USER gehören ein, könnt ihr die eingetragenen Werte auch leicht wieder ändern. Aber testet es doch vorher in einer Testumgebung aus. Ich würde mir dazu mit dem VMWare-Converter vorher einen DC virtuallisieren und die Änderung dann in einer Testumgebung, die natürlich keine Verbindung zur produktiven Umgebung hat, austesten. Dann seht ihr ja was passiert.

Authorative Wiederherstellung? Backup & Systemstate?

Eine Autoritative Wiederherstellung wäre zwar eine Möglichkeit, aber bei 25 DCs (sind die wirklich notwendig?) eine Riesenakt. Eine System State Sicherung muss ohnehin existieren, mindestens vom FSMO-Rollen Träger oder besser von jedem DC.

Änderungen nur auf manche DCs replizieren und erst wenn OK auf alle, sonst zurück?

Das wäre eine Möglichkeit, das ihr auf dem DC wo ihr die Änderung durchführt die ausgehende (Outbound) Replikation und auf 23 DCs die eingehende Replikation deaktiviert. Somit erhält nur ein anderer DC die Änderung.

Mir schwirren einige Ideen durch den Kopf, vielleicht hat jemand von Euch mehr Erfahrung dabei?

Da ihr ja noch unsicher seit und die Auswirkungen noch nicht kennt, gehört das selbstverständlich vorher in einer Testumgebung getestet. Das Testen in der produktiven Umgebung wäre mehr als grob fahrlässig.