Gründe für globalen Katalog am Standort

Es gibt Applikationen, die fortlaufend mit LDAP Abfragen auf den globalen Katalog zugreifen um dort Informationen zu speichern. Wenn der nur über lahme WAN-Verbindungen erreichbar ist wird dies zu langen Antwortzeiten führen.

Auch wenn oft über das Startmenü nach Personen oder Druckern gesucht oder in einer die Option "Gesamtes Verzeichnis" bei Abfragen auswählt wird, geht viel Datenverkehr an den globalen Katalog.

Hier muss an den Standorten ein GC her, selbst wenn wegen der geringen Bandreite der Anbindung dies nicht so günstig erscheint.

Dazu wird in den Eigenschaften der NTDS Settings des Active-Directory-Objektes für den gewünschten Server am Standort der GC einfach aktiviert.

Zwischenspeichern der universellen Gruppenmitgliedschaft aktivieren ist dann keine Alternative, da hier nur die Anmeldung beschleunigt werden kann!

Probleme beim Umbenennen einer Domäne

Will man eine Domäne umbenennen muss die jeweilige Domäne in der Domänenfunktionsebene "Windows Server 2003" (eigentlich reicht "- 2000-pur" das steht aber in vielen Büchern anders) betrieben werden

Dazu müssen müssen alle Domänencontroller auf das Betriebssystem Windows Server 2003 aktualisiert ("Active Directory-Domänen und -Vertrauensstellungen", dort auf die einzelnen Domänen und "Domänenfunktionsebene heraufstufen") und erst danach die Gesamtstruktur auf Windows 2003 heraufgestuft werden (ebenda, aber den Stammknoten im Kontextmenü "Gesamtstrukturfunktionsebene heraufstufen").

Um die Aktualisierung der Domänencontroller auf das Betriebssystem Windows Server 2003 vorzubereiten kann man den Befehl "adprep.exe /forestprep" verwenden, dazu muss ein Benutzerkonto verwendet werden das zur Sicherheitsgruppe Organisations-Admins gehört.

Wenn dann die Gesamtstruktur heraufgestuft wird impliziert dies das Heraufstufen der Domänenfunktionsebene aller Domänen der Gesamtstruktur durch die Replikation.

Für die Umbenennung müssen alle Clients Verbindung zum DC haben, es werden DNS-und AD-Einträge automatisch aktualisiert. Das kann aber etwas dauern und es vorrübergehend zu Zugriffsproblemen kommen.

Sollten dabei Computer z. B. mit Windows 2000 nicht upgedatet worden sein, so muss man diese mit den Befehl "dcpromo /forceremoval" und zu einem Windows 2000 Mitgliedserver herunterstufen und dann nach der Aktualisierung des Servers auf Windows Server 2003 wieder "dcpromo" ausführen.

Explizite bidirektionale Vertrauensstellungen zwischen der umbenannten und anderen Domänen müssen nach einer Umbenennung neu erstellt werden.

GPO nicht auf Server anwenden

Um eine GPO auf allen Computer bis auf den Servern anzuwenden müssen OUs jeweils für Server als auch für die anderen Computer existieren.

So kann man auch GPOs nur auf die Server anwenden, um z. B. nurden Mitarbeitern des Supportteams das Benutzerrecht "lokal anmelden zulassen" zu geben, damit sie alle täglichen Wartungsarbeiten an den Servern durchführen können.

Kennwort-GPOs können nur auf die Domain angewendet werden, daher kann es sein dass man das so machen muss. Dagegen kann man GPOs zur Zuweisung einer Software am besten auf die OU einer Abteilung anwenden, diese sind meist den Standorten untergeordnet.

Alternativ kann man die Discretionary Access Control List (DACL) des GPOs bearbeiten und einer Gruppe die Berechtigungen "verweigern - Lesen" und "verweigern - Gruppenrichtlinie übernehmen" zuweisen.

Eine weitere Möglichkeit besteht darin, mit einem WMI Filter z.B. den Gehäusetyp des Computers zu ermitteln und sicherzustellen, dass sich eine GPO nur auf mobile Computer auswirkt. Achtung: WMI-Filter können nur von Windows XP Professional Maschinen verarbeitet werden, Windows 2000-Clients ignorieren WMI Filter.

