28
FSLogix - Profile Container werden teilweise nicht geladen
Moin zusammen,
wir verzweifeln aktuell mit einer Reihe an Problemen die wir seit der Umstellung auf FSLogix haben. Zunächst einmal eine kleine Übersicht:
1 Session Broker VM (Windows Server 2019 - aktuellstes Update)
2 Sessions Hosts VM (Windows Server 2019 - aktuellstes Update)
FSLogix ist auf der aktuellsten Version 2.9.8884.27471
Ca. 30-40 gleichzeitige User
User greifen per IGEL-ThinClient auf System
Wir haben wie angesprochen mit Problemen zu kämpfen seit der Umstellung auf FSLogix, vorher RoamingProfile bzw. UPD. Die Migration so wie die Konvertierung der Profile lief ohne Vorkommnisse. Die ersten User hatten dann kleinere Probleme, das mal Disk beim ersten Laden nicht erkannt wurde. Mittlerweile sind es diese 3 Vorkommnisse:
1. User meldet sich an --> Bitte warten Sie auf "FsLogix Apps Services" lädt bis zu 5 Minuten --> Fehlermeldung Semaphore Timeout
Der Identische Fehler passiert ebenfalls wenn sich der User anmeldet wenn wir ihm seine Disk gelöscht haben, damit diese neu erstellt wird. Die Disk wird auch erstellt stockt aber bei genau 4 MB und nichts weiter passiert. Wenn wir dann die alte Disk wieder einfügen läuft es meistens.
Manchmal hilft es aber auch die bei der Anmeldung lokal erstellten Benutzerordner zu löschen und den User erneut anmelden zu lassen.
2. User meldet sich an --> Fehlermeldung "Der angeforderte Vorgang konnte nicht ausgeführt werden, da die Remotedesktopdienste derzeit ausgelastet sind. Versuchen Sie in einige Minuten noch einmal. Andere Benutzer können sich normalerweise weiterhin anmelden."
Wenn wir nun die Verbindung auf den z.b. ersten Host bzw. zweiten Host (je nachdem auf welchem der User am vor Tag gearbeitet hat) nicht zulassen, kann der User sich plötzlich wieder anmelden. Die Disk ist zum Zeitpunkt der Anmeldung nicht gemountet oder ähnliches.
3. User meldet sich an --> Lokales Benutzer Profile lädt
Auch hier wissen wir nicht warum er sich bei einigen Usern lokal lädt und bei einigen nicht. Zu dem ist nicht erkennbar warum es bei einigen Usern lädt und einigen nicht.
Wie bereits schon mit aufgeführt haben wir mittlerweile Workarounds gefunden die das Problem lösen, aber die wir täglich durchführen müssen. Teilweise sind wir mit 3 Kollegen bis zu 2 Stunden täglich am morgen dabei und User sind stark eingeschränkt in Ihrer Arbeit. Unser derzeit einziger Anhaltspunkt ist das Thema "Folder Redirection". Wir leiten dort Desktop, Dokumente, Downloads und Bilder um über eine Gruppenrichtlinie. Ich habe bereits einiges dazu Online gelesen, hat jemand dort eventuell eine Idee oder Ahnung zu diesem Thema? Uns ist aufgefallen das User teilweise unter den Freigegebenen Ordnern noch in den Verzeichnissen ist, obwohl sie nicht angemeldet sind.
Generell zum Abschluss noch mal eine kleine Übersicht was derzeit Konfiguriert ist über die GPO´s. Wir vermuten dort irgendeine widersprüchliche Richtlinie die uns in die quere kommt bei unserem System. Ich bin dankbar für jede Hilfe und hoffe jemand von euch kann uns bei diesem Problem helfen!
Viele Grüße
Darius
wir verzweifeln aktuell mit einer Reihe an Problemen die wir seit der Umstellung auf FSLogix haben. Zunächst einmal eine kleine Übersicht:
1 Session Broker VM (Windows Server 2019 - aktuellstes Update)
2 Sessions Hosts VM (Windows Server 2019 - aktuellstes Update)
FSLogix ist auf der aktuellsten Version 2.9.8884.27471
Ca. 30-40 gleichzeitige User
User greifen per IGEL-ThinClient auf System
Wir haben wie angesprochen mit Problemen zu kämpfen seit der Umstellung auf FSLogix, vorher RoamingProfile bzw. UPD. Die Migration so wie die Konvertierung der Profile lief ohne Vorkommnisse. Die ersten User hatten dann kleinere Probleme, das mal Disk beim ersten Laden nicht erkannt wurde. Mittlerweile sind es diese 3 Vorkommnisse:
1. User meldet sich an --> Bitte warten Sie auf "FsLogix Apps Services" lädt bis zu 5 Minuten --> Fehlermeldung Semaphore Timeout
Der Identische Fehler passiert ebenfalls wenn sich der User anmeldet wenn wir ihm seine Disk gelöscht haben, damit diese neu erstellt wird. Die Disk wird auch erstellt stockt aber bei genau 4 MB und nichts weiter passiert. Wenn wir dann die alte Disk wieder einfügen läuft es meistens.
Manchmal hilft es aber auch die bei der Anmeldung lokal erstellten Benutzerordner zu löschen und den User erneut anmelden zu lassen.
2. User meldet sich an --> Fehlermeldung "Der angeforderte Vorgang konnte nicht ausgeführt werden, da die Remotedesktopdienste derzeit ausgelastet sind. Versuchen Sie in einige Minuten noch einmal. Andere Benutzer können sich normalerweise weiterhin anmelden."
Wenn wir nun die Verbindung auf den z.b. ersten Host bzw. zweiten Host (je nachdem auf welchem der User am vor Tag gearbeitet hat) nicht zulassen, kann der User sich plötzlich wieder anmelden. Die Disk ist zum Zeitpunkt der Anmeldung nicht gemountet oder ähnliches.
3. User meldet sich an --> Lokales Benutzer Profile lädt
Auch hier wissen wir nicht warum er sich bei einigen Usern lokal lädt und bei einigen nicht. Zu dem ist nicht erkennbar warum es bei einigen Usern lädt und einigen nicht.
Wie bereits schon mit aufgeführt haben wir mittlerweile Workarounds gefunden die das Problem lösen, aber die wir täglich durchführen müssen. Teilweise sind wir mit 3 Kollegen bis zu 2 Stunden täglich am morgen dabei und User sind stark eingeschränkt in Ihrer Arbeit. Unser derzeit einziger Anhaltspunkt ist das Thema "Folder Redirection". Wir leiten dort Desktop, Dokumente, Downloads und Bilder um über eine Gruppenrichtlinie. Ich habe bereits einiges dazu Online gelesen, hat jemand dort eventuell eine Idee oder Ahnung zu diesem Thema? Uns ist aufgefallen das User teilweise unter den Freigegebenen Ordnern noch in den Verzeichnissen ist, obwohl sie nicht angemeldet sind.
Generell zum Abschluss noch mal eine kleine Übersicht was derzeit Konfiguriert ist über die GPO´s. Wir vermuten dort irgendeine widersprüchliche Richtlinie die uns in die quere kommt bei unserem System. Ich bin dankbar für jede Hilfe und hoffe jemand von euch kann uns bei diesem Problem helfen!
Viele Grüße
Darius
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: 668336
Url: https://administrator.de/contentid/668336
Ausgedruckt am: 24.11.2024 um 21:11 Uhr
28 Kommentare
Neuester Kommentar
Also vorab: Eine konkrete Idee habe ich nicht.
Zu Fehler 2:
Das Verhalten kenne ich, habe ich leider nie eine Lösung für gefunden. Das tritt hier auch selten auf, meist im laufe des Vormittags. Warten funktioniert, sperre des RD-SH für die Anmeldung auch, Neustart natürlich auch. Das ganze hat aber nach meinem Verständnis nichts oder nicht direkt etwas mit FSLogix zu tun. Wir hatten das unter Server 2019 und unter 2012 R2.
zu redirected folders:
Die haben wir auch in Kombination mit FSLogix im Einsatz, das ist auch gar kein Problem bei uns und würde ich jedem empfehlen. Wenn sich der Speicherort eines redirected folders ändert, gibt es allerdings einiges zu beachten, die Dateien verschieben sich dabei nicht. Auch die GPO kann dafür verschiedene Vorgaben machen.
Zum Verständnis:
- Das gpresult ist vom Administrator?
- gpupdate läuft sauber durch?
- Machine-GPO?
Die VHD-Location beinhaltet bei uns keine! %USERNAME%-Variable. FSLogix legt von sich aus einen Unterordner an. Die NTFS-Rechte auf den VHD-Store sollten i.d.R. genauso gesetzt werden, wie bei Profilordnern. Wenn FSLogix dann Unterordner und Container anlegt, müssten der Benutzer der Datei-Besitzer sein und natürlich auch entsprechend Rechte bekommen.
- Liegt der VHD-Store auf einem DFS-Pfad oder einem einzelnen Server-Share?
Wenn NTFS-Rechte sauber gesetzt werden und gpupdate, DNS und ggf. DFS sauber arbeiten, wie genau ist der RD-SH mit dem VHD-Server vernetzt? Läuft irgendwas über WAN oder Firewall?
Zu Fehler 2:
Das Verhalten kenne ich, habe ich leider nie eine Lösung für gefunden. Das tritt hier auch selten auf, meist im laufe des Vormittags. Warten funktioniert, sperre des RD-SH für die Anmeldung auch, Neustart natürlich auch. Das ganze hat aber nach meinem Verständnis nichts oder nicht direkt etwas mit FSLogix zu tun. Wir hatten das unter Server 2019 und unter 2012 R2.
zu redirected folders:
Die haben wir auch in Kombination mit FSLogix im Einsatz, das ist auch gar kein Problem bei uns und würde ich jedem empfehlen. Wenn sich der Speicherort eines redirected folders ändert, gibt es allerdings einiges zu beachten, die Dateien verschieben sich dabei nicht. Auch die GPO kann dafür verschiedene Vorgaben machen.
Zum Verständnis:
- Das gpresult ist vom Administrator?
- gpupdate läuft sauber durch?
- Machine-GPO?
Die VHD-Location beinhaltet bei uns keine! %USERNAME%-Variable. FSLogix legt von sich aus einen Unterordner an. Die NTFS-Rechte auf den VHD-Store sollten i.d.R. genauso gesetzt werden, wie bei Profilordnern. Wenn FSLogix dann Unterordner und Container anlegt, müssten der Benutzer der Datei-Besitzer sein und natürlich auch entsprechend Rechte bekommen.
- Liegt der VHD-Store auf einem DFS-Pfad oder einem einzelnen Server-Share?
Wenn NTFS-Rechte sauber gesetzt werden und gpupdate, DNS und ggf. DFS sauber arbeiten, wie genau ist der RD-SH mit dem VHD-Server vernetzt? Läuft irgendwas über WAN oder Firewall?
Danke erstmal für deine Antwort und Hilfe.
Wir haben hier keine Daten verschoben oder sonstiges. Diese sind am gleichen Ort. Aber dann werden wir die Redirection erstmal so lassen und weiter schauen.
Tatsächlich ist das die direkte Auswertung aus dem GPO-Editor. Soweit wie wir das ganze auch in Anleitungen verstanden haben, werden die Richtlinien als Computerrichtlinien festgelegt und dem Server zugewiesen richtig?
GPUpdate und co. laufen problemlos durch mit egal welchem User.
NTFS, DNS und GPUpdate laufen sauber, richtig. Die Server liegen direkt bei uns und kommunizieren ohne Firewall-Settings.
zu redirected folders:
Die haben wir auch in Kombination mit FSLogix im Einsatz, das ist auch gar kein Problem bei uns und würde ich jedem empfehlen. Wenn sich der Speicherort eines redirected folders ändert, gibt es allerdings einiges zu beachten, die Dateien verschieben sich dabei nicht. Auch die GPO kann dafür verschiedene Vorgaben machen.
Die haben wir auch in Kombination mit FSLogix im Einsatz, das ist auch gar kein Problem bei uns und würde ich jedem empfehlen. Wenn sich der Speicherort eines redirected folders ändert, gibt es allerdings einiges zu beachten, die Dateien verschieben sich dabei nicht. Auch die GPO kann dafür verschiedene Vorgaben machen.
Wir haben hier keine Daten verschoben oder sonstiges. Diese sind am gleichen Ort. Aber dann werden wir die Redirection erstmal so lassen und weiter schauen.
Zum Verständnis:
- Das gpresult ist vom Administrator?
- gpupdate läuft sauber durch?
- Machine-GPO?
- Das gpresult ist vom Administrator?
- gpupdate läuft sauber durch?
- Machine-GPO?
Tatsächlich ist das die direkte Auswertung aus dem GPO-Editor. Soweit wie wir das ganze auch in Anleitungen verstanden haben, werden die Richtlinien als Computerrichtlinien festgelegt und dem Server zugewiesen richtig?
GPUpdate und co. laufen problemlos durch mit egal welchem User.
Wenn NTFS-Rechte sauber gesetzt werden und gpupdate, DNS und ggf. DFS sauber arbeiten, wie genau ist der RD-SH mit dem VHD-Server vernetzt? Läuft irgendwas über WAN oder Firewall?
NTFS, DNS und GPUpdate laufen sauber, richtig. Die Server liegen direkt bei uns und kommunizieren ohne Firewall-Settings.
Die VHD-Location beinhaltet bei uns keine! %USERNAME%-Variable. FSLogix legt von sich aus einen Unterordner an.
Wie genau habt ihr das gesetzt? Mir ist gerade aufgefallen das beim Laden der Profile im FSLogix Profile Status Tool die folgende Meldung angezeigt wird:
10:18:45.254][tid:00011670.0001b638][ERROR:0000065e] Cannot read registry key: SOFTWARE\FSLogix\Profiles\VHDLocations (Daten mit diesem Typ werden nicht unterstützt.)Eventuell gibt es doch einen zusammenhang mit %username%...
Ich glaube auch das die Variable eventuell das Problem ist. Wir haben einfach nur den Pfad auf den Überordner gesetzt und auf diesem die NTFS-Rechte nach best practice gesetzt. Das hier sieht ganz gut aus:
https://learn.microsoft.com/en-us/fslogix/how-to-configure-storage-permi ...
Eventuell solltet ihr einen neuen Pfad anlegen, um nicht mit alten Benutzerordnern in Konflikt zu geraten. Und dann gpupdate an einem RD-SH und einen User testweise neu anmelden. Ihr scheint ja sowieso diverse Male schon neue Container erzeugt zu haben, dürfte dann erstmal nicht so schlimm sein.
https://learn.microsoft.com/en-us/fslogix/how-to-configure-storage-permi ...
Eventuell solltet ihr einen neuen Pfad anlegen, um nicht mit alten Benutzerordnern in Konflikt zu geraten. Und dann gpupdate an einem RD-SH und einen User testweise neu anmelden. Ihr scheint ja sowieso diverse Male schon neue Container erzeugt zu haben, dürfte dann erstmal nicht so schlimm sein.
Zitat von @TerraIT:
Tatsächlich ist das die direkte Auswertung aus dem GPO-Editor. Soweit wie wir das ganze auch in Anleitungen verstanden haben, werden die Richtlinien als Computerrichtlinien festgelegt und dem Server zugewiesen richtig?
Richtig. Eventuell mit gpresult testen aber das scheint ja grundsätzlich zu laufen.Tatsächlich ist das die direkte Auswertung aus dem GPO-Editor. Soweit wie wir das ganze auch in Anleitungen verstanden haben, werden die Richtlinien als Computerrichtlinien festgelegt und dem Server zugewiesen richtig?
Es gibt noch die lokalen Rechte-Gruppen von FSLogix. Da haben wir eine AD-Gruppe auf die white list gesetzt, das funktioniert auch. Habt ihr das mit einer AD-Gruppe oder mit AD-Benutzern gemacht?
Erstmal vielen Dank für deine weitere Hilfe.
Wir sind dabei uns jetzt durch den Artikel zuarbeiten und werden die jeweiligen Anpassungen vornehmen, sobald wir was finden was abweicht. Wir waren schon oft auf dem Artikel aber haben keine weitere Relevanz dem geschenkt.
Beim setzten es Überordners habe ich noch einmal eine genau Frage. Der Pfad an sich wird ja über die GPO gesteuert. Mein Kollege hat gestern in seiner Verzweiflung nach möglichen Ansätzen gesucht und zusätzlich auf dem Host eine Einstellung gesetzt in der Registry wie auf dem Bild zusehen. Sollten wir beide Löschen und neuladen lassen oder die VHD-Locations stehen lassen als Zusatz? Den Zusatz mit %username% werden wir dann streichen und heute Abend testen.
Auch das Thema besprechen und planen wir mal für später.
Gerade mal geprüft. Wir haben unter FSLogix Include List einfach Jeder stehen, was ja reichen sollten. Ich könnte wahlweise auch die Nutzergruppe die wir dafür verwenden auch hinzufügen.
Ich glaube auch das die Variable eventuell das Problem ist. Wir haben einfach nur den Pfad auf den Überordner gesetzt und auf diesem die NTFS-Rechte nach best practice gesetzt. Das hier sieht ganz gut aus:
https://learn.microsoft.com/en-us/fslogix/how-to-configure-storage-permi ...
https://learn.microsoft.com/en-us/fslogix/how-to-configure-storage-permi ...
Wir sind dabei uns jetzt durch den Artikel zuarbeiten und werden die jeweiligen Anpassungen vornehmen, sobald wir was finden was abweicht. Wir waren schon oft auf dem Artikel aber haben keine weitere Relevanz dem geschenkt.
Beim setzten es Überordners habe ich noch einmal eine genau Frage. Der Pfad an sich wird ja über die GPO gesteuert. Mein Kollege hat gestern in seiner Verzweiflung nach möglichen Ansätzen gesucht und zusätzlich auf dem Host eine Einstellung gesetzt in der Registry wie auf dem Bild zusehen. Sollten wir beide Löschen und neuladen lassen oder die VHD-Locations stehen lassen als Zusatz? Den Zusatz mit %username% werden wir dann streichen und heute Abend testen.
Eventuell solltet ihr einen neuen Pfad anlegen, um nicht mit alten Benutzerordnern in Konflikt zu geraten. Und dann gpupdate an einem RD-SH und einen User testweise neu anmelden. Ihr scheint ja sowieso diverse Male schon neue Container erzeugt zu haben, dürfte dann erstmal nicht so schlimm sein.
Auch das Thema besprechen und planen wir mal für später.
Es gibt noch die lokalen Rechte-Gruppen von FSLogix. Da haben wir eine AD-Gruppe auf die white list gesetzt, das funktioniert auch. Habt ihr das mit einer AD-Gruppe oder mit AD-Benutzern gemacht?
Gerade mal geprüft. Wir haben unter FSLogix Include List einfach Jeder stehen, was ja reichen sollten. Ich könnte wahlweise auch die Nutzergruppe die wir dafür verwenden auch hinzufügen.
Gerade mal geprüft. Wir haben unter FSLogix Include List einfach Jeder stehen, was ja reichen sollten.
Hmm ich weiß nicht, ob der Administrator dann dort gefiltert wird. Der soll ja vermutlich keine Profile Disk haben (und ich meine, davon wird auch abgeraten). Zumindest kannst du keinen User mit Profile Disk an mehr als einem Host gleichzeitig anmelden, z.B. einen Domain-Admin.
Die Einstellung ProfileDirectory habe ich bei mir nicht gesetzt, die würde ich auf jeden Fall erstmal wieder raus nehmen. Eigentlich sollte nur die GPO "VHDLocations" liefern, ich denke, das sollte reichen.
Perfekt, dann werden wir diese Änderungen auch noch mal vornehmen. Komischerweise werden für einige Nutzer auch gerade Lokale Profile erstellt. Diese Laden natürlich Problemlos und extrem schnell. Wir sind beinahe am überlegen diese zu nutzen, da es uns immerhin kein Problem ist.
Was für uns immer noch ein Problem ist, ist die Zugehörigkeit. Die User sind quasi auf einen Server fixiert und können nur auf einem Server angemeldet sein. Sobald jemand auf Server 1 statt auf Server 2 wegen dem Loadbalancer geleitet wird, funktioniert nichts und der User muss explizit dort hin wo er auch vorher war. Habt ihr auch einen im Einsatz und wenn ja gibt es dort spezielle Konfigurationen zu dem Thema?
Was für uns immer noch ein Problem ist, ist die Zugehörigkeit. Die User sind quasi auf einen Server fixiert und können nur auf einem Server angemeldet sein. Sobald jemand auf Server 1 statt auf Server 2 wegen dem Loadbalancer geleitet wird, funktioniert nichts und der User muss explizit dort hin wo er auch vorher war. Habt ihr auch einen im Einsatz und wenn ja gibt es dort spezielle Konfigurationen zu dem Thema?
Die lokalen Profile werden bei Abmeldung gelöscht. Das wird vermutlich nicht besonders toll werden wenn sich der User jeden Morgen erstmal Edge konfigurieren oder Teams installieren muss oder dergleichen. Kann man machen aber irgendwie bin ich da skeptisch.
Wenn du die Profile im Netz liegen hast, und das funktioniert wie gedacht, dann ist ein Serverwechsel doch kein Problem? Ich meine, genau dafür nutzen wir es. Natürlich müssen alle Server die selbe FSLogix Version haben und den selben Profilpfad.
Wenn du die Profile im Netz liegen hast, und das funktioniert wie gedacht, dann ist ein Serverwechsel doch kein Problem? Ich meine, genau dafür nutzen wir es. Natürlich müssen alle Server die selbe FSLogix Version haben und den selben Profilpfad.
Die lokalen Profile werden bei Abmeldung gelöscht. Das wird vermutlich nicht besonders toll werden wenn sich der User jeden Morgen erstmal Edge konfigurieren oder Teams installieren muss oder dergleichen. Kann man machen aber irgendwie bin ich da skeptisch.
Das soll definitiv auch nicht das Ziel sein, aber die Verzweiflung treibt einen ja leider mit sich. Automatisch gelöscht werden sie tatsächlich nicht, obwohl es konfiguriert ist.
Wenn du die Profile im Netz liegen hast, und das funktioniert wie gedacht, dann ist ein Serverwechsel doch kein Problem? Ich meine, genau dafür nutzen wir es. Natürlich müssen alle Server die selbe FSLogix Version haben und den selben Profilpfad.
Genau das wundert uns ja so sehr. Die Profile liegen auf unserem Fileserver und jeder User hat Zugang zu seiner Disk.
Mir fällt nebenbei aber gerade auf das wir die Richlinie "Profile Type" in den GPO´s auf "Nicht konfiguriert" haben. Könnte daher ebenfalls ein Fehler ruhen? ich schau sonst gleich nochmal ob irgendwas in den Logs steht was dabei helfen kann das Problem zu analysieren.
Wenn der User am RD-SH aktiv angemeldet ist sieht man unter erweiterte Systemeinstellungen in der Profilliste das gemountete Profil. Dort muss als Typ local gesetzt werden, nicht roaming. Bei roaming würde dann ggf. ein roaming profile mit dem Inhalt der Profile Disk synchronisiert. Das macht bei der ersten Anmeldung am RD-SH Sinn, um den Inhalt eines aktiven roaming profiles zu übernehmen. Im Anschluss muss das aber auf local gesetzt werden und auf local bleiben, auch bei einer neuen Anmeldung.
PS: Wenn du das auf ein temporäres Profil setzt, müsste es wieder verworfen werden.
Wenn du roaming weiter aktiv hast, dann brauchen die Sitzungen auch länger für das An- und Abmelden bzw. bleiben da ggf. hängen - weil ist halt roaming.
PS: Wenn du das auf ein temporäres Profil setzt, müsste es wieder verworfen werden.
Wenn du roaming weiter aktiv hast, dann brauchen die Sitzungen auch länger für das An- und Abmelden bzw. bleiben da ggf. hängen - weil ist halt roaming.
Wenn der User am RD-SH aktiv angemeldet ist sieht man unter erweiterte Systemeinstellungen in der Profilliste das gemountete Profil. Dort muss als Typ local gesetzt werden, nicht roaming. Bei roaming würde dann ggf. ein roaming profile mit dem Inhalt der Profile Disk synchronisiert. Das macht bei der ersten Anmeldung am RD-SH Sinn, um den Inhalt eines aktiven roaming profiles zu übernehmen. Im Anschluss muss das aber auf local gesetzt werden und auf local bleiben, auch bei einer neuen Anmeldung.
Ich muss sagen, dass ich leider nicht genau verstanden habe, wo wir das ganze finden sollen. Hättest du da nochmal eine genauere Erklärung wo?
Nach weiteren Tests habe ich eine sehr interessante Entdeckung bei meinem Profil bzw. der Disk gemacht. Das Profil lädt extrem schnell beim ersten mal rein ohne Probleme mit allen Daten. Wenn ich mich nun abmelde und wieder anmelde laufe ich auf den ganz oben genannten ersten Fehler. Wenn dieser Anmeldeversuch dann final gescheitert ist, kann ich den Fehlerhaften Ordner löschen und mich dann wieder ganz normal und ohne Probleme am Server anmelden. Ich kann derzeit nicht rekonstruieren woran es hier genau liegt....
Noch etwas ganz interessantes was wir gerade gefunden haben. Bei der Anmeldung versucht er wohl das Profile zwei mal zu laden. Einmal als lesen+schreiben und einmal nur als lesen. Wieso er das doppelt probiert kann ich derzeit nicht finden.
Nutzt Du CloudCache oder das "klassische Einbinden"?
Ich habe sehr gute Erfahrungen mit Cloud-Cache und SMB-Shares.
Ich habe sehr gute Erfahrungen mit Cloud-Cache und SMB-Shares.
Das haben wir jetzt mal geprüft - stand total auf dem schlauch was du gemeint hast. Alle Profile stehen hier auf Lokal und nicht auf Roaming. Dort sollte es also nichts mit am Hut haben.
Auch die Änderungen am Speicherort haben keine Auswirkung gehabt. Wir haben nun 1-2 User die weniger Probleme haben, aber eine Finale Lösung ist weiterhin in der Ferne. Wir suchen nahezu ohne Pause...
Auch die Änderungen am Speicherort haben keine Auswirkung gehabt. Wir haben nun 1-2 User die weniger Probleme haben, aber eine Finale Lösung ist weiterhin in der Ferne. Wir suchen nahezu ohne Pause...
Nutzt Du CloudCache oder das "klassische Einbinden"?
Ich habe sehr gute Erfahrungen mit Cloud-Cache und SMB-Shares.
Ich habe sehr gute Erfahrungen mit Cloud-Cache und SMB-Shares.
Moin,
danke für deine Nachricht. Wir nutzen derzeit nicht den Cloudcache. In wie fern kann der Cache dabei helfen die Nutzung zu verbessern?
Unser derzeitiges Hauptproblem ist weiterhin das die User an einem Server kleben und sobald diese durch den Broker auf einen anderen Server geschoben werden, läuft nix. Bei einigen Usern läuft es ja auch problemlos, bei einigen läuft nichts.
Also wenn sich der Benutzer auf dem ersten Server abmeldet, wird der Dateizugriff auf den Container gar nicht geschlossen? Eigentlich sollte er auf dem Zielserver (wo die VHDX liegt) nichts mehr geöffnet haben.
Doch, der Zugriff auf die Disks wird getrennt. Generell wird der Zugriff auf alle Daten, mit denen der User gearbeitet hat getrennt.
Heute morgen ist es z.b. ganz schlimm. Nahezu jeder User hat sich gemeldet, dass etwas nicht richtig geladen wurde. Die Lösung ist: Ausloggen --> Verbindung auf den Server nicht zulassen welchen er vorher benutzt hat --> Einloggen (Funktioniert dann super schnell ohne Probleme) --> Verbindung wieder zulassen. Das machen wir dann für jetzt knapp 1 Stunde und es läuft wieder....
Heute morgen ist es z.b. ganz schlimm. Nahezu jeder User hat sich gemeldet, dass etwas nicht richtig geladen wurde. Die Lösung ist: Ausloggen --> Verbindung auf den Server nicht zulassen welchen er vorher benutzt hat --> Einloggen (Funktioniert dann super schnell ohne Probleme) --> Verbindung wieder zulassen. Das machen wir dann für jetzt knapp 1 Stunde und es läuft wieder....
Hat das eigentlich einen Grund warum ihr die Einstellungen per Regkey ausrollt und nicht einem ADMX Template?
https://learn.microsoft.com/en-us/fslogix/how-to-use-group-policy-templa ...
Hier mal unsere Einstellungen:
Computerkonfiguration (Aktiviert)Ausblenden
Administrative VorlagenAusblenden
FSLogix/Profile ContainersAusblenden
Dynamic VHD(X) allocation Aktiviert
Profile type Aktiviert
Try for read-write profile and fallback to read-only
Size in MBs 204800
Store search database in profile container Aktiviert
Single-user search
VHD location Aktiviert
VHD location \\domain.de\Profile\profile_disks_fsl\win2019\sammlung-mitarbeiter
FSLogix/Profile Containers/AdvancedAusblenden
Keep local folder after user logs out Aktiviert
Prevent login with temporary profile Aktiviert
FSLogix/Profile Containers/Container and Directory NamingAusblenden
Swap directory name components Aktiviert
Virtual disk type Aktiviert
VHDX
Zusätzl. Reg.-einst.Ausblenden
Software\FSLogix\Profiles\ConcurrentUserSessions 1
https://learn.microsoft.com/en-us/fslogix/how-to-use-group-policy-templa ...
Hier mal unsere Einstellungen:
Computerkonfiguration (Aktiviert)Ausblenden
Administrative VorlagenAusblenden
FSLogix/Profile ContainersAusblenden
Dynamic VHD(X) allocation Aktiviert
Profile type Aktiviert
Try for read-write profile and fallback to read-only
Size in MBs 204800
Store search database in profile container Aktiviert
Single-user search
VHD location Aktiviert
VHD location \\domain.de\Profile\profile_disks_fsl\win2019\sammlung-mitarbeiter
FSLogix/Profile Containers/AdvancedAusblenden
Keep local folder after user logs out Aktiviert
Prevent login with temporary profile Aktiviert
FSLogix/Profile Containers/Container and Directory NamingAusblenden
Swap directory name components Aktiviert
Virtual disk type Aktiviert
VHDX
Zusätzl. Reg.-einst.Ausblenden
Software\FSLogix\Profiles\ConcurrentUserSessions 1
Hat das eigentlich einen Grund warum ihr die Einstellungen per Regkey ausrollt und nicht einem ADMX Template?
Wir benutzen dafür ebenfalls die GPO´s. Der Ausschnitt aus dem ersten Bild ist sogar die Konfig der GPO. Wir passen jetzt mal unsere Werte an. Der Punkt Profile Type ist nicht konfiguriert bei uns. Daher könnte natürlich auch der Fehler kommen. Wir testen und berichten. Danke!
Wir sind jetzt nochmal etwas weiter mit Forschung der Ursachen, dank deiner Tipps und so sehen die Ergebnisse aus:
Unsere User können sich anmelden und Laden auch Ihre Disk sobald sie auf den richtigen Server landen. Dieser wird durch den Brocker im Normalfall nach Auslastung entschieden. Es scheint aber so als würden manche User nur auf dem 1. Server arbeiten können und manche nur auf dem zweiten Arbeiten können. Nach dem wir das Verhältnis auf 65/35 geändert haben, meldeten sich weniger User.
Mit der frxtray.exe haben wir das Problem dann weiter untersucht. Auffällig war unter Events/Operational das auf dem ersten Server, wo auch mehr Leute rauf kommen wir für jeden User eine Meldung erhalten das die Disk richtig geladen wurde und die User normal arbeiten. Allerdings kann nicht einsehen und auch keine Logs finden von den Usern die sich nicht einloggen konnten auf dem ersten Server und ich weiß das es 2 User gab die nicht auf den ersten sondern den zweiten Server müssen.
Aus unserer Sicht gibt es hier gerade nur eine wirkliche Möglichkeit wo das Problem liegt: dem Broker. Wenn wir die User zum richtigen Server leiten klappt alles wunderbar. Die Disk und FSLogix scheinen dabei keine große Rolle zu spielen. Trotzdem bleibt für uns jetzt die Frage offen wie man fortfahren kann.
Für die beiden Server gibt es einen DNS Eintrag welcher ja vom Broker benötigt wird. Wenn wir nun also den Broker wegnehmen würden und den Usern einen festen Server geben sollte das Problem behoben sein. Die Frage ist nur, wie stellt man das nun mit dem DNS Eintrag genau an oder kann dem Broker sogar gesagt werden welche Person wo hin soll? Bin mal auf Erfahrungswerte gespannt.
Unsere User können sich anmelden und Laden auch Ihre Disk sobald sie auf den richtigen Server landen. Dieser wird durch den Brocker im Normalfall nach Auslastung entschieden. Es scheint aber so als würden manche User nur auf dem 1. Server arbeiten können und manche nur auf dem zweiten Arbeiten können. Nach dem wir das Verhältnis auf 65/35 geändert haben, meldeten sich weniger User.
Mit der frxtray.exe haben wir das Problem dann weiter untersucht. Auffällig war unter Events/Operational das auf dem ersten Server, wo auch mehr Leute rauf kommen wir für jeden User eine Meldung erhalten das die Disk richtig geladen wurde und die User normal arbeiten. Allerdings kann nicht einsehen und auch keine Logs finden von den Usern die sich nicht einloggen konnten auf dem ersten Server und ich weiß das es 2 User gab die nicht auf den ersten sondern den zweiten Server müssen.
Aus unserer Sicht gibt es hier gerade nur eine wirkliche Möglichkeit wo das Problem liegt: dem Broker. Wenn wir die User zum richtigen Server leiten klappt alles wunderbar. Die Disk und FSLogix scheinen dabei keine große Rolle zu spielen. Trotzdem bleibt für uns jetzt die Frage offen wie man fortfahren kann.
Für die beiden Server gibt es einen DNS Eintrag welcher ja vom Broker benötigt wird. Wenn wir nun also den Broker wegnehmen würden und den Usern einen festen Server geben sollte das Problem behoben sein. Die Frage ist nur, wie stellt man das nun mit dem DNS Eintrag genau an oder kann dem Broker sogar gesagt werden welche Person wo hin soll? Bin mal auf Erfahrungswerte gespannt.
Also DNS ist in einer gewöhnlichen RD-Farm auch ganz normal konfiguriert. In dem Zusammenhang verstehe ich diesen Satz nicht richtig:
Es gibt bei dir drei Server VMs:
1x RD Session Broker (+ vermutlich Lizenzserver etc.)
2x RD Session Host
Jeder hat einen DNS Eintrag - fertig.
Es gibt Szenarien mit 2x RD Session Broker, da wurde oder wird immer noch mit DNS Round Robin gearbeitet. Das ist aber bei einem einzelnen Broker nicht nötig.
Die User bauen vermeintlich eine RDP Verbindung zum Broker auf. Es wird aber eine Sammlung mit gegeben. Daher weiß der Broker, das die Verbindung nicht für ihn selbst ist (man kann ja auch als Admin auf den Broker connecten wollen). Die Anfrage für eine RDP Verbindung unterscheidet sich nur durch das Attribut Sammlung von einem normalen Verbindungsaufbau. Der Broker leitet dann die Verbindung an einen Session Host in der jeweiligen Sammlung.
Wenn du jetzt direkt an den Session Host eine Verbindungsanfrage startest fragt dieser dennoch erst den Broker. Wenn das Load Balancing (bei 50:50) auf dem Broker sagt, der angefragte Session Host hat weniger oder gleich viel zu tun, kommt die Verbindung zustande. Wenn der angefragte Session Host mehr aktive Verbindungen hat, müsste er die Anfrage ablehnen oder an einen anderen Session Host abtreten. (Ich meine ich hatte zumindest mal die Situation, das ich auf Server A verbinden wollte und bei B gelandet bin, da bin ich jetzt aber nicht ganz sicher, ob das out of the box funktioniert.)
Für die beiden Server gibt es einen DNS Eintrag welcher ja vom Broker benötigt wird.
Meinst du, einen DNS Eintrag pro Server?Es gibt bei dir drei Server VMs:
1x RD Session Broker (+ vermutlich Lizenzserver etc.)
2x RD Session Host
Jeder hat einen DNS Eintrag - fertig.
Es gibt Szenarien mit 2x RD Session Broker, da wurde oder wird immer noch mit DNS Round Robin gearbeitet. Das ist aber bei einem einzelnen Broker nicht nötig.
Die User bauen vermeintlich eine RDP Verbindung zum Broker auf. Es wird aber eine Sammlung mit gegeben. Daher weiß der Broker, das die Verbindung nicht für ihn selbst ist (man kann ja auch als Admin auf den Broker connecten wollen). Die Anfrage für eine RDP Verbindung unterscheidet sich nur durch das Attribut Sammlung von einem normalen Verbindungsaufbau. Der Broker leitet dann die Verbindung an einen Session Host in der jeweiligen Sammlung.
Wenn du jetzt direkt an den Session Host eine Verbindungsanfrage startest fragt dieser dennoch erst den Broker. Wenn das Load Balancing (bei 50:50) auf dem Broker sagt, der angefragte Session Host hat weniger oder gleich viel zu tun, kommt die Verbindung zustande. Wenn der angefragte Session Host mehr aktive Verbindungen hat, müsste er die Anfrage ablehnen oder an einen anderen Session Host abtreten. (Ich meine ich hatte zumindest mal die Situation, das ich auf Server A verbinden wollte und bei B gelandet bin, da bin ich jetzt aber nicht ganz sicher, ob das out of the box funktioniert.)
Wenn du jetzt direkt an den Session Host eine Verbindungsanfrage startest fragt dieser dennoch erst den Broker. Wenn das Load Balancing (bei 50:50) auf dem Broker sagt, der angefragte Session Host hat weniger oder gleich viel zu tun, kommt die Verbindung zustande. Wenn der angefragte Session Host mehr aktive Verbindungen hat, müsste er die Anfrage ablehnen oder an einen anderen Session Host abtreten. (Ich meine ich hatte zumindest mal die Situation, das ich auf Server A verbinden wollte und bei B gelandet bin, da bin ich jetzt aber nicht ganz sicher, ob das out of the box funktioniert.)
Das ist die Aufgabe welche der Broker eben hat richtig. Wir haben diese nun auch umgestellt und haben teilweise auch die Fehlermeldung, dass aktuell keine Verbindung aufgrund von Auslastung möglich sind. Wenn ich das jetzt aber richtig sehe anhand unserer DNS-Einträge wird die Verbindung "Falsch" aufgebaut. Die User melden sich via "WTS-Terra" an. WTSBR19 stellt dabei Broker mit Lizenzserver da und WTSFS1 und 2 sind jeweils die Hosts.
Mittlerweile habe ich das Gefühl mal alles gelernte nicht mehr richtig verknüpfen zu können da der Kopf doch etwas durch ist.
wts-terra wird aber mal mit 52 und mal mit 53 aufgeführt, da passt wohl wirklich was nicht. Ist das nur ein AD DNS oder gibt es noch weitere DNS Server? Steht vielleicht irgendwo was in einer hosts Datei? Eigentlich kann das ja nicht passieren...
Da es sowieso per VMs läuft, vielleicht ist das Beste, einen neuen Broker und 2 neue Session Hosts sauber zu installieren nach best practice, neue DNS Namen verwenden, VHDX Dateien können übernommen werden sofern man nicht in beiden Farmen gleichzeitig angemeldet sein kann.
Da es sowieso per VMs läuft, vielleicht ist das Beste, einen neuen Broker und 2 neue Session Hosts sauber zu installieren nach best practice, neue DNS Namen verwenden, VHDX Dateien können übernommen werden sofern man nicht in beiden Farmen gleichzeitig angemeldet sein kann.
Wir haben das Problem nun erfolgreich lösen können. Die Antwort heißt: Alles neu.
Anschein nach liegen die Probleme an anfänglicher falscher Konfiguration und zu vielen Änderungen die der Server nicht vertragen hat. mit zwei neuen FS-Servern läuft es jetzt problemlos und jeder User kann sich wieder auf beiden Servern anmelden.
Für die Zukunft kann ich sagen: Server aufsetzten und alle Programme installieren, eine gesamte Sicherung erstellen via Backup und dann FS-Logix installieren und konfigurieren ( am besten nach offizieller Anleitung! https://learn.microsoft.com/de-de/fslogix/overview-what-is-fslogix )
Danke für die Hilfe soweit, jetzt ist wieder alles in Ordnung.
Anschein nach liegen die Probleme an anfänglicher falscher Konfiguration und zu vielen Änderungen die der Server nicht vertragen hat. mit zwei neuen FS-Servern läuft es jetzt problemlos und jeder User kann sich wieder auf beiden Servern anmelden.
Für die Zukunft kann ich sagen: Server aufsetzten und alle Programme installieren, eine gesamte Sicherung erstellen via Backup und dann FS-Logix installieren und konfigurieren ( am besten nach offizieller Anleitung! https://learn.microsoft.com/de-de/fslogix/overview-what-is-fslogix )
Danke für die Hilfe soweit, jetzt ist wieder alles in Ordnung.
2
Bitte noch als gelöst markieren.
1
