Für die meisten virtuellen Umgebungen ist es problemlos möglich, den Prozessor zu “überbuchen”, d.h. den virtuellen Servern mehr CPUs zuzuweisen, als tatsächlich physisch im Host-Server vorhanden sind. Zu den Hauptaufgaben des Hypervisors gehört es ja schließlich, den VMs Rechenzeit zuzuteilen. Im Falle von Hyper-V 2.0 (als mit Windows Server 2008 R2 auf dem Hostsystem) gilt ein Verhältnis zwischen 4:1 und 8:1 als sinnvoll. Microsoft leistet bei Servervirtualisierung Unterstützung für ein Verhältnis von bis zu 8:1; nur für VDI-Umgebungen (virtuelle Desktops) mit virtuellen Windows-7-Rechnern liegt die Grenze bei 12:1.

Was aber bedeuten diese Angaben?

Ein typischer Host-Server für Virtualisierung hat heute zwei physische CPUs mit jeweils vier CPU-Kernen (Cores). Auf diese Cores kommt es an. Das ebenfalls einsetzbare Hyper-Threading erhöht zwar in bestimmten Zusammenhängen die Zahl der “sichtbaren” Prozessoren, ist im Fall der Virtualisierung aber nicht von Interesse. Unser Beispielserver hat also acht CPU-Kerne, die er für die Virtualisierung einsetzen und an die VMs verteilen kann.

Ein Verhältnis von 4:1 bedeutet nun, dass jeder CPU-Kern in vier virtuelle CPUs (vCPUs) “aufgeteilt” wird. Das ist ein rein rechnerischer Vorgang, der besagt, dass ein CPU-Kern problemlos vier CPUs für virtuelle Maschinen darstellen kann (also treibt jeder Kern in einem Viertel der verfügbaren Zeit jeweils eine bestimmte VM an). Diese rechnerische Größe ergibt in unserem Beispiel nun also vier mal acht, sprich 32 vCPUs, die auf die VMs verteilt werden können. Legt man ein Verhältnis von 8:1 zugrunde, so kommt man sogar auf 64 vCPUs.

Direkt umgerechnet hieße das nun also für das Verhältnis 4:1, dass auf dem Server bis zu 32 virtuelle Server mit jeweils einer virtuellen CPU problemlos laufen sollten. Beim Verhältnis 8:1 käme man sogar auf 64 VMs zu je einer vCPU. Weist man einzelnen VMs mehr als eine vCPU zu, so verändert sich natürlich die Gesamtzahl an möglichen VMs.

Vorsicht: Der Host muss auch arbeiten!

Viele Admins übersehen aber, dass auch der Host selbst für seine Arbeit Reserven braucht, und zwar sowohl Arbeitsspeicher als auch CPU-Leistung. Eine Faustformel besagt, dass man “einen halben Core” an CPU-Leistung und zwei bis vier Gigabytes an RAM für den Host reservieren sollte. Macht bei der Grundlage 4:1 also zwei vCPUs, bei der Grundlage 8:1 vier vCPUs, die man für den Host zurückhält, also nicht an VMs zuweist.

Bleiben bei der 4:1-Zuordnung also 30 vCPUs und bei der 8:1-Aufteilung 60 vCPUs für die tatsächlichen VMs. Wie oben erwähnt, stellt bei einer solchen Leistungsreserve aber sicher der Arbeitsspeicher das tatsächliche Limit dar.

Immer rein – kost ja nix!?

Diese große Reserve sollte nun aber nicht dazu verleiten, den virtuellen Servern einfach ein paar mehr CPUs zuzuordnen, nach dem Motto “viel hilft viel, und wir haben’s ja”. Leider haben die letzten Jahre bei “echten”, also physischen Servern dazu geführt, dass die allermeisten Systeme hoffnungslos überdimensioniert waren. Solche Server verfügen über CPU und RAM im Überfluss, weil man ja schlicht keine Maschinen mit geringerer Ausstattung mehr bekam.

In der Virtualisierung wäre das aber ein Irrweg. Hier gilt die Devise “so wenig wie möglich”. Ein Server, der nicht mehr als eine CPU braucht, sollte also auch als VM nicht mehr als eine vCPU bekommen. Sonst steht man schnell vor dem Problem, dass man die Ressourcen des Hosts zu großzügig verteilt und damit unflexibel wird.

Mehrfach-CPUs in virtuellen Servern haben aber auch einen weiteren Nachteil: Eine VM mit vier vCPUs kann vom Hypervisor immer nur dann Rechenzeit erhalten, wenn gleichzeitig vier “echte” CPU-Cores frei sind (denn nur die echten CPUs können ja die Rechenarbeit erledigen). Hat der Admin zu großzügig verteilt und viele Server mit einer, zwei und vier vCPUs auf seinem Host gemischt, kann es bei hoher Auslastung durchaus sein, dass der Hypervisor nur selten vier CPU-Kerne gleichzeitig an eine VM zuteilen kann. Im Effekt wäre eine solche VM also “langsamer” als erwartet, weil ihre vier virtuellen CPUs ständig auf Rechenzeit warten, aber nur selten welche bekommen. Zwar tritt ein solches Phänomen nur in Grenzsituationen auf, aber dann ist es um so nachteiliger.

Rechnerisch vs. real

Diese Berechnungsgrundlagen gelten vor allem für produktive Systeme, für die ein verlässliches Leistungsniveau wichtig ist und für die der Support durch den Hersteller gewahrt bleiben muss. Es gibt keine “harte” Limitierung auf ein bestimmtes Verhältnis von virtuellen zu realen CPUs. In einem Testsystem wird man problemlos auch höhere Dichten als 8:1 hinbekommen. Nur endet eben der Microsoft-Support für VM-Server bei 8:1, weil die Praxis in anspruchsvollen Umgebungen zeigt, dass bei höherer Dichte allzu oft Engpässe auftreten. Für andere Virtualisierer gelten übrigens sehr ähnliche Berechnungsformeln.

Vorsicht auch: Bei bestimmten Applikationen kann es durchaus sein, dass der Applikationshersteller striktere Limitierungen setzt. Bevor man also seine Hosts zu voll packt, ist Planung und Recherche angesagt.

Mehr dazu:

[Ratio vCPU vs. LP mit SP1 erhöht - German Virtualization Blog - Site Home - TechNet Blogs]
http://blogs.technet.com/b/germanvirtualizationblog/archive/2011/01/12/ratio-vcpu-vs-lp-mit-sp1-erh-246-ht.aspx

[Requirements and Limits for Virtual Machines and Hyper-V in Windows Server 2008 R2]
http://technet.microsoft.com/en-us/library/ee405267(WS.10).aspx

Verwandte Beiträge:

1. Virtuelle DCs: Zeitprobleme vermeiden
   Wer Domänencontroller als virtuelle Maschinen betreibt, sollte besonderes Augenmerk auf...
2. Zwei Hyper-V-FAQs: Pagefile und Hyper-Threading
   Zwei oft gestellte, aber nur selten beantwortete Fragen zu Hyper-V...
3. Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte
   Beinahe täglich beantworte ich die Frage erstaunter Anwender, warum auf...

Technisch ist es möglich, Dienste in der Parent Partition (“auf dem Host”) auszuführen. Es ist aber dringend davon abzuraten – je nach Applikation ist diese Konfiguration sogar “unsupported”, denn: Anders als viele annehmen, ist der “Host” mitnichten unbeschäftigt, wenn er keine weiteren Dienste ausführt. Ganz im Gegenteil steht er bei allen Virtualisierern ziemlich unter Dampf, denn er führt ja die VMs aus!

