6
User Profile Disks unter Windows Server 2012 R2 - Temporäre Anmeldung
Guten Abend,
für Testzwecke, weil wir demnächst von alten Terminalservern unter Windows 2008 auf Windows 2012 R2 umstellen wollen, dabei auch gleichzeitig auf einen Farmbetrieb wechseln, erproben wir auf einem Testserver verschiedene Möglichkeiten für eine RDS-Sammlung im Farmbetrieb. Die Konfiguration sieht aktuell wie folgt aus:
1x RDS-Host, OS 2012 R2
1x Fileserver, OS 2012
1x Session Broker, OS 2012 R2
Der Session Broker hat eine Sammlung generiert, in der der RDS-Host eingebunden ist und darin auch definiert, die Userprofiledisk auf den Fileserver an- bzw. abzulegen.
Anfänglich liefen die Arbeiten am Server normal. Mit zwei Usern erste Testergebnisse gesammelt. Danach wollten wir einen weiteren User aufschalten, damit begannen dann die Probleme.
Auch hier am Anfang alles normal, bis wir eigene Dateien in sein neues Profil kopiert haben, hierbei blockierte plötzlich die UPD, an- und abmelden am System brachte kein Erfolg. Auf dem Fileserver wurde die UPD beim Aufruf mit dem Fehler das er dieses Image nicht bereitstellen kann abgebrochen.
Erster Verdacht war eine beschädigte UPD. In der Registry vom RDS-Host und auf dem Fileserver haben wir die Spuren dieser UPD und dem betroffenen Profil gelöscht. Dabei festgestellt, das bereits .BAK Einträge vorhanden waren, die durch die nachträglichen An- und Abmeldungen entstanden sind. Nachdem alles gelöscht war, konnte der User aber sich weiterhin nicht anmelden - die anderen zwei User jedoch ohne Probleme.
Wir sind dann ferner davon ausgegangen, das eventuell ein tiefersitzender Fehler in der Registry vorliegen dürfte und haben kurzerhand den Server (ist eine VM unter HyperV) gelöscht und eine Sicherung aufgespielt, die eine Woche älter ist, demzufolge weit vor dem Zeitraum der Userprofile. Nachdem der Server wieder sauber integriert war, haben wir erst mit den ursprünglich sauber laufenden Profilen gestartet - diese haben sich auch ohne Probleme sofort angemeldet und die UPD genutzt. Danach das "problembehaftete" Profil - was sofort wieder nur Temporär sich anmelden wollte.
Jetzt ist der aktuelle Status, das sich sowohl der User, als auch der Domänenadmin nur noch temporär anmelden können, während die anderen beiden User damit gar kein Problem haben.
Nun zur Frage, ist dieses Phänomen so schonmal jemanden begegnet, bzw. gibt es dafür irgendein Lösungsansatz? Der Weg über ProfilList und .bak Endungen entfernen hilft faktisch nicht.
Auch ein Hinweis auf SMB und SMB 3.0 ist nicht erfolgreich, es gibt hierfür extra eine GPO die auf allen Servern das freigibt, insofern könnte das Problem daher nicht rühren, vorallem da es ja teilweise funktioniert.
Häufige Fehler im Ereignislog die zu diesem Ereignis gehören:
215:AppReadiness - Fehler bei "ART:ResolveStoreCategories" für Administrator. Fehler: Zugriff verweigert
1511:User Profile Service - Das lokale Benutzerprofil wurde nicht gefunden
1515:User Profile Service - Das Benutzerprofil wurde gesichert.
20493:TerminalServices-RemoteConnectionManager - Die Remotedesktopdienste konnten keinen Benutzerdesktop für ein Benutzerkonto mit der SID "S-1-5-21-500" anwenden. Für den Benutzer wurde ein temporäres Profil erzwungen. Überprüfen Sie die Benutzerprofil-Datenträgereinstellungen. Fehlercode: 0x20.135
20495:TerminalServices-RemoteConnectionManager - Die Remotedesktopdienste konnten einen Benutzerprofil-Datenträger für das Benutzerkonto mit der SID "S-1-5-21-500" nicht einblenden. Fehlercode: 0x20.135
20499:TerminalServices-RemoteConnectionManager - Das Laden der Benutzerkonfiguration von Server "\\DC2.domain.local" für Benutzer "Administrator" durch die Remotedesktopdienste hat zu lange gedauert.
Bin für jede Hilfe dankbar - eventuell ist es nur eine Kleinigkeit, die ich aktuell bei der Sache übersehe.
Grüße
Forseti
für Testzwecke, weil wir demnächst von alten Terminalservern unter Windows 2008 auf Windows 2012 R2 umstellen wollen, dabei auch gleichzeitig auf einen Farmbetrieb wechseln, erproben wir auf einem Testserver verschiedene Möglichkeiten für eine RDS-Sammlung im Farmbetrieb. Die Konfiguration sieht aktuell wie folgt aus:
1x RDS-Host, OS 2012 R2
1x Fileserver, OS 2012
1x Session Broker, OS 2012 R2
Der Session Broker hat eine Sammlung generiert, in der der RDS-Host eingebunden ist und darin auch definiert, die Userprofiledisk auf den Fileserver an- bzw. abzulegen.
Anfänglich liefen die Arbeiten am Server normal. Mit zwei Usern erste Testergebnisse gesammelt. Danach wollten wir einen weiteren User aufschalten, damit begannen dann die Probleme.
Auch hier am Anfang alles normal, bis wir eigene Dateien in sein neues Profil kopiert haben, hierbei blockierte plötzlich die UPD, an- und abmelden am System brachte kein Erfolg. Auf dem Fileserver wurde die UPD beim Aufruf mit dem Fehler das er dieses Image nicht bereitstellen kann abgebrochen.
Erster Verdacht war eine beschädigte UPD. In der Registry vom RDS-Host und auf dem Fileserver haben wir die Spuren dieser UPD und dem betroffenen Profil gelöscht. Dabei festgestellt, das bereits .BAK Einträge vorhanden waren, die durch die nachträglichen An- und Abmeldungen entstanden sind. Nachdem alles gelöscht war, konnte der User aber sich weiterhin nicht anmelden - die anderen zwei User jedoch ohne Probleme.
Wir sind dann ferner davon ausgegangen, das eventuell ein tiefersitzender Fehler in der Registry vorliegen dürfte und haben kurzerhand den Server (ist eine VM unter HyperV) gelöscht und eine Sicherung aufgespielt, die eine Woche älter ist, demzufolge weit vor dem Zeitraum der Userprofile. Nachdem der Server wieder sauber integriert war, haben wir erst mit den ursprünglich sauber laufenden Profilen gestartet - diese haben sich auch ohne Probleme sofort angemeldet und die UPD genutzt. Danach das "problembehaftete" Profil - was sofort wieder nur Temporär sich anmelden wollte.
Jetzt ist der aktuelle Status, das sich sowohl der User, als auch der Domänenadmin nur noch temporär anmelden können, während die anderen beiden User damit gar kein Problem haben.
Nun zur Frage, ist dieses Phänomen so schonmal jemanden begegnet, bzw. gibt es dafür irgendein Lösungsansatz? Der Weg über ProfilList und .bak Endungen entfernen hilft faktisch nicht.
Auch ein Hinweis auf SMB und SMB 3.0 ist nicht erfolgreich, es gibt hierfür extra eine GPO die auf allen Servern das freigibt, insofern könnte das Problem daher nicht rühren, vorallem da es ja teilweise funktioniert.
Häufige Fehler im Ereignislog die zu diesem Ereignis gehören:
215:AppReadiness - Fehler bei "ART:ResolveStoreCategories" für Administrator. Fehler: Zugriff verweigert
1511:User Profile Service - Das lokale Benutzerprofil wurde nicht gefunden
1515:User Profile Service - Das Benutzerprofil wurde gesichert.
20493:TerminalServices-RemoteConnectionManager - Die Remotedesktopdienste konnten keinen Benutzerdesktop für ein Benutzerkonto mit der SID "S-1-5-21-500" anwenden. Für den Benutzer wurde ein temporäres Profil erzwungen. Überprüfen Sie die Benutzerprofil-Datenträgereinstellungen. Fehlercode: 0x20.135
20495:TerminalServices-RemoteConnectionManager - Die Remotedesktopdienste konnten einen Benutzerprofil-Datenträger für das Benutzerkonto mit der SID "S-1-5-21-500" nicht einblenden. Fehlercode: 0x20.135
20499:TerminalServices-RemoteConnectionManager - Das Laden der Benutzerkonfiguration von Server "\\DC2.domain.local" für Benutzer "Administrator" durch die Remotedesktopdienste hat zu lange gedauert.
Bin für jede Hilfe dankbar - eventuell ist es nur eine Kleinigkeit, die ich aktuell bei der Sache übersehe.
Grüße
Forseti
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: 252669
Url: https://administrator.de/forum/user-profile-disks-unter-windows-server-2012-r2-temporaere-anmeldung-252669.html
Ausgedruckt am: 16.02.2025 um 18:02 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
leider erging es mir ganz genauso - bzw. sehr ähnlich. Nach zich "Hilfeanfragen" bei Microsoft und diversen durchstöberten Foren gab es nur eine Lösung:
UPDs deaktivieren und auf lokale bzw. servergespeicherte Profile umsteigen.
Ich habe hier sogar eine Frage eröffnet:
Windows Server 2012 Terminal-Server - Temporäre Profile bei Nutzung eines Benutzerprofil-Datenträgers
Dort ist auch ein sehr interessanter Link zu einem Technet-Forum enthalten..
LG,
Florian
leider erging es mir ganz genauso - bzw. sehr ähnlich. Nach zich "Hilfeanfragen" bei Microsoft und diversen durchstöberten Foren gab es nur eine Lösung:
UPDs deaktivieren und auf lokale bzw. servergespeicherte Profile umsteigen.
Ich habe hier sogar eine Frage eröffnet:
Windows Server 2012 Terminal-Server - Temporäre Profile bei Nutzung eines Benutzerprofil-Datenträgers
Dort ist auch ein sehr interessanter Link zu einem Technet-Forum enthalten..
LG,
Florian
Guten Morgen Florian,
Deinen Beitrag hab ich bereits gesehen, wobei ich, wenn ich Deinen Beitrag richtig gelesen habe, der Unterschied darin bestand, das bei Dir die User sich einmalig anmelden konnten und danach generell nur noch temporär - wobei bei mir es sich so verhält, das ein Teil generell sich normal anmelden kann und ein anderer Teil ab einem Zeitpunkt X nur noch temporär.
Die Frage wo wir uns aktuell stellen ist, ob der Bug tatsächlich vom Terminalserver ausgelöst wird oder an einer anderen Stelle zu suchen ist.
Der Fehler trat am 20.10. erstmalig auf - daher haben wir gestern abend den Server einfach neu aus der Sicherung vom 14.10. aufgesetzt, insofern hätte sich das System dann wieder wie ursprünglich verhalten sollen, was es jedoch nicht macht, sondern bei den besagten Userprofilen gleich wieder den Fehler produziert.
Daher überlege ich, ob der Bug nicht dadurch entsteht das Informationen im SessionBroker oder gar im Domaincontroller geführt werden. Den Fileserver würde ich dabei nicht berücksichtigen, da die Freigaben auf diesen soweit funktionieren, mehr ist ja eigentlich seine Aufgabe dabei nicht. Den Link zum Technet-Forum gehe ich aber mal näher nach.
Grüße
Forseti
Deinen Beitrag hab ich bereits gesehen, wobei ich, wenn ich Deinen Beitrag richtig gelesen habe, der Unterschied darin bestand, das bei Dir die User sich einmalig anmelden konnten und danach generell nur noch temporär - wobei bei mir es sich so verhält, das ein Teil generell sich normal anmelden kann und ein anderer Teil ab einem Zeitpunkt X nur noch temporär.
Die Frage wo wir uns aktuell stellen ist, ob der Bug tatsächlich vom Terminalserver ausgelöst wird oder an einer anderen Stelle zu suchen ist.
Der Fehler trat am 20.10. erstmalig auf - daher haben wir gestern abend den Server einfach neu aus der Sicherung vom 14.10. aufgesetzt, insofern hätte sich das System dann wieder wie ursprünglich verhalten sollen, was es jedoch nicht macht, sondern bei den besagten Userprofilen gleich wieder den Fehler produziert.
Daher überlege ich, ob der Bug nicht dadurch entsteht das Informationen im SessionBroker oder gar im Domaincontroller geführt werden. Den Fileserver würde ich dabei nicht berücksichtigen, da die Freigaben auf diesen soweit funktionieren, mehr ist ja eigentlich seine Aufgabe dabei nicht. Den Link zum Technet-Forum gehe ich aber mal näher nach.
Grüße
Forseti
So, den Technet-Forum auch durchgestöbert, interessant das der Fehler schon ca. 2 Jahre ohne Problembehebung durchläuft. Wobei beim Technet-Forum meine Event-ID's nicht vorkommen. Irgendwie gehören aber diese Fehler zusammen.
Ein weiterer interessanter Link zu diesem Thema: https://help.austlink.net/hc/en-us/articles/203419403-Windows-2012-Remot ...
Dies wird evtl. für den einen oder anderen hilfreich sein, wenn das UPD sich verheddert hat und der RDS-Host dieses Image nicht mehr freigibt.
In meinem speziellen Fall sind aber die User Disk's gar nicht vorhanden, da sie nie angelegt werden. Aber ich such weiter.
Dies wird evtl. für den einen oder anderen hilfreich sein, wenn das UPD sich verheddert hat und der RDS-Host dieses Image nicht mehr freigibt.
In meinem speziellen Fall sind aber die User Disk's gar nicht vorhanden, da sie nie angelegt werden. Aber ich such weiter.
und die Suche war aktuell erfolgreich, ich beobachte nun weiter, ob es stabil bleibt, dann gebe ich dazu nochmal ein Bericht ab, aber für alle, die an der Lösung interessiert sind, hier nochmal die kurze Zusammenfassung:
Problem:
vereinzelte Userprofile können die UPD (User Profil Disk) nicht mehr hochladen, Anmeldungen enden genrell in einem TEMP-Profil, die UPD wird mit BAK gekennzeichnet und auch in der Registry landet unter ProfilList der betreffende Eintrag immer mit der .bak Endung.
Neustart und Löschen von Registry sowie der UPD bringt keinen Erfolg
Lösung:
Systeme bereinigen, hierzu wie folgt vorgehen:
Am betreffenden Terminalserver (RDS Host) Registry und C:\Users bereinigen, sprich die Temp und BAK-Eintragungen löschen.
Terminalserver neustarten
Sitzungsbroker und Fileserver, der die UPD hostet, neustarten
Damit befindet sich das System erstmal in einem neutralen Zustand, nun zum entscheidenden Schritt:
Im UPD-Share liegt eine Datei mit dem Namen UVHD-Template - diese kopieren und auf die SID-Kennung des betroffenen Users abändern (vor Löschen der BAK also die Bezeichnung der alten UVHD notieren)
Die neue UVHD mit dem Recht für den Users versehen (Benutzername - Vollzugriff)
Danach Logon am Terminalserver durch den Benutzer - es wird die UVHD-Kopie des Templates hochgeladen, sprich ein neues sauberes Profil, aber in C:\Users\ steht nun die Verbindung zur UPD und nicht mehr eine BACKUP oder BAK Datei. Änderungen in dem Profil werden gespeichert und sind auch beim wiederholten Login noch da.
Ob notwendig oder nicht, einen Zwischenschritt hab ich noch gemacht, den RDS-Host aus der Sammlung entfernt und wieder eingebunden, allein für sich hat der Teilschritt aber keine Auswirkung gehabt, inwiefern er für den gesamten Lösungsvorgang überhaupt notwendig wäre, sei dahin gestellt.
Eventuell hilft es dem einen oder anderen verzweifelten Admin - eine UPD wieder zum Laufen zu bringen.
Grüße
Forseti
Problem:
vereinzelte Userprofile können die UPD (User Profil Disk) nicht mehr hochladen, Anmeldungen enden genrell in einem TEMP-Profil, die UPD wird mit BAK gekennzeichnet und auch in der Registry landet unter ProfilList der betreffende Eintrag immer mit der .bak Endung.
Neustart und Löschen von Registry sowie der UPD bringt keinen Erfolg
Lösung:
Systeme bereinigen, hierzu wie folgt vorgehen:
Am betreffenden Terminalserver (RDS Host) Registry und C:\Users bereinigen, sprich die Temp und BAK-Eintragungen löschen.
Terminalserver neustarten
Sitzungsbroker und Fileserver, der die UPD hostet, neustarten
Damit befindet sich das System erstmal in einem neutralen Zustand, nun zum entscheidenden Schritt:
Im UPD-Share liegt eine Datei mit dem Namen UVHD-Template - diese kopieren und auf die SID-Kennung des betroffenen Users abändern (vor Löschen der BAK also die Bezeichnung der alten UVHD notieren)
Die neue UVHD mit dem Recht für den Users versehen (Benutzername - Vollzugriff)
Danach Logon am Terminalserver durch den Benutzer - es wird die UVHD-Kopie des Templates hochgeladen, sprich ein neues sauberes Profil, aber in C:\Users\ steht nun die Verbindung zur UPD und nicht mehr eine BACKUP oder BAK Datei. Änderungen in dem Profil werden gespeichert und sind auch beim wiederholten Login noch da.
Ob notwendig oder nicht, einen Zwischenschritt hab ich noch gemacht, den RDS-Host aus der Sammlung entfernt und wieder eingebunden, allein für sich hat der Teilschritt aber keine Auswirkung gehabt, inwiefern er für den gesamten Lösungsvorgang überhaupt notwendig wäre, sei dahin gestellt.
Eventuell hilft es dem einen oder anderen verzweifelten Admin - eine UPD wieder zum Laufen zu bringen.
Grüße
Forseti
Nachtrag:
Ein Phänomen was noch Auftritt, sich aber leicht beheben lässt, besteht darin, das sich der User anmeldet und er erhält auf dem Terminalserver lediglich eine TEMP-Anmeldung. Das UPD-Share zeigt nur ganz reguläre Dateien, keine endet mit BAK, jedoch wird auf dem Terminal in der Registry ein .bak Eintrag erstellt.
Lösung:
Auf den Fileserver aufschalten, der das UPD-Share erzeugt. Dort in den Explorer gehen, am Ende werden einige Userdisks gemountet sein. Die Disk vom betroffenen User auswerfen. Den Registry Eintrag wieder entfernen und User anmelden lassen, danach läuft das Profil wieder sauber hoch.
Ein Phänomen was noch Auftritt, sich aber leicht beheben lässt, besteht darin, das sich der User anmeldet und er erhält auf dem Terminalserver lediglich eine TEMP-Anmeldung. Das UPD-Share zeigt nur ganz reguläre Dateien, keine endet mit BAK, jedoch wird auf dem Terminal in der Registry ein .bak Eintrag erstellt.
Lösung:
Auf den Fileserver aufschalten, der das UPD-Share erzeugt. Dort in den Explorer gehen, am Ende werden einige Userdisks gemountet sein. Die Disk vom betroffenen User auswerfen. Den Registry Eintrag wieder entfernen und User anmelden lassen, danach läuft das Profil wieder sauber hoch.
