14
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.
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.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 142261
Url: https://administrator.de/contentid/142261
Printed on: April 25, 2024 at 14:04 o'clock
14 Comments
Latest comment
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ß
.
Die drei FSMO Rollen unserer Domäne liegen auf einem der beider DC: PDC, RID pool manager, Infrastructure master
Sämtliche DCs sind Global Catalog Server.
Sämtliche DCs sind Global Catalog Server.
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)
Der Fehler tritt dauerhaft, aber scheinbar zufällig bezüglich der Betroffenen auf. Heißt, es sind immer mal wieder andere Clients betroffen. Trotzdem gib es eine Häufung bei bestimmten Usern (nicht bestätigte Vermutung: insbesondere bei älteren PC)
Im Moment ist der Workaround der, dass im Login-Script mit dem Holzhammer das User laufwerk nocht mal gelöscht und mit "net use" zugemappt wird.
Damit haben wir erst mal "Ruhe", aber das problem ist nicht erkannt oder gar behoben.
Die anderen Fragen muss ich mit einem Kollegen klären.
Im Moment ist der Workaround der, dass im Login-Script mit dem Holzhammer das User laufwerk nocht mal gelöscht und mit "net use" zugemappt wird.
Damit haben wir erst mal "Ruhe", aber das problem ist nicht erkannt oder gar behoben.
Die anderen Fragen muss ich mit einem Kollegen klären.
Zu Deinen weiteren Fragen: Beide DCs haben das DFS root
Die Server sind alles VM maschinen, die Disks sind virtuelle Disks angebunden an ein schnelles SAN
An den Servers sind keine Performance Engpässen erkennbar.
Die Disk-IO ist ebenfalls im grünen Bereich.
Die Server sind alles VM maschinen, die Disks sind virtuelle Disks angebunden an ein schnelles SAN
An den Servers sind keine Performance Engpässen erkennbar.
Die Disk-IO ist ebenfalls im grünen Bereich.
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.
Hallo und danke erst mal für den Tipp.
Prinzipiell ist dieser Hinweis auch nich ganz neu für uns.
Verschiedene Diskussionen zum gleichen Thema verweisen auch darauf.
Wir haben schon versucht, diese GPO für alle Clients zu setzen.
Nur geholfen hat es nicht.
Es sah zumindest aus Sicht des Servers so aus, als hätte der Test-Client diese Richtlinie bekommen.
Da es nicht gewirkt hat, könnten man das vielleicht auch anzweifeln.
Was uns fehlt, ist eine Möglichkeit, die Abarbeitung der Policies und überhaupt des gesamten Login-Vorganges zu loggen oder zu debuggen.
Dann würde man warscheinlich schnell sehen, was genau da los ist.
Gibt es vielleicht eine Möglickeit ein solchens lückenloses Logging zu erzeugen?
Prinzipiell ist dieser Hinweis auch nich ganz neu für uns.
Verschiedene Diskussionen zum gleichen Thema verweisen auch darauf.
Wir haben schon versucht, diese GPO für alle Clients zu setzen.
Nur geholfen hat es nicht.
Es sah zumindest aus Sicht des Servers so aus, als hätte der Test-Client diese Richtlinie bekommen.
Da es nicht gewirkt hat, könnten man das vielleicht auch anzweifeln.
Was uns fehlt, ist eine Möglichkeit, die Abarbeitung der Policies und überhaupt des gesamten Login-Vorganges zu loggen oder zu debuggen.
Dann würde man warscheinlich schnell sehen, was genau da los ist.
Gibt es vielleicht eine Möglickeit ein solchens lückenloses Logging zu erzeugen?
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
OK, danke.
Das werde ich morgen mal prüfen.
Ich melde mich wieder.
Das werde ich morgen mal prüfen.
Ich melde mich wieder.
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.
lt. Fehlerbeschreibung hatte die Namensauflösung wohl funktioniert.
Der Eintrag verweist ja auf den DFS Root-Pfad.
Nur der Zugriff auf die darunterliegenden Verzeichnisse war wahrscheinlich nicht möglich.
Aber wenn es das Problem löst würde ich mich über eine Antwort von WinSysOp freuen.
Der Eintrag verweist ja auf den DFS Root-Pfad.
Nur der Zugriff auf die darunterliegenden Verzeichnisse war wahrscheinlich nicht möglich.
Aber wenn es das Problem löst würde ich mich über eine Antwort von WinSysOp freuen.
Sorry, dass ich mich erst jetzt wieder melde, aber es gab jede Menge anderer Probleme und nervöser User - tippe auf schlechte Mondphase ... 
Dem Hinweis von Thor1970 mit dem "Geradebiegen" der scheinbar falsch gestzten HOME Variablen bin ich nicht weiter nachgegangen, weil ich den Eindruck hatte, dass hiermit das Bild nur optisch beschönigt wird.
Der Tipp von SysADWin geht vermutlich in die richtige Richtung.
Wir haben unser DFS jetzt voll auf DNS und nicht mehr auf NETBIOS umgestellt. Die Details liefere ich noch nach.
Das Ergebnis ist verblüffend.
Am Beispiel eines definierten Users hat sich nachfolgend dieses Bild gezeigt:
- Home-Laufwerk O: nur noch über Profil zugewiesen => Laufwerk richtig gemappt
- Gruppen-Laufwerke R: S: X: über Mapping Policy statt über Login Script zugewiesen => alle Laufwerke richtig gemappt
- zum Zeitpunkt der Ausführung des Login-Scriptes:
- keine Variable HOMEDRIVE vorhanden
- HOMEPATH: \users1\test
- HOMESHARE: \eu\rad
- nach Login mit SET im command-Fenster.
- HOMEDRIVE O:
- HOMEPATH: \
- HOMESHARE: \eu\rad\users1\test
Wie gesehen, ändern sich die HOME-Variablen, möglicherweise auch asynchron bezogen auf den Startzeitpunkt Login-Scriptes.
Vielleicht erklärt das auch die Zufälligkeit der zuvor aufgetretenen Fehler beim Laufwerksmapping und ggf. auch den zufälligen Schifstand der HOME-Variablen nach erfolgtem Login.
Wir beobachten das Verhalten weiter.
Die Stimmung ist aber merklich gestiegen.
Danke Euch beiden für alle zuletzt gegebenen Tipps und Ratschläge.
Dem Hinweis von Thor1970 mit dem "Geradebiegen" der scheinbar falsch gestzten HOME Variablen bin ich nicht weiter nachgegangen, weil ich den Eindruck hatte, dass hiermit das Bild nur optisch beschönigt wird.
Der Tipp von SysADWin geht vermutlich in die richtige Richtung.
Wir haben unser DFS jetzt voll auf DNS und nicht mehr auf NETBIOS umgestellt. Die Details liefere ich noch nach.
Das Ergebnis ist verblüffend.
Am Beispiel eines definierten Users hat sich nachfolgend dieses Bild gezeigt:
- Home-Laufwerk O: nur noch über Profil zugewiesen => Laufwerk richtig gemappt
- Gruppen-Laufwerke R: S: X: über Mapping Policy statt über Login Script zugewiesen => alle Laufwerke richtig gemappt
- zum Zeitpunkt der Ausführung des Login-Scriptes:
- keine Variable HOMEDRIVE vorhanden
- HOMEPATH: \users1\test
- HOMESHARE: \eu\rad
- nach Login mit SET im command-Fenster.
- HOMEDRIVE O:
- HOMEPATH: \
- HOMESHARE: \eu\rad\users1\test
Wie gesehen, ändern sich die HOME-Variablen, möglicherweise auch asynchron bezogen auf den Startzeitpunkt Login-Scriptes.
Vielleicht erklärt das auch die Zufälligkeit der zuvor aufgetretenen Fehler beim Laufwerksmapping und ggf. auch den zufälligen Schifstand der HOME-Variablen nach erfolgtem Login.
Wir beobachten das Verhalten weiter.
Die Stimmung ist aber merklich gestiegen.
Danke Euch beiden für alle zuletzt gegebenen Tipps und Ratschläge.
