none
Nichtverbundenes Netzlaufwerk sobald DFS verwendet wird RRS feed

  • Frage

  • Hallo Zusammen,

    folgendes Problem:

    Server1 hatte bisher eine normale Freigabe auf dem Ordner C:\Daten mit dem Namen "Daten". Diese Freigabe war von allen vorhanden Terminalservern und Clients als Laufwerk E: verbunden. Bisher gab es damit keine Probleme. 

    Nun wurde diese Freigabe aber in einen DFS Namespace geändert. Heisst die Freigabe auf den Ordner C:\Daten wurde entfernt und einer neuer DFS Namespace \\Server1\Daten angelegt. Als DFS-Root wurde C:\Daten angegeben, damit die in C:\Daten liegenden Dateien gleich über den DFS Namespace verfügbar sind. Ich kann problemlos auf \\Server1\Daten zugreifen und mir auch nach wie vor das Laufwerk an den Clients als Netzlaufwerk E: verbinden.

    Problem ist allerdings, dass seit dieser Umstellung das Netzlaufwerk immer als "Nichtverbundenes Netzlaufwerk" im Arbeitsplatz angezeigt wird.

    Dieses Phänomen habe ich bei 2 Kunden in unabhängigen Installationen. Der "Server1" ist dabei einmal ein Server 2008R2, im anderen Fall ein Server 2012. Clients sind Windows 7, Server 2008R2 (TS) und Server 2012 bzw 2012 R2.

    Zudem macht es keine Unterschied ob ich das Netzlaufwerk per GPO oder Startskript verbinde. Es wird immer als "Nichtverbundenes Netzlaufwerk" angezeigt.

    Hat jemand eine Idee oder ein ähnliches Problem?

    Danke, Gruß Christoph

    Donnerstag, 30. Oktober 2014 10:15

Antworten

Alle Antworten

  • Als DFS-Root wurde C:\Daten angegeben, damit die in C:\Daten liegenden Dateien gleich über den DFS Namespace verfügbar sind.

    Ich wüsste nicht wie man es hätte falscher machen können:

    http://blogs.technet.com/b/deds/archive/2011/07/12/wie-ein-dfs-namespace-nicht-aussehen-sollte.aspx

    Also solltet ihr das nochmal neu machen.

    Gruß
    Lennart

    Donnerstag, 30. Oktober 2014 15:36
  • > Ich wüsste nicht wie man es hätte falscher machen können:
     
    Like! :-))
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Freitag, 31. Oktober 2014 07:24
  • Den Artikel kenne ich schon, mir ist auch bewusst, dass das nicht Best Practice ist! Wenn ich das DFS Root aber im Original Verzeichnis belasse, habe ich das gleiche Problem. Das ist also nicht der Grund!
    Montag, 3. November 2014 06:49
  • Diese Konfiguration ist nicht ohne Grund not supported...

    Ich rate dir dringend, das alles nochmal richtig zu machen und dein DFS richtig aufzubauen - sonst wird dir kaum jemand weiterhelfen.

    Montag, 3. November 2014 10:58
  • Nachdem ihr alle meine Konfiguration bemängelt habt (zu recht), habe ich es nun nochmal neu gemacht und das DFS Root im Standardverzeichnis belassen. Zudem habe ich eine Testumgebung mit einem Server 2012 R2 Server als Fileserver und einem als Client / Terminalserver installiert. Hier konnte ich das gleiche Problem nachstellen. Zuerst habe ich ein Verzeichnis als normale Freigabe freigegeben und am Client als LW verbunden. Ohne Probleme. Dann habe ich die Freigabe gelöscht und auf den gleichen Namen ein DFS Namespace erstellt. Das Laufwerk wird zwar wieder verbunden, jedoch auch als "nichtverbunden".
    Montag, 10. November 2014 13:57
  • Hallo Zusammen,

    kurzes Update: Bin in einem anderen Forum auf einen Hinweis gestoßen. Das Problem mit dem nichtverbundenen Netzlaufwerk haben anscheinend mehrere Leute die DFS Shares verwenden. Und zwar sobald auf dem Client die UAC deaktiviert ist. Das war auch bei mir der Fall. Sobald ich die UAC wieder aktiviere verschwindet das Problem mit dem Laufwerk.

    http://community.spiceworks.com/topic/493874-windows-2012-r2-rds-display-network-drives-with-a-red-cross

    Gruß Christoph
    Donnerstag, 4. Dezember 2014 07:07
  • Mahlzeit,

    bei uns haben die oben genannten Links keine engültige Lösung gebrcht.

    nach stundelangen Telefonate mit MS Support konnte die tatsächliche Ursache herausgefunden werden.

    Windows 2012 R2 arbeitet wie schon erwähnt dahingehend fehlerhaft was dem zugriff von elevated Prozessen in einer Session betrifft. DIe UAC ist hier nur bedingt involviert. Bei uns waren sowohl mit aktiver als auch inaktiver UAC die nichtverbundenen Laufwerke zu finden.

    Auf einem Testserver konnte ich nachstellen das wenn ich in User Session 1 ein DFS LAufwerk auf R: verbinde genau 3 Sekunden später in Session 2 plötzlich ein rotes X mit einem nicht verbundenen Laufwerk R: auftauchte. Spätestens bei Logoff/Logon war dieses Laufwerk immer sichtbar. Trennen des Laufwerks in Session 1 führte ebenfalls wieder zum verschwinden des Laufwerk R. in Session 2.

    Auf einer Farm mit 180 Usern waren diese Zusammenhänge zuerst nicht so leicht zu erkennen. :)

    Nun endlich zur Lösung:

    In der Regsitry findet man auf dem Session Host unter

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

    das DWORD:

    EnableLinkedConnections = 1

    Dieser Key sollte eigentlich administrativen Prozessen ermöglichen auf Laufwerke des Users zuzugreifen unter dessem Security Context das Programm mit Administrator Rechten aufgerufen wurde.

    Auf RDS Hosts kommt es hier jedoch zu dem Session übergriefenden Zugriff auf Laufwerke ALLER USER auf dem Host. 

    Nach einer Standardinstallation eines RDS Host ist dieser Key NICHT VORHANDEN. Bisher konnte ich noch nicht ergründen wer oder was den Key anlegt.

    Löscht man diesen Key auf allen RDS Hosts und startet die Hosts durch, sind alle Nichtverbundenen Laufwerke weg und auch der Zugriff auf DFS Share klappt ohne Probleme!!!

    Grüße

    Rene

    Freitag, 16. Januar 2015 13:54