Bei Hyper-V und den anderen Paravirtualisierern kommt noch ein weiterer Umstand dazu: Jeder I/O (also jeder Netzwerk- oder Storage-Zugriff) wird durch die Parent Partition geleitet, weil dort die Treiber installiert sind. Wenn die Parent Partition nun noch weitere Dienste ausführen muss, stehen die dafür nötigen Ressourcen nicht dem VMs zur Verfügung. Wer also weitere Dienste auf dem “Host” installiert, schadet seiner gesamten Virtualisierungsumgebung.

Es gibt aber auch Sicherheitsprobleme, wenn neben Hyper-V weitere Anwendungen laufen. Da die Parent Partition in Hyper-V (ebenso wie etwa in XenServer) eine privilegierte Stellung hat und über den VMBus den gesamten ein- und ausgehenden Datenverkehr sämtlicher VMs steuert, darf sie nicht kompromittiert werden. Schon dadurch verbietet sich der Einsatz weiterer Dienste auf dem “Host”.

Dazu kommt, dass die Netzwerkkonfiguration der Parent Partition sich verändert, sobald man Hyper-V aktiviert. Jede zugewiesene Netzwerkkarte wird zu einem virtuellen Switch, und die VMs erhalten zugriff auf virtualisierte (“synthetische”) Netzwerkkarten. Jeder nicht durch Hyper-V kontrollierte Netzwerkzugriff wird so zu einem immensen Risiko für Stabilität und Sicherheit.

Und nicht zuletzt gibt es auch lizenzrechtliche Einschränkungen*: Wer die Standard- oder Enterprise Edition von Windows Server 2008/R2 einsetzt, bekommt mit der Lizenz für den physischen Server eine bzw. vier VM-Lizenzen mitgeliefert. Man darf mit derselben Lizenz, die auf der Hardware “installiert” ist, also eine bzw. bis zu vier VMs mit Windows Server 2008/R2 betreiben, ohne zusätzlich Geld auszugeben. Das gilt aber nur, solange die physische Installation nichts außer der Hyper-V-Rolle ausführt (sowie die direkt dazu gehörenden Management-Werkzeuge). Aktiviert man “auf dem Host” eine weitere Rolle oder installiert einen zusätzlichen Dienst, so benötigt auch die Parent Partition eine eigene, separate Lizenz.

Also: Ein Hyper-V-Host ist ein Hyper-V-Host ist ein Hyper-V-Host. Er ist kein Fileserver, DC, Backupserver oder was auch immer. Solche Dienste installiert man als VM und lässt sie dann innerhalb von Hyper-V laufen. Ein totales No-Go ist es, die Hyper-V-Rolle nachträglich auf einem Produktionsserver zu aktivieren, der bereits Dienste ausführt.

Dabei ist natürlich auch zu berücksichtigen, dass die Parent Partition über genügend Reserven verfügen muss, um ihrer Aufgabe gerecht zu werden. Ein Daumenwert sind 2-4 GB Speicher und eine bis zwei vCPU für den Host (entspricht “einem halben bis ganzen Core”). Gönnt man ihm zu wenig, wird die gesamte VM-Umgebung des Servers instabil laufen und vor Performanceproblemen stehen.

(*Aussagen zu Microsofts Lizenzbedingungen sind hier nicht rechtsverbindlich und dienen nur der Illustration der Zusammenhänge.)

Verwandte Beiträge:

1. Hyper-V Dynamic Memory: Reservierung für den Parent
   Toni Pohl vom österreichischen TechNet-Team weist auf einen Umstand hin,...
2. Zwei Hyper-V-FAQs: Pagefile und Hyper-Threading
   Zwei oft gestellte, aber nur selten beantwortete Fragen zu Hyper-V...
3. Warum kann ein Benutzer Dateien ändern, für die er keine Rechte hat?
   Benutzer können Dateien löschen, auf die sie keinen Zugriff haben....

Trotzdem bleibt die wichtige Frage, wie viel physische Technik man denn aufwenden muss, um die vorhandene Infrastruktur zu virtualisieren. Um sie zu beantworten, bieten einige Hersteller ihre Werkzeuge an. Neben kommerziellen Anwendungen, die mit vielen ausgefeilten Funktionen glänzen, gibt es auch ein kostenloses Programm von Microsoft, das die grundlegenden Fragen durchaus ordentlich beantworten kann. Insbesondere wenn man eine Virtualisierung mit Hyper-V plant, bietet das Microsoft Assessment and Planning Toolkit (MAP) eine wertvolle und doch kostenlose Handreichung.

Die Software findet sich hier mit einem allgemeinen Überblick zum kostenlosen Download:

[Microsoft Assessment and Planning Toolkit]
http://technet.microsoft.com/en-us/library/bb977556.aspx

Wie alle Anwendungen dieser Art sammelt auch MAP die realen Leistungsdaten der zu virtualisierenden (Windows-) Server und schreibt sie in eine zentrale Datenbank. Von dort können sie für Reports und Empfehlungen ausgewertet werden. Diese Auswertung übernimmt das Tool selbst und erzeugt auf Basis leistungsfähiger Algorithmen Empfehlungen für die Platzierung der virtuellen Maschinen auf physischen Hosts.

Sinnvollerweise lässt man MAP die Leistungsdaten über einen längeren Zeitraum sammeln, etwa eine oder mehrere Wochen, damit ein realistischer Ausschnitt entsteht, der auch Lastspitzen berücksichtigt. Die Sammlung erfolgt über die WMI-Schnittstelle der Windows-Zielsysteme und sollte nicht unterbrochen werden – eine der Einschränkungen von MAP ist, dass es seine Sammlung in einem zusammenhängenden Vorgang ausführen will.

Zur Installation reicht ein XP- oder Vista-System aus, auf dem Office 2003 oder 2007 installiert ist. Anspruchsvolle Umgebungen werden ein Serversystem vorziehen. Auf jeden Fall sollte man auf großzügigen Arbeitsspeicher Wert legen. Ein Dokument, das dem Download beiliegt, macht nähere Angaben.

MAP installiert eine eigene Instanz von SQL Server Express. Zwar ist es technisch möglich, auf einen vorhandenen SQL Server zuzugreifen, doch es empfiehlt sich nicht besonders, denn MAP erwartet eine SQL-Instanz namens “MAP”, auf die es exklusiven Zugriff hat. Der Grund dafür ist, dass auf diese Weise zahlreiche Vorgänge in der Datenbank recht schlank und effizient abgehandelt werden können – auch wenn es eigentlich nicht der eleganteste Weg ist. Also: Bei der Vorgabe bleiben und SQL Express nutzen.

Die Office-Installation auf dem MAP-Rechner ist nötig, damit MAP seine Analysen und Reports erzeugen kann. Dazu benötigt es auch die Microsoft Office Primary Interop Assemblies. Anders als in der Setup-Anleitung angegeben, befinden sich diese für Office 2007 nicht auf der Office-CD, sondern als Download auf Microsofts Webseite.

[Download details: 2007 Microsoft Office System Update: Redistributable Primary Interop Assemblies]
http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&DisplayLang=en

Durch diese und andere Voraussetzungen dauert es ein wenig, bis man mit der MAP-Installation loslegen kann. Ist es einmal geschafft, dann bietet MAP eine ganze Reihe an Assistenten zur Analyse. Derjenige, der hier interessiert, ist der Server Virtualization and Consolidation Wizard, der in zwei Phasen vorgeht. In der ersten Phase sind die Leistungsdaten zu sammeln, die das Werkzeug dann in der zweiten Phase auswertet.

