2008 Domäne %HomeShare% %HomePath%

[Nimral]

Hi allseits,

Microsoft schafft es doch immer wieder einem lange Nächte zu verschaffen, in denen man die Segnungen ihrer Machwerke so richtig genießen darf. Es geht nun bald auf Mitternacht, ich habe keine Lust mehr auf den Mist, und schreibe noch schnell einen Hilferuf ins Forum - eventuell habe ich dann morgen früh einen Lösungsansatz auf den ich heute (und gestern, und vorgestern) nicht gekommen bin.

Problem: man nehme einen Domänen-User Account in einer Windows 2008 Domäne. 08/15. Dann verpasse man ihm per Active Directory ein Home-Verzeichnis dergestalt:

h: --> \server\share\username\daten

Die %HOMEDRIVE% und %HOMESHARE% Systemvariablen liefern jahrelang brav:

(1)
%HOMEDRIVE% = H:
%HOMESHARE% = \server\share\username\daten
%HOMEPATH% = \

Bis vor 4 Tagen. An einem AUßenstandort (eigene AD OU mit eigenen Policies) liefern die altbewährten Variablen nämlich andere Werte:

(2)
%HOMEDRIVE% = H:
%HOMESHARE% = \server\share
%HOMEPATH% = \username\daten

Bei der weiteren Fehlersuche wandelt sich das Staunen langsam in blanken Frust: nicht nur dass sich für diese Verhaltensänderung keine Ursache finden lässt - offenbar gilt dieser Sinneswandel nur während der Login-Phase: werden Scripte als Login-Scripte angestartet, lösen diese Variablen wie unter (2) beschrieben auf, sobald man dasselbe Script später von Hand vom User Desktop weg startet (oder wenn man das „set“ Kommando bemüht um nachzusehen) liefert es die Werte nach (1). WIndoof ändert also eigenmächtig diese Variablen.

Mit einer eilends nachgebauten Windows 2008 Domäne und einem XP SP-3 Testclient und einem User-Account mit den selben Einstellungen lässt sich das Problem nicht festnageln: Scripte liefern da immer Werte nach (1). Also wird das Verhalten von *irgendwas* anderem ausgelöst.

Hat jemand so was schon gesehen? Hat jemand eine Domäne in der immer nach (2) aufgelöst wird? Ich brauche dingend eine Spur, was dieses dämliche verhalten auslöst, da laufen nämlich Programme ohne Ende die sich beim Zugriff auf Userdaten an (1) orientieren, und die langen nun plötzlich alle ins Leere!

Armin.

[end_of_file]

Hallo,

laut http://support.microsoft.com/kb/969006 gibt es zwei Möglichkeiten:

1.) jemand hat an den GPOs gefummelt
User Configuration -> Administrative Templates -> System -> Logon/Logoff -> Connect home directory to root of the share

auf disabled setzen.

2.)
Netzwerk delay.
Computer Configuration -> Administrative Templates -> System -> Logon -> Always wait for the network at computer startup and logon

auf enabled setzen.

Hier eine Erklärung der „Connect home directory to root of the share“ das is eine GPO die mit W2k kam, und Kompatibilität zu NT Domänen bietet. Sollte man eher nicht mehr setzen, ausser man muss unbedingt.

http://technet.microsoft.com/en-us/library/cc962471…

Könnte es das gewesen sein?

Viel Erfolg,
Thomas

[Nimral]

Hi Thomas …

Hallo,

laut http://support.microsoft.com/kb/969006 gibt es zwei
Möglichkeiten:

1.) jemand hat an den GPOs gefummelt
User Configuration -> Administrative Templates -> System ->
Logon/Logoff -> Connect home directory to root of the share

Hier „fummelt“ keiner an GPOs, glaub mir

Ich war heute nicht untätig, habe diese Policy, die ich bisher nie beachtet hatte, gefunden und kontrolliert, und zwar im AD ebenso wie an der Quelle (Registry eines der betroffenen Clients): sie steht definitiv auf „disabled“, der entsprechende Registry Eintrag auf dword:0, GPResult meint auch sie sein nicht gesetzt --> trifft nicht zu.

Außerdem würde sie hoffentlich BEIDE Environments auf die selben Werte setzen, ich erinnere daran dass das Problem bei den Clients nur während des Ausführens der Login-Scripte besteht, nachher sind die Einträge korrekt - deshalb habe ich auch Tage gebraucht um das Problem zu isolieren, man kann es nur sehen wenn man in der Login-Phase die Umgeungsvariablen in eine Datei dumpt. Sobald der Login abgeschlossen ist, stehen alle Variablen korrekt, und auch H: ist korrekt verbunden.

