none
DFS-N - Domänenbasierter Namensraum - Client Standort/Verweise Reihenfolge und ABE RRS feed

  • Frage

  • Hallo Zusammen,

    hoffe hier wieder einmal Hilfe zu finden?

    Umfeld:

    AD-Domain Gesamt/Domain Level Windows 2008 R2,
    DFS-N auf Server 2012 R2

    + DFS-RootNameSpace \\<DomainFQDN>\NameSpaceName mit ABE und 1x DFS-N in Standort A und 2x Standort B
    + unterhalb des NameSpaceNamen ein Ordner und dann mehrere OrdnerLinks
    z.B. \\domain.local\Share\Folder\FolderLink1,  \\domain.local\Share\Folder\FolderLink2 etc.

    + ABE zuerst auf DFS-N Server im Standort A wie folgt aktiviert und gesetzt:
    - auf den OrdnerLinks auf "Explizierte Anzeigeberechtigungen für den DFS-Ordner festgelegt"
    - ACLs im DFS-Roots Ordner mit "List-Folder" AD-Gruppen angepasst

    + Clients hauptsächlich am Standort A
    + DFS-N in Standort B zur Redundanz
    + Sortiermethode "Zufällige Reihenfolge" ohne Option "Clientfailback zu bevorzugten Zielen" 

    Problembeschreibung:

    + Nach dem hinzufügen von weiteren DFS-Namespace Servern welche sich am Standort B befinden, halten diese zwar die ACLs des FolderLinks (DFS-System Kontrolle), jedoch nicht die angepasste ACLs des Filesystem wie Server im Standort A. Kann natürlich angepasst werden (Get-ACL/Set-ACL), ist aber nicht schön gemacht!?
    + Clients aus Standort A sehen nur die berechtigten Ordner (ABE Funktion) wenn an den entsprechenden Standort A verwiesen wird, was aber nicht immer der Fall ist.

    Hinweise:

    + Diagnose mittels nltest /DSGETSITE oder  dfsdiag /TestSites /Machine:<hostname>,  sehen in Ordnung aus, also Standortzuordnung passt.
    + nslookup _ldap._tcp.SiteA._sites.<domain name> wird aufgelöst
    + dfsdiag /testreferral , dfsdiag /testsites /DFSPath:\\domain.local\Share oder dfsutil /insite laufen ohne Fehler durch.
    +Auch das setzen der "Verweisreihenfolge außer Kraft setzen" beim DFS-N Standort A brachte keinen Erfolg!
    Was mir auffällt ist, dass alle Standorte-Verknüpfungen  die gleichen Kosten besitzen!?

    Frage:

    1. Eigentlich müssten die Clients mit der Einstellung den Standort A DFS-N auflösen, da nur ein Server im Standort und die Standort Zuordnung funktioniert?
      https://technet.microsoft.com/de-de/library/cc782417(v=ws.10).aspx
    2. Kann ich die Kosten evtl. auf die DFS Reihenfolge selbst setzen oder ziehen hier immer die Standort und Dienste Kosten?
    3. Reicht evtl. eine Anpassung der Kosten bei "Standort und Dienste"?
    4. Wie sind die Empfehlungen für Standort-Verknüpfungen und Kosten bei einem MPLS Netzwerk?
    5. Ist die Umsetzung mit dem ABE so eigentlich empfehlenswert / möglich? 
      Ziel ist, das die Anwender auch den \\domain.local\Share\FOLDER nicht sehen sollen wenn Sie keinen Zugriff haben und der liegt ja blöderweise im Filesystem!

    Vielen Dank im Voraus und LG, sowie ein schönes WE

    Freitag, 13. Februar 2015 12:10

Antworten

  • Hallo Manfred,

    welcher Output kommt bei dem Befehl: dfsutil cache referral

    Danke schonmal!

    Zweite Idee:

    It appears that if the link targets have different offline caching settings, it considers the targets with offline caching enabled first and only if that fails does it consider the preferred target. So I checked my targets to see if they have different caching settings and sure enough the preferred target didn’t have caching. Turned on caching for it, rebooted the laptop, and now it picks up the correct target!

    Quelle: http://rakhesh.com/windows/clients-picking-up-the-wrong-dfsn-target-dfsutil-shows-accessstatus-0xc000003a/

    • Bearbeitet Chris Vill Donnerstag, 19. Februar 2015 16:13
    • Als Antwort markiert MSchueler Donnerstag, 12. März 2015 07:30
    Donnerstag, 19. Februar 2015 16:10
  • Richte doch bitte den Bereich für das externe Subnet im AD Sites and Services ein und teste die Umgebung erneut. 

    http://support.microsoft.com/kb/2003961

    Montag, 23. Februar 2015 13:09