Sind die OUs nun nach anderen Kriterien gegliedert, z.B. nach Standorten (üblicher Weg) so muss die GPO auf die ganze Domäne angewendet werden. Danach filtern man das GPO, so dass allen Mitgliedsservern und Domänencontrollern die Rechte lesen und Gruppenrichtlinie übernehmen verweigert werden.

Die Anwendung einer besonderen GPO z. B. mit Sicherheitsvorgaben auf einen Teil der Server erfordert eine weitere OU unterhalb der OU mit den Servern, will man komplizierte Filterungen oder DACL-Einträge vermeiden. Für die untergeordnete OU kann man dann die Vererbung deaktivieren.

Die Zuweisung von Software-Updates erfolgt üblicherweise nicht an die Domäne, sondern z. B. an die OU mit den Client-Computern. Hier würde dann z. B. konfiguriert automatisch Updates von den Microsoft Update Servern über das Internet einem internen Software Update Server (SUS) herunterzuladen.

Gründe für zwischenspeichern der universalen Gruppenmitgliedschaft

Üblicherweise der Grund und sofort erkennbar; Der Anmeldevorgang für die Benutzer am Standort einer per WAN-Verbindung angebundenen Zweigstelle soll beschleunigt werden.

Außerdem ebenfalls Bedingung: Ein globaler Katalog kommt wegen einer zu dünnen Anbindung (128 kbit/s und weniger) nicht in Frage.

Ist die Anbindung sehr dünn und arbeiten nur wenige Mitarbeiter an einem Standort ist bei Enpässen in der Connectivity zu überlegen ob überhaupt ein DC an dem Standort stehen muss, durch Wegfall aller Replikation wird die Kapazität der Leitung schon sehr entlastet.

Sollen Gruppenmitgliedschaften geändert werden, so sollte man sich mit dem dem PDC-Emulator der Domäne verbinden. Er ist der erste DC der über Kennwortänderungen und Änderungen von Gruppenmitgliedschaften informiert wird, gewissermassen die Quelle der folgenden Replikation.

IP-Bridgehead-Server für Replikation

Bridgehead-Server (Brückenkopf-Server) sind sozusagen die Gateways für den Replikations-Traffic des AD. Die Performance wird verbessert mehr innerhalb der lokalen Netze als über die Site-Grenzen hinaus repliziert wird.

Um zwei Domänen an zwei Standorten zu verbinden brauchen beide jeweils einen Bridgehead-Server. Dieser Domain-Controller sollte auch den globalen Katalog beinhalten. Auf jeden Fall sollte ein leistungsfähiger Server (mit schneller CPU) verwendet werden.

Wenn es zwei RRAS-Server gibt, die tatsächlich das Gateway für eine Festverbindung bedienen, dann werden meist diese verwendet (z.B. mit Modems, heute eher selten der Fall).

Vorsicht: Fällt die Kommunikation zwischen diesen beiden Servern oder einer der Server aus, wird gar nicht mehr repliziert!

Soll die Ausfallsicherheit erhöht werden, gibt es zwei Möglichkeiten: Keinen Bridgehead verwenden wenn die Topologie dies erlaubt oder pro Seite zwei Bridgehead-Server.

Bridgehead-Server sind auch sinnvoll um die Replikation durch Firewalls zu erlauben. Dies kann auch durch einen VPN-Tunnel erfolgen.

Auch die Domain-Controller mit dem DNS-Server können sinnvoll für einen Site-Link verwendet werden.

Statt IP könnte zwar auch SMTP verwendet werden, dies aber unnötig aufwendig und umständlich, man benötigt auch zusätzlich eine Zertifizierungstelle mit Public-Key-Verschlüsselung.

Die Replikationsrate für die standortübergreifende Replikation kann mit dem Knoten "Inter-Sites Transports" in der Konsole "Active Directory-Standorte und –Dienste" eingestellt werden.

Werden Zeiten für die Replikation eingestellt, so ist darauf zu achten, dass diese sich überlappen! Wenn eine Standortverknüpfung bis ein Uhr nachts replizieren will und die andere erst danach beginnt (Zeitzonen beachten!) wird sich die gesamte Replikation um einen Tag verzögern.
tweetbackcheck