Jump to content

2012 R2 - RDS Farm User Profile Disk


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo Leute,

 

habe bei einen Kunden eine neue Domain mit einer 2012 R2 RDS Farm installiert (3 RDS Server, 1 CB, alles virtuell unter ESXi 5.5).

Problem ist das SPORADISCH die Benutzerprofile nicht geladen werden können und die Benutzer mit einen temporären Profil angemeldet werden.

 

Die Profile sind auf einen Fileserver umgeleitet und zwar über die Sessioneinstellung unter User Profile Disk (es werden alle Ordner dorthin umgeleitet).

Was ich denke was ich ausschließen kann:

 

- Virenschutz 100% (ich hatte die Farm und die Server aufgrund eines Programmes einmal komplett neu installiert, da trat das Problem auch auf als auf noch keinen Server Virenschutz installiert war)

- Ordnerberechtigungen - Die Ordnerberechtigungen kann ich denke ich auch ausschließen, denn wenn es ein Berechtigungsproblem auf das Share wäre wo die UPDs liegen, dann würde es meiner Meinung nach gar nicht gehen. Es geht ja aber von 10 Anmeldeversuchen ca. 4 mal (ganz genau kann man das nicht sagen, es varriert, manchmal klappt die Anmeldung 2 mal hintereinander, manchmal 2mal hintereinander nicht)

 

Ich habe schon gegoogelt und dieses Problem auch schon oft gelesen in Zusammenhang mit 2012 R2, leider jedoch nie eine Antwort gefunden.

 

Was ich aber festgestellt habe:

Wenn ich mich mit der ESXi Console "lokal" Anmelde als Admin, dann den Server darüber Neustarte ist die nächste Anmeldung (egal ob auf dem Server oder einen anderen) 100% nicht möglich (also mit Temp-Profil). Wenn ich mich aber ABMELDE und den Server neustarte (via ESXI Client), dann ist die Anmeldung danach 100% wieder möglich.

 

Und genauso scheint es auch bei den RDP Session´s zu sein, ich VERMUTE das AB UND ZU beim Abmelden irgendwas nicht korrekt durchgeführt wird, sodass das Profil wie noch "in Verwendung" ist (die User sind aber abgemeldet, zumindest auf dem Connection Broker nicht mehr zu sehen), und somit eine Anmeldung dann fehlschlägt.

 