Alle Antworten

  • Hallo,

    zu deinen beiden Problembeschreibungen:

    DFS-Replikation repliziert NTFS-Dateiberechtigungen und alternative Datenströme, aber keine festen NTFS-Links und Analysepunkte. Vielleicht bringt Dich das ein Stück weiter.

    Quelle: https://technet.microsoft.com/en-us/library/59a9462a-cbdd-45e7-828b-12c6cd9ae478

    Freitag, 13. Februar 2015 15:53
  • Hallo,

    danke für die Antwort, aber NTFS als solches ist mir bekannt.

    DFS-Replikation ist im Moment auch gar nicht im Einsatz.

    Mir geht es darum festzustellen, ob das beschriebene Verhalten Frage 1 und die weiteren, zwischen DFS-Client, DC und DFS-N stimmt, da die Clients sich ja, trotz richtiger Site-Zuordnung scheinbar doch auch hin und wieder an einem DFS-N eines anderen Standorts wenden!

    Frage:

    1. Eigentlich müssten die Clients mit der Einstellung den Standort A DFS-N auflösen, da nur ein Server im Standort und die Standort Zuordnung funktioniert?
      https://technet.microsoft.com/de-de/library/cc782417(v=ws.10).aspx

    Ich vermute evtl, bedingt durch den domänenbasierten NameSpaces \\domain.local und der DNS Abfrage auf diese, wo alle DCs zurückgegeben "nslookup domain.local", das die Clients dadurch möglicherweise den falschen DFS-Verweis erhalten?



    Manfred Schüler

    Montag, 16. Februar 2015 07:52
  • Hallo Manfred,

    hast Du das "Site-Costing" aktiviert? Demnach kannst du den Clients ein priorisiertes Ziel im DFS mitgeben.

    Das "Server Target Prioritization" ist dafür da ein Namespace Server Vorang zu geben sollten mehrere Standorte ein DNS-N Server zur Verfügung stellen. https://msdn.microsoft.com/en-us/library/bb524795(v=vs.85).aspx

    Montag, 16. Februar 2015 08:57
  • Hallo Chris,

    ich habe das "Site-Costing" wie folgt schon gesetzt gehabt:

    1. Namespace \\domain.local\DFSNameSpaceRoot \ Option Verweise
            + Cachedauer = "300"
    + Sortiermethode = "Zufällige Reihenfolge"
            +Clientfailback zu bevorzugten Zielen" = "deaktiviert"

    2. Namespace \\NameSpaceServerA.domain.local\ Erweitert "Folgende Verweisreihenfolge"..             + Ausser Kraft setzen  = "aktiviert"
            + Zielpriorität = "Das erste von allen Zielen "

    3. Namespace \\NameSpaceServerB.domain.local\ Erweitert "Folgende Verweisreihenfolge"..
            + Ausser Kraft setzen  = "deaktiviert"

    http://blogs.technet.com/b/askds/archive/2011/10/27/dfs-override-referral-ordering-messing-with-the-natural-order.aspx

    und die Rückgabe des dfsutils clientseitig ausgeführt, dürften Verweise/Zugriffe vom Client doch gar nicht auf die andere Site (NameSpaceServerB) verweisen!?

    Dfsutil /spcinfo

    [*][DCA.domain.local*NetBiosDOMAINName] [*][domain.local] [+][domain.local] [+DCA.domain.local] AccessStatus: 0

    [-][NetBiosDOMAINName]

    Dfsutil /pktinfo


    Entry: \domain.local\DFSNameSpaceRoot

    ShortEntry: \domain.local\DFSNameSpaceRoot

    Expires in XX seconds

    UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )

       0:[\NameSpaceServerA.domain.local\DFSNameSpaceRoot] AccessStatus: 0 ( ACTIVE TARGETSET )

       1:[\NameSpaceServerB domain.local\DFSNameSpaceRoot] ( TARGETSET )

       2:[\NameSpaceServerB domain.local\DFSNameSpaceRoot]

    Im Moment habe ich die beiden NameSpaceServerB deaktiviert, um die Mitarbeiter nicht zu sehr zu belasten.
    Kann man ein DFS Logging am Client aktivieren, so wie beim Netlogon service?

    Ich vermute zudem, dass es evtl. an IPv6 liegen könnte, da Server und Clients (Citrix) mit v6 Adressen arbeiten und ich zu dem Standort keine IPv6 Zuordnung finde!? Oder auch ein Holzweg?

    http://support.microsoft.com/kb/2003961?ln=de-ch
    http://blogs.technet.com/b/askds/archive/2009/10/28/dfs-referrals-and-ipv6-outta-site.aspx



    Manfred Schüler

    Montag, 16. Februar 2015 14:46
  • Hallo Manfred,

    welcher Output kommt bei dem Befehl: dfsutil cache referral

    Danke schonmal!

    Zweite Idee:

    It appears that if the link targets have different offline caching settings, it considers the targets with offline caching enabled first and only if that fails does it consider the preferred target. So I checked my targets to see if they have different caching settings and sure enough the preferred target didn’t have caching. Turned on caching for it, rebooted the laptop, and now it picks up the correct target!

    Quelle: http://rakhesh.com/windows/clients-picking-up-the-wrong-dfsn-target-dfsutil-shows-accessstatus-0xc000003a/

    • Bearbeitet Chris Vill Donnerstag, 19. Februar 2015 16:13
    • Als Antwort markiert MSchueler Donnerstag, 12. März 2015 07:30
    Donnerstag, 19. Februar 2015 16:10
  • Hallo Chris,

    wie gesagt, ich habe im Moment die beiden NameSpaceServerB deaktiviert und nur NameSpaceServerA ist aktiv, damit ein arbeiten überhaupt möglich ist.

    Ich konnte das Problem selbst nicht nachstellen und
     die Ausgabe von meinem letzen Post zeigt auch keinen Fehler, so deute ich dies.

    Ich kann jedoch feststellen das,

    1. 2x NameSpaceServerB hat Offline Share Einstellung auf
      "Nur von Benutzer angegebene Dateien und Programme sind offline"
    2. NameSpaceServerA (am Client Standort) hat Offline Share Einstellung auf:
      "Keine Dateien oder Programme aus dem freigegebenen Ordner offline verfügbar machen"

    Wobei die Client die "Windows Offline Funktion" deaktiviert haben!

    Werde dann wohl die beiden NameSpaceServer wieder aktivieren und hoffen den Fehler nachstellen zu können.

    Gibt es zum DFSUtil und den Ausgaben eine Referenz oder Dokumentation was welcher Status Code bedeutet?

    Zum Beispiel verstehe ich nicht warum ich einen Output erhalte (UseCount 2) obwohl aktuell nur ein Verweis gelistet wird? Oder was bedeutet UseCount?

    Entry: \domain.local\share
    ShortEntry: \domain.local\share
    Expires in 299 seconds
    UseCount: 2 Type:0x81 ( REFERRAL_SVC DFS )
       0:[\NameSpaceServerA\DFSNameSpaceRoot] AccessStatus: 0 ( ACTIVE TARGETSET )


    Manfred Schüler


    • Bearbeitet MSchueler Freitag, 20. Februar 2015 12:56
    Freitag, 20. Februar 2015 12:55
  • Der Output ist vollkommend in Ordnung.

    Output Description for /PktInfo

    Current Partition Knowledge Table (PKT) information can be displayed by using the /pktinfo parameter. The following describes the type of output produced when /pktinfo is used. The description numbers correspond to the numbers in the sample output.

    1.  The initial entry specifies how many entries are included in the output.

    2.  Every entry has both a full (Entry) and a short (ShortEntry) name.

    3.  Expires or Time To Live (TTL) is the length of time a DFS client stores referral information from the PKT in its local cache. The DFS client requests new information from the PKT if the TTL expires or the client is restarted. The TTL is reset if the shared folder is accessed before it expires.

    4.  UseCount is the number of times it's used since got this referral. Type specifies the type of referral being made.

    5.  Each entry contains a sequentially numbered target list. A referral is a list of targets a DFS client receives from the PKT when a user attempts to access a root or a link in the namespace. Referrals are cached locally on the client for a time specified by time indicated in Expires. The referral information can tell you which target is active for your DFS client. The number after each target name indicates the state of the target. Attempts to access an inactive target will be referred to the currently active target.

    • State 0x21:inactive or not responding
    • State 0x31:responding and an active target

    6.  An ACTIVE target status indicates it is currently being accessed by the client. If access to this target fails, the client will try to access the next target in the list. In this entry, the client would try to access the 12th target, \dom-dc-12.dom.company.com\SysVol.

    dfsutil /pktinfo

    https://technet.microsoft.com/en-us/library/cc779494%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396



    • Bearbeitet Chris Vill Freitag, 20. Februar 2015 13:39
    Freitag, 20. Februar 2015 13:35
  • Danke für die Info. Dennoch sind mir die Status Code und der UseCount noch unklar!?

    Ich nutze DFSUtil aus den Support-Tools mit der Version 4.2 (Dateiversion 5.2.3790.1830) und dann aus dem RSAT mit der (Dateiversion 6.1.7600.16385), welche unterschiedliche Outputs produzieren:

    1. DFSUtil (SupportTools) Output

    Entry: \domain.local\share
    ShortEntry: \domain.local\share
    Expires in 14 seconds
    UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
       0:[\NameSpaceServerA\DFSNameSpaceRoot] State:0x110 ( ACTIVE TARGETSET )
       1:[\NameSpaceServerB\DFSNameSpaceRoot] State:0x100 ( TARGETSET )
       2:[\NameSpaceServerC\DFSNameSpaceRoot] State:0x00

    2. DFSUtil (RSAT Windows 7)

    Entry: \domain.local\share
    ShortEntry: \domain.local\share
    Expires in 0 seconds
    UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
       0:[\NameSpaceServerA\DFSNameSpaceRoot] AccessStatus: 0 ( ACTIVE TARGETSET )
       1:[\NameSpaceServerB\DFSNameSpaceRoot] ( TARGETSET )
       2:[\NameSpaceServerC\DFSNameSpaceRoot]

    Beide Outputs sind in Ordnung.

    UseCount "is the number of times it's used since got this referral" bedeutet UseCount 0 das auch Verweis 0 genutzt wird oder wirklich nur wie oft (bleibt bei mir immer gleich!?) ?

    Nochmal, wie kann ich feststellen,

    1. welcher Verweis nun wirklich vom Client genutzt wird?
      Also "ACTIVE" ist der genutzte?
    2. Übersicht aller Status Codes?
    3. warum hat Verweis B den Output (TARGETSET) und Verweis C nicht, obwohl gleich konfiguriert?

    Ich habe die Verweise B/C wieder aktiviert und prüfe den Zustand sobald als möglich.

    Danke im Voraus.


    Manfred Schüler

    Montag, 23. Februar 2015 08:28
  • Hallo Manfred,

    hast Du unter den "Active Directory Sites and Services" ein IPv6 Subnet angelegt für den externen Standort?

    Generell sollte IPv6 funktionieren, es muss jedoch korrekt eingerichtet sein und vollständig laufen. 

    ---

    Läuft paralell noch IPv4? Kann man das IPv6 testweise deaktiveren?

    Gruß

    Chris

    Montag, 23. Februar 2015 12:09
  • Hallo Chris,

    die DFS-N Server in den Standorten arbeiten mit IP v4 ("AD Sites and Services" konfiguriert) und mit IP v6 "link local" Adressen, welche nicht in "Active Directory Sites and Services" konfiguriert sind.

    IP v6 Adressen würde ich ungern deaktivieren und wenn, dann nur wenn ich den Fehler nachstellen kann. Hierzu warte ich nun auf eine Rückmeldung aus dem betroffenen Standort.

    Gruß

    Manfred


    Manfred Schüler

    Montag, 23. Februar 2015 12:36
  • Richte doch bitte den Bereich für das externe Subnet im AD Sites and Services ein und teste die Umgebung erneut. 

    http://support.microsoft.com/kb/2003961

    Montag, 23. Februar 2015 13:09
  • Hallo Chris,

    ich habe etwas Zeit benötigt um sicher zu sein, das die "different offline caching settings" wohl die Ursache waren, da ich nach der Anpassung (hier kein Offline Cache) die Anwender keine Probleme mehr gemeldet haben.

    Vielen Dank für die Unterstützung und die Bitte an Microsoft dies auch zu dokumentieren!


    Manfred Schüler

    Donnerstag, 12. März 2015 11:57
  • Hallo Chris,

    wird eigentlich eine mehrfache Verlinkung der DFS Targets unter Windows Server 2008/2012 unterstützt?

    IST-Zustand:

    In der DFS Namespace Struktur zeigen in unterschiedlichen Ordner Strukturen Links auf das gleiche Ziel?

    Beim Ausführen von dfsdiag /TestDFSIntegrity /dfsRoot:\\domain.local\namespaceroot erhalte ich Warnhinweise?

    Warning: These are DFS folders (links) pointing to the same folder target: \\Server\Share\FolderA\FolderB

    \\DOMAIN\namespaceroot\FolderA\LinkA
    \\DOMAIN\namespaceroot\FodlerB\LinkB

    Vielen Dank im Voraus für eine Antwort und Unterstützung.

    Gruß

    Manfred


    Manfred Schüler

    Dienstag, 17. März 2015 07:11