Das Problem wurde überhaupt erst bemerkt als die Ordnerumleitung für die Favoriten eingeschaltet wurde und dann massenweise Favoritenordner im Nichts verschwanden. Inzwischen weiß ich, dass die Ordnerumleitung offenbar mit den falschen Werten arbeitet, und ich kann - im Unterschied zu Windows - die Favoriten deshalb auch auf der Platte finden und wieder da hin schieben wo sie hin gehören, aber das nervt ganz kollossal.

2.)
Netzwerk delay.
Computer Configuration -> Administrative Templates -> System
-> Logon -> Always wait for the network at computer startup
and logon

Die Computer sind Domänen-Mitglieder, soweit mir bekannt ist diese Einstellung dann ohne Wirkung, da für den Login an der Domäne der Netzwerkstart ohnehin abgewartet werden muss.

ABer ich kann die Policy am Montag mal versuchsweise setzen. Und wieder ist die Frage, warum Windows die Variablen *unterschiedlich* setzt damit nicht zu erklären.

auf enabled setzen.

Hier eine Erklärung der „Connect home directory to root of the
share“ das is eine GPO die mit W2k kam, und Kompatibilität zu
NT Domänen bietet. Sollte man eher nicht mehr setzen, ausser
man muss unbedingt.

Ist wie gesagt nicht gesetzt.

http://technet.microsoft.com/en-us/library/cc962471…

Könnte es das gewesen sein?

Leider nein, aber es weist wohl in die richtige Richtung. Das Interessante ist, wie gesagt, nicht nur, dass die Clients diesen Mechanismus aus irgendeinem Grund aufwecken, sondern die Inkonsistenz zwischen der Login-Script Phase und der Phase nachher.

Viel Erfolg,

Thx. Danke für den Hinweis auf die Policy!

[end_of_file]

Hallo,

ich glaube gern, dass da niemand an den GPOs fummelt. Das war nur in dem KB Artikel, und ich wollte es hineinschreiben, falls mal jemand über die Suche auf dieses Post trifft. Ich glaube da eher an die Performanceprobleme / Network delay. Leider ist das etwas unschön zu debuggen.

Ich habe noch etwas gefunden, das helfen könnte:
Computer Configuration->Administrative Templates ->System->Scripts->Run logon script synchronously
Auf enabled setzen.

Das soll laut folgendem link ähnliche Probleme beheben. Allerdings, wird es den Loginprozess verlangsamen, da der Explorer / Startleiste erst geladen wird, wenn die Skripte durch sind.
http://www.computing.net/answers/windows-2003/home-f…

Viele Erflog,
Thomas

[Nimral]

Hi Thomas,

alles auch gefunden, alles auch probiert, kein Ergebnis.

Inzwischen habe ich alle PCs (3500) mit einem Script gefilzt um zu sehen, ob ich bei den betroffenen Maschinen ein gemeinsames Problem finde. Es ließ sich keins finden. Etwa 10% der Computer sind betroffen (manche schon über 2 Jahre lang). Es trifft ein und den selben User an einer Maschine mal, und mal nicht, mal trifft es ihn an einer anderen Maschine, mal nicht.

Der Anteil der betroffenen User, bei denen das Problem auftrat, und bei denen das Login-Script per GPO gestartet wurde ist deutlich höher (10:1), als der Anteil derer die mit dem „klassischen“ Login Script konfiguriert sind.

Bedenklich: die automatische Suche hat sehr selten noch andere Fehlerbilder geliefert, bei denen sich mir die Haare sträuben, unter Anderem Kombinationen aus %HomeShare% = \Server\Share statt kompletter Home-UNC Pfad und gleichzeitig %HOMEPATH% = „Documents and Settings\Username“, offenbar ein wilder Mischmasch aus einem Teil Netzwerk-Home Pfad und einem Teil lokaler Pfad. Auch die Kombination %HomeShare% = \Server\Share mit %HOMEPATH% = leer kam einige Male vor. User Accounts und Berechtigungen auf die Hoemshares wurden sorgfältig geprüft und für OK befunden.

–> so sehen Windows Bugs aus.

Maschinen mit Legacy Script sind kaum betroffen. Ich werde dem GPO basietren Login-Script in den kommenden Tagen adieu sagen und reumütig wieder zum Legacy-Script zurückkehren, der GPO Script hat mir keinerlei Vorteile und nur einen Haufen Scherereien eingebracht.

Dir vielen Dank für Deine Bemühungen

AL.