emeriks
Goto Top

Eure Erfahrungswerte - AD DNS Inseleffekt

Hi,
ich möchte niemanden mit meinem langen Text erschlagen. Deshalb hier die Frage vorab in Kurzform. Wer mag, kann sich das gerne komplett durchlesen. face-wink

Könnt Ihr Euch vorstellen oder gar bestätigen, dass in Anwendungspartionen gespeicherte AD-integrierte DNS-Zonen, eigentlich schon vom Microsoft entschärften Inseleffekt nach wie vor entstehen lassen können?


Einige von Euch kennen doch sicherlich den sogenannten Inseleffekt, der beim Starten eines AD Domaincontrollers aufteten kann, wenn er der erste DC des AD ist, welcher gerade startet (oder die anderen nicht erreichbar sind) und die DNS-Zone für seine Domäne im AD integriert ist und er sich selbst als DNS-Server eingetragen hat.
DC startet und fragt DNS-Server nach Informationen, welche er zum Starten des AD Dienst benötigt. Der DNS ist lokal. DNS-Server will Zone laden aber die ist im AD integriert, was zu diesem Zeitpunkt noch nicht geladen ist. Katze beißt sich in den ### (Wirbelsäulenvortsatz face-wink) .
Was in älteren Versionen von Windows noch ein Problem darstellten konnte, wurde relativ schnell von MS erkannt und gefixt (ich glaube schon unter Win 2003). Wo früher die DC's dann ewig gebraucht haben, um zu starten, starten die DC's im o.g. Szenario heute normal durch.

So weit, so gut.

Meine Frage nun, ob bei einer von Euch bei sich ein ähnliches Szenario hat, wie ich es gleich beschreiben werde, und ob dort schon mal ähnliches Problem aufgetreten ist.

Wir haben ein größeres AD mit vielen Domänen und Standorten. An mehreren Standorten sind DC's, die meisten jedoch im zentralen Rechenzentrum.
Die DNZ-Zonen für die einzelnen Domänen sind alle im AD integriert. Diese Zonen werden nur auf DCs/DNSs repliziert, wo sie benötigt werden. So werden also z.B. die Zonen zur Domäne A, welche für Kunde A am Standort A zuständig sind, nur auf DCs von A und vom RZ repliziert. Analog Domäne B des Kunden B an Standort B.
Die Zonen der Domänen, welche nur im RZ benötigt werden, werden i.A. nicht zu den Standorten repliziert. Wenn hier mal Namen aus diesen Zonen aufgelöst werden müssen, dann erfolgt das Ganze über DNS-Weiterleitungen.

Auch so weit alles gut.

Jetzt haben wir im RZ also eine Verwaltungsdomäne, welche auch DIE zentralen DNS-Server bereitstellt, welche eben alle DCs dieser Domäne sind. Die DNS-Zone für diese Domäne ist in der genannten Domänen-Partition gespeichert.
Vor einiger Zeit gab es eine Anforderung, dass diese Zone aus Gründen der Performance schreibbar an einem Aussenstandort bereitgestellt werden musste/sollte. Es sollte aber kein weiterer DC der betreffenden Domäne des RZ installiert und in diesem Standort platziert werden, sondern einer der dort vorhandenen DC der zum Standort gehörigen Domäne sollte die Zone hosten.
Also haben wir die Zonen-Replikation angepasst. Statt wie bisher nur innerhalb der Domäne auf alle DC zu replizieren, haben wir eine Anwendungspartition erstellt, die DC der RZ-Domäne sowie den einen DC des Aussenstandorts dort hinzugefügt und die Replikation der DNS-Zone auf diese Anwednungspartition geändert.

Soweit auch alles gut. Funktioneirt alles.

Nun das Problem-Szenario:
Bei einem gelpanten, vollständigen Runterfahren des RZ sind alle DCs/DNSs der RZ-Domäne, welche die zugeghörige DNS-Zone hosten, anschließend nicht wieder vollständig hochgefahren. Der Anmeldebildschirm kam noch, aber man konnte sich nicht mit einem produktiven Adminstratorkonto anmelden. Auch nicht, wenn diese Benutzer Domänen- bzw. Organisations-Admins waren.
Die Anmeldung war nur mit DEM Administrator möglich (Passwort kryptisch und irre lang sowie im Safe). Unter dessen Anmeldung haben wir dann feststellen können, dass der DNS-Dienst die DNS-Zone für die RZ-Domäne nicht laden konnte. Die Tools für AD haben das AD nicht gefunden. Der AD-Dienst lief aber. Man konnte nichts nachschauen oder machen. Auch kein ADSIedit.
Wir haben einiges probiert, bis wir auf die Idee kamen, einen Memberserver schnell mal zum DNS zu machen und diesem eine leere Primär-Zone für diese Domäne zu verpassen. Dann haben wir diesen DNS-Server einem DC als 1. DNS-Server eingetragen und den DC durchgestartet. Bingo! Inseleffekt? (Ach so: Alle Server sind Win2008 R2.)

Verstehen tuen wir das nicht wirklich. Wo soll hier der Unterschied sein, zu einem Standalone-DC, der AD-integrierte DNS-Zonen hat und allein das AD hostet. Und welcher auch problemlos hochfahren kann.

Das einzige, wass ich mir da vorstellen könnte und was ich Euch fragen will, ob Ihr das nachvollziehen oder gar bestätigen könnt:
Der Unterschied ist, dass die Zone für die RZ-Domäne nicht in der Domänen-Partition gespeichert ist sondern in einer Anwendungspartition.
Könnte das das Zünglein an der Waage sein?