Schritt für Schritt: Daten sammeln und auswerten

Phase 1: Daten sammeln

Schritt 1: Anlegen oder auswählen der Datenbank, in der MAP die gesammelten Leistungsdaten ablegt. Für jede Sammlung erzeugt MAP eine komplett neue Datenbank in der MAP-Instanz des SQL Server. Achtung: Die Zugriffsrechte werden für den User gesetzt, der MAP ausführt. Danach wählt man die Option “Capture performance metrics for server consolidation”.

Schritt 2: Um die Rechner auszuwählen, für die MAP die Leistungsdaten sammeln soll, bereitet man eine Textdatei vor. Diese enthält die Namen der Server, je ein Name pro Zeile. Diese Datei gibt man hier im Assistenten an, und man wird sie meist auch später in der Auswertungsphase nutzen.

Schritt 3: MAP verbindet sich per WMI mit den auszuwertenden Servern. Dazu sind Adminrechte auf den Zielrechnern nötig. In einer Domäne wird man meist ein Domänen-Adminkonto oder einen vergleichbaren Account angeben können, doch der Assistent lässt auch eine Angabe mehrerer Konten zu, die MAP dann der Reihe nach durchprobiert.

Schritt 4: Das war es auch schon fast. MAP legt sofort mit seiner Datensammlung los und beendet diese zu einem definierten Zeitpunkt. Achtung: Um einen Virtualisierungs-Report zu erzeugen, benötigt MAP pro Server mindestens 24 Datensätze. Da es diese alle 5 Minuten sammelt und auch mal ein Abfrageintervall erfolglos bleiben kann, sollte man auch für erste Tests mindestens zweieinhalb Stunden vorgeben.

Schritt 5: Nun sammelt MAP eine Weile.

Phase 2: Auswerten und empfehlen

Schritt 1: Nach dem Abschluss der Datensammlung wählt man die Option “Prepare recommendations for server consolidation”. Der Assistent fragt dann die einzusetzende Virtualisierungsplattform ab – im Regelfall wohl Hyper-V.

Schritt 2: Nun kann man dem MAP vorgeben, welche Hardwareklasse man für Hyper-V einzusetzen gedenkt. Die wichtigsten Eckdaten typischer Hardware lassen sich auswählen. Das wiederholt sich noch mal für die Platten- und die Netzwerkausstattung.

Schritt 3: Nach Abschluss des Reportings offenbart sich eine weitere Beschränkung des MAP: Es legt seine Reports im Dokumente-Ordner des Benutzers ab, der MAP gestartet hat. Das lässt sich auch nicht konfigurieren. Wer MAP also per runas mit einem anderen Konto ausgeführt hat, kommt nur auf Umwegen an die Dokumente heran (ein Word- und ein Excel-Dokument). Der folgende Screenshot zeigt, wie man es hinkriegt:

Wer direkt mit dem MAP-ausführenden Konto angemeldet ist, kann natürlich gleich die Excel- und Worddateien öffnen. Die Excel-Datei mit dem Namensteil “Recommendations” gibt ausführliche Daten an, warum MAP eine bestimmte Verteilung von VMs auf die physischen Hosts empfiehlt. Das Word-Dokument begründet diese Auswahl ausführlich, allerdings nur auf Englisch.

Verwandte Beiträge:

1. Zwei Hyper-V-FAQs: Pagefile und Hyper-Threading
   Zwei oft gestellte, aber nur selten beantwortete Fragen zu Hyper-V...
2. Hyper-V, das SP1 und Dynamic Memory
   Das Service Pack 1 für Windows Server 2008 R2 ist...
3. Exchange Server Support für Hyper-V
   Microsoft hat am 19. August 2008 ihre Software Licensing Terms...

Das Dokument wird regelmäßig ergänzt und ist daher einen Link-Favoriten wert:

[Active Directory Maximum Limits]
http://technet.microsoft.com/en-us/library/cc756101.aspx

Verwandte Beiträge:

1. Kann ich NT4 im Active Directory betreiben?
   Workstations oder Server unter Windows NT 4.0 können grundsätzlich problemlos...
2. Fallen und Auswege beim Recovery von Active Directory
   Der Microsoft-Supportmitarbeiter Herbert Mauerer hat einen sehr lesenswerten Artikel zum...
3. TechNet-Webcast: Active Directory richtig sichern und wiederherstellen
   Am 23. August 2006 habe ich für Microsoft TechNet einen...

Der Foliensatz liegt im XPS-Format vor, ein Viewer dafür ist notwendig (in Vista bereits enthalten, für andere hier auffindbar).

Verwandte Beiträge:

1. ice:2010 AD-Delegation – die Folien und Skripts
   Hier ist der Download der Folien (PDF-Format) und der Demo-Skripts...
2. \\ice:2008: Active Directory als Datenspeicher? Die Folien
   Wie eben gerade im Vortrag versprochen – hier sind die...
3. \\ice:2007: Windows Server 2008: Weniger ist mehr (Folien)
   Die Folien zu meiner Session "Windows Server 2008: Weniger ist...

Es gibt eine in den Newsgroups häufig gestellte Frage, die ich aufklären möchte:

Frage: Darf der Infrastruktur-Master auf einem Domänencontroller laufen, der auch Global Catalog Server ist?

Antwort: Eine übliche Antwort hierauf beruht auf einem falsch verstandenen Gerücht. Hiernach dürfe der Infrastruktur-Master (IM) nur dann auf einem Global Catalog Server (GC) laufen, wenn jeder Domänencontroller (DC) im gesamten Forest ein Global Catalog Server sei. Dieses Gerücht beruht allerdings auf missverständlichen Formulierungen.

Die Aufgabe des Infrastruktur-Masters besteht darin, Objekte der eigenen Domäne mit Objekten anderer Domänen im gleichen Forest zu vergleichen und mögliche Unterschiede (insbesondere domänenübergreifende Gruppenmitgliedschaften) zu korrigieren. Wenn nun der Server, der die IM-Rolle hält, gleichzeitig Globaler Katalog ist, wird er niemals einen Unterschied feststellen, weil er ja bereits eine Teilkopie jedes Objekts im ganzen Forest hat. Daher wird der IM in diesem Fall in seiner eigenen Domäne niemals eine Änderung an solchen Objekten durchführen. Wenn allerdings jeder DC innerhalb der Domäne auch GC ist, hat der IM schlicht nichts zu tun, denn jeder GC kennt ohnehin alle Objekte anderer Domänen. Wenn man sich nun also ansieht, was der IM zu tun hat, wird es klar, dass die IM-Rolle auf einem GC laufen darf, wenn es sich um ein Einzeldomänen-Netzwerk handelt (denn dann gibt es keine anderen Domänen, von denen Objekte repliziert werden). Ebenso klar ist, dass die IM-Rolle auf einem GC laufen darf, wenn der Forest aus mehreren Domänen besteht, aber jeder DC in der eigenen Domäne auch GC ist (kein Bedarf an Objektvergleichen, weil der GC sowieso "alles" weiß).

Also ist die folgende Infrastruktur eine gültige Konfiguration:

Domäne A

• A-DC1 (GC + IM)
• A-DC2 (GC)
• A-DC3 (muss GC sein!)

Domäne B

• B-DC1 (GC)
• B-DC2 (IM)
• B-DC3 bis B-DCx (GC oder nicht spielt hier keine Rolle)

