RDS-Profil eines Benutzers ist kaputt - Neuanlage klappt nicht

Kann ich dir gar nicht genau sagen. Das war der Kollege der das gemacht hat. Erst wo es zu Problemen kam, wurde ich benachrichtigt da ich das ganze auch im Alleingang aufgebaut habe.


Zu spät, der Kollege hat das wohl händisch gelöscht. Ich habe mir das Tool jedoch nun heruntergleden und das betroffene USerprofil wird aber nicht aufgelistet, sprich: es nicht tatsächlich nicht mehr vorhanden.


Unter C:\Users habe ich allerdings und komischerweise lokale Profile des betroffenen Users gefunden. Und zwar 2 Stück. Alle anderen Profile werden 'gemountet' und entsprechend angezeigt. Der User XY hat aber plötzlich 2 Ordner, einmal XY und einmal XY.000 und es wurde trotzdem eine VHDX-Datei auf dem Profile-Fileserver erstellt (und nicht eingebunden / genutzt).

Warum wird a) bei einer Neuanmeldung 3 Profile erstellt (1. die zentral gespeicherte VHDX-Datei), 2. XY-Ordner und 3. XY.000 Ordner) und b) warum wird das zentral gespeicherte nicht genutzt?
Was kann ich noch tun?

Windows eigene UPDs (nehme ich mal an da FSLogix hier nicht genutzt wird. Dies wird in neueren Systemen wie unserem Horizon genutzt aber nicht in der RDS-Farm.

Ich hatte zuvor geprüft ob Profilordner des betreffenden Users unter C:\Users\ vorhanden waren. Waren sie nicht. Ob er noch von woanders irgendwelche Daten bezogen hat kann ich nicht sagen.
Wir haben für den Benutzer XY eine VHDX-Datei auf dem Fileserver liegen gehabt und diese wurde blöderweise 'händisch' gelöscht.


Hier wird weder während der User angemeldet noch nach dessen Abmeldung vom Server sein Profil aufgelistet.

Mit delprof2 habe ich die lokalen Profile auf dem Session-Host gelöscht.
Wo muss ich diese in der Registry löschen?

Nur das Löschen mit delprof2 hat nichts gebracht. Nach einer neuerlichen Anmeldung wurden wieder 2 lokale Verzeichnisse angelegt. XY und XY.000

P.S. Die VHDX-Datei auf dem Profile-Server wurde ebenfalls wieder angelegt aber nicht genutzt / eingebunden.
Der Dateiname der VHDX-Datei ist immer die SID und die ist natürlich gleich geblieben.
Nur wenn die VHDX-Datei gemountet werden würde...

Sorry, ja, das kenne ich ja sogar bereits und das habe ich ja total vergessen zu erwähnen: dort wird der User gar nicht aufgelistet auf dem Session-Host??

Was ich noch bemerkt habe:

User XY meldet sich an, es werden 2 Profilordner lokal auf dem Session-Host erstellt.
Einmal XY und einmal XY.000. Dazu natürlich noch die VHDX-Datei, die gemountet werden soll, auf dem Profilserver (also Fileserver).
Wenn ich nun delprof2 nutzte, löscht er mir nur den lokalen Profilordner XY.000. Den XY-Odnder erstmal nicht. Erst wenn ich die VHDX-Datei auf dem Profilserver lösche, kann ich mit delprof2 den lokalen Ordner "XY" auf dem Session-Host löschen.

Wie es aussieht ist der locale XY-Profilordner der Versuch die VHDX-Datei einzubinden. Das klappt dann nicht und so wird gleich der nächste XY.000-Profilordner lokal erstellt. Meldet sich der User ab, so kann ich mit delprof2 nur diesen letzten Profilordner löschen (also XY.000). Den ersten Ordner, der wahrscheinlich der 'Mountpoint' hätte sein sollen, erst nachdem ich die VHDX-Datei auf dem Profilserver lösche.

Die Anmeldegeschwindigkeit des Users ist aber atemberaubend. Es sieht nicht danach aus als ob das System im Hintergrund ein neues Profil erstellt wie das sonst üblich ist wenn sich ganz neue User zum ersten mal anmelden.

Wir haben hier in der Firma nur eine RDS-Farm. Ist der User nicht im Homeoffice, arbeitet er an seiner Workstation mit seinem lokalen eigenen Profil. Nur eine spezial-Abteilung nutzt nicht die RDS-Farm sondern Horizon (Konstruktion mit CAD-Software) wo der betreffenden User nicht dazugehört.
Wir haben in der Farm 4 Session-Hosts, verteilt auf 2 Sammlungen. Die betreffende Sammlung hat momentan nur einen SessionHost da der andere gerade neu aufgebaut wurde und noch nicht aktiviert wurde.
Also in dieser 'RDS-Welt' ist der User definitiv nirgends ein zweites Mal angemeldet. Im Servermananger zur RDS-Farm würde ich es ja auch sehen wenn der User noch wo angemeldet ist.

Sieht für mich jedenfalls exakt so aus.
Der User hat kein Profil da gelöscht worden. Er meldet sich nun an RDS an und folgendes passiert:
1. Ein neues VHDX-File mit dem SID des USers als Dateiname wird erstellt.
2. auf dem Session-Host wird ein Ordner erstellt mit dem Namen des Benutzers (XY) im C:\User-Verzeichnis
3. auf dem Session-Host wird ein weiterer Ordner erstellt mit dem Namen des Benutzers +" .000" (XY.000)
4. Der Benutzer bekommt ein Desktop mit den Verknüpfungen die wir per GPO drauf abstellen. JEDOCH bleibt die Statusleiste leer (Systray hat jedoch die Uhrzeit, Datum usw.) und der Windows-Start-Konpf ist sichtbar aber man kann ihn nicht öffnen und auch das Kontextmenü nicht anzeigen. Alles tot. Abmelden geht nur mir Win+R & "shutdown -L".
5. Nach der Abmeldung kann man händisch oder mit "delprof2" den lokalen "XY.000"-Ordner löschen. Den lokalen "XY"-Profilordner jedoch nicht. Erst wenn man die VHDX-Datei gelöscht hat, kann man auch diesen Ordner wieder löschen (z.B. mit "delprof2"). Das deutet darauf hin das der Versuch den Profilordner zu mounten fehlgeschlagen ist und es einfach 'hängen' bleibt. Darum ist der lokale 'Mount-Ordner' permanent in Zugriff von der VHDX-Datei und kann nicht gelöscht werden bevor die VHDX-Datie selber gelöscht wurde.

Ich habe die Berechtigung mit einer anderen Festplatten-Image-Datei verglichen (welche natürlich funkioniert bei entsprechendem User) und die unterscheidet sich in nichts.
Was mir aber noch aufgefallen ist: die größe der VHDX-Datei. Die ist lediglich 132 MB groß. Eine andere, korrekt neu angelegte VHDX-Datei hat 192 MB. Die 132 MB große Datei ist genauso groß wie die Template-VHDX-Datei.

Hi
Ja, schon meine Eltern haben mir gesagt gehabt ich wäre was ganz besonderes als ich noch klein war.. ;)
Habe ich gemacht. Sieht normal aus würde ich mal behaupten.

