Domänenstruktur unter Windows Server 2008

[DeathAndPain2 10]

Hallo allerseits,

 

bisher hatten wir eine NT4-Domänenstruktur mit einer Hauptniederlassung und mehreren Zweigstellen. Jede Zweigstelle war eine eigene Domäne; alle Domänen hatten zueinander eine wechselseitige Vertrauensstellung. ActiveDirectory gab es nicht wegen NT4 Server.

 

Jede Niederlassung hat einen eigenen Server, der als Domänencontroller und zentrale Dateiablage dient. Die Niederlassungen sind miteinander durch ein MPLS-Netz verbunden. Die Anbindungsdatenraten sind je nach Niederlassung unterschiedlich, aber vielfach nur ADSL mit dementsprechend bescheidenen Datenraten in Senderichtung.

 

Jetzt rüsten wir komplett auf Windows Server 2008 auf. Dabei ergibt sich die Chance, die logische Struktur beliebig umzugestalten. Auf wikipedia habe ich gelesen, daß man unter ActiveDirectory zwar mehrere Domänen einrichten kann, aber mit so wenig wie möglich Domänen wie möglich auskommen soll. Dafür könne man ja "Sites" definieren. ActiveDirectory würde sich dann darum kümmern, den siteübergreifenden Datenverkehr gering zu halten.

 

Nun bin ich unsicher, wie ich vorgehen soll. Nur eine große, zweigstellenübergreifende Domäne? Soll dann jeder Niederlassungsserver ein Domänencontroller dieser Domäne sein? Dann hätten wir acht verstreute DCs derselben Domäne... macht das unter ActiveDirectory Sinn?

 

Und was ist mit den Dateiablagen. Derzeit hat jede Niederlassung ihre eigene Dateiablage. Den ActiveDirectory-Ansatz verstehe ich so, daß es einen Riesenbaum gibt, wo man dann die einzelnen Teildateiablagen quasi als Unterverzeichnisse reinhängt. Aber daß eine Niederlassung auf die Dateiablage der anderen zugreift, ist in der Realität die Ausnahme, und beim Browsen des Baumes hätten wir dann ständig jede Menge nutzlosen Traffics auf den Fernleitungen, nur um die entfernten Verzeichnisse aufzulisten. Oder sehe ich das falsch?

 

Momentan sagt mir mein Bauchgefühl, daß ich lieber wie bisher eine Domäne pro Zweigstelle aufsetze. Aber ich will nicht einen strategischen Fehler machen, bloß weil ich mich Neuerungen verschließe oder diese nicht hinreichend kenne.

[Daim 12]

Servus,

 

auf gehts... ran an das Konzept. ;)

 

 

Nun bin ich unsicher, wie ich vorgehen soll. Nur eine große, zweigstellenübergreifende Domäne? Soll dann jeder Niederlassungsserver ein Domänencontroller dieser Domäne sein? Dann hätten wir acht verstreute DCs derselben Domäne... macht das unter ActiveDirectory Sinn?

 

Umso weniger Domänen - desto leichter ist die Administration.

Die Anzahl an Domänen hängt z.B. davon ab, welche IT-Leute betreuen die Domäne. Wenn es die gleichen Admins sind, die den ganzen Forest betreuen, so würde sich ein Single-Domänen Forest anbieten. Denn mehrere Domänen würde man z.B. erstellen, wenn ein Standort seine eigene Sicherheitsgrenze darstellen soll. Aber ein gewiefter Admin aus der Sub-Domäne könnte sich auch Organisations-Admin Rechte erlangen. Das ist zwar nicht trivial, aber möglich. Ein weiterer Vorteil mehrerer Domänen wäre z.B., wenn man unterschiedliche DNS-Namensräume haben möchte.

 

Ich bin jederzeit ein Freund davon, einen Single-Domänen Forest, also eine Gesamtstruktur bestehend aus einer Domäne zu erstellen und das Unternehmen mit AD-Standorten sowie Organisationseinheiten abzubilden. Da aber jedes Unternehmen ein unikat ist, kann es natürlich je nach Umgebung und Anforderung Abweichungen geben. Wenn z.B. das Thema Sicherheit ganz groß sein soll, dann könnte man z.B. an eine leere Root-Domäne denken oder das erstellen mehrerer Gesamtstrukturen. Es kommt eben auf die Anforderung an.

 

