45455
04.05.2010
13079
10
0
Index.dat in servergespeicherten Profilen bleibt stehen
Hallo,
seit einiger Zeit kämpfe ich in mehreren Domänen mit dem Problem, dass Roaming-Profile nicht vollständig gelöscht werden.
Dafür ist derzeit ein Workaround am laufen, der per batch die verwaisten Dateien beim Neustarten löscht.
Konkret bleibt in verschiedenen Ordnern jeweils die Datei "index.dat" stehen:
%userprofile%\Cookies
%userprofile%\IETldCache
%userprofile%\Lokale Einstellungen\Temporary Internet Files\Content.IE5
%userprofile%\Lokale Einstellungen\Verlauf\History.IE5
Clients sind XP in W2K3-AD-Domäne, Roaming-Profile werden vom Client beim Abmelden gelöscht
UPHC ist installiert
Laut processexplorer hat winlogon noch ein Handle auf die Dateien NACH dem Abmelden, gibt sie also erst bei einem Neustart frei.
Darüberhinaus bin ich aber noch auf keine Idee gekommen, warum das so ist.
Das dauernde Neustarten nervt die User aber zusehens, daher suche ich nach einer endgültigen Lösung.
Wäre schön, wenn da noch jemand einen Ansatz hätte.
Gruß
Kai
seit einiger Zeit kämpfe ich in mehreren Domänen mit dem Problem, dass Roaming-Profile nicht vollständig gelöscht werden.
Dafür ist derzeit ein Workaround am laufen, der per batch die verwaisten Dateien beim Neustarten löscht.
Konkret bleibt in verschiedenen Ordnern jeweils die Datei "index.dat" stehen:
%userprofile%\Cookies
%userprofile%\IETldCache
%userprofile%\Lokale Einstellungen\Temporary Internet Files\Content.IE5
%userprofile%\Lokale Einstellungen\Verlauf\History.IE5
Clients sind XP in W2K3-AD-Domäne, Roaming-Profile werden vom Client beim Abmelden gelöscht
UPHC ist installiert
Laut processexplorer hat winlogon noch ein Handle auf die Dateien NACH dem Abmelden, gibt sie also erst bei einem Neustart frei.
Darüberhinaus bin ich aber noch auf keine Idee gekommen, warum das so ist.
Das dauernde Neustarten nervt die User aber zusehens, daher suche ich nach einer endgültigen Lösung.
Wäre schön, wenn da noch jemand einen Ansatz hätte.
Gruß
Kai
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 142098
Url: https://administrator.de/contentid/142098
Ausgedruckt am: 23.11.2024 um 01:11 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
wir haben hier das Selbe Problem bei einem Kunden, nach dem Du ja relativ wenig Angaben zum System gemacht hast, muss ich mal raten
Nach dem wir da Problem aber schon ausführlich analysiert haben, tippe ich jetzt mal darauf, dass auf den XP Clients IE8 installiert ist.
Bei unseren Nachforschungen haben wir herausgefunden, dass alles wunderbar funktioniert bis einschließlich IE7.
Nach der Installation von IE8 tritt unmittelbar genau das von Dir beschriebene Problem auf. Und zwar sowohl an Terminalservern mit Windows 2003 als auch an allen XP-Clients bei denen die GPO :
Delete cached copies of roaming profiles"
bzw. "Zwischengespeicherte Kopie von servergespeicherten Profilen löschen"
Aktiv ist.
Bei den „normalen“ Clients wird die Ursache wohl auch da sein, fällt aber prinzipiell mal nicht ins Gewicht, da ja die lokale Kopie bestehen bleibt.
Das Verhalten Trift auf den KB840378 bei MS zu. Allerdings sind die dort angegebenen Ursachen natürlich nicht mehr zutreffend da es sich auf andere Versionen bezieht.
Als Konkreten Hinweis kann ich mal UPHClean 2.0 Beta (Weiterentwicklung leider eingestellt) nennen. Dies protokoliert nämlich im Eventlog folgendes:
Ereignistyp: Informationen
Ereignisquelle: UPHClean
Ereigniskategorie: Keine
Ereigniskennung: 1610
Datum: 17.06.2010
Zeit: 02:01:18
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: XPTest
Beschreibung:
The following processes are preventing access to C:\Dokumente und Einstellungen\testuser\Lokale Einstellungen\Verlauf\History.IE5\index.dat:
winlogon.exe (448) handle 0x948
winlogon.exe (448) section 0x94c
Access was not successful after a 1 seconds delay.
Dieser Eintrag wiederholt sich dann für jede der Dateien. Bis natürlich auf den Pfad und die Nummern bei winlogon und handle
Das erhöhen des Delay bewirkt gar nichts (außer dass die Abmeldung länger dauert.) Wenn für UPHClean der Wert SHARING_VIOLATION_REMAP aktiviert wird, bleibt überhaupt „Einstellungen werden gespeichert“ so lange stehen bis der PC abgeschaltet wird. Unter %systemroot%\debug\usermode\userenv.log wird nach setzen des Wertes
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
UserEnvDebugLevel = 0x00010002
Default ist 0x00010001
Folgendes protokoliert:
USERENV(1c0.1c4) 21:14:03:099 Delnode_Recurse: FindFile found: <Cookies>
USERENV(1c0.1c4) 21:14:03:099 Delnode_Recurse: Entering, lpDir = <\\?\C:\Dokumente und Einstellungen\testuser\Cookies>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: FindFile found: <.>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: FindFile found: <..>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: FindFile found: <index.dat>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: Failed to delete <index.dat>. Error = 32
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: Leaving <\\?\C:\Dokumente und Einstellungen\testuser\Cookies\index.dat>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: Failed to delete directory <\\?\C:\Dokumente und Einstellungen\testuser\Cookies>. Error = 145
...
usw.
Wir haben für unseren Kunden jedenfalls einen Support-Call bei MS eröffnet. Sobald wir die Lösung haben, würden wir sie hier posten.
Grüße
Daniel
wir haben hier das Selbe Problem bei einem Kunden, nach dem Du ja relativ wenig Angaben zum System gemacht hast, muss ich mal raten
Nach dem wir da Problem aber schon ausführlich analysiert haben, tippe ich jetzt mal darauf, dass auf den XP Clients IE8 installiert ist.
Bei unseren Nachforschungen haben wir herausgefunden, dass alles wunderbar funktioniert bis einschließlich IE7.
Nach der Installation von IE8 tritt unmittelbar genau das von Dir beschriebene Problem auf. Und zwar sowohl an Terminalservern mit Windows 2003 als auch an allen XP-Clients bei denen die GPO :
Delete cached copies of roaming profiles"
bzw. "Zwischengespeicherte Kopie von servergespeicherten Profilen löschen"
Aktiv ist.
Bei den „normalen“ Clients wird die Ursache wohl auch da sein, fällt aber prinzipiell mal nicht ins Gewicht, da ja die lokale Kopie bestehen bleibt.
Das Verhalten Trift auf den KB840378 bei MS zu. Allerdings sind die dort angegebenen Ursachen natürlich nicht mehr zutreffend da es sich auf andere Versionen bezieht.
Als Konkreten Hinweis kann ich mal UPHClean 2.0 Beta (Weiterentwicklung leider eingestellt) nennen. Dies protokoliert nämlich im Eventlog folgendes:
Ereignistyp: Informationen
Ereignisquelle: UPHClean
Ereigniskategorie: Keine
Ereigniskennung: 1610
Datum: 17.06.2010
Zeit: 02:01:18
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: XPTest
Beschreibung:
The following processes are preventing access to C:\Dokumente und Einstellungen\testuser\Lokale Einstellungen\Verlauf\History.IE5\index.dat:
winlogon.exe (448) handle 0x948
winlogon.exe (448) section 0x94c
Access was not successful after a 1 seconds delay.
Dieser Eintrag wiederholt sich dann für jede der Dateien. Bis natürlich auf den Pfad und die Nummern bei winlogon und handle
Das erhöhen des Delay bewirkt gar nichts (außer dass die Abmeldung länger dauert.) Wenn für UPHClean der Wert SHARING_VIOLATION_REMAP aktiviert wird, bleibt überhaupt „Einstellungen werden gespeichert“ so lange stehen bis der PC abgeschaltet wird. Unter %systemroot%\debug\usermode\userenv.log wird nach setzen des Wertes
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
UserEnvDebugLevel = 0x00010002
Default ist 0x00010001
Folgendes protokoliert:
USERENV(1c0.1c4) 21:14:03:099 Delnode_Recurse: FindFile found: <Cookies>
USERENV(1c0.1c4) 21:14:03:099 Delnode_Recurse: Entering, lpDir = <\\?\C:\Dokumente und Einstellungen\testuser\Cookies>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: FindFile found: <.>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: FindFile found: <..>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: FindFile found: <index.dat>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: Failed to delete <index.dat>. Error = 32
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: Leaving <\\?\C:\Dokumente und Einstellungen\testuser\Cookies\index.dat>
USERENV(1c0.1c4) 21:14:03:115 Delnode_Recurse: Failed to delete directory <\\?\C:\Dokumente und Einstellungen\testuser\Cookies>. Error = 145
...
usw.
Wir haben für unseren Kunden jedenfalls einen Support-Call bei MS eröffnet. Sobald wir die Lösung haben, würden wir sie hier posten.
Grüße
Daniel
Auf den Zusammenhang mit IE8 vs IE7 bin ich jetzt noch nicht gekommen, da das Problem unmittelbar davor noch mit anderen gesperrten Dateien bestand, was UPHClean ja behoben hatte.
Offenbar hatte sich das bei uns überschnitten, denn UPHClean habe ich erst installiert, als die Probleme begonnen hatten. Das war recht zeitnah zu IE8, der durchgängig installiert ist.
Auf die Lösung von MS bin ich jetzt allerdings auch gespannt, denn die User sind manchmal schon etwas genervt davon, dass ein Neuanmelden eigentlich nicht geht, sondern immer ein Neustart laufen muss, um sicher zu sein, dass alles funktioniert.
Gruß
Kai
Offenbar hatte sich das bei uns überschnitten, denn UPHClean habe ich erst installiert, als die Probleme begonnen hatten. Das war recht zeitnah zu IE8, der durchgängig installiert ist.
Auf die Lösung von MS bin ich jetzt allerdings auch gespannt, denn die User sind manchmal schon etwas genervt davon, dass ein Neuanmelden eigentlich nicht geht, sondern immer ein Neustart laufen muss, um sicher zu sein, dass alles funktioniert.
Gruß
Kai
Hallo,
ich habe soeben die (vorläufige) Lösung bekommen Sihe: http://support.microsoft.com/kb/974277/en-us
Es reicht eventuell aber auch in der GPO unter: "User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page"
"Site to Zone Assignment List" zu disablen bzw. auf "Not Configured" zu setzen. oder alle "nicht US-Domains" daraus zu entfernen.
Sofern die Liste über den IE von den Usern selbst gepflegt wird, könnte es nach meiner Meinung aber erforderlich sein die in dem KB-Artikel beschriebenen Registryeinträge vorzunehmen.
Bei unserem Kunden haben wir das Problem jedenfalls erst mal behobe in dem wir die GPO "Site to Zone Assignment List" deaktivirt haben.
Weitere Tests mit dem Reg-Key stehen noch aus.
KB974277 bestätigt ja uch gewisser maßen das, dass ein Problem von IE8 (ode rmöglicherweise ein Feature) ist
Ich hoffe das, dass auch Dir weiterhilft.
Grüße
Daniel
ich habe soeben die (vorläufige) Lösung bekommen Sihe: http://support.microsoft.com/kb/974277/en-us
Es reicht eventuell aber auch in der GPO unter: "User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page"
"Site to Zone Assignment List" zu disablen bzw. auf "Not Configured" zu setzen. oder alle "nicht US-Domains" daraus zu entfernen.
Sofern die Liste über den IE von den Usern selbst gepflegt wird, könnte es nach meiner Meinung aber erforderlich sein die in dem KB-Artikel beschriebenen Registryeinträge vorzunehmen.
Bei unserem Kunden haben wir das Problem jedenfalls erst mal behobe in dem wir die GPO "Site to Zone Assignment List" deaktivirt haben.
Weitere Tests mit dem Reg-Key stehen noch aus.
KB974277 bestätigt ja uch gewisser maßen das, dass ein Problem von IE8 (ode rmöglicherweise ein Feature
) istIch hoffe das, dass auch Dir weiterhilft.
Grüße
Daniel
Falls es von Interesse ist, ich habe mir ein kleines script gebastelt, dass nun als Startscript über GPO kommt und den Regkey setzt.
Grüße
Daniel
Grüße
Daniel
Der RegKey alleine bringt leider keine Veränderung.
Das ist schade, denn die GPO der Zonen-Zuweisung habe ich verwendet, um auf einfache Weise die penetrantesten Werbeeinblendungen zu unterbinden.
Das ist schade, denn die GPO der Zonen-Zuweisung habe ich verwendet, um auf einfache Weise die penetrantesten Werbeeinblendungen zu unterbinden.
Dann scheint da noch was anderes mit im Spiel zu sein!? Hier sieht es jedenfalls so aus, als ob es der RegKey tut.
Die Zonenzuweisung habe ich jedenfalls wider in kraft gesetzt. Nach einem Reboot siht erst mal alles gut aus.
Frage: Welche version von UPHClean hast Du denn im Einsatz.?
eventuell die 2.0.49.0 unter http://blogs.technet.com/b/uphclean/archive/2008/10/31/new-uphclean-bet ... herunterladen.
Aktivir doch mal bei einem "Testrechner"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
UserEnvDebugLevel = 0x00010002
und unter %systemroot%\Debug\usermode für die Datei Userenv.bak das Attribut Schreibgeschützt.
UserEnvDebugLevel bitte dann aber möglichst bald wieder auf 0x00010001 setzen und nach dem wegkopieren der userenv.log den Schreibsutz bei userenv.bak wieder entfernen.
Die Zonenzuweisung habe ich jedenfalls wider in kraft gesetzt. Nach einem Reboot siht erst mal alles gut aus.
Frage: Welche version von UPHClean hast Du denn im Einsatz.?
eventuell die 2.0.49.0 unter http://blogs.technet.com/b/uphclean/archive/2008/10/31/new-uphclean-bet ... herunterladen.
Aktivir doch mal bei einem "Testrechner"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
UserEnvDebugLevel = 0x00010002
und unter %systemroot%\Debug\usermode für die Datei Userenv.bak das Attribut Schreibgeschützt.
UserEnvDebugLevel bitte dann aber möglichst bald wieder auf 0x00010001 setzen und nach dem wegkopieren der userenv.log den Schreibsutz bei userenv.bak wieder entfernen.
Version UPHC war die 1.6.3
Hab da jetzt UPHC 2.0.49.0 drauf, seitdem gehts. Danke für den Tipp.
Das mit dem Testrechner hab ich auch probiert, muss ich aber mal in Ruhe durchschauen. Das Log-File wird ja recht lang.
(Rückstellen hab ich nicht vergessen
)
Gruß
kai
Hab da jetzt UPHC 2.0.49.0 drauf, seitdem gehts. Danke für den Tipp.
Das mit dem Testrechner hab ich auch probiert, muss ich aber mal in Ruhe durchschauen. Das Log-File wird ja recht lang.
(Rückstellen hab ich nicht vergessen
)Gruß
kai
Freut mich, dass ich anscheinend helfen konnte das mit UPHC 2.0 liegt daran, dass dieses auch offene File-Handles schließt und nicht nur Registry-Hives wie die 1.6.3
Grüße
Daniel
das mit UPHC 2.0 liegt daran, dass dieses auch offene File-Handles schließt und nicht nur Registry-Hives wie die 1.6.3Grüße
Daniel
Offensichtlich hilft nur beides zusammen, Reg-Key und neureres UPHC, denn vor Konfiguration der Site to Zone Assignment List gabs das Problem ja nicht. Und die 1.6.3 ist ja schon länger installiert.
So, ich konnte das nun in mehreren Domänen umsetzen und es funktioniert tadellos.
Nochmal vielen Dank.
Hiermit gelöst.
Nochmal vielen Dank.
Hiermit gelöst.
