none
Clients und DCs in unterschiedlichen Subnetzen / Sites: welchen DC fragt der Client? RRS feed

  • Frage

  • Hallo zusammen,

    wir haben eine Domain mit 4 DCs.
    Drei davon stehen in einem gemeinsamen Subnetz in der Zentrale,
    einer ist ein RODC in einer Aussenstelle.
    Wir nutzen DFS-N und jeder DC ist Namespace-Server.
    In Sites & Services ist der RODC in der Site der Aussenstelle eingetragen,
    die DCs in der Zentrale in der entsprechenden Site.

    Jetzt fiel auf, dass viele Clients aus Subnetzen auf den RODC zugreifen wollen (138, 139,445 ...)
    und natürlich von der Firewall blockiert werden, weil nicht jeder Client in jedes Subnetz darf, logisch.

    Jetzt stellt sich die Frage, woher soll der Client aus Site 1 (sagen wir Frankfurt, Site ohne DC) wissen bzw. wie bringt man ihm bei,
    dass er auf die DCs in Site 2 (München, Site mit 3 DCs) zugreifen soll und NICHT
    auf den RODC in Site 3 (Hamburg, Site mit RODC).

    Aufgefallen ist das Ganze, weil User immer wieder von "Hängern" im Explorer berichten,
    wenn sie auf die Verzeichnisse hinter dem DFS-N Namespace zugreifen.
    Wenn die Clients beim Zugriff auf einen DFS-N Namespace "wahlfrei" oder "zufällig" auf die DCs zugreifen
    und manche dabei an den RODC geraten, den sie ja aus dem AD kennen, auf den sie aber wegen der FW nicht zugreifen können,
    könnte man sich die Hänger erkären.

    Mit freundlichem Gruss,
    Horst Wirth

    Donnerstag, 26. Juli 2012 10:55

Antworten

  • Grundsätzlich muss jeder DC, auch der RODC, erreichbar sein. Hintergrund ist wie die Clients ihren DC erkennen. Zur ersten Anmeldung geht der Client an einen beliebigen DC um sich eine Liste der DC's zu erhalten. Der DC erkennt dabei zu welcher Site der Client gehört und liefert die entsprechenden Server. Das bedeutet, ein Rechner kann durchaus am RODC landen, auch wenn er es nicht "darf".

    Der nächste Effekt entsteht, wenn ein Client am RODC-Standort angemeldet war. Diese Info hat er nämlich lokal abgespeichert. Beim nächsten Start wendet er sich automatisch an seinen letzten DC. Befindet sich der Rechner aber wieder in der Hauptstelle, bekommt er keine Antwort vom RODC.

    DFS-N wiederum ist in deinem Fall abhängig vom DFS-Client. Der holt sich bevorzugt den der Site zugehörigen Namespace Server. Aber jetzt kommt der Unterschied in den Versionen. Unter Win XP ruft der DFS-Client zu jedem DFS-Link die Information ab. Ist der DFS-Server nicht erreichbar, eben weil die FW blockt, kommt es zum Hänger, weil er keine Antwort bekommt. Der Client wartet aber einige Minuten ab. Unter Win 7 wurde der DFS-Client verbessert. Erreicht er den DFS Server nicht, läuft auf Timeout, setzt er seine Auflistung einfach fort. Es gibt keine Hänger.

    Empfehlung: In einer verteilten Umgebung sollten Domänendienste/DFS immer erreichbar sein.

    Montag, 30. Juli 2012 08:11
  • Man kann es nur bedingt steuern. Die Kosten in den Sites&Services dienen für verschiedene AD-Dienste wie Replikation oder DFS. Dadurch lässt sich steuern welche "Routen" bevorzugt genutzt werden. Allerdings ist das keine Garantie. Die Wege können sich trotzdem ändern.

    Was ist die Alternative? Keine wirklich. Denn DFS wird spätestens mit DFS-R ja auch für SYSVOL genutzt. Und wo ein Windows Client sich anmelden muss, müssen auch die Ports zu allen DCs der Domäne offen sein, unabhängig einer Unternehmenspolicy.

    Montag, 30. Juli 2012 10:09

