Domänenstruktur unter Windows Server 2008

[twenty 12]

Baue eine Testdomäne mit 3 Domäncontrollern auf. "Töte" einen DC und versuche ihn auf Deine Art und Weise wieder herzustellen. Versuche das selbe noch einmal mit den Vorschlägen meiner Vorposter.

 

Ergebnis: Ein Backup ist unbedingt notwendig. Alles andere ist grob fahrlässig.

 

Du kannst einen DC nicht ohne Backup des Systemstate wieder herstellen. Du kannst nur einen "neuen" hinzufügen. Der verstorbenen DC muss mühsam aus dem AD entfernt werden. Das ist mehr Aufwand als ein vernünftiges Backupkonzept zu erstellen und warten.

[Daim 12]

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?

[Daim 12]

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.

[DeathAndPain2 10]

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

 

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?

Wir haben insgesamt nur etwas über 100 Benutzer, und die sind ja auch nicht alle in derselben OU. Während Du also im Prinzip recht hast, wäre das in unserem Fall nicht so tragisch.

 

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.

Schau mal, in allen unseren NT4-Domänen gibt es z.B. einen RAS-User, der früher für administrative ISDN-Einwahlen in die einzelnen Niederlassungen verwandt wurde. Das war noch vor meiner Zeit; das Netz war damals wie ein Schweizer Käse: In jede Niederlassung konnte man sich per ISDN direkt reinwählen, wenn man Nummer und Paßwort kannte.

 

Das haben wir irgendwann beseitigt, aber die komischen Einwahluser sind geblieben. Sie lassen sich auch nicht löschen; der NT4 Server verweigert die Löschung. Ich habe das Thema vor Jahren mal hier im Forum angesprochen. (Link)

 

Na gut, der Zombieuser ist deaktiviert und richtet weiter keinen Schaden an. Aber wenn wir jetzt mit 2008 was ganz Neues anfangen, dann wollen wir doch nicht so einen Dreck importieren!

 

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.

Das ist mir klar, aber:

• Die Berechtigungen sind bei uns fast alle auf Gruppenebene und nicht auf Benutzerebene vergeben. Es genügt also, die Gruppen neu einzurichten und die Benutzer beim Neuanlegen in ihre jeweilige Gruppe wieder einzutragen.
  
• Wir tauschen ja nicht nur das OS, sondern auch die gesamten Server. Die Verzeichnisstruktur wird also auch neu angelegt. Möglicherweise könnte man zwar mit entsprechenden Parametern beim XCOPY-Befehl die Zugriffsrechtinformationen mitkopieren, aber ich denke, nach Jahren ist dies eine gute Gelegenheit, da nochmal händisch einen Blick drauf zu werfen und alte Zöpfe abzuschneiden.
   
  Beispielsweise gibt es bei uns in jeder Domäne einen Ordner "Allgemein", in dem jeder Schreibberechtigung hat. Ursprünglich (noch zu Zeiten vor Interneteinführung) war das mal als Tauschbörse gedacht, damit Benutzer Dateien tauschen können, die wechselseitig keine Schreibrechte im Gruppenverzeichnis des jeweils anderen haben. Aber solch Allgemein-Ordner ist sehr bequem und wurde daher zunehmend als Dauerdatenspeicher mißbraucht. Mittlerweile herrscht dort das blanke Chaos an Verzeichnissen und Dateien unklarer Zugehörigkeit. Sowas will man nicht 1:1 in die neue Struktur übernehmen.
  

 

Was machst du denn mit den Benutzerprofilen?

Die sind bei uns lokal. Wir haben früher mit serverbasierten Profilen gearbeitet und schlechte Erfahrungen damit gemacht. War viel zu viel administrativer Aufwand, das zu pflegen, und das Verkehrsaufkommen war teilweise sogar schon im LAN zu groß, wenn einige Spezialisten sich große Dateien eben mal auf den Desktop gelegt hatten. Da arbeiten wir lieber mit lokalen Profilen und leben damit, daß eben ein neues Profil erstellt wird, wenn ein Anwender mal den PC wechselt.

 

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

[Daim 12]

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.

[DeathAndPain2 10]

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

Ja, Anti-Schlupf-Regelung. Gewinnt man an der Ampel jedes Stechen mit. :D

 

ASR findet man schon, aber leider noch hauptsächlich für die Vorgängerversionen von Windows. 2008 ist halt noch sehr neu.

 

Ich sage dir, wenn du mit ADMT migrierst, sparst du dir eine Menge Arbeit

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.

 

Wenn du nun in der neuen Domäne den Benutezr neu einrichtest, erhält der User ein neues Profil.

Das erhält er jedes Mal, wenn er sich auf einem PC einloggt, auf dem er noch nie eingeloggt war. Aber das hake ich unter "Schicksal" ab. Es steht ihm frei, mit dem Defaultprofil zu arbeiten oder sein Hintergrundbild eben auch hier wieder einzupflegen.

 

Also musst du dann das alte Profil umkopieren, mit all seinen Macken.

Warum sollte ich das tun? Neue Domäne, neue Profile. Die erzeugt Windows bei der Erstanmeldung automatisch, und wenn die Anwender meinen, daran noch was optimieren zu müssen, dann können sie das gerne selber machen.

[Daim 12]

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.

[DeathAndPain2 10]

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

Was das angeht: A-Karte gezogen. Firmenrichtlinie ist ganz klar, daß Dateien von Bedeutung - insbesondere Word und Excel-Dokumente - auf dem Netzlaufwerk L: abzulegen sind, das auf den jeweiligen Zweigstellenserver verweist. Nur davon wird auch ein regelmäßiger Backup gemacht. Wer auf seiner lokalen Festplatte was ablegt, riskiert, daß es verloren geht - und sei es durch einen Plattencrash.

 

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

Ja. Du hast mir sehr geholfen, vielen Dank!!