4
User Profile Disks mit doppelten Benutzerordnern
Hallo zusammen,
da ich gerade wieder einmal etwas am Aufräumen bin und mir die gängigen Lösungen bisher nicht weiter geholfen haben, stelle ich hier einmal die Frage.
Eckdaten:
Auf den Session Servern bleiben sporadisch Rückstände der UPDs übrig nach dem Schema:
max.mustermann
max.mustermann.000
max.mustermann.001
...
Es ist IMMER der gleiche und einzige Ordner:
C:\Users\max.mustermann\AppData\Local\Microsoft\Windows\INetCache
Die bisherigen Recherchen ergaben, dass in der Regel ein Prozess noch ein Log hält oder ähnliches, nur finde ich hierzu keinerlei Hinweise im Ereignislog.
Auch finde ich keinerlei Hinweise, wenn ich das Log nach User Profile Service oder User Profile General durchsuche - Alles sauber.
Hat wer ähnliches schonmal gehabt und eine Lösung?
(Ich könnte natürlich ein Skript schreiben, welches mir regelmäßig alle entsprechenden Ordner löscht, aber ich mag Workarounds nicht)
da ich gerade wieder einmal etwas am Aufräumen bin und mir die gängigen Lösungen bisher nicht weiter geholfen haben, stelle ich hier einmal die Frage.
Eckdaten:
- 2019er TS Farm mit User Profile Disks
- 2 Sessions Hosts
- UPDs auf extra Server
Auf den Session Servern bleiben sporadisch Rückstände der UPDs übrig nach dem Schema:
max.mustermann
max.mustermann.000
max.mustermann.001
...
Es ist IMMER der gleiche und einzige Ordner:
C:\Users\max.mustermann\AppData\Local\Microsoft\Windows\INetCache
Die bisherigen Recherchen ergaben, dass in der Regel ein Prozess noch ein Log hält oder ähnliches, nur finde ich hierzu keinerlei Hinweise im Ereignislog.
Auch finde ich keinerlei Hinweise, wenn ich das Log nach User Profile Service oder User Profile General durchsuche - Alles sauber.
Hat wer ähnliches schonmal gehabt und eine Lösung?
(Ich könnte natürlich ein Skript schreiben, welches mir regelmäßig alle entsprechenden Ordner löscht, aber ich mag Workarounds nicht)
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: 594473
Url: https://administrator.de/contentid/594473
Printed on: May 11, 2024 at 01:05 o'clock
4 Comments
Latest comment
Hi,
eine User Profile Disk wird beim Login ins "C.\Users" "verbogen". Dabei wird für den Benutzer ein Ordnerlink erstellt.
Normalerweise kann jetzt nichts außerhalb dieser Profile Disk geschrieben werden, es sei denn, das erfolgt beim Logout, nachdem die Profile Disk schon wieder entladen wurde. In diesem Fall hängt es vom Prozess ab, welcher da schreiben will, ob dieser einfach abbricht (kann nicht schreiben) oder ob dieser dann die fehlende Ordnerstruktur gleich mit erstellt. Wenn letzteres, dann wird also nach dem Trennen der Profile Disk dieser Benutzerordner durch diesen verbleibenden Prozess wieder erstellt. Und dann ist dieser Ordner beim nächsten Login "im Weg", wenn Windows für den Benutzer die Profil Disk mounten will. Dann erstellt Windows einfach einen neuen neuen Ordner parallel zu existierenden und nummeriert den am Ende durch.
Sowas sollte eigentlich nicht eintreten.
Workaround: Lass regelmäßig per Scheduled Task ein Script laufen, welches solche "Leichen" löscht. Kriterium könnte sein: Ordner existiert, aber keine Datei namens NTUSER.DAT darin vorhanden.
E.
eine User Profile Disk wird beim Login ins "C.\Users" "verbogen". Dabei wird für den Benutzer ein Ordnerlink erstellt.
Normalerweise kann jetzt nichts außerhalb dieser Profile Disk geschrieben werden, es sei denn, das erfolgt beim Logout, nachdem die Profile Disk schon wieder entladen wurde. In diesem Fall hängt es vom Prozess ab, welcher da schreiben will, ob dieser einfach abbricht (kann nicht schreiben) oder ob dieser dann die fehlende Ordnerstruktur gleich mit erstellt. Wenn letzteres, dann wird also nach dem Trennen der Profile Disk dieser Benutzerordner durch diesen verbleibenden Prozess wieder erstellt. Und dann ist dieser Ordner beim nächsten Login "im Weg", wenn Windows für den Benutzer die Profil Disk mounten will. Dann erstellt Windows einfach einen neuen neuen Ordner parallel zu existierenden und nummeriert den am Ende durch.
Sowas sollte eigentlich nicht eintreten.
Workaround: Lass regelmäßig per Scheduled Task ein Script laufen, welches solche "Leichen" löscht. Kriterium könnte sein: Ordner existiert, aber keine Datei namens NTUSER.DAT darin vorhanden.
E.
Hallo emeriks,
danke für die Antwort.
Soweit ist mir das geläufig. Nur, wie ich bereits schrieb, geht's mir darum, keinen Workaround anzuwenden, sondern der Ursache auf den Grund zu gehen.
Die Logs geben halt nicht viel her, aber da es auch immer der gleiche Ordner ist, ist ja schon eine Richtung vorgegeben. Nur gehen mir die Ideen aus, wo ich noch schauen könnte. Tippe auf IExplorer, welcher ja auch systemseitig genutzt wird bei diversen Prozessen, dass da irgendwo der Cache nicht schnell genug geleert wird.
danke für die Antwort.
Soweit ist mir das geläufig. Nur, wie ich bereits schrieb, geht's mir darum, keinen Workaround anzuwenden, sondern der Ursache auf den Grund zu gehen.
Die Logs geben halt nicht viel her, aber da es auch immer der gleiche Ordner ist, ist ja schon eine Richtung vorgegeben. Nur gehen mir die Ideen aus, wo ich noch schauen könnte. Tippe auf IExplorer, welcher ja auch systemseitig genutzt wird bei diversen Prozessen, dass da irgendwo der Cache nicht schnell genug geleert wird.
Mahlzeit zu früher Stunde, 
Was passiert nach einem Reboot der RDSHs?
Sind die Rückstände dann weg oder noch da?
Ich betreibe eine 2016er-Farm mit 3 RDSHs, die jedes Wochenende per Powershell einmal durchstarten.
Seitdem keine Probleme dieser Art mehr bei mir aufgetreten.
Reboot tut gut. Zumindest hat es bei mir bisher nicht geschadet.
bdmvg
Was passiert nach einem Reboot der RDSHs?
Sind die Rückstände dann weg oder noch da?
Ich betreibe eine 2016er-Farm mit 3 RDSHs, die jedes Wochenende per Powershell einmal durchstarten.
Seitdem keine Probleme dieser Art mehr bei mir aufgetreten.
Reboot tut gut. Zumindest hat es bei mir bisher nicht geschadet.
bdmvg
Moin,
Gruß,
Dani
Hat wer ähnliches schonmal gehabt und eine Lösung?
Stand bei uns unregelmäßig auf der Tagesordnung. Wir haben sogar hin und wieder den Microsoft Premier Support konsultiert. Aber eine absichtliche Reproduktion ist uns nie gelungen. Daher haben wir Microsoft UPD verbannt und setzen auf FSLogix, welches inzwischen auch zu Microsoft gehört. Ist eine der besten Entscheidungen die wir in dem Bereich getroffen haben. Gruß,
Dani