Fakt ist aber, umso weniger Domänen existieren - desto leichter ist die Administration. Denn schließlich sollte in jeder Domäne gerade wegen der Ausfallsicherheit zwei DCs existieren. Dadurch entstehen hohe Hardware- sowie Softwarekosten.

 

Der Nachteil bei mehreren Domänen wären:

 

- Bei mehreren Domänen ist der adminstrative Aufwand Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte.

- Dadurch entstehen hohe Hardware- sowie Lizenzkosten.

- Jeder DC sollte/muss vor Ort physikalisch geschützt sein.

- Jede Domäne muss gesichert werden (Backup).

 

 

Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss.

Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration.

 

 

Und was ist mit den Dateiablagen. Derzeit hat jede Niederlassung ihre eigene Dateiablage. Den ActiveDirectory-Ansatz verstehe ich so, daß es einen Riesenbaum gibt, wo man dann die einzelnen Teildateiablagen quasi als Unterverzeichnisse reinhängt. Aber daß eine Niederlassung auf die Dateiablage der anderen zugreift, ist in der Realität die Ausnahme, und beim Browsen des Baumes hätten wir dann ständig jede Menge nutzlosen Traffics auf den Fernleitungen, nur um die entfernten Verzeichnisse aufzulisten. Oder sehe ich das falsch?

 

Erstmal hat eine Dateiablage - also ein File-Server - nichts mit dem AD zu tun.

Das AD ist ein Verzeichnisdienst, mit dem das Netzwerk verwaltet wird. Auch in einer AD-Umgebung kannst du weiterhin deinen Fileserver betreiben, wie du es bisher getan hast. Also es kann und sollte an jedem Standort sein eigener Fileserver weiterhin existieren.

 

 

... to be continued.

[Daim 12]

Momentan sagt mir mein Bauchgefühl, daß ich lieber wie bisher eine Domäne pro Zweigstelle aufsetze. Aber ich will nicht einen strategischen Fehler machen, bloß weil ich mich Neuerungen verschließe oder diese nicht hinreichend kenne.

 

Mein Bauchgefühl sagt mir aber, dass du besser mit einer einzigen Domäne fahren würdest. Wie gesagt, dass Domänen-Modell kann variieren. Du kannst später wenn du mit dem "Einen-Domänen-Modell" nicht glücklich bist, jederzeit umstellen und Sub-Domänen erstellen. Was die Administration betrifft, kannst du gezielte Berechtigungen im Active Directory an deine Kollegen delegieren. Im AD steckt schon einiges drin. ;)

 

Siehe:

