In einer Windows-Server-2019-RDS-Farm mit zwei Session Hosts und User Profile Disks (UPD) trat wiederholt das Problem auf, dass Benutzer temporäre Profile erhielten oder auf den Session Hosts immer neue lokale Profilverzeichnisse entstanden.
Das Fehlerbild sah beispielsweise so aus:
C:\Users\Benutzer01
C:\Users\Benutzer01.000
C:\Users\Benutzer01.001
C:\Users\Benutzer01.002
C:\Users\Benutzer01.003Teilweise mussten anschließend sowohl die User Profile Disk als auch die zugehörigen ProfileList-Einträge bereinigt werden.
Die eigentliche Ursache lag am Ende allerdings nicht direkt bei den UPDs, sondern bei zurückbleibenden Dateien von Adobe Acrobat.
Ausgangssituation
Die Umgebung besteht aus:
- Windows Server 2019
- zwei RDS Session Hosts
- zentral gespeicherten User Profile Disks
- RDS Collection mit UPD
- Adobe Acrobat auf den Session Hosts
Die UPDs werden dabei nicht für das komplette Benutzerprofil verwendet. Innerhalb der RDS-Collection werden unter anderem die Benutzerregistrierung und Roaming-Profildaten in der UPD gespeichert.
Die UPD eines betroffenen Benutzers war beispielsweise bereits seit längerer Zeit vorhanden:
UVHD-S-1-5-21-1111111111-2222222222-3333333333-12345.vhdxDie VHDX selbst wurde also nicht bei jeder Anmeldung neu angelegt.
Trotzdem entstanden auf dem Session Host laufend neue lokale Profilverzeichnisse.
Zunächst sieht es nach einem klassischen UPD-Problem aus
Im Eventlog waren unter anderem Events des User Profile Service vorhanden:
Event ID 1511
Das lokale Benutzerprofil wurde nicht gefunden.
Sie werden mit einem temporären Benutzerprofil angemeldet.Zusätzlich konnte im Operational-Log des User Profile Service beispielsweise folgendes gesehen werden:
Anmeldetyp: RDS
Speicherort des lokalen Profils: C:\Users\TEMP.DOMAIN.003
Profiltyp: TemporaryNaheliegend war daher zunächst ein Problem beim Mounten bzw. Unmounten der UPD.
Interessant war allerdings, dass bei einem anderen Login eines betroffenen Benutzers ausdrücklich ein reguläres Profil geladen wurde:
Speicherort des lokalen Profils: C:\Users\Benutzer01.000
Profiltyp: RegularDamit war klar:
Benutzer01.000 war kein temporäres Profil.
Windows hatte tatsächlich einen neuen regulären lokalen Profilpfad angelegt.
ProfileList und UPD prüfen
Die SID des Benutzers lässt sich beispielsweise so ermitteln:
([System.Security.Principal.NTAccount]'DOMAIN\Benutzer01').Translate([System.Security.Principal.SecurityIdentifier]).ValueDer zugehörige Eintrag befindet sich unter:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>Beispiel:
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-1111111111-2222222222-3333333333-12345" /sWährend der Benutzer angemeldet war, sah der Zustand beispielsweise so aus:
ProfileImagePath : C:\Users\Benutzer01.003
State : 0
FullProfile : 1Auch über WMI bzw. CIM war das Profil korrekt geladen:
Get-CimInstance Win32_UserProfile |
Where-Object {$_.SID -eq 'S-1-5-21-1111111111-2222222222-3333333333-12345'} |
Select SID,LocalPath,Loaded,Status,LastUseTimeBeispielausgabe:
LocalPath : C:\Users\Benutzer01.003
Loaded : True
Status : 0Das Profil war also aus Sicht von Windows zunächst vollkommen in Ordnung.
Verhalten beim Abmelden
Interessant wurde es nach einer kontrollierten Abmeldung.
Direkt danach war der ProfileList-Eintrag verschwunden:
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\$sid"Ausgabe:
FalseAuch Win32_UserProfile lieferte keinen Eintrag mehr.
Auf dem Fileserver war außerdem keine geöffnete UPD-VHDX mehr vorhanden.
Die UPD wurde also sauber getrennt.
Das lokale Profilverzeichnis blieb jedoch bestehen.
Der entscheidende Fund im lokalen Profil
Nach der Abmeldung enthielt das übrig gebliebene lokale Profil praktisch nur noch:
C:\Users\Benutzer01.003\AppData\Local\Temp\acrobat_sbx\Darin befanden sich Dateien wie:
Z@R1234.tmp
Z@R5678.tmp
Z@R9ABC.tmpDer komplette Rest des Profils war bereits entfernt worden.
Eine Prüfung mit:
Get-ChildItem 'C:\Users\Benutzer01.003' -Force -Recurse -ErrorAction SilentlyContinue |
Select FullName,Length,Attributeszeigte letztlich nur noch die Adobe-Sandbox-Dateien.
Damit war die Ursache ziemlich eindeutig eingegrenzt.
Warum entstehen dadurch .000, .001, .002 usw.?
Beim Logout versucht Windows, den lokalen Profilcache zu entfernen.
Der Ablauf sieht vereinfacht folgendermaßen aus:
Benutzer meldet sich ab
|
v
ProfileList-Eintrag wird entfernt
|
v
UPD wird sauber getrennt
|
v
Lokaler Profilordner soll gelöscht werden
|
v
Adobe-Datei unter AppData\Local\Temp\acrobat_sbx bleibt zurück
|
v
Profilordner kann nicht vollständig entfernt werdenBeim nächsten Login existiert damit beispielsweise weiterhin:
C:\Users\Benutzer01Windows hat aber keinen dazu passenden registrierten lokalen Profilcache mehr.
Also wird ein neuer eindeutiger Profilpfad erzeugt:
C:\Users\Benutzer01.000Beim nächsten Mal:
C:\Users\Benutzer01.001und so weiter.
Das erklärt auch, warum diese Verzeichnisse als normale Profile und nicht zwangsläufig als TEMP-Profile auftauchen.
Prüfung auf Reparse Points
Zur Sicherheit wurde außerdem geprüft, ob die zurückgebliebenen Ordner möglicherweise alte Mountpoints oder Junctions waren:
fsutil reparsepoint query C:\Users\Benutzer01
fsutil reparsepoint query C:\Users\Benutzer01.000
fsutil reparsepoint query C:\Users\Benutzer01.001
fsutil reparsepoint query C:\Users\Benutzer01.002
fsutil reparsepoint query C:\Users\Benutzer01.003Alle Verzeichnisse lieferten:
Fehler: Die Datei oder das Verzeichnis ist kein Analysepunkt.Es handelte sich also um ganz normale NTFS-Verzeichnisse.
Auch ein manuelles Umbenennen des verbliebenen Profilordners war nach der Abmeldung problemlos möglich.
Das spricht dafür, dass die Adobe-Dateien nur während des eigentlichen Logout-/Cleanup-Vorgangs noch blockiert waren. Kurz danach waren die Handles bereits wieder freigegeben, Windows startete den fehlgeschlagenen Cleanup aber nicht erneut.
Lösung
Die Lösung orientierte sich an einem entsprechenden Adobe-Community-Beitrag zu genau diesem Problem.
Es wurden zwei Anpassungen vorgenommen.
Keine sitzungsspezifischen temporären Ordner
Adobe wurde so konfiguriert, dass nicht für jede Sitzung separate temporäre Verzeichnisse verwendet werden.
Damit wird verhindert, dass bei jeder RDS-Sitzung erneut eigene Sandbox-/Temp-Strukturen entstehen, die beim Logout zurückbleiben können.
Adobe-Sandbox-Verzeichnis in die UPD aufnehmen
Zusätzlich wurde der relevante Adobe-Pfad in die User Profile Disk aufgenommen.
In dieser Umgebung handelt es sich um:
AppData\Local\Temp\acrobat_sbxDadurch wird der Adobe-Bereich nicht mehr ausschließlich im lokalen Profilcache des Session Hosts behandelt.
Die Änderung kann in der RDS-Collection über:
Server-Manager
→ Remotedesktopdienste
→ Sammlungen
→ Eigenschaften
→ Benutzerprofil-Datenträgervorgenommen werden.
Unter den zusätzlich einzuschließenden Ordnern wird der entsprechende Adobe-Pfad ergänzt.
Kontrolle nach der Änderung
Vorhandene Altlasten wie:
Benutzer01
Benutzer01.000
Benutzer01.001
Benutzer01.002
Benutzer01.003werden durch die Änderung natürlich nicht automatisch entfernt.
Entscheidend ist zunächst, dass nach neuen An- und Abmeldungen keine weiteren Verzeichnisse wie:
Benutzer01.004
Benutzer01.005mehr entstehen.
Nach einer Testabmeldung kann beispielsweise kontrolliert werden:
Get-Item 'C:\Users\Benutzer01*' -Force |
Select Name,CreationTime,LastWriteTimeZusätzlich sollte geprüft werden, dass:
- der
ProfileList-Eintrag nach der Abmeldung korrekt entfernt wird, - kein
Win32_UserProfilemehr geladen ist, - die UPD auf dem Fileserver nicht mehr geöffnet ist,
- kein neuer lokaler Profilrest entsteht.
Fazit
Das Fehlerbild sah zunächst stark nach einem klassischen RDS-UPD-Problem aus.
Die UPD wurde allerdings sauber getrennt und auch die Windows-Profilregistrierung korrekt aufgeräumt.
Die eigentliche Ursache waren zurückbleibende Dateien aus der Adobe-Acrobat-Sandbox unter:
AppData\Local\Temp\acrobat_sbxDadurch konnte Windows den lokalen Profilcache während des Logouts nicht vollständig entfernen.
Beim nächsten Login existierte der alte Profilordner weiterhin, sodass Windows automatisch einen neuen Profilpfad mit .000, .001, .002 usw. erzeugte.
Die Kombination aus angepasstem Adobe-Temp-Verhalten und Aufnahme des Adobe-Sandbox-Pfades in die UPD beseitigt genau diesen Konflikt.
Disclaimer
Dieser Artikel wurde mit Unterstützung von dieser KI gemacht, von der gerade alle reden und die den RAM so teuer macht…