In der ersten Domäne muss der IM keine Informationen aus anderen Domänen abrufen, weil der GC "alles" bereits kennt. Die andere Domäne hat den IM auf einem Nicht-GC, also ruft der IM Informationen aus den anderen Domänen ab und repliziert sie bei Bedarf auf die anderen DCs.

Der folgende KB-Artikel stellt dies richtig dar: [FSMO placement and optimization on Active Directory domain controllers]
http://support.microsoft.com/kb/223346/EN-US/

Um es also kurz zu machen:

Der Infrastruktur-Master darf nicht auf einem Global Catalog Server laufen, wenn alle folgenden Voraussetzungen gegeben sind:

• es gibt mehrere Domänen im Forest und
• es gibt Domänencontroller in derselben Domäne, die nicht Global Catalog Server sind.

Der Infrastruktur-Master darf auf einem Global Catalog Server laufen, wenn mindestens eine der folgenden Voraussetzungen gegeben ist:

• es gibt nur eine Domäne im Forest und/oder
• jeder Domänencontroller in derselben Domäne ist auch Global Catalog Server

Hier noch zwei ergänzende Links (Dank an Tatjana Aggoussi):

• 248047 Phantoms, Tombstones and the Infrastructure Master
  http://support.microsoft.com/?id=248047
• Details about the Active Directory EventId 1419
  http://www.microsoft.com/technet/support/ee/result.aspx?EvtSrc=Active+Directory&EvtID=1419&ProdName=Windows+Operating+System&LCID=1033&ProdVer=5.0

Verwandte Beiträge:

1. Wie verwalte ich die speziellen Domänencontroller-Rollen?
   Zwar sind grundsätzlich alle Domänencontroller im Active Directory gleichberechtigt. Doch...
2. Was muss ich tun, um den ersten DC zu deinstallieren?
   Der erste installierte Domänencontroller des Active Directory hat eine spezielle...
3. Alle Global Catalog Server auflisten
   Es ist gar nicht so einfach, alle Domänencontroller (DC) aufzulisten,...

Active Directory ermöglicht eine Vielzahl von Domänenmodellen, die sehr unterschiedliche Ansprüche erfüllen können. Domänen können einzeln stehen, in einer Struktur (Tree) angeordnet sein oder sich in komplexen Konstrukten mit mehreren einzelnen Strukturen (Forest) zusammenfinden. Grundsätzlich gilt das KISS-Prinzip: Keep it simple, stupid! Der Ausgangspunkt der Überlegungen sollte also immer das Einzeldomänenmodell sein, denn es bietet den geringsten Hardware- und Administrationsaufwand.

So einfach ist es aber oft nicht. Daher folgt hier eine sehr kurze Übersicht der wichtigsten Vor- und Nachteile verschiedener üblicher Modelle. Zu dieser Übersicht ist auch folgender Artikel sehr interessant, der Diskussionen der internationalen AD-Expertenstzene zusammenfasst:

[Multiple Domain Forests: Still a Valid Design Model? > ActiveDir.org > ActiveDir Articles]
http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId/68/Default.aspx

Domänenmodelle mit einem gemeinsamen Forest

Ein Forest (in der deutschen Übersetzung: Gesamtstruktur) bildet die oberste Einheit eines gemeinsamen Active Directory. Alle Domänen eines Forests haben ein gemeinsames Schema (Datenbankdefinition), einen gemeinsamen Global Catalog und eine gemeinsame AD-Konfiguration. Zudem sind einige Gruppen einmalig im Forest vorhanden (z.B. Organisations-Admins). Während administrativ jede Domäne einen eigenen Sicherheitsbereich darstellt, durch den Ressourcenzugriffe weitgehend auf Benutzer der eigenen Domäne eingegrenzt werden können, ist die Sicherheitstrennung nicht absolut: Einem Admin aus einer beteiligten Domäne kann es gelingen, in andere Domänen desselben Forests einzudringen (das ist nicht trivial, aber möglich). Wenn also eine echte Sicherheitstrennung zwischen Geschäftsbereichen erforderlich ist, müssen die Bereiche auf eigenständige, getrennte Forests verteilt werden. Für zusammenhängende Unternehmen sind in der Regel Modelle mit einem gemeinsamen Forest am vorteilhaftesten.

Weitere Anmerkungen:

• Keines der Modelle erlaubt eine zukünftige Eingliederung oder Abtrennung von Domänen oder Teilstrukturen. Active Directory ermöglicht nicht die Verbindung getrennter AD-Umgebungen. In solchen Fällen wäre stets eine Migration nötig, in der (mindestens) Teile der Zielumgebung neu aufgebaut werden müssen.
• Der Replikationsverkehr steht in keinem direkten Zusammenhang mit einem der Modelle. Die AD-Replikation wird ausschließlich durch AD-Standorte (Sites) gesteuert und nicht durch Domänen. Es gibt für die Replikation keine messbaren Vorteile durch ein Modell mit mehr oder weniger Domänen.
• Jedes der hier vorgestellten Modelle verfügt über ein gemeinsames Schema und einen gemeinsamen Globalen Katalog.
• Es gibt keinen einfachen Zusammenhang zwischen dem Domänenmodell und der Sicherheit. Kein Domänenmodell ist pauschal "sicherer" als irgendein anderes.
• Neben den hier vorgestellten Modellen gibt es zahlreiche Variationsmöglichkeiten. Diese müssen stets auf den Bedarf des Unternehmens abgestimmt werden.

Modelle mit mehreren Forests

Sobald zwei Active-Directory-Domänen unabhängig voneinander installiert wurden, bilden sie jeweils einen eigenen Forest. Active Directory ermöglicht es nicht, eine Domäne aus einem Forest in einen anderen Forest einzugliedern (siehe auch oben). Zwischen Domänen unterschiedlicher Forests können externe Vertrauensstellungen eingerichtet werden, sodas gezielte Ressourcenzugriffe möglich und administrierbar werden. Es gibt jedoch keinen gemeinsamen Global Catalog, kein gemeinsames Schema und keine gemeinsame Konfiguration. Beim Exchange-Einsatz ist zu beachten, dass der Forest die Organisationsgrenze ist: Das Globale Adressbuch etwa enthält nur Einträge aus dem eigenen Forest, und auch das einfache Verschieben von Mailboxen funktioniert nur innerhalb des Forest.

In manchen Situationen gibt es Gründe dafür, innerhalb eines Unternehmens oder Unternehmensverbunds mit mehreren getrennten Forests zu arbeiten. Hier einige Beispiele:

• Eine Testumgebung oder ein bestimmter Arbeitsbereich sollen vollständig von der Produktivumgebung getrennt werden.
• Es ist eine wirksame Sicherheitstrennung zwischen mehreren Bereichen nötig. Innerhalb desselben Forests kann ein Administrator einer Domäne sich administrative Rechte in einer anderen Domäne verschaffen (das ist nicht einfach, aber es ist möglich). Nur wenn mit getrennten Forests gearbeitet wird, bestehen echte getrennte Sicherheitsbereiche für die Windows-Ressourcen.
• Eine Firma schließt sich mit einer anderen zusammen, und beide betreiben bereits ein Active Directory.
• Es soll auf eine neue Umgebung migriert werden.

Verwandte Beiträge:

1. Wie viel [XYZ] kann Active Directory speichern?
   Über die Speicherkapazität von Active Directory gibt es eine Reihe...
2. Das „Wer mit wem“ in der Active Directory-(intra-site) Replikation
   Die Active Directory-Replikation ist für viele Administratoren ein Buch mit...
3. Active-Directory-Massenoperationen mit AdMod und AdFind
   Windows Server 2003 enthält die so genannten "ds*-Tools": Eine Sammlung...

