19
FSLogix auf Terminalserver 2016
Hallo Zusammen
Wir haben folgende Probleme mit FSLogix und wissen gerade nicht mehr weiter:
1. FSLogix in der aktuellen Version unter Server 2016 RDS Server installiert und konfiguriert.
2. Einen Testbenutzer in die FSLogix Gruppe aufgenommen.
3. Die Benutzer haben alle 2 Roaming Profile: Eines für die lokalen PCs und eines für den TS (Im AD so eingetragen)
4. Der Eintrag für das Roaming Profil des Terminalservers wurde im AD so stehen gelassen, damit FSLogix nicht das Roaming Profil des PCs anzieht oder verändert.
5. Den Benutzer angemeldet. TS-Profil des Benutzers wurde erfolgreich übernommen und der FSLogix Profile Container wurde erstellt. Danach getestet, ob FSLogix auch wirklich nur Daten aus diesem Profil lädt, was anfänglich den Anschein machte.
Nun haben wir aber folgende Probleme in unregelmässigen Abständen festgestellt:
1. Der Benutzer meldet sich an. Waiting for FSLogix Profile Service... Nach 10 Sekunden wechselt die Anzeige auf "Waiting for Windows User Profile Service" und es geht nicht weiter. Server muss komplett abgewürgt werden. Danach geht es wieder für einige male und plötzlich ist der Fehler wieder da.
2. Es können bereits andere User auf dem TS drauf sein, dass Problem tritt erst auf, wenn sich der Benutzer mit dem FSLogix Profil anmeldet. Damit werden auch alle anderen Benutzer auf dem TS beeinträchtig, da der User Profile Service vollständig mit sich selbst beschäftigt ist. Neustart des Service geht auch nicht.
Die GPO für "Only allow local profile" kennen wir, können wir aber erst anwenden, wenn alle umgestellt sind oder?
Damit wären 2 unterschiedliche Profile für die lokalen PCs und Server möglich.
Kann es daran liegen, dass beide Roaming Profil Pfade im AD noch eingetragen sind und hier ein "Misch Masch" entsteht? Wir haben zumindest gesehen, dass die NTUSER.DAT Datei im alten Roaming Profile aktualisiert wurde und einen aktuellen Zeitstempel trägt.
Vor dem Wochenende mussten wir beide Profile (FSLogix und das Roaming Profile) wiederherstellen, weil beide "zerschossen" waren. Alle Icons und Einstellungen waren weg.
Wir dachten zuerst, es liegt daran, dass Adobe immer solche Z@XXXX.tmp Dateien erstellt, welche bei der Abmeldung nicht gelöscht werden können. Dieses Problem haben wir jedoch durch einen Workaround beheben können. Die temporären FSLogix Profile werden nun richtig entfernt.
Beste Grüsse
Wir haben folgende Probleme mit FSLogix und wissen gerade nicht mehr weiter:
1. FSLogix in der aktuellen Version unter Server 2016 RDS Server installiert und konfiguriert.
2. Einen Testbenutzer in die FSLogix Gruppe aufgenommen.
3. Die Benutzer haben alle 2 Roaming Profile: Eines für die lokalen PCs und eines für den TS (Im AD so eingetragen)
4. Der Eintrag für das Roaming Profil des Terminalservers wurde im AD so stehen gelassen, damit FSLogix nicht das Roaming Profil des PCs anzieht oder verändert.
5. Den Benutzer angemeldet. TS-Profil des Benutzers wurde erfolgreich übernommen und der FSLogix Profile Container wurde erstellt. Danach getestet, ob FSLogix auch wirklich nur Daten aus diesem Profil lädt, was anfänglich den Anschein machte.
Nun haben wir aber folgende Probleme in unregelmässigen Abständen festgestellt:
1. Der Benutzer meldet sich an. Waiting for FSLogix Profile Service... Nach 10 Sekunden wechselt die Anzeige auf "Waiting for Windows User Profile Service" und es geht nicht weiter. Server muss komplett abgewürgt werden. Danach geht es wieder für einige male und plötzlich ist der Fehler wieder da.
2. Es können bereits andere User auf dem TS drauf sein, dass Problem tritt erst auf, wenn sich der Benutzer mit dem FSLogix Profil anmeldet. Damit werden auch alle anderen Benutzer auf dem TS beeinträchtig, da der User Profile Service vollständig mit sich selbst beschäftigt ist. Neustart des Service geht auch nicht.
Die GPO für "Only allow local profile" kennen wir, können wir aber erst anwenden, wenn alle umgestellt sind oder?
Damit wären 2 unterschiedliche Profile für die lokalen PCs und Server möglich.
Kann es daran liegen, dass beide Roaming Profil Pfade im AD noch eingetragen sind und hier ein "Misch Masch" entsteht? Wir haben zumindest gesehen, dass die NTUSER.DAT Datei im alten Roaming Profile aktualisiert wurde und einen aktuellen Zeitstempel trägt.
Vor dem Wochenende mussten wir beide Profile (FSLogix und das Roaming Profile) wiederherstellen, weil beide "zerschossen" waren. Alle Icons und Einstellungen waren weg.
Wir dachten zuerst, es liegt daran, dass Adobe immer solche Z@XXXX.tmp Dateien erstellt, welche bei der Abmeldung nicht gelöscht werden können. Dieses Problem haben wir jedoch durch einen Workaround beheben können. Die temporären FSLogix Profile werden nun richtig entfernt.
Beste Grüsse
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: 31089929816
Url: https://administrator.de/forum/fslogix-auf-terminalserver-2016-31089929816.html
Ausgedruckt am: 26.12.2024 um 12:12 Uhr
19 Kommentare
Neuester Kommentar
War FSLogix zuvor in einer anderen Version installiert? Sind die Probleme da schon aufgetreten oder erst mit der neuesten Version?
Wenn der Benutzer mit FSLogix angemeldet ist, steht dann in der Profilliste am RD-SH Roaming oder Local? Da muss Local stehen bzw. gesetzt werden, sonst macht er beides!
Wenn der Benutzer mit FSLogix angemeldet ist, steht dann in der Profilliste am RD-SH Roaming oder Local? Da muss Local stehen bzw. gesetzt werden, sonst macht er beides!
Guten Tag Ukulele-7
Frage 1: Nein, FSLogix wurde neu installiert und damit eben die neuste verfügbare Version.
Frage 2: Ich verstehe nicht ganz. Auf dem Terminal Server unter C:\Users\ sehe ich einmal ein BenutzerXY und einmal ein LOCAL_XY Profil. Beide verschwinden wieder, wenn sich der User abmeldet. Das kommt aber vom FSLogix so. Oder meinst du unter "Erweiterte Systemeinstellungen \ Benutzerprofile"? --> Das weiss ich gerade nicht. Muss ich nachschauen wenn du das meinst....
Da wir aber Person um Person umstellen möchten, können wir die GPO "Only allow local profile" nicht auf dem ganzen TS setzten.
Kann ich das irgendwie für einzelne Benutzer anwenden? Oder wie bekomme ich es hin, dass FSLogix das Roaming Profil der PCs nicht anfasst und der einmal umgestellte FSLogix Benutzer danach nicht mehr beide anzieht?
Grüsse
Pleci87
Grüsse
Frage 1: Nein, FSLogix wurde neu installiert und damit eben die neuste verfügbare Version.
Frage 2: Ich verstehe nicht ganz. Auf dem Terminal Server unter C:\Users\ sehe ich einmal ein BenutzerXY und einmal ein LOCAL_XY Profil. Beide verschwinden wieder, wenn sich der User abmeldet. Das kommt aber vom FSLogix so. Oder meinst du unter "Erweiterte Systemeinstellungen \ Benutzerprofile"? --> Das weiss ich gerade nicht. Muss ich nachschauen wenn du das meinst....
Da wir aber Person um Person umstellen möchten, können wir die GPO "Only allow local profile" nicht auf dem ganzen TS setzten.
Kann ich das irgendwie für einzelne Benutzer anwenden? Oder wie bekomme ich es hin, dass FSLogix das Roaming Profil der PCs nicht anfasst und der einmal umgestellte FSLogix Benutzer danach nicht mehr beide anzieht?
Grüsse
Pleci87
Grüsse
Moin,
Grundsätzlich:
wir haben bei den Usern nirgend den Pfad zum Userprofil fest hinterlegt.
Das läuft bei uns via GPO.
Die OU, in denen die RDS abgelegt sind, bekommen keine GPOs vererbt. Hier liegt dann eine GPO, die die Profilpfade für die RDS-Umgebung setzt bzw. eben nicht setzt. Dafür dann die GPO für die FSLogix Profile
In der OU, in der die User abgelegt sind, ist dann die GPO, die die Profilpfade für die RDS-FSLogix-Profile definiert, verknüpft.
Damit ist ausgeschlossen, dass "irgendwelche" Pfade aus dem AD-Objekt irgendwas übersteuern.
Auf dem Terminal Server unter C:\Users\ sehe ich einmal ein BenutzerXY und einmal ein LOCAL_XY Profil. Beide verschwinden wieder, wenn sich der User abmeldet. Das kommt aber vom FSLogix so
Korrekt, das macht FSLogixGrundsätzlich:
wir haben bei den Usern nirgend den Pfad zum Userprofil fest hinterlegt.
Das läuft bei uns via GPO.
Die OU, in denen die RDS abgelegt sind, bekommen keine GPOs vererbt. Hier liegt dann eine GPO, die die Profilpfade für die RDS-Umgebung setzt bzw. eben nicht setzt. Dafür dann die GPO für die FSLogix Profile
In der OU, in der die User abgelegt sind, ist dann die GPO, die die Profilpfade für die RDS-FSLogix-Profile definiert, verknüpft.
Damit ist ausgeschlossen, dass "irgendwelche" Pfade aus dem AD-Objekt irgendwas übersteuern.
Ja ich meine die Profilliste unter Erweiterte Systemeinstellungen \ Benutzerprofile. Dort kannst du auch die Einstellung von Roaming auf Local ändern. Ablauf:
1) Benutzer meldet sich am RD-SH an. Wenn der Benutzer selbst oder eine Gruppe, in der der Benutzer Mitglied ist, lokal am RD-SH in der Include-Berechtigungsgruppe von FSLogix ist (und nicht in der Exclude-Gruppe) wird FSLogix aktiv.
2) FSL legt dann, falls nicht vorhanden, eine Profiledisk an. Steht das Profil auf roaming, wird das roaming profile geladen und in die Profiledisk kopiert. Das ist quasi immer der Fall wenn der Benutzer sich das erste mal anmeldet, egal ob er vorher ein roaming profile hatte oder nicht.
3) Während der Benutzer angemeldet ist, musst du dann hier das Profil auf local umstellen. Wenn er sich dann abmeldet, werden die Änderungen nicht mehr in das roaming profile im Netz zurück geschrieben.
4) Wenn er dann abgemeldet ist, müssen alle Kopien des Profiles über die Profilliste von ALLEN RD-SH gelöscht werden. Sonst steht das Profil wieder auf roaming, sobald einer der Server noch eine lokale Kopie hat und der User sich dort anmeldet.
5) Dann kann sich der Benutzer wieder anmelden. Er muss wieder auf local stehen und macht dann nur noch FSLogix. Das kann man sehr gut pro Benutzer machen, leider ist die Profilliste nicht grade sehr schnell.
Sollte das auf roaming umspringen wenn der Benutzer sich erneut anmeldet, dann arbeitet dort etwas nicht richtig. Eventuell schießt dann auch eine GPO dazwischen. Die häufigste Ursache ist aber eine lokale Kopie des roaming profiles, die noch vom letzten mal auf dem RD-SH liegt.
1) Benutzer meldet sich am RD-SH an. Wenn der Benutzer selbst oder eine Gruppe, in der der Benutzer Mitglied ist, lokal am RD-SH in der Include-Berechtigungsgruppe von FSLogix ist (und nicht in der Exclude-Gruppe) wird FSLogix aktiv.
2) FSL legt dann, falls nicht vorhanden, eine Profiledisk an. Steht das Profil auf roaming, wird das roaming profile geladen und in die Profiledisk kopiert. Das ist quasi immer der Fall wenn der Benutzer sich das erste mal anmeldet, egal ob er vorher ein roaming profile hatte oder nicht.
3) Während der Benutzer angemeldet ist, musst du dann hier das Profil auf local umstellen. Wenn er sich dann abmeldet, werden die Änderungen nicht mehr in das roaming profile im Netz zurück geschrieben.
4) Wenn er dann abgemeldet ist, müssen alle Kopien des Profiles über die Profilliste von ALLEN RD-SH gelöscht werden. Sonst steht das Profil wieder auf roaming, sobald einer der Server noch eine lokale Kopie hat und der User sich dort anmeldet.
5) Dann kann sich der Benutzer wieder anmelden. Er muss wieder auf local stehen und macht dann nur noch FSLogix. Das kann man sehr gut pro Benutzer machen, leider ist die Profilliste nicht grade sehr schnell.
Sollte das auf roaming umspringen wenn der Benutzer sich erneut anmeldet, dann arbeitet dort etwas nicht richtig. Eventuell schießt dann auch eine GPO dazwischen. Die häufigste Ursache ist aber eine lokale Kopie des roaming profiles, die noch vom letzten mal auf dem RD-SH liegt.
Hallo em-pie
Danke. Soweit verstehe ich deine Konfiguration. Ich frage mich jedoch, was für uns in frage kommt, wenn die Benutzer bereits 2 unterschiedliche Roaming Pfade im AD hinterlegt haben.
Das eine Profil ist unter "Profil" eingetragen mit \\server\Benutzer
Das andere Profil ist eingetragen unter Remote Desktop Services Profile unter\\server\Benutzer-TS
Bei der ersten Anmeldung mit FSLogix haben wir gesehen, dass das Benutzer-TS Profil angezogen wurde. Danach sah es so aus, als ob FSLogix nur noch mit dem Container arbeiten würde. Deshalb wurden die Einträge im AD so stehen gelassen. Denn sobald der Eintrag unter "Remote Desktop Services Profile" entfernt wird, wurde das FSLogix Profil wieder durch das andere Roaming Profil überschrieben.
Auf der OU für den TS sind nur die FSLogix Gruppenrichtlinien gesetzt. Die anderen Richtlinien laufen über die OU der User.
@ukulele-7
Danke, unser Beitrag hat sich wohl gerade überschnitten.
Wie ich sehe, gibt es 2 weitere Richtlinien zum Thema Roaming Profiles.
1. Add the Administrators security group to roaming user profiles --> Enabled
2. Exclude directories in roaming profile --> Enabled -.-> Darin stehen verschiedene AppData\Roaming Sachen.
Sonst aber nix.
Zu deiner Anleitung:
Punkt 1 = Klar, ist bei uns aktuell nur eine Person.
Punkt 2 = Klar. Er nimmt entweder das lokale Profil auf dem TS oder das Roaming Profil des Users.
Punkt 3 = Angenommen der Benutzer ist angemeldet, kann ich mich im Hintergrund als Admin am TS anmelden und die Änderung auf "Local" durchführen oder muss das der besagte Benutzer mit meiner Hilfe in seiner Session machen?
--> Zudem habe ich bei FSLogix die Option Delete Local Profile When VHD Should Apply aktiviert. Das führt vermutlich dazu, dass ich von diesem Benutzer gar kein Profil auf dem Server sehen kann. Denn in der Profilliste unter C:\Users\ sehe ich das alte Profil "BenutzerXY-TS" nicht mehr. Das hat er nach der ersten Anmeldung gekillt.
Punkt 4 + 5 = Ich stelle den Benutzer auf Local um. Damit wird sein Profil nur noch lokal abgefragt. Danach meldet sich der Benutzer ab. Jetzt lösche ich das Profil. Was hindert Ihn nun daran, das Roaming Profil wieder abzurufen? Der Server weiss doch nicht, dass der Benutzer jemals ein Profil auf dem Server hatte, wenn ich es lösche?! Oder entferne ich nach der Bereinigung des Benutzers den TS Roaming Eintrag im AD?
Danke. Soweit verstehe ich deine Konfiguration. Ich frage mich jedoch, was für uns in frage kommt, wenn die Benutzer bereits 2 unterschiedliche Roaming Pfade im AD hinterlegt haben.
Das eine Profil ist unter "Profil" eingetragen mit \\server\Benutzer
Das andere Profil ist eingetragen unter Remote Desktop Services Profile unter\\server\Benutzer-TS
Bei der ersten Anmeldung mit FSLogix haben wir gesehen, dass das Benutzer-TS Profil angezogen wurde. Danach sah es so aus, als ob FSLogix nur noch mit dem Container arbeiten würde. Deshalb wurden die Einträge im AD so stehen gelassen. Denn sobald der Eintrag unter "Remote Desktop Services Profile" entfernt wird, wurde das FSLogix Profil wieder durch das andere Roaming Profil überschrieben.
Auf der OU für den TS sind nur die FSLogix Gruppenrichtlinien gesetzt. Die anderen Richtlinien laufen über die OU der User.
@ukulele-7
Danke, unser Beitrag hat sich wohl gerade überschnitten.
Wie ich sehe, gibt es 2 weitere Richtlinien zum Thema Roaming Profiles.
1. Add the Administrators security group to roaming user profiles --> Enabled
2. Exclude directories in roaming profile --> Enabled -.-> Darin stehen verschiedene AppData\Roaming Sachen.
Sonst aber nix.
Zu deiner Anleitung:
Punkt 1 = Klar, ist bei uns aktuell nur eine Person.
Punkt 2 = Klar. Er nimmt entweder das lokale Profil auf dem TS oder das Roaming Profil des Users.
Punkt 3 = Angenommen der Benutzer ist angemeldet, kann ich mich im Hintergrund als Admin am TS anmelden und die Änderung auf "Local" durchführen oder muss das der besagte Benutzer mit meiner Hilfe in seiner Session machen?
--> Zudem habe ich bei FSLogix die Option Delete Local Profile When VHD Should Apply aktiviert. Das führt vermutlich dazu, dass ich von diesem Benutzer gar kein Profil auf dem Server sehen kann. Denn in der Profilliste unter C:\Users\ sehe ich das alte Profil "BenutzerXY-TS" nicht mehr. Das hat er nach der ersten Anmeldung gekillt.
Punkt 4 + 5 = Ich stelle den Benutzer auf Local um. Damit wird sein Profil nur noch lokal abgefragt. Danach meldet sich der Benutzer ab. Jetzt lösche ich das Profil. Was hindert Ihn nun daran, das Roaming Profil wieder abzurufen? Der Server weiss doch nicht, dass der Benutzer jemals ein Profil auf dem Server hatte, wenn ich es lösche?! Oder entferne ich nach der Bereinigung des Benutzers den TS Roaming Eintrag im AD?
Zitat von @Plexi87:
Punkt 3 = Angenommen der Benutzer ist angemeldet, kann ich mich im Hintergrund als Admin am TS anmelden und die Änderung auf "Local" durchführen oder muss das der besagte Benutzer mit meiner Hilfe in seiner Session machen?
Das kannst du für alle Benutzer als Admin machen. Ob der Benutzer es für sich selber innerhalb der Session machen kann weiß ich ehrlich gesagt nicht mal, habe ich nie versucht.Punkt 3 = Angenommen der Benutzer ist angemeldet, kann ich mich im Hintergrund als Admin am TS anmelden und die Änderung auf "Local" durchführen oder muss das der besagte Benutzer mit meiner Hilfe in seiner Session machen?
--> Zudem habe ich bei FSLogix die Option Delete Local Profile When VHD Should Apply aktiviert. Das führt vermutlich dazu, dass ich von diesem Benutzer gar kein Profil auf dem Server sehen kann. Denn in der Profilliste unter C:\Users\ sehe ich das alte Profil "BenutzerXY-TS" nicht mehr. Das hat er nach der ersten Anmeldung gekillt.
Klingt richtig so, allerdings kenne ich die Option noch nicht. Ist schon ein paar Jahre her das wir den Wechsel gemacht haben. In jedem Fall, nach der Erstanmeldung mit FSL auf local setzen und nach der Abmeldung muss das Profil aus der Profilliste auf allen RD-SH weg sein.Punkt 4 + 5 = Ich stelle den Benutzer auf Local um. Damit wird sein Profil nur noch lokal abgefragt. Danach meldet sich der Benutzer ab. Jetzt lösche ich das Profil. Was hindert Ihn nun daran, das Roaming Profil wieder abzurufen? Der Server weiss doch nicht, dass der Benutzer jemals ein Profil auf dem Server hatte, wenn ich es lösche?! Oder entferne ich nach der Bereinigung des Benutzers den TS Roaming Eintrag im AD?
FSLogix greift ja im Hintergrund lokal ein und tut so, als sei es das lokale Profil. Wenn dort aber nicht local sondern roaming steht, dann greift er auch auf den roaming Pfad zu und synchronisiert das, was er für das lokale Profil hält.
Wir haben unsere Umstellung auch wirklich von roaming auf FSL User für User gemacht. Ich habe immer noch den roaming Pfad per GPO gesetzt als eine Art Fallback. Der Pfad ist im Normalfall leer. Sollte mal vergessen werden, einen Benutzer in die FSL Anwendergruppe aufzunehmen würde der ein roaming profile bekommen. Auf dem Pfad sehe ich das dann irgendwann und kann es umstellen. Auch hatte ich schon mal nach einem RD-SH Crash plötzlich wieder roaming profiles aller Benutzer, die zu dem Zeitpunkt angemeldet waren. Es gab auch Fälle, wo der Benutzer plötzlich die Leserechte auf die VHDX verloren hat, dann wurde allerdings eine temporäre VHDX angelegt - ich weiß noch nicht genau wann das passiert.
Alles klar. Besten Dank für deine Infos. Das wird mir hoffentlich einiges an Problemen ersparen.
Ich habe eine Kopie der Umgebung, welche ich separat starten kann.
Ich versuche das von dir beschriebene Verhalten nachzustellen. Wenn es funktioniert, wende ich es sofort beim besagten Benutzer an.
PS: Es wäre nett, wenn du das Thema noch eine Weile verfolgen könntest, solten noch weiter Fragen auftauchen
Danke im Voraus.
Plexi87
Ich habe eine Kopie der Umgebung, welche ich separat starten kann.
Ich versuche das von dir beschriebene Verhalten nachzustellen. Wenn es funktioniert, wende ich es sofort beim besagten Benutzer an.
PS: Es wäre nett, wenn du das Thema noch eine Weile verfolgen könntest, solten noch weiter Fragen auftauchen
Danke im Voraus.
Plexi87
Wenn man sich die Mühe macht, egal ob im Test- oder im Livebetrieb, genau zu gucken was wann passiert, dann hilft einem das später enorm weiter. Eigentlich ist es aber sehr robust aus meiner Erfahrung.
Ich gucke hier ein paar mal am Tag rein und antworte auch auf alte Threads.
Ich gucke hier ein paar mal am Tag rein und antworte auch auf alte Threads.
Hallo Ukulele-7
Was soll ich sagen! DANKE für den Tipp. Das hat bestens funktioniert. Das Terminalserver Roaming Profil wird nicht mehr angefasst. Damit arbeitet der Benutzer nur noch mit dem FS-Logix Container.
Nun geht es darum, weitere Benutzer zu migrieren.
Würdest du folgendes Vorgehen für richtig befinden?
1. Die Benutzer welche am Tag X umgestellt werden sollen, werden vor Arbeitsbeginn zur FSLogix Gruppe hinzugefügt.
2. Die Mitarbeiter kommen am Morgen und melden sich an. Dabei wird der FSLogix Container erstellt.
3. Wärend Sie angemeldet sind, wird das Profil auf "Local" umgestellt.
4. Am Mittag melden sich die besagten Benutzer ab. Dabei wird das Profil in den FSLogix Container zurückgeschrieben.
5. Ich prüfe, ob keine Profilreste mehr auf dem TS sind. Wenn doch, lösche ich diese.
6. Die Benutzer melden sich wieder an und sind damit auf FSLogix umgestellt.
Ich war mir nicht mehr sicher, ob die Container bei der Anmeldung oder Abmeldung erstellt werden. Wie ich jetzt gelesen habe, wird dieser bei der Anmeldung erstellt. Richtig?
Beste Grüsse und Danke!
Plexi87
Was soll ich sagen! DANKE für den Tipp. Das hat bestens funktioniert. Das Terminalserver Roaming Profil wird nicht mehr angefasst. Damit arbeitet der Benutzer nur noch mit dem FS-Logix Container.
Nun geht es darum, weitere Benutzer zu migrieren.
Würdest du folgendes Vorgehen für richtig befinden?
1. Die Benutzer welche am Tag X umgestellt werden sollen, werden vor Arbeitsbeginn zur FSLogix Gruppe hinzugefügt.
2. Die Mitarbeiter kommen am Morgen und melden sich an. Dabei wird der FSLogix Container erstellt.
3. Wärend Sie angemeldet sind, wird das Profil auf "Local" umgestellt.
4. Am Mittag melden sich die besagten Benutzer ab. Dabei wird das Profil in den FSLogix Container zurückgeschrieben.
5. Ich prüfe, ob keine Profilreste mehr auf dem TS sind. Wenn doch, lösche ich diese.
6. Die Benutzer melden sich wieder an und sind damit auf FSLogix umgestellt.
Ich war mir nicht mehr sicher, ob die Container bei der Anmeldung oder Abmeldung erstellt werden. Wie ich jetzt gelesen habe, wird dieser bei der Anmeldung erstellt. Richtig?
Beste Grüsse und Danke!
Plexi87
Zitat von @Plexi87:
1. Die Benutzer welche am Tag X umgestellt werden sollen, werden vor Arbeitsbeginn zur FSLogix Gruppe hinzugefügt.
2. Die Mitarbeiter kommen am Morgen und melden sich an. Dabei wird der FSLogix Container erstellt.
3. Wärend Sie angemeldet sind, wird das Profil auf "Local" umgestellt.
4. Am Mittag melden sich die besagten Benutzer ab. Dabei wird das Profil in den FSLogix Container zurückgeschrieben.
5. Ich prüfe, ob keine Profilreste mehr auf dem TS sind. Wenn doch, lösche ich diese.
6. Die Benutzer melden sich wieder an und sind damit auf FSLogix umgestellt.
Das ist der Weg.1. Die Benutzer welche am Tag X umgestellt werden sollen, werden vor Arbeitsbeginn zur FSLogix Gruppe hinzugefügt.
2. Die Mitarbeiter kommen am Morgen und melden sich an. Dabei wird der FSLogix Container erstellt.
3. Wärend Sie angemeldet sind, wird das Profil auf "Local" umgestellt.
4. Am Mittag melden sich die besagten Benutzer ab. Dabei wird das Profil in den FSLogix Container zurückgeschrieben.
5. Ich prüfe, ob keine Profilreste mehr auf dem TS sind. Wenn doch, lösche ich diese.
6. Die Benutzer melden sich wieder an und sind damit auf FSLogix umgestellt.
Ich war mir nicht mehr sicher, ob die Container bei der Anmeldung oder Abmeldung erstellt werden. Wie ich jetzt gelesen habe, wird dieser bei der Anmeldung erstellt. Richtig?
Definitiv Anmeldung. Allerdings ist im Normalbetrieb der Abmeldevorgang das, was lange dauern kann.FSL erstellt eine VHDX und eine RW-Datei. Die VHDX ist zu dem Zeitpunkt quasi leer, die RW-Datei nimmt alle geänderten Daten auf. Der RD-SH mountet die VHDX und RW-Datei, läd das roaming profile beim ersten mal vom Profilserver und schreibt die Daten in die RW-Datei. Beim Abmelden integriert FSL die Daten der RW-Datei in die VHDX. Also grade beim ersten Abmeldevorgang oder immer, wenn viele Daten im Profil verändert wurden, dauert das, bis alles in der eigentlichen VHDX ankommt. Auch gelöschte Daten sind ja Änderungen, die in die VHDX integriert werden müssen. Außerdem passiert das alles durch den RD-SH und damit übers Netzwerk, weil da der FSL Dienst läuft. Der User kann aber z.B. die Sitzung während der Abmeldung schon trennen, die Abmeldung läuft weiter.
Die normale Anmeldung ohne roaming ist immer schnell, weil nur gemountet wird aber wenig über das Netzwerk geladen werden muss.
Moin,
halte aber die größe der Profile im Auge.
Insbesondere wenn da viel mit Teams und Konsorten gewerkelt wird, blähen sich die Profile auf, schrumpfen aber nicht wieder.
Dafüf gib es aber PS-Scripte (https://github.com/FSLogix/Invoke-FslShrinkDisk) oder andere Mechanismen (https://4sysops.com/archives/fslogix-vhdx-compaction-resize-virtual-disk ..), die man zyklisch laufen lassen kann (wenn keines der FSL-VHDXs geladen ist).
Diese Varianten aber im Vorfeld erstmal testen...
halte aber die größe der Profile im Auge.
Insbesondere wenn da viel mit Teams und Konsorten gewerkelt wird, blähen sich die Profile auf, schrumpfen aber nicht wieder.
Dafüf gib es aber PS-Scripte (https://github.com/FSLogix/Invoke-FslShrinkDisk) oder andere Mechanismen (https://4sysops.com/archives/fslogix-vhdx-compaction-resize-virtual-disk ..), die man zyklisch laufen lassen kann (wenn keines der FSL-VHDXs geladen ist).
Diese Varianten aber im Vorfeld erstmal testen...
1
Auch werden die VHDX meist mit einem Größenlimit angelegt, bis zu dem die von alleine Wachsen können. Wenn das erreicht ist, können Änderungen aus der RW nicht mehr in die VHDX geschrieben werden und gehen bei Abmeldung verloren. Die VHDX muss dann angepasst werden, das Größenlimit wird bei Dateierstellung festgelegt.
Hallo Zusammen
Danke Euch für die Inputs. Jetzt war ich gerade verunsichert. Die Disks wurden in Ihrer Grösse nicht speziell festgelegt.
Habe jetzt in der GPO nachgesehen.
Zitat:
VHD(x)s will be dynamically allocated. VHD(x) file size will grow as data is added to the VHD(x). If disabled, VHD(x)s that are auto-created will be fully allocated.
NOTE: Default is Enabled (1) which is the same as "Not Configured"
Registry Entry: HKLM\SOFTWARE\FSLogix\Profiles\IsDynamic
Type: DWORD
Values: 0 = Disabled, 1 = Enabled
Daher sollte dies passen. Ich muss einfach den Speicherplatz auf dem Laufwerk im Auge behalten. Die Profile an sich sind relativ klein. Für Office Cache haben wir ein separaten ODFC Container eingerichtet. Damit sind die Müllberge voneinander getrennt
Die Skripte werde ich mir gerne anschauen. Besten Dank.
Grüsse
Plexi87
Danke Euch für die Inputs. Jetzt war ich gerade verunsichert. Die Disks wurden in Ihrer Grösse nicht speziell festgelegt.
Habe jetzt in der GPO nachgesehen.
Zitat:
VHD(x)s will be dynamically allocated. VHD(x) file size will grow as data is added to the VHD(x). If disabled, VHD(x)s that are auto-created will be fully allocated.
NOTE: Default is Enabled (1) which is the same as "Not Configured"
Registry Entry: HKLM\SOFTWARE\FSLogix\Profiles\IsDynamic
Type: DWORD
Values: 0 = Disabled, 1 = Enabled
Daher sollte dies passen. Ich muss einfach den Speicherplatz auf dem Laufwerk im Auge behalten. Die Profile an sich sind relativ klein. Für Office Cache haben wir ein separaten ODFC Container eingerichtet. Damit sind die Müllberge voneinander getrennt
Die Skripte werde ich mir gerne anschauen. Besten Dank.
Grüsse
Plexi87
Ich würde annehmen, dass eine "fully allocated VHDx" eine feste Größe in Höhe des Speicherlimits hat, quasi thick provisioning. Aber vielleicht denke ich da auch falsch, probier das aus.
Guten Morgen
Ich habe die Richtlinien noch einmal durchgesehen. Als Ergänzung zur oberen Richtlinie "Is Dynamic" habe ich noch die Richtlinie "Size in MB" gefunden. Auch dort wird folgendes besagt:
Zitat:
Specify the size for auto-created VHD(x) files.
NOTE: Default is 30,000 (30GB) which is the same as "Not Configured"
Registry Entry: HKLM\SOFTWARE\FSLogix\Profiles\SizeInMBs
Type: DWORD
Values: Min = 500, Max = 1000000
Unser bereits migrierter Benutzer hat eine Profilgrösse von 2.8 GB. Die VHDX Datei ist genau so gross. Daher wird keine VHDX Datei mit 30GB erstellt und voll zugewiesen. Scheint also richtig zu funktionieren, da ich "Is Dynamic" auf 1 habe.
Im Umkehrschluss bedeutet dies, dass ein zu migrierendes Profil sicher nicht grösser als 30GB sein darf, da ich sonst die Richtlinie "Size in MB" manuell festlegen muss. Aber so grosse Profile gehören sowieso verboten
Eine kleine Frage ist jedoch noch aufgetaucht:
- Was ist der Unterschied zwischen "Outlook Cache Mode" in der Profil GPO und in der ODFC GPO?
- Aktuell habe ich diese im Profil aktiviert, scheint jedoch nicht zu greifen. Beim User steht noch immer "Online" im Outlook.
Greift die Einstellung nur, wenn man kein ODFC Container verwendet? Muss ich die Einstellung also dort vornehmen?
Danke.
Plexi87
Ich habe die Richtlinien noch einmal durchgesehen. Als Ergänzung zur oberen Richtlinie "Is Dynamic" habe ich noch die Richtlinie "Size in MB" gefunden. Auch dort wird folgendes besagt:
Zitat:
Specify the size for auto-created VHD(x) files.
NOTE: Default is 30,000 (30GB) which is the same as "Not Configured"
Registry Entry: HKLM\SOFTWARE\FSLogix\Profiles\SizeInMBs
Type: DWORD
Values: Min = 500, Max = 1000000
Unser bereits migrierter Benutzer hat eine Profilgrösse von 2.8 GB. Die VHDX Datei ist genau so gross. Daher wird keine VHDX Datei mit 30GB erstellt und voll zugewiesen. Scheint also richtig zu funktionieren, da ich "Is Dynamic" auf 1 habe.
Im Umkehrschluss bedeutet dies, dass ein zu migrierendes Profil sicher nicht grösser als 30GB sein darf, da ich sonst die Richtlinie "Size in MB" manuell festlegen muss. Aber so grosse Profile gehören sowieso verboten
Eine kleine Frage ist jedoch noch aufgetaucht:
- Was ist der Unterschied zwischen "Outlook Cache Mode" in der Profil GPO und in der ODFC GPO?
- Aktuell habe ich diese im Profil aktiviert, scheint jedoch nicht zu greifen. Beim User steht noch immer "Online" im Outlook.
Greift die Einstellung nur, wenn man kein ODFC Container verwendet? Muss ich die Einstellung also dort vornehmen?
Danke.
Plexi87
Zitat von @Plexi87:
Unser bereits migrierter Benutzer hat eine Profilgrösse von 2.8 GB. Die VHDX Datei ist genau so gross. Daher wird keine VHDX Datei mit 30GB erstellt und voll zugewiesen. Scheint also richtig zu funktionieren, da ich "Is Dynamic" auf 1 habe.
Jo sieht gut aus.Unser bereits migrierter Benutzer hat eine Profilgrösse von 2.8 GB. Die VHDX Datei ist genau so gross. Daher wird keine VHDX Datei mit 30GB erstellt und voll zugewiesen. Scheint also richtig zu funktionieren, da ich "Is Dynamic" auf 1 habe.
Im Umkehrschluss bedeutet dies, dass ein zu migrierendes Profil sicher nicht grösser als 30GB sein darf, da ich sonst die Richtlinie "Size in MB" manuell festlegen muss. Aber so grosse Profile gehören sowieso verboten
Also ich habe welche über 200 GB, natürlich gegen meinen Willen...Eine kleine Frage ist jedoch noch aufgetaucht:
- Was ist der Unterschied zwischen "Outlook Cache Mode" in der Profil GPO und in der ODFC GPO?
- Aktuell habe ich diese im Profil aktiviert, scheint jedoch nicht zu greifen. Beim User steht noch immer "Online" im Outlook.
Greift die Einstellung nur, wenn man kein ODFC Container verwendet? Muss ich die Einstellung also dort vornehmen?
Ich bin da kein Experte, aber ich glaube der Cache Mode hat nichts mit einem ODFC Container zu tun. Der Cache Mode geht glaube ich auch mit roaming profiles oder eigentlich egal was man hat und legt nur eine pst-Datei an. Bei diesen Office Containern wird glaube ich den Office-Anwendungen ein Container in APPDATA gemountet, aber die Office Anwendung weiß davon nichts. Die hält das genau wie bei einer Profile Disk für ihren lokalen Pfad.- Was ist der Unterschied zwischen "Outlook Cache Mode" in der Profil GPO und in der ODFC GPO?
- Aktuell habe ich diese im Profil aktiviert, scheint jedoch nicht zu greifen. Beim User steht noch immer "Online" im Outlook.
Greift die Einstellung nur, wenn man kein ODFC Container verwendet? Muss ich die Einstellung also dort vornehmen?
Ich habe beides noch nicht benutzt, das nehme ich jetzt nur an.
Moin,
ODFC ist im Rahmen von FsLogix für Microsoft 365 Apps gedacht. ODFC ist sozusagen Bestandteil des eigentliche Profil Containers des Benutzers. Es soll dir die Flexibilität geben, um die M365 an einem anderen Ort zu speichern. Stichwort Storage Tiering.
Gruß,
Dani
- Was ist der Unterschied zwischen "Outlook Cache Mode" in der Profil GPO und in der ODFC GPO?
ersteres ist eine GPO für Microsoft Office bzw. Outlook, oder? Da geht es um die Konfiguration des Caches Modus von Outlook. Es hat vermutlich nichts mit dem Speicherort der OST Datei zu tun. Aber mehr, wenn du uns den Pfad oder einen Screenshot von der Richtlinie postet.ODFC ist im Rahmen von FsLogix für Microsoft 365 Apps gedacht. ODFC ist sozusagen Bestandteil des eigentliche Profil Containers des Benutzers. Es soll dir die Flexibilität geben, um die M365 an einem anderen Ort zu speichern. Stichwort Storage Tiering.
Gruß,
Dani
Hallo Dani
Vielen Dank. Wir haben bei der Umsetzung von FSLogix sowohl den ODFC und den Profile-Container aktiviert.
Dabei haben wir die Einstellung "Enable Cache Mode" für Outlook in der Gruppenrichtlinie des Profile-Containers aktiviert und nicht in der ODFC. Die gleiche Einstellung existiert jedoch auch in der ODFC-Gruppenrichtlinie. Wir haben festgestellt, dass diese Einstellung bei den Usern auf dem TS nicht aktiviert wird.
Daher die Frage:
Welche Einstellung zieht in welchem Fall (Profile / ODFC)? Vermutlich hätten wir die GPO im ODFC Container aktivieren müssen damit es funktioniert.
Wir haben es belassen, da die Benutzer seit eh und jeh im Online Modus arbeiten. Keine schlafenden Wölfe wecken mit neuen Einstellungen
Grüsse
Plexi
Vielen Dank. Wir haben bei der Umsetzung von FSLogix sowohl den ODFC und den Profile-Container aktiviert.
Dabei haben wir die Einstellung "Enable Cache Mode" für Outlook in der Gruppenrichtlinie des Profile-Containers aktiviert und nicht in der ODFC. Die gleiche Einstellung existiert jedoch auch in der ODFC-Gruppenrichtlinie. Wir haben festgestellt, dass diese Einstellung bei den Usern auf dem TS nicht aktiviert wird.
Daher die Frage:
Welche Einstellung zieht in welchem Fall (Profile / ODFC)? Vermutlich hätten wir die GPO im ODFC Container aktivieren müssen damit es funktioniert.
Wir haben es belassen, da die Benutzer seit eh und jeh im Online Modus arbeiten. Keine schlafenden Wölfe wecken mit neuen Einstellungen
Grüsse
Plexi
Moin,
Gruß,
Dani
Dabei haben wir die Einstellung "Enable Cache Mode" für Outlook in der Gruppenrichtlinie des Profile-Containers aktiviert und nicht in der ODFC
nenne doch einmal den Pfad zu der genannten Richtlinie. Alternativ einen Screenshot. Damit wir alle die gleiche Datengrundlage haben.Wir haben festgestellt, dass diese Einstellung bei den Usern auf dem TS nicht aktiviert wird.
Wie habt ihr das festgestellt/geprüft?Wir haben es belassen, da die Benutzer seit eh und jeh im Online Modus arbeiten.
Der Vorteil des Caches ist, dass das Netzwerk und damit auch der Exchange-Server nicht so stark belastet wird. Ist der Exchange-Server temporär nicht erreichbar, merkt das in der Regel erst einmal keiner. Weil Kalender, Kontakte, sind verfügbar. Gruß,
Dani