u.a.:
USERDNSDAOMIN=Firma.local
USERDOMAIN=Firma
USERDOMAIN_ROAMINGPROFILE=Firma
USERNAME=XY
USERPROFILE=C:\Users\XY


Ich sehe nur lauter Fehler bezüglich der Cortana ("Der Remoteprozeduraufruf ist fehlgeschlagen") und SearchUI (da steht es wäre relativ zur CortanaUI, also hängt das zusammen. Den Fehler habe ich aber sonst auch und Cortana wird bei uns nicht genutzt. Kann ich ignorieren würde ich mal sagen.
Ich habe bezüglich des betreffenden Users (mit dem fehlerhaften Profil) noch Fehlermeldungen das die ntuserdat nicht gelesen werden kann. Klar, die liegt ja im eigenen Profil und das ist ja kaputt..

Also folgende Fehler im Event Viewer:
- Ereignis 1508 (Fehler), User Profile Service: Die Registrierung konnte nicht gelesen werden.... Zugriff verweigert C:\Users\XY\ntuser.dat
- Ereignis 1508 (Fehler), User Profile Service: Die Registrierung konnte nicht gelesen werden.... Zugriff verweigert C:\Users\XY.000\ntuser.dat
- Ereignis 1000 (Fehler), Application Error: ShellExperienceHost.exe. Ausnahmecode:0x00000004...
- Ereignis 1001 (Information), Windows Error Reporting: Fehlerbucket 1165976556322457497, Typ 5, Ereignisname: MoAppCrash...

Wir haben einige GPOs die sich jedoch lediglich um ein paar Vorlagen kümmern, Laufwerksmappings vornehmen und eine die symbolische Links im 'Eigene Dateien\Dokumente' setzt. Auch haben wir noch GPOs die sich um Desktopverknüpfungen kümmert für verschiedene Abteilungen. Nichts besonderes und bis auf die symbolsichen Links alles Standard.


Gruß
Kaineanung

Hallo,

nein, ist nicht gemountet. Die VHDX-Datei wird ja auch immer von mir dann gelöscht damit eine neue erstellt wird beim Problem-User. Also ist diese definitiv nicht gemounted. Die Template-VHDX ist ebenfalls nicht im Zugriff da diese ja für neue User herangezogen wird und das klappt ja bei anderen Usern ausser bei diesem einen bei dem mein Kollege blöderweise dessen VHDX-Datei gelöscht hatte weil er dadurch meinte ein anderes Problem so zu lösen.
Ich nutze das Programm 'Sidder' um z.B. die VHDX-Dateien, welche mit dem SID der User benannt sind, zu identifizieren. Sprich: zum ermitteln wem gehört die VDHX-Datei. Diese zeigt immer an welche der Dateien gerade in Benutzung sind und welche nicht (farblich dargestellt). Die Template ist nicht in Benutzung und die des Users XY (mein aktueller Problemfall) ebenfalls nicht.

Ich wollte so gerne das Problem lösen. Wahrscheinlich werde ich den User in der AD komplett löschen, neu anlegen (andere SID!) und wahrscheinlich wird es dann klappen. Das wollte ich aber vermeiden weil ich ungerne neue User anlege weil sich ja die SID ändert und dadurch an anderen Stellen (z.B. persönliche Daten/Profil auf der Workstation) Probleme auftauchen könnten.

Ich bleibe vorerst aber noch am Ball und hoffe das Problem noch zu lösen ohne den User ganz neu anzulegen...