Zunächst einmal benötigt jede AD-Domäne nicht einen, sondern zwei Namen: Einen DNS-Namen und einen NetBIOS-Namen. Beide müssen nicht übereinstimmen, sie brauchen noch nicht einmal etwas miteinander zu tun zu haben. Erfahrungsgemäß wird die Alltagsadministration aber einfacher, wenn beide Namen eine logische Verbindung zueinander haben.

DNS-Name

Grundsätzlich besteht ein DNS-Domänenname aus mindestens zwei Teilen, die mit einem Punkt getrennt sind. Als Zeichen kommen nur die Buchstaben a bis z, die Ziffen 0 bis 9 und der Bindestrich in Betracht. Andere Zeichen lässt Windows zwar teilweise zu, das sollte man aus Kompatibilitätsgründen aber bleiben lassen. Der gesamte DNS-Name darf bis zu 255 Zeichen lang sein, und einzelne Labels (Abschnitte zwischen zwei Punkten) dürfen maximal 63 Zeichen umfassen.

Für die Auswahl des DNS-Domänennamens gibt es drei übliche Modelle, die die folgende Tabelle darstellt.

Update Juli 2008: Im Sommer 2008 wurde bekannt, dass in Kürze TLDs allgemein frei gegeben werden, d.h. grundsätzlich kann sich jeder eine TLD ausdenken und diese registrieren. Das wird zwar teurer als eine "normale" Domain, aber es wird möglich sein. Man muss also davon ausgehen, dass "selbst ausgedachte" bzw. "generische" TLDs überhaupt nicht mehr für private Namensräume geeignet sind. Vielleicht gibt es in diesem Zuge endlich eine Festlegung für private Namensräume, aber ich würde mich nicht darauf verlassen.

Das ist eine neue Situation. Ich modifiziere also meine Empfehlung und empfehle nur noch Domains, die einem selbst gehören (Modell 1 und 2 der Tabelle). Die folgende Übersicht gebe ich daher nur noch aus historischen Gründen.

Unternehmensname oder nicht?

Viele Berater und Admins tendieren dazu, ganz selbstverständlich die Domäne nach dem Unternehmen zu benennen. So nahe liegend dies ist: In manchen Fällen entstehen daraus Probleme. Ändert etwa das Unternehmen seinen Namen, so ist es schnell politisch erwünscht (wenn nicht gefordert), die Domäne umzubenennen. Ein solcher Vorgang ist aber alles andere als trivial und mündet in manchen Situationen in einer kompletten Netzwerkmigration. Es ist auch gar nicht einmal so unwahrscheinlich, dass dieser Fall eintritt, denn die Bildung einer Unternehmensgruppe durch Ausgründung einer Abteilung oder durch Zukauf einer anderen Firma ist ein durchaus häufig genutztes kaufmännisches Mittel.

Es ist sehr ärgerlich, wenn der einzige Grund, eine gut funktionierende Umgebung aufzugeben, in ihrem veralteten Namen besteht. Aus diesem Grunde spricht durchaus einiges für einen abstrakten Domänennamen, der unabhängig vom Unternehmensnamen ist.

Welche Top Level Domain?

Falls ein generischer Name genutzt wird, der nicht dem Namen des Unternehmens bzw. der Internet-Domäne entspricht, sollte dieser entweder bei einer Registrierungsstelle (z. B. DeNIC) registriert werden, oder es sollte ein lokaler Namensraum eingesetzt werden. Leider gibt es für solche lokalen Zwecke keine offiziell vorgesehene Top Level Domain (TLD, der DNS-Namensteil, der ganz rechts im Namen steht). Die oft eingesetzte TLD ".local" ist problematisch, weil sie, anders als oft vermutet, nicht für lokale Zwecke reserviert ist. Sie wird einerseits im kommenden IP-Adressierungsstandard IPv6 für Adressen im lokalen Netzwerk verwendet und andererseits in Apples "Rendezvous"-Protokoll. Viele andere, oft "selbsterfundene" TLDs wie ".priv", ".intern", ".dom" oder ähnliche Varianten sind ebenso problematisch, denn es kann nicht ausgeschlossen werden, dass solche TLDs künftig offiziell verwendet werden (vgl. ".biz", ".aero" oder ".museum").

Viele betrachten hier einen Abschnitt der ISO-Norm 3166 als aussagekräftig, die internationale Länderkürzel definiert. Die Internet-Koordinationsstelle IANA hat sich in der Vergangenheit bei den TLD-Definitionen an dieser Norm orientiert. Dort sind die Buchstabenkombinationen "ZZ", "AA", "QM-QZ" und "XA-XZ" als "benutzerdefiniert" eingeordnet. Zwar besteht keine Verpflichtung für die IANA, diese Zuweisung zu übernehmen, und ebenso wenig ist diese Norm für alle Zeiten festgeschrieben. Trotzdem wird von vielen Experten die TLD ".zz" als geeignet für interne Zwecke angesehen.

NetBIOS-Name

