Probleme mit Mapping von Homeshare (DFS) unter Windows XP
Hallo zusammen, mein erster Tag hier und mein erster Beitrag.
Er soll auch gleich ein Leckerbissen für alle Windows Systemadminstratoren sein.
Seit einiger Zeit tritt in unserem Netzwerk folgendes Problem auf. Die Homeshares der Benutzer, die im AD-Profil hinterlegt sind, werden sporadisch nicht korrekt gemappt.
Das Laufwerk ("O:") ist zwar nach dem Login da, zeigt aber auf den DFS Root-Pfad.
D.h. im Profil steht: \\eu\rad\users\benutzername im Ergebnis zeigt Laufwerk O: auf \\eu\rad
Ausserdem stehen die Enviroment-Variablen im "Gut-Fall" so:
HOMEPATH=\
HOMESHARE=\\eu\rad\Users\benutzername
Im "Schlecht-Fall" so:
HOMEPATH=\users\benutzername
HOMESHARE=\\eu\rad
Abhilfe bringt nur ein "gpupdate /force" und abschliessender Neustart - allerdings nur für kurze Zeit (max 2-3 Tage).
Das Mappen von Laufwerken auf das DFS + Unterverzeichnisse über Login-Script funkioniert, wobei gelegentlich der erste Mapping-Vorgang fehl schlägt.
Unsere Systemumgebung:
500 Clients Windows XP Prof. SP3
2 DCs Win Server 2008 R2 64bit, beide gleichzeitig auch DFS Server
Das Problem wurde schon öfter im Netz in fast identischer Weise beschrieben, nur konnte niemand die Ursache erklären oder einen wirklich verbindliche Lösung anbieten.
Er soll auch gleich ein Leckerbissen für alle Windows Systemadminstratoren sein.
Seit einiger Zeit tritt in unserem Netzwerk folgendes Problem auf. Die Homeshares der Benutzer, die im AD-Profil hinterlegt sind, werden sporadisch nicht korrekt gemappt.
Das Laufwerk ("O:") ist zwar nach dem Login da, zeigt aber auf den DFS Root-Pfad.
D.h. im Profil steht: \\eu\rad\users\benutzername im Ergebnis zeigt Laufwerk O: auf \\eu\rad
Ausserdem stehen die Enviroment-Variablen im "Gut-Fall" so:
HOMEPATH=\
HOMESHARE=\\eu\rad\Users\benutzername
Im "Schlecht-Fall" so:
HOMEPATH=\users\benutzername
HOMESHARE=\\eu\rad
Abhilfe bringt nur ein "gpupdate /force" und abschliessender Neustart - allerdings nur für kurze Zeit (max 2-3 Tage).
Das Mappen von Laufwerken auf das DFS + Unterverzeichnisse über Login-Script funkioniert, wobei gelegentlich der erste Mapping-Vorgang fehl schlägt.
Unsere Systemumgebung:
500 Clients Windows XP Prof. SP3
2 DCs Win Server 2008 R2 64bit, beide gleichzeitig auch DFS Server
Das Problem wurde schon öfter im Netz in fast identischer Weise beschrieben, nur konnte niemand die Ursache erklären oder einen wirklich verbindliche Lösung anbieten.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 142261
Url: https://administrator.de/contentid/142261
Ausgedruckt am: 13.11.2024 um 09:11 Uhr
14 Kommentare
Neuester Kommentar
hallo
das sind ja reichlich clients auf den beiden dc´s.
wie sind die fsmo-rollen verteilt ?
bei dem thema fällt mir immer eins meiner lieblingsthemen ein " timestamp" diesmal bei den vorlagen.
das gpupdate / force schaut nicht auf den timestamp sondern nimmt sich was es bekommen kann.
als zweites habe ich ein timeproblem gehabt zum san wo das dfs liegt und dem dfs-root-server
aber leider ( zum glück ) habe ich kein system mit ähnlichen verhalten, wo ich mal testen könnte ( ok auch kein netzwerk mit 500 clients und nur 2dc´s/ mein größtes sind 290clients mit 4dc und 4member teilweise virtuell)
ich werde mal das problem mir auf wv legen
viel erfolg
gruß
.
das sind ja reichlich clients auf den beiden dc´s.
wie sind die fsmo-rollen verteilt ?
bei dem thema fällt mir immer eins meiner lieblingsthemen ein " timestamp" diesmal bei den vorlagen.
das gpupdate / force schaut nicht auf den timestamp sondern nimmt sich was es bekommen kann.
als zweites habe ich ein timeproblem gehabt zum san wo das dfs liegt und dem dfs-root-server
aber leider ( zum glück ) habe ich kein system mit ähnlichen verhalten, wo ich mal testen könnte ( ok auch kein netzwerk mit 500 clients und nur 2dc´s/ mein größtes sind 290clients mit 4dc und 4member teilweise virtuell)
ich werde mal das problem mir auf wv legen
viel erfolg
gruß
.
der arme.
aber der dfs-root liegt dann nicht auch noch auf dem wo die arbeit gemacht wird ?
dann ist dies warscheinlich auch der ältere der beiden ( oder erster ) und darf auch schemamaster sein.
ist bei solch vielen clients ein wenig ungünstig, denke ich.
was ich vorhin vergessen hatte zu fragen.
tritt der fehler wenn er auftritt dauerhafft auf über mehrer tage ? oder machst du gleich den workaround ?
hast du schon zeit gefunden nach dem timestamp zu schauen oder überhaubt nach der time allgemein ( timequelle solte auf jeden fall der fsmo-server bei dir sein)
aber der dfs-root liegt dann nicht auch noch auf dem wo die arbeit gemacht wird ?
dann ist dies warscheinlich auch der ältere der beiden ( oder erster ) und darf auch schemamaster sein.
ist bei solch vielen clients ein wenig ungünstig, denke ich.
was ich vorhin vergessen hatte zu fragen.
tritt der fehler wenn er auftritt dauerhafft auf über mehrer tage ? oder machst du gleich den workaround ?
hast du schon zeit gefunden nach dem timestamp zu schauen oder überhaubt nach der time allgemein ( timequelle solte auf jeden fall der fsmo-server bei dir sein)
Hallo WinSysOp,
das gpupdate /force läßt vermuten, das du den Eintrag "Bei Neustart bzw Anmeldung auf Netzwerk warten" in einer GPO fixiert hast.
Wenn das gpupdate hilft, vermute ich mal, das dann die obige Einstellung greift.
Wenn das Problem wieder auftritt, wäre eine sofortige Überprüfung der Einstellungen des Client-PCs mit dem jeweiligen User über das Group Policy Management - Gruppenrichtlinienergebnisse hilfreich.
Mal schaun ob der PC ALLE Richtlinien sauber verarbeitet.
MfG Thor1970
das gpupdate /force läßt vermuten, das du den Eintrag "Bei Neustart bzw Anmeldung auf Netzwerk warten" in einer GPO fixiert hast.
Wenn das gpupdate hilft, vermute ich mal, das dann die obige Einstellung greift.
Wenn das Problem wieder auftritt, wäre eine sofortige Überprüfung der Einstellungen des Client-PCs mit dem jeweiligen User über das Group Policy Management - Gruppenrichtlinienergebnisse hilfreich.
Mal schaun ob der PC ALLE Richtlinien sauber verarbeitet.
MfG Thor1970
Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten (Beschreibung von MS)
Legt fest, ob Windows XP beim Start des Computers und bei der Benutzeranmeldung auf das Netzwerk wartet. Standardmäßig wartet Windows XP beim Start und bei der Benutzeranmeldung nicht, bis das Netzwerk vollständig konfiguriert ist. Vorhandene Benutzer werden angemeldet, indem zwischengespeicherte Zugangsberechtigungen verwendet werden, was zu kürzeren Anmeldezeiten führt. Wenn das Netzwerk verfügbar wird, werden im Hintergrund Gruppenrichtlinien angewendet.
Achten Sie darauf, dass dies eine Aktualisierung im Hintergrund ist, Erweiterungen wie Softwareinstallation und Ordnerumleitung zwei Anmeldungen benötigen, damit die Änderungen wirksam werden. Um sicher arbeiten zu können, erfordern diese Erweiterungen, dass keine Benutzer angemeldet sind. Daher müssen sie im Vordergrund bearbeitet werden, bevor Benutzer den Computer aktiv verwenden. Außerdem kann es sein, dass für Änderungen am Benutzerobjekt, wie z.B. Hinzufügen eines Pfades eines servergespeicherten Profils, eines Basisverzeichnisses oder eines Benutzerobjekt-Anmeldeskripts das Erkennen von bis zu zwei Anmeldungen erforderlich ist.
Wenn ein Benutzer mit einem servergespeicherten Profil, einem Basisverzeichnis oder einem Benutzerobjekt-Anmeldeskript sich bei einem Computer anmeldet, wartet Windows XP immer darauf, dass das Netzwerk initialisiert ist, bevor der Benutzer angemeldet wird.
Wenn ein Benutzer sich noch nie bei diesem Computer angemeldet hat, wartet Windows XP immer darauf, dass das Netzwerk initialisiert ist.
Wenn Sie diese Einstellung aktivieren, werden Anmeldungen auf dieselbe Weise durchgeführt wie für Windows 2000-Clients, d.h. Windows XP wartet darauf, dass das Netzwerk vollständig initialisiert ist, bevor die Benutzer angemeldet werden. Im Vordergrund werden Gruppenrichtlinien synchron angewendet.
Wenn sie diese Einstellung deaktivieren oder nicht konfigurieren, wartet Windows nicht darauf, dass das Netzwerk vollständig initialisiert ist, und die Benutzer werden mit zwischengespeicherten Zugangsberechtigungen angemeldet. Gruppenrichtlinien werden asynchron im Hintergrund angewendet.
Hinweis: Wenn Sie die Anwendung der Ordnerumleitung, Softwareinstallation oder der Einstellungen von servergespeicherten Profilen in nur einem Anmeldevorgang garantieren wollen, aktivieren Sie diese Einstellung, um sicherzustellen, dass Windows darauf wartet, dass das Netzwerk zur Verfügung steht, bevor die Richtlinien angewendet werden.
Hinweis: Bei Servern verhält sich die Start- und Anmeldeverarbeitung immer so, als ob die Richtlinien-Einstellung aktiviert ist.
PS. "Erweiterungen wie Softwareinstallation und Ordnerumleitung zwei Anmeldungen benötigen"
Das Mappen von Laufwerken auf das DFS + Unterverzeichnisse über Login-Script funkioniert, wobei gelegentlich der erste Mapping-Vorgang fehl schlägt. --> Anmeldung Nr.2
Die Frage ist nur, ob deine Clients die GPO auch anziehen.
Legt fest, ob Windows XP beim Start des Computers und bei der Benutzeranmeldung auf das Netzwerk wartet. Standardmäßig wartet Windows XP beim Start und bei der Benutzeranmeldung nicht, bis das Netzwerk vollständig konfiguriert ist. Vorhandene Benutzer werden angemeldet, indem zwischengespeicherte Zugangsberechtigungen verwendet werden, was zu kürzeren Anmeldezeiten führt. Wenn das Netzwerk verfügbar wird, werden im Hintergrund Gruppenrichtlinien angewendet.
Achten Sie darauf, dass dies eine Aktualisierung im Hintergrund ist, Erweiterungen wie Softwareinstallation und Ordnerumleitung zwei Anmeldungen benötigen, damit die Änderungen wirksam werden. Um sicher arbeiten zu können, erfordern diese Erweiterungen, dass keine Benutzer angemeldet sind. Daher müssen sie im Vordergrund bearbeitet werden, bevor Benutzer den Computer aktiv verwenden. Außerdem kann es sein, dass für Änderungen am Benutzerobjekt, wie z.B. Hinzufügen eines Pfades eines servergespeicherten Profils, eines Basisverzeichnisses oder eines Benutzerobjekt-Anmeldeskripts das Erkennen von bis zu zwei Anmeldungen erforderlich ist.
Wenn ein Benutzer mit einem servergespeicherten Profil, einem Basisverzeichnis oder einem Benutzerobjekt-Anmeldeskript sich bei einem Computer anmeldet, wartet Windows XP immer darauf, dass das Netzwerk initialisiert ist, bevor der Benutzer angemeldet wird.
Wenn ein Benutzer sich noch nie bei diesem Computer angemeldet hat, wartet Windows XP immer darauf, dass das Netzwerk initialisiert ist.
Wenn Sie diese Einstellung aktivieren, werden Anmeldungen auf dieselbe Weise durchgeführt wie für Windows 2000-Clients, d.h. Windows XP wartet darauf, dass das Netzwerk vollständig initialisiert ist, bevor die Benutzer angemeldet werden. Im Vordergrund werden Gruppenrichtlinien synchron angewendet.
Wenn sie diese Einstellung deaktivieren oder nicht konfigurieren, wartet Windows nicht darauf, dass das Netzwerk vollständig initialisiert ist, und die Benutzer werden mit zwischengespeicherten Zugangsberechtigungen angemeldet. Gruppenrichtlinien werden asynchron im Hintergrund angewendet.
Hinweis: Wenn Sie die Anwendung der Ordnerumleitung, Softwareinstallation oder der Einstellungen von servergespeicherten Profilen in nur einem Anmeldevorgang garantieren wollen, aktivieren Sie diese Einstellung, um sicherzustellen, dass Windows darauf wartet, dass das Netzwerk zur Verfügung steht, bevor die Richtlinien angewendet werden.
Hinweis: Bei Servern verhält sich die Start- und Anmeldeverarbeitung immer so, als ob die Richtlinien-Einstellung aktiviert ist.
PS. "Erweiterungen wie Softwareinstallation und Ordnerumleitung zwei Anmeldungen benötigen"
Das Mappen von Laufwerken auf das DFS + Unterverzeichnisse über Login-Script funkioniert, wobei gelegentlich der erste Mapping-Vorgang fehl schlägt. --> Anmeldung Nr.2
Die Frage ist nur, ob deine Clients die GPO auch anziehen.
Interessant ist wahrscheinlich der Binärwert "ForceForegroundLogging" in der Registry(könnte der Schalter für das Anmeldeverhalten sein-bitte mal testen),
desweiteren die Einstellung "Setting Policy for Slow-Link Definition" in der GPO --> für eine langsame Netzwerkverbindung.
siehe: http://technet.microsoft.com/en-us/library/cc758898%28WS.10%29.aspx
desweiteren die Einstellung "Setting Policy for Slow-Link Definition" in der GPO --> für eine langsame Netzwerkverbindung.
siehe: http://technet.microsoft.com/en-us/library/cc758898%28WS.10%29.aspx
Die falschen Registry-Eintragungen könntest du über ein Anmeldeskript geradebiegen
Zugewiesen über die Benutzereinstellungen der GPO
die .cmd bzw .bat sollte dann so aussehen:
Reg Add "HKCU\Volatile Environment" /V "HOMESHARE" /D \\eu\rad\Users\%username% /T REG_SZ /F
Reg Add "HKCU\Volatile Environment" /V "HOMEPATH" /D \ /T REG_SZ /F
ist zwar nicht schön, sollte aber abhilfe schaffen.
Zugewiesen über die Benutzereinstellungen der GPO
die .cmd bzw .bat sollte dann so aussehen:
Reg Add "HKCU\Volatile Environment" /V "HOMESHARE" /D \\eu\rad\Users\%username% /T REG_SZ /F
Reg Add "HKCU\Volatile Environment" /V "HOMEPATH" /D \ /T REG_SZ /F
ist zwar nicht schön, sollte aber abhilfe schaffen.
Das Problem scheint an der NETBIOS Namensauflösung zu liegen.
http://support.microsoft.com/kb/244380/en-us
How to configure DFS to use fully qualified domain names in referrals
A Windows 2000-based server that is using Microsoft Distributed File System (DFS) replies to a DFS "get referral" query with a NetBIOS name format (\\server\share) by default. This is necessary in certain environments in which NetBIOS is relied upon.
Depending on the client's Domain Name System (DNS) configuration, the client may not be able to resolve the server name returned from the DFS "get referral" query.
..
Wir haben das DFS auf FQDN umgestellt. ( wie in KB 244380 unter "To enable fully qualified domain names in DFS"beschrieben. )
Seitdem ist der Fehler nicht mehr aufgetreten.
http://support.microsoft.com/kb/244380/en-us
How to configure DFS to use fully qualified domain names in referrals
A Windows 2000-based server that is using Microsoft Distributed File System (DFS) replies to a DFS "get referral" query with a NetBIOS name format (\\server\share) by default. This is necessary in certain environments in which NetBIOS is relied upon.
Depending on the client's Domain Name System (DNS) configuration, the client may not be able to resolve the server name returned from the DFS "get referral" query.
..
Wir haben das DFS auf FQDN umgestellt. ( wie in KB 244380 unter "To enable fully qualified domain names in DFS"beschrieben. )
Seitdem ist der Fehler nicht mehr aufgetreten.