Yusuf`s Directory - Blog - Objektdelegierungen einrichten

 

 

Jetzt kommt aber noch der Aspekt des Windows Server 2008 hinzu, in dem die Domänensicherheit dank des RODCs und Server Core erheblich erhöht wurde. Aber bevor wir hier tiefer in die Materie des Windows Server 2008 einsteigen, lies dir bitte diese Artikel durch:

 

Yusuf`s Directory - Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Yusuf`s Directory - Blog - Windows Server 2008 Core

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

 

 

Aber egal wie, du solltest dir für dieses Vorhaben externe Hilfe beiziehen, damit ein entsprechendes Konzept erarbeitet wird.

[DeathAndPain2 10]

Erst mal vielen Dank für die ausführlichen Erläuterungen. Es gibt aber in unserem Fall einige Gesichtspunkte, die zu berücksichtigen sind.

 

Fakt ist aber, umso weniger Domänen existieren - desto leichter ist die Administration. Denn schließlich sollte in jeder Domäne gerade wegen der Ausfallsicherheit zwei DCs existieren. Dadurch entstehen hohe Hardware- sowie Softwarekosten.

Wir arbeiten schon seit vielen Jahren ohne BDC in den Zweigstellen. Nur das Stammhaus hat einen. Bedenke, daß die Domänencontroller in den Zweigstellen eigentlich nur der Benutzeranmeldung sowie als Dateiablageserver für Office-Dateien dienen. Selbst letztere Funktionalität hat nur mäßige Bedeutung, da der Schwerpunkt der Arbeit bei uns im SAP liegt. Wenn ein Domänen-DC ausfällt, dann können sich die Benutzer immer noch mit cached credentials anmelden und schaffen es damit bis ins SAP, da SAP von der Windows-Domänenstruktur völlig unabhängig läuft. Es würde unproblematisch reichen, wenn sich in so einem Fall ein Admin ins Auto setzt, in die Niederlassung fährt und ein paar Stunden später der dortige DC wieder läuft (Image wieder eingespielt; notfalls Hardware getauscht). Die Ausfalltoleranz der DCs in den Niederlassungen ist also sehr groß.

 

- Jeder DC sollte/muss vor Ort physikalisch geschützt sein.

In der Vergangenheit war das sowieso unumgänglich, daher existieren überall vernünftige Serverräume. Das haben wir also sowieso schon.

 

- Jede Domäne muss gesichert werden (Backup).

Nicht wirklich. Die Zweigstellen haben nicht allzu viele Mitarbeiter. Es genügt, ein Festplattenimage der Systempartition zu haben, mit dem man den DC schnell wieder aufsetzen kann. Wenn danach 5 Benutzer händisch wieder eingepflegt werden müssen, dann ist das für eine Totalcrashsituation ein sehr überschaubarer Aufwand.

 

Gebackupt werden müssen natürlich die Dateiablagen in den Zweigstellen. Das ist aber so oder so der Fall, egal ob da ein DC steht oder nicht. Wir lösen das Problem durch einen nächtlichen Robocopy, der auf einem dafür vorgesehenen Backup-Server im Stammhaus als Task eingeplant ist. So haben wir stets ein Backup sämtlicher Niederlassungs-Dateiablagen auf einer Festplatte, die täglich getauscht wird.

 

Erstmal hat eine Dateiablage - also ein File-Server - nichts mit dem AD zu tun.

Das AD ist ein Verzeichnisdienst, mit dem das Netzwerk verwaltet wird. Auch in einer AD-Umgebung kannst du weiterhin deinen Fileserver betreiben, wie du es bisher getan hast. Also es kann und sollte an jedem Standort sein eigener Fileserver weiterhin existieren.

Das ist mir klar. Aber wenn ich das richtig verstanden habe, wird solch lokaler Fileserver dann in den AD-Baum wie ein virtuelles Unterverzeichnis reingehängt? 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? Oder sehe ich das falsch?

 

Was die Administration betrifft, kannst du gezielte Berechtigungen im Active Directory an deine Kollegen delegieren. Im AD steckt schon einiges drin.

Das ist ein Vorteil, aber auch eine Gefahr. Unsere gesamte EDV besteht niederlassungsübergreifend aus zwei Hansels. Ob das sinnvoll ist, steht an dieser Stelle nicht wirklich zur Debatte. :D Das bedeutet, daß wir die Dinge einfach und klar halten müssen. Rollenabhängige Berechtigungsstrukturen und Teiladminberechtigungen wird es hier wohl nicht geben. Das wäre für uns gar nicht wartbar.

[DeathAndPain2 10]

Auf der einen Seite spricht das natürlich schon für die Ein-Domänen-Struktur. 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. 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.

 

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.

 

Andererseits kann es natürlich hilfreich sein, die gesamte Pflege zentral auf einem Server vornehmen zu können und sich über die Verteilung der Informationen auf die Niederlassungen keinen Kopf mehr machen zu müssen. Auch das Konzept des RODCs ist mir nicht unsympathisch.

 

Wichtig ist aber meines Ermessens, daß es so wenig wie möglich Virtualisierungen gibt, denn die machen das Gesamtsystem immer undurchschaubar. Deswegen finde ich auch Windows Vista so furchtbar: Auf der Platte wird so viel mit Junction Points (Hardlinks) gearbeitet, daß man oft gar nicht mehr weiß, in welchem Verzeichnis man sich gerade befindet. Das kriegt man oft nur über die Kommandozeile raus, denn im Windows Explorer ist diese Virtualisierung nicht richtig abschaltbar. Damit kann man gut arbeiten, solange alles funktioniert. Aber wehe, es klemmt mal was: Wenn die Windows-Automatismen versagen, dann ist man darauf angewiesen, sich manuell ein Bild zu verschaffen. Und wenn einen die Virtualisierungen dann auf's Glatteis führen, dann hat man richtig ein Problem.

 

AD mit nur einer Domäne kann also Sinn machen, wenn:

• es möglich ist, einen klar strukturierten Baum zu schaffen, dem man immer noch auf Anhieb ansehen kann, was zu welcher Niederlassung gehört
  
• der Traffic auf den Fernleitungen gesicherterweise minimal ist, d.h. nicht nennenswert über dem liegt, was bei getrennten Domänen entstehen würde
  

 

Denkst Du, daß das realisierbar ist?

 

P.S.: Der Artikel mit dem Hinzufügen eines 2008 DC zu einer bestehenden Struktur war zwar interessant, aber für uns nicht wirklich relevant, da wir mit Sicherheit nicht unsere alte Struktur schrittweise hochrüsten werden, sondern wirklich migrationsmäßig etwas Neues aufsetzen. Bedeutet: der NT4-Kram läuft vorerst weiter, während ich im Hintergrund die 2008-Struktur auf neuen Servern zusätzlich frisch aufsetze, frei von altem Ballast. Von den alten Servern rüberkopiert werden nur die Nutzdaten, also die Dateiablage. 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. Wenn das geklappt hat, fliegen die alten Server auf den Elektroschrott und der Fall ist erledigt. Du kannst also von einer kompletten Neuinstallation ausgehen.

[NorbertFe 1.856]

Wir arbeiten schon seit vielen Jahren ohne BDC in den Zweigstellen. Nur das Stammhaus hat einen.

 

Bei NT4 kann man auch ganz anders agieren. Allerdings überlege ich grad, was die Anzahl deiner DCs mit der Aussage zu tun hat, dass du mit einer Single Domain besser fahren würdest.

 

unabhängig läuft. Es würde unproblematisch reichen, wenn sich in so einem Fall ein Admin ins Auto setzt, in die Niederlassung fährt und ein paar Stunden später der dortige DC wieder läuft (Image wieder eingespielt; notfalls Hardware getauscht). Die Ausfalltoleranz der DCs in den Niederlassungen ist also sehr groß.

[/Quote]

 

Wenn du das im AD machst, ohne zu wissen was genau dabei zu beachten ist, hast du ganz schnell kein AD mehr. ;)

 

Nicht wirklich. Die Zweigstellen haben nicht allzu viele Mitarbeiter. Es genügt,

ein Festplattenimage der Systempartition zu haben, mit dem man den DC schnell wieder aufsetzen kann. Wenn danach 5 Benutzer händisch wieder eingepflegt werden müssen, dann ist das für eine Totalcrashsituation ein sehr überschaubarer Aufwand.

 

Dazu sag ich lieber nix.

 

 

Das ist ein Vorteil, aber auch eine Gefahr. Unsere gesamte EDV besteht niederlassungsübergreifend aus zwei Hansels. Ob das sinnvoll ist, steht an dieser Stelle nicht wirklich zur Debatte. :D Das bedeutet, daß wir die Dinge einfach und klar halten müssen. Rollenabhängige Berechtigungsstrukturen und Teiladminberechtigungen wird es hier wohl nicht geben. Das wäre für uns gar nicht wartbar.

 

 

Noch ein Grund mehr, nur mit Single Domain zu arbeiten.

 

Bye

Norbert

–

 

AD mit nur einer Domäne kann also Sinn machen, wenn:

• es möglich ist, einen klar strukturierten Baum zu schaffen, dem man immer noch auf Anhieb ansehen kann, was zu welcher Niederlassung gehört
  
• der Traffic auf den Fernleitungen gesicherterweise minimal ist, d.h. nicht nennenswert über dem liegt, was bei getrennten Domänen entstehen würde
  

 

Denkst Du, daß das realisierbar ist?

 

 

Ja.

 

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.

 

Und Userprofile usw. interessieren dich nicht?

 

Bye

Norbert

[Daim 12]

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.

[Daim 12]

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.

[DeathAndPain2 10]

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

Es gibt aber dazu keine Alternative, sondern allenfalls Ergänzungen. Die von Dir verlinkten Artikel sind zwar sehr lehrreich und für mich sicherlich auch hilfreich, vielen Dank. 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, wenn ich einen Plattencrash hatte und gerade die neue Festplatte eingebaut habe. Dann habe ich nämlich zunächst einmal keinen DC mehr; ich habe dann noch nicht einmal einen Windows Server 2008. Und bei dieser schlimmstmöglichen Situation muß ein Restore ansetzen. Nicht bei einem laufenden Server, der aus irgendwelchen Gründen ein paar AD-Einstellungen vergessen hat.

 

Ein Online-Backup bei laufender Datenbank wäre natürlich auch reichlich naiv, sofern er nicht auf die Datenbank zugeschnitten ist, also einen korrekten Full-Online-Backup samt Archivdateien anlegt.

 

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. 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.

 

Allerdings haben mich Deine Artikel und Hinweise auf wichtige Fallstricke dabei hingewiesen und waren insofern sehr wertvoll. So, wie ich das jetzt sehe, sollte man das Image anlegen, bevor man den Server überhaupt in die Domäne reinnimmt. Dann sind auch keine alten AD-Daten im Image, die später zu Problemen führen könnten. Auf diesem Image könnte man dann die AD-Wiederherstellung entsprechend der faq-o-matic-Anleitung aufsetzen. Kann man aber auch bleiben lassen, weil der Server sich sowieso synchronisiert, wenn man ihn in die Domäne reinnimmt und zum DC macht.

 

In meinem Kopf formt sich jetzt folgendes Bild. Bitte sagt mir, ob es daran was auszusetzen gibt:

• Wir arbeiten nur mit einer Domäne.
  
• Im Stammhaus stehen zwei vollwertige Domänencontroller, die sich im Falle eines Crashes wechselseitig ersetzen können.
  
• In den Niederlassungen stehen DCs, die sich mit dem Stammhaus synchronisieren.
  
• 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.

 

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 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?

 

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

[DeathAndPain2 10]

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.

 

Wäre ein Backup des AD notwendig, um menschliches Versagen aufzufangen? (Im Gegensatz zu Hardwarecrashes werden menschliche Bedienungsfehler ja im gesamten AD repliziert.) 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.

 

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

 

Nein, oder sprichst du evtl. von DFS?

Möglicherweise habe ich da was durcheinandergebracht, ja. 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?

 

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.

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. 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. Und da ist die Frage, ob es nicht schneller geht, die neuen Gruppen händisch unter 2008 anzulegen und die Benutzer einzutragen. Zumal wir ja auch keine versteckten Konfigurationsleichen aus dem alten NT4 mit in das neue System rüberschleppen wollen. 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.

 

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.

[Daim 12]

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.

[Daim 12]

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.

[Daim 12]

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. ;)

[Daim 12]

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.

[DeathAndPain2 10]

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.

Der Artikel beschäftigt sich nur mit der Wiederherstellung des AD. Er geht davon aus, daß man bereits (wieder) einen Windows Server 2008 hat, auf dem man AD wiederherstellen kann. Das ist ein Fakt.

 

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

 

Prinzipiell zwar korrekt, aber wie gesagt, eine ASR-Sicherung wäre z.B. eine Alternative.

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, aber:

 

ASR will try to restore all the disk configurations, but under some circumstances it might not be able to. ASR then installs a simple installation of Windows and automatically starts a restoration using the backup created by the ASR Wizard.

Das ist ein viel komplexerer, fehlerträchtigerer und auch zeitlich längerdauernderer Vorgang als das Zurückspielen eines Festplatten-Images. Wo läge in dem von mir geschilderten Szenario der Vorteil? Wenn ich die Platte als leeren, frischen 2008 Server aus dem Image wiederherstelle, dann ist das innerhalb weniger Minuten abgeschlossen. 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?

 

Warum soll ich eine Wissenschaft aus dem Backup/Restore machen, wenn es so viel einfacher und dennoch zuverlässig geht? Nur damit ich mir selber auf die Schulter klopfen kann, daß ich offizielle Microsoft-Werkzeuge verwende?

 

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

 

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

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

 

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. Wenn ich von jedem einzelnen Server ein eigenes Systempartitionsimage halte, dann brauche ich zwar mehr Speicherplatz zum Speichern der Images, aber brauche noch nicht einmal zu anonymisieren. 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?