Auch weiterhin werden NetBIOS-Namen in Windows-Netzwerken ihre Bedeutung haben (vgl. "Brauche ich noch WINS, wenn ich ein AD betreibe?", http://www.faq-o-matic.net/content/view/126/45/). Daher muss eine AD-Domäne einen NetBIOS-Namen tragen. Mit diesem Namen werden Benutzer meist auch mehr Kontakt haben als mit dem DNS-Namen, denn in den meisten Netzwerken wird die Anmeldung mit dem klassischen Format "DOMÄNE\Benutzer" durchgeführt (bzw. mit dem zweizeiligen Anmeldefenster, in dem erst der Benutzername und dann der NetBIOS-Domänenname angegeben wird).

Der NetBIOS-Name muss in der Domäne und im ganzen Windows-Netzwerk eindeutig sein. Sofern eine netzwerkübergreifende WINS-Replikation genutzt wird, muss der Name sogar im ganzen Replikationsbereich eindeutig sein. Das bedeutet: Kein Computer, keine andere Domäne und keine Arbeitsgruppe dürfen diesen Namen bereits verwenden.

Verwandte Beiträge:

1. Wie finde ich heraus, welcher Benutzer an welchem PC arbeitet?
   Es gibt leider keine einfache und hundertprozentig verlässliche Möglichkeit, diese...
2. Kann ich eine Domäne oder einen DC umbenennen?
   Das Umbenennen einer Domäne oder eines Domänencontrollers wurde zwischen Windows...
3. Wie mache ich eine Migration von NT nach AD?
   Im Wesentlichen hast du dazu zwei Möglichkeiten. In-place Upgrade: Den...

Update 3. August 2010: Microsoft hat nun eine eigene "offizielle" und umfassende Liste an Empfehlungen veröffentlicht. Siehe dazu:

[faq-o-matic.net » DNS für AD: Die offiziellen Empfehlungen]
http://www.faq-o-matic.net/2010/08/03/dns-fr-ad-die-offiziellen-empfehlungen/

Man beachte: Es gibt drei wesentliche Problemquellen im Zusammenhang mit Active Directory und Exchange:

• Namensauflösung
• Namensauflösung
• Namensauflösung

Beim DNS-Design können einfache von komplexeren Umgebungen unterschieden werden. Unter "einfach" sind hier Netzwerke mit einem einzigen Standort zu verstehen, in denen ein zusammenhängendes IP-Subnetz für das LAN verwendet wird. In diesen Umgebungen führen die folgenden Empfehlungen zu einer sinnvollen DNS-Umgebung:

• Alle DCs sollten als DNS-Server konfiguriert sein.
  (Zudem sollte es zwei WINS-Server geben, idealerweise auch auf den DCs. Viel mehr als zwei sollten es normalerweise nicht sein.)
• Der Name der DNS-Zone wird identisch mit dem AD-Namen gewählt.
• Konfigurationsoptionen der DNS-Zone: "Active-Directory-integriert", sichere Updates zulassen.
  (Dadurch ist es nur einmalig nötig, die Zone einzurichten. Alle anderen DCs, die auch DNS-Server sind, erhalten die Zone automatisch, sie muss dort nicht separat eingerichtet werden. Einfach DNS-Server installieren und eine Weile warten.)
• Der Name von AD und DNS sollte ein echter DNS-Name sein, also (mindestens) einen Punkt und eine TLD enthalten und somit kein Single-Label-DNS darstellen!
  (Heißt: "firma.de" oder "ad.firma.de" und nicht nur "firma"!)
• Eine Reverse-Lookup-Zone für das Netzwerk ist nicht zwingend erforderlich, hilft aber, manche Probleme zu vermeiden.
• Jedes Domänenmitglied sollte mindestens zwei der DCs als DNS-Server eingetragen bekommen (und idealerweise auch mindestens zwei WINS-Server). Das lässt sich über DHCP sehr effizient einrichten.
  Achtung: Auf keinen Fall einen externen DNS-Server (z.B. den des Providers) bei einem Client eintragen!
  Falls eine Internet-Namensauflösung durch die Clients gewünscht ist, sollte man auf den DNS-Server einen Forwarder (Weiterleitung) auf den DNS-Server des Providers bzw. auf einen anderen externen DNS-Server eintragen.
• Jeder DC bzw. DNS-Server muss selbst natürlich auch als DNS-Client konfiguriert sein.
  Grundsätzlich ist es empfehlenswert, dass der primäre Eintrag auf einen anderen DNS-Server zeigt und der sekundäre auf die eigene Adresse. Dadurch lassen sich einige Fehlersituationen vermeiden.
• In den DNS-Client-Einstellungen des DNS-Servers sollten stets reale IP-Adressen eingetragen werden; die Loopback-Adresse 127.0.0.1, die der dcpromo-Assistent einträgt, sollte durch die echte Adresse ersetzt werden.
  (Achtung, diese Empfehlung ist umstritten. So spricht Microsofts Support oft eine gegenteilige Empfehlung aus. Da unsere Empfehlung auf Problemen beruht, die vor mehreren Jahren beobachtet wurden – siehe etwa einen alten KB-Eintrag -, beharren wir nicht auf diesem Punkt. Die Loopback-Adresse kann z.B. besser sein, wenn sich die IP-Adresse des Servers mal ändert.)
• Die DCs müssen korrekt im DNS eingetragen sein (A-Einträge, SRV-Einträge, PTR-Einträge).
  Um dies zu erzwingen ggf. im CMD-Fenster ausführen (nacheinander):
  ipconfig /flushdns
  ipconfig /registerdns
  net stop netlogon
  net start netlogon
• Jeder Client und jeder Server muss im DNS eingetragen sein, und zwar vor allem in der Forward-, zusätzlich gern auch in der Reverse-Lookup-Zone. Bei richtiger Konfiguration geschehen die Eintragungen automatisch.

In komplexeren Umgebungen, die aus mehreren IP-Subnetzen und/oder aus mehreren Standorten bestehen, sollten weitere Empfehlungen berücksichtigt werden, damit DNS nicht zur "Insel" wird. Folgendes Szenario könnte auftreten:

Am Hauptstandort ist Active Directory mit mehreren DNS-Servern korrekt konfiguriert. Nun soll ein Domänencontroller für eine Niederlassung aufgesetzt werden. Um den Vorgang effizient zu halten, wird der DC zunächst am Hauptstandort installiert und konfiguriert – logischerweise mit den IP-Adressen des Hauptstandorts. Der fertige Domänencontroller wird in die Niederlassung gebracht. Bei der Inbetriebnahme vor Ort wird seine IP-Konfiguration auf das Subnetz der Niederlassung angepasst. Der primäre DNS-Eintrag zeigt auf den Server selbst, denn er hat ja DNS installiert, und durch die bereits erfolgte Replikation kann er alle vorhandenen Ressourcen auflösen. Alles in Butter also. Alles in Butter?

Nein. Denn die Domänencontroller am Hauptstandort haben in ihren DNS-Zonen noch die "alte" IP-Adresse des Niederlassungs-DC stehen. Da dieser primär seine eigene DNS-Datenbank nutzt, wird auch nur diese aktualisiert. Die DNS-Server am Hauptstandort können also den Namen des Niederlassungs-DCs nicht auflösen. Dadurch schlägt die Active-Directory-Replikation fehl, und die Niederlassung wird zur Insel. Ähnliche Effekte können auftreten, wenn an einem der Standorte die IP-Adressen geändert werden.

Um solche Situationen zu vermeiden, sollte in Netzwerken mit mehreren Standorten eine DNS-Sterntopologie aufgebaut werden: Die DNS-Server der Außenstellen zeigen mit ihrem primären DNS-Eintrag auf einen Server des Hauptstandorts. Dadurch aktualisieren sie dort ihre eigenen Einträge, die dann durch die DNS-Replikation (idealerweise integriert in die AD-Replikation) an alle anderen DNS-Server verteilt werden. Der sekundäre bzw. weitere DNS-Server-Einträge können dann auf Server des eigenen Standorts bzw. auf die lokale Maschine zeigen, damit Unterbrechungen der WAN-Verbindung nicht zu lokalen Betriebsunterbrechungen führen. Eine solche Konfiguration vermeidet auch Probleme bei nächträglichen Änderungen der IP-Subnets.

Natürlich sollten diese Konfigurationen stets aktuell dokumentiert werden, damit mögliche Fehler schnell aufgedeckt werden können.

Zu diesem Thema vergleiche auch folgenden Newsgroup-Thread: http://groups.google.com/group/microsoft.public.de.german.windows.server.active_directory/browse_frm/thread/74b695bc8bfb8c73/afaa9654ec6f3f82?hl=de#afaa9654ec6f3f82

Für hilfreiche Anmerkungen außerdem besten Dank an Frank Carius.

Verwandte Beiträge:

1. Was muss ich beim Anheben des AD-Betriebsmodus beachten?
   Schon seit der ersten Version des Active Directory kennt der...
2. Fallen und Auswege beim Recovery von Active Directory
   Der Microsoft-Supportmitarbeiter Herbert Mauerer hat einen sehr lesenswerten Artikel zum...
3. Was muss ich bei der Schema-Erweiterung beachten?
   Vieles! Das Ändern des AD-Schemas ist ein schwerwiegender Eingriff, der...

Ein Standort besteht aus einem oder mehreren Subnetzen und muss einer Standortverknüpfung angehören. Dabei kann ein Standort mehreren Domänen und eine Domäne kann mehreren Standorten angehören. In erster Linie besteht der Sinn von Standorten darin, dass man sowohl standortintern (Intra-Site) als auch standortübergreifend (Inter-Site) die Replikationsabläufe verwalten kann. Dort kann man durch Kosten, Intervall, Bridgeheadserver und Replikationspartner die Replikation beeinflussen. Damit die Replikation auch ordnungsgemäß verläuft, wird auf allen Domänencontrollern ein Konsistenzprüfungsdienst (Knowledge Consistency Checker – KCC) ausgeführt, der ständig prüft ob sich an den Gegebenheiten etwas verändert hat. Falls das so ist, passt der Prozess KCC die Replikationstopologie den Gegebenheiten an.

Mit dem Snap-In "Active Directory-Standorte und -Dienste" kann man seine Unternehmensstruktur abbilden. Dort kann man unter anderem:

• Standorte erstellen
• Standorte umbenennen
• Standorte löschen
• Subnetze erstellen
• Standorte einem Subnetz zuordnen
• Subnetze löschen
• Globaler-Katalog-Server erzeugen
• Intervalle zur Replikation festlegen (standardmäßig alle 180 Minuten, min. 15 bis max. 10.080 Minuten)
• Replikation an bestimmten Wochentagen oder zu bestimmten Zeiten festlegen, z.B. nur nachts
• Repliziervorgang "sofort" einsetzen (jetzt replizieren)

Die Replikation zwischen DCs innerhalb des gleichen Standortes basiert auf Benachrichtigungen, die innerhalb von fünf Minuten nach einer Objektänderung ausgegeben wird. Wenn eine Änderung an einem Objekt vorgenommen wurde, dauert es in der Regel 15 Sekunden, bis eine Änderungsnachricht (Change Notification) an den nächstliegenden Replikationspartner versandt wird. Wenn der Quelldomänencontroller mehrere Replikationspartner hat, werden nach und nach Benachrichtigungen, standardmäßig alle 3 Sekunden, an die weiteren Replikationspartner versandt (bei der Gesamtstrukturfunktionsebene Windows Server 2003).

Wenn die Domäne von Windows Server 2000 auf Windows Server 2003 aktualisiert wurde oder die Gesamtstruktur sich im "Windows Server 2000"-Modus befindet, sind es 300 Sekunden für eine Replikationsankündigung und 30 Sekunden Wartezeit (Verzögerung) für die weiteren Replikationspartner (Verhältnis 15/3 zu 300/30). Der Grund für diese deutliche Verkürzung der Replikationsverzögerung besteht darin, dass sich der Replikationsdatenverkehr als deutlich geringer herausgestellt hat, als die Entwickler beim Entwurf der ersten Active Directory-Versionen für Windows 2000 angenommen hatten.

Bei einigen Verzeichnisänderungen wie z.B. "Konto gesperrt" oder Änderungen an den Kennwort-Policys bzw. Änderung des Domänen-Administrator-Kennworts gelten die 15 Sekunden Wartezeit nicht, sondern die Replikation erfolgt sofort. Diese sofortige Replikation wird auch als dringende Replikation bezeichnet.

Zeitpläne sind von immenser Bedeutung. Wenn z.B. eine bestimmte Zeit lang nichts verändert und damit auch keine Replikation erfolgen würde, so repliziert das Active Directory dennoch standardmäßig alle 6 Stunden, um sicherzustellen, dass alle Domänencontroller auf dem aktuellen Stand sind und dass die Replikationstopologie intakt ist und keine Verbindungsprobleme bestehen.

Wenn ein Client bootet und sich anmelden möchte, meldet er sich standardmäßig an einem Domänencontroller innerhalb des eigenen Standortes an, und wenn er eine Dienst-Anfrage startet, fragt er an einem Domänencontroller desselben Standortes an. Der Client gehört automatisch dem Standort an, welchem der Server angehört, der dem Client seine Anmeldeinformationen (IP, DNS, usw.) übermittelt hat. Falls der Server oder der Client eine IP-Adresse hat, die keinem Standort zugeordnet ist, wird der Server bzw. Client automatisch dem zuerst erstellten Standort zugeordnet, dem Standort "Standardname-des-ersten-Standorts".

Active Directory repliziert Verzeichnisinformationen innerhalb eines Standortes (Intra-Site) häufiger als zwischen verschiedenen Standorten. So erhalten die Domänencontroller mit den schnellsten Verbindungen, also die, die bestimmte Verzeichnisinformationen am ehesten benötigen, die replizierten Daten zuerst.

Die Domänencontroller in den anderen Standorten erhalten die Änderungen ebenfalls, nur nicht so häufig, um Bandbreite zu sparen. Die Replikation zwischen den Standorten (Inter-Site) wird von Active Directory anders behandelt als standortintern, da standortübergreifend weniger Bandbreite zur Verfügung steht als standortintern. Standortintern geschieht die Replikation unkomprimiert, während sie standortübergreifend komprimiert repliziert wird.

Bei entsprechend konfigurierten Diensten kann das Datenvolumen bei der standortinternen Active Directory-Replikation Folgendes enthalten:

• Änderung an der Active Directory-Datenbank (NTDS.dit)
• Replikation des SYSVOL-Ordners
• Replikation des DFS (Distributed File Systems)

Beispiele für das Einrichten eines oder mehrerer Standorte

Das "optimale" Replikationsverhalten hängt sehr von der physikalischen Struktur des Netzwerks ab. Wenn z.B. ein Unternehmen nur einen Standort (ein Netz) mit hoher Bandbreite hat, empfiehlt sich ein Einzelstandort. Falls das Unternehmen mehrere Standorte hat, die evtl. durch "langsame" WAN Anbindungen untereinander verbunden sind, dann sollten mehrere Standorte eingerichtet werden, um das Replikationsverhalten präziser zu steuern. Auch reduziert sich im Zusammenhang mit der Authentifizierung die Wartezeit und die Netzwerklast ist geringer im WAN.

Vorteile eines Einzelstandorts sind:

• Einfache Replikation
• Replikation geschieht mehr oder weniger automatisch durch Änderungsnachricht – dadurch sind alle DCs stets auf dem aktuellen Stand
• Keine Replikationskonfiguration
• Weniger Hardware
• Weniger Administration

Vorteile mehrerer Standorte sind:

• Bessere Steuerung und effiziente Ausnutzung der WAN-Bandbreite bei der Replikation
• Reduzierung der Wartezeiten bei der Authentifizierung (Client sucht zuerst einen Domänencontroller am gleichen Standort, um sich anzumelden).
• Präzise Replikationssteuerung durch relative Kostenkontrolle

KCC (Knowledge Consistency Checker)

Der KCC (= Konsistenzprüfungsdienst) ist ein Prozess des Active Directory und dafür zuständig, dass die Verbindung zwischen den Replikationspartnern besteht und in der Gesamtstruktur eine effiziente Replikationstopologie entsteht. Ebenfalls sorgt der KCC für eine Konsistenz der verteilten Active Directory-Datenbank auf allen Domänencontrollern in der Gesamtstruktur. Wenn z.B. eine Verbindung/Leitung ausfällt, stellt der KCC wieder eine neue Verbindung zum Replikationspartner her. In der Regel nimmt der KCC alle 15 Minuten eine erneute Berechnung der Replikationstopologie für den Domänencontroller vor, damit Änderungen an der Active Directory-Struktur automatisch berücksichtigt werden und somit ein manuelles Eingreifen nicht erforderlich ist. Der Administrator kann weitere Verbindungen erstellen. Falls aber die Verbindung an irgendeiner Stelle abbricht, greift der KCC erneut ein und behebt dies. Dabei wird das Verfahren des Least-Cost-Spanning-Tree-Algorithmus (Inter-Site = standortübergreifend) angewendet, das auf Bandbreiteneffizienz ausgelegt ist.

Der KCC erstellt anhand eines Ringentwurfs automatisch eine effiziente Replikationstopologie innerhalb eines Standortes (Intra-Site) und eine für die standortübergreifende Replikation (zwischen den Standorten – Inter-Site).
Diese Ringtopologie versucht zwecks Fehlertoleranz mindestens zwei Verbindungen zu jedem Domänencontroller zu erstellen mit maximal 3 Hops zwischen den beliebigen DCs (dies wegen Reduzierung der Replikationswartezeit). Weiter erstellt der KCC für jede Verzeichnispartition eine eigene Replikationstopologie (Schema-, Konfigurations-, Anwendungs- sowie Domänenverzeichnispartition). Er überwacht (dynamisch) permanent die Gegebenheiten wie z.B., wenn DCs einem Standort hinzugefügt, entfernt oder verschoben werden, die Kosten sich ändern oder wenn ein Domänencontroller nicht erreichbar ist. In diesen Fällen "justiert" der KCC nach, so dass die Replikation weiter reibungslos verläuft.

Falls man nicht möchte, dass der KCC die Replikationstopologie automatisch erstellt, kann man dies abstellen. Das bedeutet aber, dass man selbst für die Replikation des evtl. bestehenden VPNs zuständig ist, und was noch viel wichtiger ist, man bemerkt nicht sofort, wenn ein Replikationsproblem besteht. Zwar beschreibt dieser Artikel, wie man das KCC deaktiviert, aber die Empfehlung ist: Finger weg – der KCC macht seine Arbeit schnell und ordentlich: http://support.microsoft.com/kb/242780/de

ISTG (Intersite Topology Generator)

Der ISTG ist eine Komponente des KCC und für die Verwaltung und Überwachung von standortübergreifenden Replikationsverbindungen verantwortlich. Er ermittelt den jeweiligen Bridgeheadserver eines Standortes (den Domänencontroller, der für die konkrete Replikationsverbindung zwischen zwei Standorten zuständig ist), und falls dieser nicht  mehr zur Verfügung steht, sucht er sich einen neuen. Der erste Domänencontroller eines Standortes bekommt automatisch die Rolle des ISTG zugewiesen – auch wenn weitere DCs dem Standort hinzugefügt werden, behält er diese Funktion. Erst wenn dieser erste DC nicht mehr zur Verfügung steht, wird die Rolle an einen anderen Domänencontroller dieses Standortes vergeben.

In einem bestimmten Intervall (standardmäßig 30 Minuten) informiert der ISTG die anderen DCs des gleichen Standortes, dass er noch vorhanden ist. Das Intervall kann man über folgenden Registry-Schlüssel beeinflussen: "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters"
(Attribut "InterSiteTopologyGenerator").

Falls das Intervall verstreicht und die Information nicht repliziert wurde, geht der KCC davon aus, das dieser DC nicht mehr zur Verfügung steht und bestimmt einen neuen Domänencontroller, der die Rolle des ISTG übernimmt.
Im Active Directory des Windows 2000 Server hatte der ISTG-Algorithmus seine Grenzen und arbeitete ab ca. 300 Standorten nicht mehr effizient, so dass man diesen ISTG-Algorithmus ausschalten und die Definition und Verwaltung von Verbindungen manuell erledigen musste. Bei Windows Server 2003 wurde die Skalierbarkeit erheblich erweitert und nun ist es auch möglich, bei 3.000 Standorten immer noch eine effiziente Replikationstopologie zu ermitteln. 

FRS (File Replication Service)

Der Dateireplikationsdienst ist zuständig für die Replikation der Daten im SYSVOL Verzeichnis eines Domänencontrollers. FRS wird unter Windows 2000 und Windows Server 2003 bis SP1 zudem für die Replikation des verteilten Dateisystems (DFS = Distributed File System) verwendet. An dieser Stelle sei erwähnt, dass sich dieses Verhalten in Windows Server 2003 R2 ändert, dort repliziert DFS sich über sein eigenes Replikationsverfahren.

Die eigentlichen Inhalte von Gruppenrichtlinien werden nicht im Active Directory gespeichert, sondern im Dateisystem eines Domänencontrollers(ADM-Dateien, POL-Dateien, Skripts usw.). In einer Umgebung, in der mehrere Domänencontroller existieren, sorgt FRS dafür, dass die Daten im Active Directory und auch im SYSVOL-Verzeichnis erfolgreich auf alle DCs repliziert werden, damit auch jeder Benutzer sowie Client überall die gleichen Einstellungen erhält – egal von welchem Domänencontroller er angemeldet wird. Der FRS arbeitet so wie das Active Directory nach der Multi-Master-Replikation, so dass Änderungen an jedem Domänencontroller zulässig sind. Anders als bei der Active Directory-Replikation werden die Daten bei FRS standortübergreifend nicht komprimiert, daher kann es bei großen Datenmengen eine Weile dauern, bis alle Daten repliziert worden sind, ebenso wie die Erst-Replikation eines Domänencontroller eine gewisse Zeit in Anspruch nimmt.

FRS speichert Logs, die ggf. bei Problemen behilflich sein können, im Verzeichnis "%Systemroot%\Debug" mit den Namen Ntfrs_0001.log bis Ntfrs_0005.log. Ebenfalls wird ein Log-File erstellt (Ntfrsapi.log), wenn ein Server zum Domänencontroller herauf- oder herabgestuft wird.

FRS hat folgende Inhalts- und Datengrenzen:

• Eine maximale Dateigröße von 20 GB
• Maximal 64 GB an Daten
• Maximal 500.000 Dateien unter dem Replikationsstamm
• Maximal 1.000.000 gleichzeitige Änderungsanforderungen

Ferner hat FRS folgende Topologiegrenzen:

• Maximal 1.000 Replikationspartner
• Maximal 150 Repliken pro Computer

Replikations-Transport-Protokolle

Das Active Directory repliziert standardmäßig über Remoteprozeduraufrufe (Remote Procedure Call = RPC) over Internetprotokoll (IP). Diese Protokolle werden sowohl für die standortinterne als auch die standortübergreifende Replikation verwendet. Für die Sicherheit bei der Übertragung der Daten durch diese Protokolle sorgt einmal die Authentifizierung mit dem Kerberos V5-Authentifizierungsprotokoll und des Weiteren die Datenverschlüsselung. Eine Komprimierung der Daten findet dabei nicht statt. Die standortübergreifende IP-Replikation benutzt standardmäßig Zeitpläne, die sich aber auch ignorieren lassen.

Als weiteres Protokoll kann auch SMTP (Simple Mail Transfer Protocol) verwendet werden. SMTP kann aber NUR standortübergreifend eingesetzt werden und nicht standortintern. Da SMTP kein sicheres Protokoll ist, braucht man ebenfalls eine Organisationszertifizierungsstelle (CA), um die Replikationsinformationen digital signieren und verschlüsseln zu können. Nur so kann sichergestellt werden, dass die gesendeten Daten unverändert und die Echtzeit den Daten auf der Empfängerseite entsprechen. Eine weitere Einschränkung ist, dass man zwar die Schema-, Konfigurations- sowie Anwendungsverzeichnispartition replizieren kann, jedoch nicht die Domänenverzeichnispartition. Aus diesen Gründen wird dieses Verfahren in der Praxis so gut wie nie eingesetzt.

Verwandte Beiträge:

1. Das „Wer mit wem“ in der Active Directory-(intra-site) Replikation
   Die Active Directory-Replikation ist für viele Administratoren ein Buch mit...
2. Active-Directory-Replikation im Detail
   Dieser Artikel soll einen etwas tieferen Einblick in die Replikation...
3. Replikation: Standorte & Standortverknüpfungsbrücken
   In diesem Artikel: Kostendefinitionen bei der Active Directory Replikation (wann und...