E.

Content-Key: 273788

Url: https://administrator.de/contentid/273788

Printed on: April 19, 2024 at 23:04 o'clock

Member: Dani
Dani Jun 04, 2015 at 19:18:37 (UTC)
Goto Top
Guten Abend @emeriks,
direkt nachvollziehen kann ich dein Problem nicht, da wir solch ein Design nicht betreiben. Aber vllt. den einen oder anderen Denkanstoß geben.

Ich habe vor einigen Monanten gelesen, dass DNS-Zonendaten welche in einer Anwendungsverzeichnispartition abgelegt werden nicht an den Global Catalog repliziert werden. Das gilt auch, wenn DC und GC auf der selben Maschine läuft.
Hast du nur die Forwardzone "domain.local" verschoben oder auch "_msdcs.domain.local"? Denn in letzter Zone erzeugen die DCs CNAME-DNS-Einträge welche an den kompletten Forest repliziert werden sollten.


Gruß,
Dani
Member: emeriks
emeriks Jun 05, 2015 at 06:35:38 (UTC)
Goto Top
Hi Dani,
z.Z. haben wir diese Sub-Domäne gar nicht in einer eigenen Zone. Dafür bestand bisher kein Bedarf.
.... welche an den kompletten Forest repliziert werden sollten.
Mit welcher Begründung?

E.
Member: Dani
Dani Jun 07, 2015 at 11:56:47 (UTC)
Goto Top
Hallöchen,
Mit welcher Begründung?
Dachte ich mir fast... face-wink
Schau ich dir nach, wenn ich wieder zu Hause bin.


Gruß,
Dani
Member: emeriks
emeriks Jun 09, 2015 updated at 09:29:07 (UTC)
Goto Top
Wir konnten das jetzt mal komplett durchspielen. Es hat nichts mit den Anwedungspartitionen zu tun. Es macht keinen Unterschied, ob die Zonen in der Domänenpartition gespeichert sind, oder in einer Anwendungspartition. Es macht auch keinen Unterschied, ob die DNS-Server DC's der Stamm-Domäne sind oder welche von weiteren Domänen der Gesamtstruktur.

Wir haben unsere Produktivumgebung in den relevanten Punkten im Labor 1:1 nachgebaut:
- 1x DC für Stamm-Domäne, kein DNS (DC01)
- 2x DC für Stamm-Domäne der 2. Struktur innerhalb der Gesamtstruktur (2. Namespace), beide mit DNS (DC02 und DC03)
- DC01 mit DC03 und DC02 als DNS-Server
- DC02 mit DC03 und DC02 als DNS-Server
- DC03 mit DC03 und DC02 als DNS-Server
- DNS-Zonen für beide Domänen in AD integriert

1. Test:
- alles aus
- nur DC03 hochgefahren
- Boot bis zur Anmeldung dauert ca. 10-15 min (zum Vergleich: Sonst 1-2 min.)
- Anmeldung mit DEM Administrator sofort möglich - mit Verzögerung, bis er dann den Desktop aufbaut - die MMC's für AD und DNS sind aber noch nicht funktionstüchtig - erst nach ca. 15 - 20 min funktionieren die MMC

2. Test:
- alles aus
- nur DC03 hochgefahren
- Boot bis zur Anmeldung dauert ca. 10-15 min
- Anmeldung mit einem anderen Admin-Konto erst nach ca. 15 - 20 min möglich
- die MMC's für AD und DNS sind funktionstüchtig

Dann haben wir die Umgebung um einen Member-Server mit DNS erweitert. Diesem DNS-Server haben wir herkömmlich Sekundär-Zonen (also nicht im AD integriert) der beiden Zonen verpasst. Diesen Server haben wir auf allen DC jeweils als 3. DNS-Server eingetragen.

3. Test:
- alles aus
- Member-Server hochgefahren --> DNS-Server funktionstüchtig
- nur DC03 hochgefahren
- Boot bis zur Anmeldung dauert ca. 5 min
- Anmeldung mit einem anderen Admin-Konto sofort möglich
- die MMC's für AD und DNS sind sofort funktionstüchtig


Fazit:
Die mögliche Anmeldung mit einem anderen Admin-Konto im 2. Test (wenn auch nur mit Verzögerung) suggeriert mir, dass wir nach unserem geplanten Blackout (s.o. in meiner Frage) beim Hochfahren des ersten DC/DNS wahrscheinlich nur etwas länger hätten warten müssen, bis wir dann normal hätten fortsetzen können. Leider kann ich nicht 100%ig abschätzen, wie lange dieses "etwas länger" in der produktiven Umgebung hätte sein müssen.

Microsoft beschreibt das mit dem weiteren DNS-Server ja prinzipiell in seinen KB's auch genau so. Allerdings geht MS wohl zuviel von der "heilen Welt" aus, in der irgendwo doch sicher noch ein DNS Server laufen wird.

Deshalb mein Tip:
Wenn ihr einen weiteren DNS-Server aufsetzt, der als "Backup"-DNS-Server für das Hochfahren des AD nach einem totalen Blackout fungieren soll, dann nicht als DC sondern als Member! Da dieser DNS-Server keine AD-integrierten DNS-Zonen direkt dedienen kann, muss er mit klassichen, Datei-basierten Zonen konfiguriert werden. Sinnvollerweise Sekundär-Zonen als Replikat von den AD-integrierten Zonen. Diesen Member-DNS-Server tragt Ihr als als letzten DNS-Server in den TCP/IP-Konfigurationen der betreffenden DC's ein.

E.