Müssen Roamingprofile zwingend auf die Clients geladen werden?

Unser Setup: Win Server 2016 + 10x Win 8.1 Client

Aktuell nutzen wir lokale Profile, was soweit auch ganz gut funktioniert. Das Problem ist, dass wir einige Mitarbeiter haben, die nur sporadisch mal ein paar Stunden kommen und sich deshalb immer an irgendeinen freien Rechner setzen. Wenn sie sich dort nun mit ihrem Windows-Login anmelden, wird logischerweise ein neues, komplett nacktes Windowsprofil ohne Drucker, Netzlaufwerke, Eigene Dateien usw. erstellt. Als Workaround nutzen diese Mitarbeiter deshalb jetzt die Logins der Mitarbeiter, die sonst an dem Rechner sitzen.

Um das ganze etwas praktikabler zu machen, habe ich jetzt zu Testzwecken auf dem Server einen Testuser mit Roamingprofil angelegt, welches auf unserem Server abgelegt ist, ein paar Dinge eingestellt und Dateien abgelegt und mich dann auf diversen Rechnern mit dem Profil angemeldet -> Läuft 1A.

Als ich dann aber auf den Clients einen Blick in den Benutzerordner geworfen habe, fiel mir auf, dass Windows die Roamingprofile trotzdem runterlädt, was ja dazu führt, dass doch wieder auf jedem Rechner Spuren hinterlassen werden und Speicherplatz verbraucht wird. Bei Profilen im dreistelligen MB-Bereich sicherlich kein Problem aber wenn es größer wird natürlich schon.

Kann man den Download der Roamingprofile auf die Clients verhindern oder muss man damit leben? Kann man evtl. einzelne Ordner vom Download ausschließen?

man kann einzelne ordner vom sync ausnehmen und/oder ordner stattdessen auf andere ordner (netzlaufwerk) umleiten aber grundsätzlich werden roaming Profile lokale runtergeladen

Das was Du suchst befindet sich eher im Bereich Terminal/Terminal-Server, schätze ich. Also lokal auf einem Client arbeiten, aber keine Spuren/Einstellungen hinterlassen. Du benutzt quasi nur die lokalen Eingabegeräte + Monitor, die Daten liegen aber auf einem anderen PC/Server. Ich weiß, dass es soetwas gibt, habe damit allerdings noch nie effektiv/produktiv zu tun gehabt, daher soll der Post nur als Ideenansatz gelten, nicht als Lösung ^^

Edit: Wie wär's wenn diese sporadischen Mitarbeiter per Remote auf ihr eigenes Konto zugreifen, welches auf dem Server per VM läuft?

0711 schrieb:

aber grundsätzlich werden roaming Profile lokale runtergeladen

Zum Vergrößern anklicken....

Naja...
Mit der GPO kann man alle benutzerbezogenen Ordner "umleiten" und dazu zählen auch die Roamings.
Ist auch sinnvoll, denn dort werden viele Programmeinstellungen der User abgelegt.
Bei Roaming muss man allerdings ein wenig vorsichtig sein bspw. Elster mag es nicht, wenn
der Roamingpfad umgeleitet ist, dann lassen sich manche PDF Ausgaben nicht mehr machen.

Danke für die Antworten. Ich werde das jetzt einfach mal testen mit ein paar Roamingprofilen.

Spricht was dagegen, ein fertig angelegtes Roamingprofil von User A in einen zweiten Profilordner von User B zu kopieren, damit man die Ersteinrichtung nur einmal machen muss?

Grundsätzlich werden Roaming Profiles immer lokal heruntergeladen. Du musst also dafür sorgen, dass der Roaming Anteil so klein wie möglich bleibt, um für schnelle An- und Abmeldezeiten zu sorgen.
Mit Windows Boardmitteln nutzt Du als erstes die Folderredirection. Diese kannst Du per GPO setzen. Hier bietet sich selbstverständlich die Ordner an, welche Daten enthalten. z.b. Eigene Dokumente, Videos, Music, Bilder usw. Spannender ist der Ordner %AppData%, %LocalAppData% und Desktop. %Appdata% wird geroamt und würde sich auch redirecten lassen. Ich würde es aber nicht redirecten. %LocalAppData% wird nicht geroamt und bleibt als Profilrest auf dem Computer zurück. Den Desktop kann man je nach Anwendungsfall umleiten.

Probleme entstehen vorallem dann, wenn die Benutzer sich auf unterschiedlichen Plattformen anmelden und auf das Roaming Profil zugreifen und das vielleicht auch noch gleichzeitig. z.b. Anmeldung am Fat Client (Profil wird geladen) --> Anmeldung am Terminal Server über Weboberfläche (Profil wird geladen). User meldet sich vom Fat Client ab (Profil wird geschrieben), geht nach Hause und arbeitet Remote in der TS Sitzung weiter und meldet sich dann ab (Profil wird geschrieben).

In so einem Szenario können sich unterschiedliche Einstellungen der Anwendungen zwischen Fat Client und Terminal Server gerne überschreiben und zu ungünstigen Situation führen.

Hat man eine Terminal Server Farm und jede Menge User, so kann auch %LocalAppData% im Laufe der Zeit die Festplatte eines jeden Terminal Server zumüllen, da dieser Teil des Profils zurückbleibt.