Alle Antworten

  • Hallo,

    Du hast von den konfigurierten Sites gesrpochen, habt Ihr auch die Subbnetze in AD Standorte und Dienste entsprechend der Sites verteilt, besonders die Subnetze der Sites OHNE DC?

    Und welche DNS Server benutzen die Maschinen mit den Problemen?


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Donnerstag, 26. Juli 2012 11:13
  • Hallo Meinolf,

    vielleicht habe ich die falschen Begriffe verwendet:
    mit Site habe ich Standort im Tool "Standorte und Dienste" gemeint.
    Pro Aussenstelle gibt es ein eigenes Subnetz.
    Dieses ist im entsprechenden "Standort" in Standorte und Dienste definiert.
    Auch die Subnetze (Aussenstellen), die keinen eigenen DC haben, sind als Standort in Standorte und Dienste definiert.

    Jeder DC ist auch DNS-Server.
    Die Info, welcher DNS-Server benutzt werden soll, wird über DHCP verteilt.
    In der Aussenstelle mit dem RODC benutzen die Clients ihren eigenen DC /DNS-Server,
    in allen anderen Standorten werden die DCs/DNS-Server aus der Zentrale verwendet,
    also die PCs in Frankfurt fragen den DC/DNS-Server in München.

    Die Maschinen mit den Problemen stehen in Subnetzen/Standorten ohne DC, also z.B. Frankfurt.

    An der Stelle muss ich gestehen, dass wir WINS noch nicht abgeschaltet haben
    und daher auch noch die Info verteilen, wer der Wins-Server ist (einer der DCs).
    Vielleicht spielt das ja auch noch eine Rolle.

    Mit freundlichem Gruss,
    Horst Wirth

    Donnerstag, 26. Juli 2012 13:30
  • Grundsätzlich muss jeder DC, auch der RODC, erreichbar sein. Hintergrund ist wie die Clients ihren DC erkennen. Zur ersten Anmeldung geht der Client an einen beliebigen DC um sich eine Liste der DC's zu erhalten. Der DC erkennt dabei zu welcher Site der Client gehört und liefert die entsprechenden Server. Das bedeutet, ein Rechner kann durchaus am RODC landen, auch wenn er es nicht "darf".

    Der nächste Effekt entsteht, wenn ein Client am RODC-Standort angemeldet war. Diese Info hat er nämlich lokal abgespeichert. Beim nächsten Start wendet er sich automatisch an seinen letzten DC. Befindet sich der Rechner aber wieder in der Hauptstelle, bekommt er keine Antwort vom RODC.

    DFS-N wiederum ist in deinem Fall abhängig vom DFS-Client. Der holt sich bevorzugt den der Site zugehörigen Namespace Server. Aber jetzt kommt der Unterschied in den Versionen. Unter Win XP ruft der DFS-Client zu jedem DFS-Link die Information ab. Ist der DFS-Server nicht erreichbar, eben weil die FW blockt, kommt es zum Hänger, weil er keine Antwort bekommt. Der Client wartet aber einige Minuten ab. Unter Win 7 wurde der DFS-Client verbessert. Erreicht er den DFS Server nicht, läuft auf Timeout, setzt er seine Auflistung einfach fort. Es gibt keine Hänger.

    Empfehlung: In einer verteilten Umgebung sollten Domänendienste/DFS immer erreichbar sein.

    Montag, 30. Juli 2012 08:11
  • Hallo Matthias,

    vielen Dank für die Info.
    Wir würden die Zugriffe aber gerne steuern.
    Beispiel: ein PC ist in einer Site ohne DC.
    Nach Deiner Aussage sucht der sich jetzt einen beliebigen DC zum Anmelden - schön.

    Mein Problem an dieser Stelle ist, dass gem. Unternehmenspolicy der Zugriff von einer Aussenstelle (z.B. Wolfsburg)
    auf eine andere Aussenstelle (z.B. Köln) nicht möglich ist.
    Aber alle Aussenstellen haben Zugriff auf die DCs in der Zentrale (München).

    Könnte man hier über "Kosten" (siehe Inter-Site-Transports in "Standorte und Dienste") etwas steuern?

    Mit freundlichem Gruss,
    Horst Wirth

    Montag, 30. Juli 2012 08:56
  • Man kann es nur bedingt steuern. Die Kosten in den Sites&Services dienen für verschiedene AD-Dienste wie Replikation oder DFS. Dadurch lässt sich steuern welche "Routen" bevorzugt genutzt werden. Allerdings ist das keine Garantie. Die Wege können sich trotzdem ändern.

    Was ist die Alternative? Keine wirklich. Denn DFS wird spätestens mit DFS-R ja auch für SYSVOL genutzt. Und wo ein Windows Client sich anmelden muss, müssen auch die Ports zu allen DCs der Domäne offen sein, unabhängig einer Unternehmenspolicy.

    Montag, 30. Juli 2012 10:09
  • Vielen Dank Matthias,

    sieht so aus, als wirkt hier die "normative Kraft des Faktischen".

    Vielen Dank für die Hilfe,

    mit freundlichem Gruss,

    Horst Wirth

    Freitag, 3. August 2012 10:45
  • Nicht ganz - man kann schon das Verhalten beeinflussen.

    Da sämtliche Infrastruktur-Informationen aus dem AD in die jeweiligen DNS-Server/Partition übertragen werden müssen, so dass die Clients die notwendigen Informationen zur Namensauflösung bereitgestellt bekommen (Hintegründe s. http://technet.microsoft.com/fr-fr/library/cc759550(v=ws.10).aspx), kann man das Verhalten welche DC in welchen Szenarien in welcher Reihenfolge zurückgegeben werden schon beeinflussen - s. z.B.:

    How to optimize the location of a domain controller or global catalog that resides outside of a client's site
    http://support.microsoft.com/kb/306602

    jedoch ist dieses dann nicht mehr dynamisch-elastisch und muss regelmässig auf Richtigkeit überprüft werden, wenn Änderungen in der AD- und/oder Netzwerk-Infrastruktur vorgenommen werden.

    Weitere Informationen zum Branch-Office Szenario findet man auch hier:

    Planning Active Directory for Branch Office
    http://technet.microsoft.com/en-us/library/cc749944.aspx

    -
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
    Freitag, 3. August 2012 12:03