Hat noch irgendwer Ideen? Es ist echt Mist sich teilweise 3* mal Anmelden zu müssen :-(

Link zu diesem Kommentar

Die Profile sind auf einen Fileserver umgeleitet und zwar über die Sessioneinstellung unter User Profile Disk (es werden alle Ordner dorthin umgeleitet).

Was ich denke was ich ausschließen kann:

Moin,

 

Du beschreibst hier den gleichzeitigen Einsatz konkurierender Technologien. UPD und folder redirection / roaming profiles. Beides dient der user state virtualization, sollte aber klar abgegrenzt werden.

Ich habe bisher noch nicht versucht die Verfahren zu mischen, da die UPD im Prinzip die beiden anderen Mechanismen ersetzen kann.

 

Die UPD wird im Sicherheitskontext des Computerkontos als Volume im Pfad des jeweiligen Benutzerprofils bereitgestellt (%USERPROFILE%).

Die UPD kann nur von einem Computer zur Zeit verwendet werden. Versucht ein anderer RDS Host die gleiche VHDX zu öffnen, schlägt der Versuch fehl, der Pfad %USERPROFILE% kann nicht geöffnet werden und der Benutzer bekommt ein temporäres Profil.

Problematisch kann es werden, wenn die Hosts in einer Sammlung verschiedene Applikationen bereitstellen. Dann macht der User ggf. mehrere Session innerhalb ein und der selben Sammlung auf und die UPD ist durch die erste Session blockiert; gleiches passiert auch, wenn sich mehrere Sammlungen die selbe UPD teilen wollen.

 

Du könntest einmal prüfen,

  • ob sichergestellt ist, dass jeder User nur eine einzige Session je UPD öffnen kann
  • ob die verwendeten Applikationen mit UPD umgehen können (es soll tatsächlich noch Programme geben, die den Profilpfad nicht abstrahieren können)
  • ob alle RDS Sessions der User nach der Abmeldung sauber geschlossen wurden, eventuell stehen die Sessions noch auf disconnected und die UPD ist noch durch den Host in Gebrauch
  • ob der RDS Host die UPD nach der Abmeldung wieder freigegeben hat (geöffnete Dateien auf dem Fileserver)
  • ob es es lokale File Locks auf dem FS gibt (z.bsp mit ProcessExplorer oder handle http://technet.microsoft.com/de-de/sysinternals/bb896655.aspx )

http://blogs.msdn.com/b/rds/archive/2012/11/13/easier-user-data-management-with-user-profile-disks-in-windows-server-2012.aspx

 

PS: Ich habe auch Empfehlungen gelesen, nach denen UPD auf einem Scale Out File Server abgelegt werden sollten. Damit soll die permanemte Verfügbarkeit der UPD sichergestellt werden. Ein einfacher File Cluster oder klassischer File Server ist nicht für permanent geöffnete Applikationsdaten ausgelegt.

Leider finde ich gerade den Referenzlink nicht.

Link zu diesem Kommentar

ich glaube du hast mich falsch verstanden bzw. ich mich falsch ausgedrückt. Es werden nicht 2 Verfahrten angewendet, sondern wirklich nur UPD.

Zu deinen Punkten:

 - zu 3: habe ich ja in meinen 1. Post schon geschrieben, laut Anzeige sind die Benutzer sauber abgemeldet, nicht disconnetet

- zu 1: das ist sichergestellt

- zu 2: ich bin mir nicht sicher was  das jetzt mit den installierten Applikationen zu tun haben soll. Es sind 3 100% identisch installierte Server in einer Farm, bis auf Office und eine Hotel Anwendung ist kein Programm weiter installiert. Es gibt auch nur eine Sammlung in den Remotedesktop Diensten

- 4 und 4 muss ich mal prüfen



PS: In den Eventlogs steht folgender Eintrag wenn ein Login fehlschlägt:

 

 

Sie konnten nicht angemeldet werden, da das lokal gespeicherte Profil nicht geladen werden konnte. Überprüfen Sie, ob eine Netzwerkverbindung besteht und das Netzwerk ordnungsgemäß funktioniert.

Details - unbekannter Fehler

Eventid: 1500



PSS: Noch eine Erkenntnis, ich habe gestern Nacht alle RDS Server neugestartet, da ich noch Office aktiviert habe und noch ein Windows Update installiert habe. Heute konnte sich ein User wieder die ganze Zeit nicht einloggen, Mittags gings dann irgendwann. Das heißt keiner der 3 RDS Server konnte die UPD in Vernwedung haben da seit den Neustart sich der betroffene User noch nicht angemeldet hatte. Ist mir irgendwie völlig unklar



PSSS: Habe grade mal einen Benutzer abgemeldet auf dem RDS, auf dem Fileserver wird unter Freigegebene Ordner > geöffnete Dateien die VHDX ordentlich "getrennt", das heißt  nach dem Abmelden ist die Datei nicht mehr in "Benutzung". Einmal hat es danach funktioniert das Anmelden, dann wieder abmelden, VHDX Datei wieder korrekt "getrennt" auf dem Fileserver und trotzdem war danach wieder kein Login möglich.

 

Das heißt dein 4 Punkt ist io, die Datei wird wieder "freigegeben" aber es ist trotzdem teilweise kein Anmelden möglich



Möchte noch etwas kurz schreiben, und zwar die Applikationen auf den RDS Servern kann ich auch zu 100% ausschließen, da dieser Fehler sogar direkt nach der Instalaltion der Server der Fehler auftrat und auch eine Neuinstallation der Server (RDS Server) auch nichts gebracht hat.

Link zu diesem Kommentar

Die Punkte waren nur ein grober Abriss mir bekannter möglicher Fehlerquellen bei der UPD. Ich kenne Deine Umgebung nicht ;)

 

Der Fehler 1500 sagt aus, dass der Pfad zum Profil nicht verfügbar ist. Ergo die UPD kann offensichtlich nicht eingebunden oder ordentlich bereitgestellt werden.

Hast Du mal geprüft, ob der Datenträger auf dem Server zu diesem Zeitpunkt präsent ist? Dass könnte helfen festzustellen in welcher Phase des Vorgangs das Problem zu suchen ist. Zugriff des RDS auf die UPD, Bereistellen der UPD im Pfad oder Zugriff des Benutzers auf Daten innerhalb seiner UPD

 

Wie sieht es auf Netzwerkebene aus? Hat das Netz genug 'Dampf' um alle UPD aller Sessions unterbrechungsfrei bereitzustellen?

Gibt es am Switch Auffälligkeiten? Kollisionen? Läuft noch anderer intensiver Verkehr - z.Bsp. iSCSI etc. - über das Netz?

Eventuell kann hier ein zusätzliches VLAN mit QoS oder ggf. dedizierte Netzwerkhardware Abhilfe schaffen.

Link zu diesem Kommentar

Danke erstmal das du dich so intensiv mit befasst :-)