Du musst Dir also Gedanken machen über:
Datenhaltung (Eigene Dokumente, Bilder, etc)
Anwendungseinstellungen die im %AppDataLocal% liegen, aber zwingend geroamt weden müssen
Profilsynchronität zwischen unterschiedlichen Platformen (Last Write Wins)
volle Platten aufgrund von Profilresten


Für all das gibt es Lösungen die aber auch mehr oder weniger Konfigurationsaufwand benötigen.

Zu nennen wäre hier das Microsoft UE-V, Citrix ProfileManagement, Appsense Environment Manager, VMWare Flex Profile Management.
Diese Produkte basieren darauf, auf einem Terminal Server mit einem Mandatory Profil zu arbeiten, welches alle nötigen Einstellung enthält, die für eine schnelle Anmeldung notwendig ist. Beim Abmelden wird das Profil vom Server entfernt, da Mandatory. Die o.g. Tools laden die entsprechenden Teile des Profils OnDemand nach. Der Nachteil ist, das man wirklich alles Einstellen muss, was genau zu welchem Zeitpunkt gemacht werden muss. d.h. jeden Registry Hive, File und Folderpath angeben und zwar für jede Anwendung oder Anwendungsgruppe extra. Scheiß Aufwand, aber lohnt.

Gruß Magic

Die einzige lösung die ohne Eingriff des Admins keinerlei Spuren hinterlässt sind User Profile Disks. Diese beinhalten das Profil und werden beim anmelden dann einfach in C:/users gemountet. Dies geht aber afaik nur in einer RDS Umgebung, sprich Terminalserver ab Server 2012 (R2?).
Sehr zu empfehlen imo.

@.mojo:
Interessant. Das Thema User Profile Disk ging irgendwie an mir vorbei. In den Multi Plattform Terminal Server Umgebungen, mit denen ich zu tun habe, kommt immer irgend eine UE-V Lösung zum Einsatz. Mal einlesen, ob ich mit User Profile Disks was anfangen kann.

Userprofiledisks leiten auch (im standard) nicht das komplette Profil um...generell wird auch hier erst mal localappdata nicht umgeleitet, die userdatenordner auch nicht usw.
Auch sind se recht zickig wenn die Verbindung hart getrennt wird, dann sind die profile unter 2k12r2 i.d.R. hinüber.

definitiv nicht meine erfahrung.
Ich habe keine Änderungen vorgenommen (Ausnahme Folder Redirection von Dokumente, Downloads etc) und nach abmeldung bleibt vom Benutzer keine Spur mehr unter C:\users
bevor sich der erste user morgens anmeldet gibt es unter users nicht mehr als den lokalen admin und all users.


Definiere hart getrennt. Wenn ein User sich nicht abmeldet bleibt das Profil natürlich gemountet. Probleme hat man wenn ein User im AD Account noch einen Remotedesktopprofilpfad gesetzt hat. Dann wurde bei mir das UPD nicht sauber getrennt und blieb im RDSH gemountet.

Wenn man das ordentlich konfiguriert hat sind UPDs absolut top.
Ich bin damit viel glücklicher als mit servergespeicherten Profilen.

.mojo schrieb:

definitiv nicht meine erfahrung.
Ich habe keine Änderungen vorgenommen (Ausnahme Folder Redirection von Dokumente, Downloads etc) und nach abmeldung bleibt vom Benutzer keine Spur mehr unter C:\users

Zum Vergrößern anklicken....

das ist richtig, ändert nichts daran was in der virtullen disk ist und was nicht...kannst ja reinschauen
z.B. wird durch das verhalten das Startmenü nicht gesynct...dazu muss man z.B. separat den ordner AppData\Local\Microsoft\Windows aufnehmen. siehe http://microsoftplatform.blogspot.de/2013/09/using-user-profile-disks-upd-in.html (oder beliebig andere Ergebnisse im web dazu) oder man nutzt eben ue-v dafür (und anderes was unter localappdata liegt) weil man mit upd eben auch diverse tmp/Cache ordner umleitet welche dort drin eigentlich völlig unnötig sind...nur appsfolder.itemdata-ms in die upd packen klappt leider nicht

Nicht ganz unerwähnt lassen sollte man auch dass nachträgliche max größenänderung der profildisk n ziemlicher krampf ist.

.mojo schrieb:

Definiere hart getrennt.

Zum Vergrößern anklicken....

serverabsturz, plötzliche verbindungsunterbrechung zwischen upd speicherort und rdsh u.ä.
https://social.technet.microsoft.co...rdat-after-rds-host-crashes?forum=winserverTS
ist sicher keins alltägliche Gefahr aber man sollte sich dem bewusst sein

.mojo schrieb:

Wenn man das ordentlich konfiguriert hat sind UPDs absolut top.
Ich bin damit viel glücklicher als mit servergespeicherten Profilen.

Zum Vergrößern anklicken....

was durchaus verständlich ist weil UPDs Vorteile haben aber eben auch kein "rundum sorglos" paket liefern

ok, geb ich dir recht.
Startmenü ist bei mir aber eh umgeleitet auf eine Freigabe.

Ist "Alle Benutzereinsetllungen und-Daten" nicht die Standardeinstellung? Kann mich nicht mehr erinnern. Ich dachte das wäre so.

UPD Speicherort sollte natürlich idealerweise auf einem Cluster liegen. Aber die Gefahr dass ein Session Host crashed ist natürlich real.
Glücklicherweise bin ich bisher davon verschont geblieben.
​2012R2 scheint mir generell ein sehr stabiles System zu sein.