Benutzer mit den meisten Antworten
DFS auf Win2008 nicht redundant?

Frage
-
Hallo zusammen,
ich habe folgende Konstellation:
- 2x Domain Controler (dc1 und dc2) mit Windows Server x64 2008 SP2
- Auf beiden DC läuft DFS
- Nutzung von Domainenbasiertem Namespace => \\dom.test\public
- beide DC sind als Namespaceserver für \\dom.test\public eingetragen
- \\dom.test\public wird repliziertProblem:
Wenn ich dc1 ausschalte, kann ich auf dc2 nicht mehr mit der DFS-Verwaltungskonsole arbeiten:
Wenn ich versuche auf dom.test\public zuzugreifen meldet die Verwaltungskonsole "Fehler: \\dom.test\public: Der Namespace kann nicht abgefragt werden. Der RPC-Server ist nicht verfügbar".
Wenn ich versuche einen neuen Domainenbasierten Namespace "home" anzulegen bekommen ich eine Fehlermeldung die besagt: \\dom.test\home die angegebene Domaine ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden.Was stimmt nicht mit meiner Konfiguration? DFS auf dem dc2 muss doch auch laufen, wenn der dc1 ausgefallen ist!? Die Clients können zwar noch arbeiten, haben aber elend lange Verzögerungszeiten beim Zugriff auf Dateien.
Gruß
Jens
Antworten
-
Hi Michael,
ich habe noch einmal mit meinem Kollegen Hubert aus dem Netzwerkteam gesprochen, er beschäftigt sich unter anderem mit DFSN: Er sagte wie auch ich, daß 10 Sekunden Cache viel zu gering ist - unter Umständen holst Du Dir damit erst Probleme ins Haus. Empfehlung ist hier in den allermeisten Umgebungen den Standardwert beizubehalten.
Zusätzlich sind Verzögerungen beim Ausfall eines Targets normal, die Frage ist eher, wie lang die Suche nach einem Target insgesamt dauert. Da hier der Client erst versucht, das alte Target zu erreichen (und dann feststellt, daß es nicht mehr erreichbar ist), dann einen Namespaceserver kontaktiert, danach dann eine SMB-Verbindung aufbauen muß, kann dies etwas Zeit in Anspruch nehmen.
Mein Vorschlagt ist wie angesprochen, daß wir diesen Thread damit "beenden":
1. Bei Änderungen muß der PDCe erreichbar sein.
2. Geringe Verzögerungen auf dem Client bei Ausfall eines Targets sind "normal", sollten die Zeiträume jedoch sehr lang sein, machst Du einen neuen Thread mit diesem neuen Thema auf. :-)
Viele Grüße
Fabian
http://blogs.technet.com/deds- Als Antwort vorgeschlagen Fabian Müller [MSFT]Microsoft employee Dienstag, 20. Oktober 2009 07:19
- Als Antwort markiert Andrei TalmaciuModerator Freitag, 23. Oktober 2009 13:27
Alle Antworten
-
Hi Jens,
wie reagieren den die Clients allgemein, wenn DC1 Off ist ?
Anmeldung und Profile = OK ?
Anderes LW-Mapping = OK ?
Beide DCs = GCs ?
DNS = OK ?
Testweise FW deaktiviert an den DCs ?
>Wenn ich dc1 ausschalte, kann ich auf dc2 nicht mehr mit der DFS-Verwaltungskonsole arbeiten:
Fokus im SnapIn dann auf DC2 geändert ?
Gruß Ralph Andreas Altermann -
wie reagieren den die Clients allgemein, wenn DC1 Off ist ?
Zugriff auf DFS geht ca. 10 sec, blockt ca.10 sec, ansonsten mehr man nix
Anmeldung und Profile = OK ?
Ja
Anderes LW-Mapping = OK ?
Ja
Beide DCs = GCs ?
Ja
DNS = OK ?
Ja
Testweise FW deaktiviert an den DCs ?
Wie mach ich das? Wenn ich den Firewall-Dienst beende, dann wird alles geblockt.
>Wenn ich dc1 ausschalte, kann ich auf dc2 nicht mehr mit der DFS-Verwaltungskonsole arbeiten:
Fokus im SnapIn dann auf DC2 geändert ?
Wie ändere ich den Fokus? -
Hi Jens,
welche DNS Server hast Du auf dem DC2 in den TCP/IP Einstellungen eingetragen? Kann es sein, daß da nur der DC1 eingetragen ist?
Viele Grüße
Fabian
http://blogs.technet.com/deds- Bearbeitet Fabian Müller [MSFT]Microsoft employee Montag, 15. Juni 2009 18:05 name
-
Zur DFS-Verwaltung
Ich konnte das Problem auch verifizieren. Die DNS-Server scheinen nicht das Problem zu sein. (Primary jeweils sich selbst, secondary der jeweils andere DC.) Die Verwaltung klappt auch dann nicht, wenn in der DFS-Verwaltung direkt der DC eingetragen wird, der noch online ist.
Es ist seltsam: Laut Netzwerkmitschnitt sucht der zweite DC mit NetBIOS den Domänennamen via Broadcast. Im Anschluss haut er 15 ARPs für den Offline-DC raus. Dann ist Schicht im Schacht.
Gruß,
Michael -
Hallo Fritz,
schön zu hören das ich mit dem Problem nicht alleine bin. Auch wenn es nicht schön ist dieses Problem zu haben.
Hast du denn auch das Problem mit dem Clients? Wenn der DFS-Server offline geht, mit dem der Cleint verbunden war, dann bekommt der Client timeouts beim Zugriff auf die DFS-Freigabe. Client ist Win XP Prof.
Auf dem Client, Explorer, DFS-Freigabe, rechte Maustaste, (DFS) anklicken zeigt mir aber, das sich der Client nach dem Wegfall mit dem anderen DFS-Server verbunden hat. Trotzdem timeouts.
@Fabian Das DNS funktioniert. Beide DC haben nen DNS Server. Als Primary DNS jeweils sich selbst und als Secondary den anderen DC. -
Hi Michael,
startest Du die DFSMGMT.MSC Konsole nach dem Abschalten des ersten DCs neu oder bleibt die Konsole offen? Ggf. einmal die Konsole neu starten.
Hi Jenso,
tritt das Problem dauerhaft auf oder nur nach direkt nach dem simulierten Ausfall des DC1 und danach nicht mehr?
Viele Grüße
Fabian
http://blogs.technet.com/deds -
Hi,
unter Windows Server 2003 R2 konnte ich das Verhalten nicht nachvollziehen. Ich schaue es mir die Tage einmal unter Windows Server 2008 / 2008 R2 an.
Es muß in diesem Zusammenhang jedoch zwischen der Verfügbarkeit der Namespaces und dem Clientverhalten unterschieden werden. Ggf. liegen zwei unterschiedliche Probleme vor, die nur in der gleichen Konstellation auftreten.
Viele Grüße
Fabian
http://blogs.technet.com/deds -
Hi,
ich konnte das Verhalten auf die Schnelle nicht nachstellen - von daher habe ich nichts neues.
Aber beim erneuten Drüberlesen fiel mir noch ein Punkt auf: Ist der "1. DC! unter Umständen der PDC-Emulator der Domäne?
Ihr startet die MMC neu --> was passiert nach einem Neustart des Systems, auf dem Ihr die DFS-GUI benutzt?
Wahrscheinlich spielt hier ein lokaler MMC-Cache des Verwaltungsservers hinein.
Viele Grüße
Fabian
http://blogs.technet.com/deds -
Hi Ralph Andreas,
nicht unbedingt in Bezug auf das konkrete Problem, aber "ja" - der PDCe ist auch bei DFSN in einigen Bereichen relevant. Siehe dazu beispielsweise den root scalability mode: http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
Q. How many root servers can host a domain-based DFS namespace? A. Use 16 or fewer root targets unless you enable root scalability mode by using the /RootScalability parameter in Dfsutil.exe. When root scalability mode is enabled, DFS root servers get updates from the closest domain controller instead of from the server acting as the primary domain controller (PDC) emulator master. As a result, root scalability mode reduces network traffic to the PDC emulator master at the expense of faster updates to all root servers. With this mode enabled, you can have as many root targets as you need, as long as the size of the DFS Active Directory object (for each root) is less than 5 MB. Note that the PDC emulator master is not removed entirely from DFS operations. The PDC emulator master is still used as follows: • When you make changes to the namespace, the changes are made on the PDC emulator master also, but the root servers no longer poll the PDC emulator master hourly for those changes. Instead, they poll the closest domain controller. If the root server is a domain controller, the root server uses itself as the source. If the root server is not a domain controller and is in the same site as the PDC emulator master, the root server treats the PDC emulator master as it would any other domain controller. • When the DFS service starts on a root server, the DFS Active Directory object is accessed on the PDC emulator master. On the next polling interval, DFS accesses the closest domain controller, which might or might not be the PDC emulator master. Do not use root scalability mode if any of the following conditions exist in your organization: • Your namespace changes frequently, and users must have a consistent view of the namespace. • Domain controller replication is slow. Slow replication increases the amount of time it takes for the PDC emulator master to replicate DFS changes to other domain controllers, which in turn replicate changes to the root servers. Until this replication is complete, the namespace remains inconsistent on all root servers. Note: The number of root targets running Windows 2000 should be limited to 16 for any one namespace. After you enable root scalability mode in a namespace with root servers running Windows 2000 and Windows Server 2003, root servers running Windows 2000 Server still obtain updates from the PDC emulator master.
Daher meine Nachfrage, um das Problem besser zu verstehen.
Meine Vermutung ist noch immer, daß auf dem abgeschalteten Server ein weiterer Namespace existiert (ggf. auch Stand-Alone), der nach der Abschaltung nicht mehr erreicht werden kann. Zwar sagte jenso, daß das bei ihm nicht der Fall ist, aber ich würde es nicht ausschließen wollen.
Schaut doch bitte einmal auf den folgenden Registry Schlüssel auf beiden Systemen: HKLM\SOFTWARE\Microsoft\Dfs\Roots\Domain --> ist dort wirklich nur der in der GUI angezeigte Namespace sichtbar?
Viele Grüße
Fabian
http://blogs.technet.com/deds -
Hi Fabian,
ok sehe hier auch keinen direkten Zusammenhang zu Problem. Wollte aber selber mein DFS umstricken, d.h. DFS-Stamm von einem DC auf zwei DCs
synchr. verteilen, mit den 'Files and Folders ref Shares' im SAN unter W2008Sp2, mal sehen ob ich das Problem reproduzieren kann.
Gruß Ralph Andreas Altermann -
Hi Ralph Andreas,
wie gesagt - ich möchte die Gesamtumgebung und damit das Problem besser verstehen.
Der Erfahrung nach gibt es bei Problemen kaum Themen, die nicht relevant sind. Daher ist die Frage nach dem PDCe durchaus nicht uninteressant. Gerade, wenn man in Foren etc. keinen Überblick über die Gesamtumgebung hat, macht die Nachfrage zu den beeinflußenden Faktoren Sinn.
Änderungen am Namespace werden übrigens auch direkt an den PDCe gesendet, das nur nebenbei.
Ok, zurück zum Thema.
Viele Grüße
Fabian
http://blogs.technet.com/deds -
Hi Fabian,
ja, Deine Vermutung ist bei mir richtig. Der 1. DC ist bei mir auch gleichzeitig der PDC-Emulator. Ich habe die DFS-Verwaltungs-MMC auf dem 2. DC aufgerufen. Einen Neustart des 2. DC habe ich während des Tests nicht ausgeführt.
Ich werde gleich mal einen Test mit einem Verwaltungsrechner durchführen. Dabei werde ich dann auch die Abhängigenkeiten zur Abfrage-Optimierung "Für Konsistenz optimieren" oder "Für Skalierbarkeit optimieren" testen.
Hier der Reg-Eintrag für DFS auf den beiden DCs (ist auf beiden DCs gleich):
Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\domainV2]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\domainV2\DFS_Root]
"RootShare"="DFS_Root"
"LogicalShare"="DFS_Root"[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Standalone]
Stimmt es nun, dass wenn der PDC-Emulator nicht zur Verfügung steht (z. B. bei Ausfall des RZ mit dort vorhandenen DC1 mit PDC-Emulator) können keine Änderungen am DFS-Namespace durchgeführt werden?
Viele Grüße
Michael -
Hi Michael,
Dabei werde ich dann auch die Abhängigenkeiten zur Abfrage-Optimierung "Für Konsistenz optimieren" oder "Für Skalierbarkeit optimieren" testen.
Hier der Reg-Eintrag für DFS auf den beiden DCs (ist auf beiden DCs gleich):
Sieht soweit gut aus.Stimmt es nun, dass wenn der PDC-Emulator nicht zur Verfügung steht (z. B. bei Ausfall des RZ mit dort vorhandenen DC1 mit PDC-Emulator) können keine Änderungen am DFS-Namespace durchgeführt werden?
Das ist korrekt - jedoch sehe ich dabei nicht so große Probleme. Denn der PDCe ist in jeder AD-Umgebung eine recht wichtige Rolle, so daß man weit mehr Probleme riskiert, wenn der PDCe nicht online ist, als nur keine Änderungen an Domain-Namespaces durchführen zu können. ;-)
In jedem Fall sollte der PDCe zumindest zeitnah wieder online gebracht werden.
Viele Grüße
Fabian
http://blogs.technet.com/deds -
Hi Fabian,
danke für Deine schnellen Antworten.
Ergebnisse der Tests:
Nachdem der PDC-Emulator nicht mehr zur Verfügung steht, kann ich zwar auf beliebigen Geräten die DFS-Verwaltungskonsole aufrufen, aber es wird dann nicht mehr der domänenbasierte DFS Namespace gefunden. Dies ist unabhängig davon, welche Abfrage-Optimierung konfiguriert ist.
Viele Grüße
Michael -
Moin Moin,
vielleicht hat sich hier ja schon etwas neues ergeben? Ich hatte heute mal wieder DFS aufgesetzt. (2008R2+7) Diesmal in der Variante: "Ordentlich", d.h, DFS nur auf 2 Mitgliedsservern, nix mit FSMOs bei Ausfall nicht erreichbar und so. Und ich habe mich erneut gefragt: Warum muss der Client bei einem Wechsel durch einen Fail bis zu 30 Sekunden warten, bis er seinen neuen Server bekommt? Wie gesagt: Es hat alles einwandfrei geklappt, aber der Wechsel... Es stockt doch ziemlich. Die Cachezeiten hatte ich auf 10 Sek. eingestellt. Liegt es daran?
Gruß,
Michael
lernschmiede.de -
Hi Michael,
wir müssen hier zwei Themen auseinander halten: Auf der einen Seite die nicht Erreichbarkeit des PDCe - das betrifft die Verwaltung von Namespaces. Auf der andere Seite die Verzögerungen beim Zugriff. Vielleicht sollten wir die Themen einmal mit einem neuen Thread aufteilen.
In Bezug auf das "Verzögerungsproblem" in Deiner Umgebung empfinde ich 10 Sekunden massiv zu niedrig - damit setzt Du die Namespaceserver unter Umständen stark unter Last. Ich könnte mir sogar vorstellen, daß das gar nicht angwendet wird - check doch einmal auf dem Client mittels "dfsutil /pktinfo", welcher Cache-Zeitraum auf dem Namespace tatsächlich zur Anwendung kommt.
Ich in nicht so der DFSN-Spezi, aber ich würde sicher einmal einen Netzwerktrace ziehen um zu prüfen, was beim Wechsel des Servers so über die Leitung geht.
Viele Grüße
Fabian
http://blogs.technet.com/deds -
Moin Fabian,
danke für die Antwort. Das mit dem neuen Thread klingt gut. Wenn ich alle Daten beieinander habe, werde ich einen neuen starten oder mich an einem bestehenden zum Thema Verzögerung beteiligen. Kann noch etwas dauern.
Gruß,
Michael
lernschmiede.de -
Hi Michael,
ich habe noch einmal mit meinem Kollegen Hubert aus dem Netzwerkteam gesprochen, er beschäftigt sich unter anderem mit DFSN: Er sagte wie auch ich, daß 10 Sekunden Cache viel zu gering ist - unter Umständen holst Du Dir damit erst Probleme ins Haus. Empfehlung ist hier in den allermeisten Umgebungen den Standardwert beizubehalten.
Zusätzlich sind Verzögerungen beim Ausfall eines Targets normal, die Frage ist eher, wie lang die Suche nach einem Target insgesamt dauert. Da hier der Client erst versucht, das alte Target zu erreichen (und dann feststellt, daß es nicht mehr erreichbar ist), dann einen Namespaceserver kontaktiert, danach dann eine SMB-Verbindung aufbauen muß, kann dies etwas Zeit in Anspruch nehmen.
Mein Vorschlagt ist wie angesprochen, daß wir diesen Thread damit "beenden":
1. Bei Änderungen muß der PDCe erreichbar sein.
2. Geringe Verzögerungen auf dem Client bei Ausfall eines Targets sind "normal", sollten die Zeiträume jedoch sehr lang sein, machst Du einen neuen Thread mit diesem neuen Thema auf. :-)
Viele Grüße
Fabian
http://blogs.technet.com/deds- Als Antwort vorgeschlagen Fabian Müller [MSFT]Microsoft employee Dienstag, 20. Oktober 2009 07:19
- Als Antwort markiert Andrei TalmaciuModerator Freitag, 23. Oktober 2009 13:27