Zum Thema Netzwerk: Also Switch und Netzwerktraffic und Co kann ich 100% ausschließen weil dieser Fehler ja auch auftrat als der Server noch in Vorbereitung war und der ESXi Host komplett "für sich lief" und gar nicht am Netzwerk angeschlossen war. (Zum Verständniss es ist ein ESXi Host, ziemlich performant, mit folgenden virtualisierten Maschinen: DC, File, Connection 'Broker, 3* TS.

 

Und das Problem trat ja schon Server"intern" auf, sodass ich das Netzwerk ausschließen kann. (zumindest das physikalische, aber an so einen ESXi Host Switch kann man ja grundlegend nicht soviel einstellen was das Problem verursachen könnte).

 

iSCSI gibt es für Backup atürlich auch, ist aber bereits in einen seperaten VLAN, außerdem war es bei der  Server-Vorbereitung auch noch nicht eingerichtet, wo die Probleme ja aber wie oben geschrieben auch schon auftraten.

 

Was genau meinst du mit Prüfen ob der Datenträger auf dem Server zu diesen Zeitpunkt aktiv ist?

Link zu diesem Kommentar

Ich meine, den Vorgang der UPD Bereitstellung Schritt für Schritt prüfen. Wenn der Fehler nicht direkt zu identifizieren ist, hilft oftmals nur das Ausschlussverfahren.

Das Fehlerbild 'Mal geht es - mal geht es nicht' zusammen mit dem Fehler 1500 ist nicht wirklich eindeutig.

Die Ursache könnte auch ganz woanders liegen, z.Bsp. beim Renew des Sitzungstoken vom RDS Host was dann als Symptom den Zugriff von RDS auf FS verhindert

 

Wenn der Fehler auftritt bspw. mit der Datenträgerverwaltung, 'Get-Volume' und/oder 'mountvol /L' abfragen, ob die UPD des Benutzer im Betriebssystem der RDS vorhanden, online und im richtigen Pfad ist.

Ist die UPD nicht vorhanden, kann der Fehler beim Zugriff des RDS auf die UPD liegen - dann wäre der Fehler zwischen RDS und FS zu suchen.

Ist die UPD bereigestellt, im richtigen Pfad online und der User kann trotzdem nicht auf sein Profil zugreigen, liegt das Problem vermutlich innerhalb des RDS, der RDS Konfiguration, des Benutzerprofils usw. Dann könnte nam ggf. RDS Host und Benutzer mal in eine neue OU ohne GPO schieben usw.

Link zu diesem Kommentar
  • 11 Monate später...

Hallo,

wenn auch spät, ich steckte in einer ähnlichen Situation. Problem ist kein Bug, sondern dass das Design von RDS ab 2012 ein anderes.

Was falsch ist: DNS-Round-Robin per Farm-Name auf die einzelnen Hosts.
Was eigentlich richtig ist: WebFeed oder RDGateway nutzen.

What the fu**? ... Ja ich weiß. Es gibt noch eine Lösung, welche es ermöglicht, per selbst erstelltem RDP-File sauber zu verbinden. Das ganze nennt sich "Connection Broker Redirection).
Man löst das DNS-RR auf und erstellt einen DNS-Eintrag mit dem Farmnamen, welcher auf den Broker zeigt.
Auf dem Broker erstellt ihr einen Registry-Eintrag:
Pfad: HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\ClusterSettings
Typ: REG_SZ
Inhalt:
 ⇒ Für Desktopsammlung: tsv://MS Terminal Services Plugin.1.Sammlungsnamme
 ⇒ Für VDI: tsv://VMResource.1.Sammlungsnamme

Ergebnis ist dann, dass der Broker immer Umleitungsserver ist und nicht einer der RDS Hosts, was zu diesen Temp Profilen führen kann.

Etwas ausführlicher hier: http://it-gotsch.com/rds2012-upd/

MfG

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...