8
Terminalserverfarm, nur eine Sitzung erlauben. Vor-Nachteile?
Hallo,
wir arbeiten seit vielen Jahren (seit Windows Server 2003) mit Terminalservern. Im Moment bereiten wir gerade den Umstieg auf Server 2019 vor.
Bisher waren bei uns mehrere Sitzungen eines Users erlaubt.
Damit ist ein "Mitnehmen" der eigenen Sitzung nur möglich, wenn man sie vorher trennt. Gibt es keine getrennte Sitzung, wird eine neue erstellt.
Ist dagegen nur eine Sitzung pro User erlaubt, wird die Sitzung immer mitgenommen. Ein großer Vorteil, wie ich finde.
Nun haben wir aber auch relativ viele Bereiche, die sind mit einem Abteilungsuser an mehreren PC's angemeldet. An diesen PC's arbeiten sie dann mit einer Software, an der sich jeder User individuell anmeldet.
Eine individuelle Windowsanmeldung wird in diesen Bereichen schwer vermittel- und umsetzbar sein.
Im Moment tendieren wir dazu, mit mehreren Abteilungsusern zu arbeiten, also abteilung1_a, abteilung1_b usw., für jeden PC ein User.
Entschieden ist das aber noch nicht.
Ein weiterer Grund, von Mehrfachanmeldung wegzukommen, ist der zukünftige Einsatz von FSLogix und somit User Profil Disks.
Mehrfachanmeldung sind zwar mittels differencing vhdx auch möglich, das möchte ich aber möglichst vermeiden, erscheint mir zu fehleranfällig.
Mich würde interessieren, was man noch als Vor-/Nachteile für "nur eine Sitzung pro User" bzw. "mehrere Sitzungen pro User" anbringen könnte.
Danke
Gruß
Martin
wir arbeiten seit vielen Jahren (seit Windows Server 2003) mit Terminalservern. Im Moment bereiten wir gerade den Umstieg auf Server 2019 vor.
Bisher waren bei uns mehrere Sitzungen eines Users erlaubt.
Damit ist ein "Mitnehmen" der eigenen Sitzung nur möglich, wenn man sie vorher trennt. Gibt es keine getrennte Sitzung, wird eine neue erstellt.
Ist dagegen nur eine Sitzung pro User erlaubt, wird die Sitzung immer mitgenommen. Ein großer Vorteil, wie ich finde.
Nun haben wir aber auch relativ viele Bereiche, die sind mit einem Abteilungsuser an mehreren PC's angemeldet. An diesen PC's arbeiten sie dann mit einer Software, an der sich jeder User individuell anmeldet.
Eine individuelle Windowsanmeldung wird in diesen Bereichen schwer vermittel- und umsetzbar sein.
Im Moment tendieren wir dazu, mit mehreren Abteilungsusern zu arbeiten, also abteilung1_a, abteilung1_b usw., für jeden PC ein User.
Entschieden ist das aber noch nicht.
Ein weiterer Grund, von Mehrfachanmeldung wegzukommen, ist der zukünftige Einsatz von FSLogix und somit User Profil Disks.
Mehrfachanmeldung sind zwar mittels differencing vhdx auch möglich, das möchte ich aber möglichst vermeiden, erscheint mir zu fehleranfällig.
Mich würde interessieren, was man noch als Vor-/Nachteile für "nur eine Sitzung pro User" bzw. "mehrere Sitzungen pro User" anbringen könnte.
Danke
Gruß
Martin
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: 1287623598
Url: https://administrator.de/forum/terminalserverfarm-nur-eine-sitzung-erlauben-vor-nachteile-1287623598.html
Ausgedruckt am: 26.12.2024 um 20:12 Uhr
8 Kommentare
Neuester Kommentar
Bei FSLogix wird aber die 2te Sitzung dann mit einer temporären RW.VHDX angemeldet und diese beim Abmelden gelöscht und nicht mit der eigentlichen VHDX verschmolzen. So habe ich das unter 2012 R2 getestet, oder ist mir was entgangen?
Hallo,
folgendes Verhalten kann unter bestimmten Bedingungen zu einem Problem werden:
Innerhalb der Benutzersitzung wird beim Starten der Sitzung eine Umgebungsvariable CLIENTNAME erstellt. Diese wird nicht geändert, wenn die Sitzung ohne Beenden auf einem anderen PC übernommen wird.
Beispiel:
Wir haben hier eine lustige Software, die die Variable CLIENTNAME nutzt, um arbeitsstationsbezogene Einstellungen zuzuweisen. Die bekommt den Wechsel nicht mit und dann funktionieren einige Formulareinstellungen beim Ausdrucken nicht...
Grüße
lcer
folgendes Verhalten kann unter bestimmten Bedingungen zu einem Problem werden:
Innerhalb der Benutzersitzung wird beim Starten der Sitzung eine Umgebungsvariable CLIENTNAME erstellt. Diese wird nicht geändert, wenn die Sitzung ohne Beenden auf einem anderen PC übernommen wird.
Beispiel:
- RDP-Verbindung von RDPCLIENTPC1 auf RDPSERVER:
C:\Users\rdpuser>set
...
CLIENTNAME=RDPCLIENTPC1
...
COMPUTERNAME=RDPSERVER- Der Benutzer wechselt den PC und stellt eine RDP-Verbindung von RDPCLIENTPC2 auf RDPSERVER her, ohne vorher die Sitzung zu beenden. Die alte Sitzung wird übernommen. Die Umgebungsvariable ändert sich nicht.
C:\Users\rdpuser>set
...
CLIENTNAME=RDPCLIENTPC1
...
COMPUTERNAME=RDPSERVERWir haben hier eine lustige Software, die die Variable CLIENTNAME nutzt, um arbeitsstationsbezogene Einstellungen zuzuweisen. Die bekommt den Wechsel nicht mit und dann funktionieren einige Formulareinstellungen beim Ausdrucken nicht...
Grüße
lcer
Moin,
wir haben das mit einigen Kollegen schonmal durchdiskutiert und sind inhaltlich zu dem Ergebnis gekommen, dass in den meisten Fällen eine Sitzung, die übernommen wird, ausreichend ist. Zum einen um technische Probleme zu vermeiden (Diff VDHX Discs,...). Zum anderen: Warum sollte das überhaupt notwendig sein? Es gibt, zumindest hier, wenig bis keine Fälle, warum der Benutzer nicht seine Sitzung fortführen können sollte. Eher das Gegenteil.
Einzige Ausnahme ist, dass es dedizierte Workstations mit Peripherie oder bestimmter Verortung gibt, wo nur bestimmte Aufgaben durchgeführt werden dürfen. Sonst nicht.
VG
wir haben das mit einigen Kollegen schonmal durchdiskutiert und sind inhaltlich zu dem Ergebnis gekommen, dass in den meisten Fällen eine Sitzung, die übernommen wird, ausreichend ist. Zum einen um technische Probleme zu vermeiden (Diff VDHX Discs,...). Zum anderen: Warum sollte das überhaupt notwendig sein? Es gibt, zumindest hier, wenig bis keine Fälle, warum der Benutzer nicht seine Sitzung fortführen können sollte. Eher das Gegenteil.
Einzige Ausnahme ist, dass es dedizierte Workstations mit Peripherie oder bestimmter Verortung gibt, wo nur bestimmte Aufgaben durchgeführt werden dürfen. Sonst nicht.
VG
Moin,
Schlechte Idee.
Richtig.
Die Auseinandersetzung hatte ich auch in einer Einheit, die ich übernommen habe. Geteilte Userkonten sind ein NoGo. Allein schon deshalb, weil man dann jedes Mal, wenn ein Mitarbeiter die Firma verlässt, das Passwort ändern muss. Die Auseinandersetzung lief so:
Ich: "Ab sofort kriegt jeder User einen persönlichen Zugang."
Stationsleiter: "So kann ich nicht arbeiten."
Ich: "Dann müssen Sie kündigen."
Ich habe dann noch auf die IT-Richtlinien verwiesen auch gegenüber der Einrichtungsleitung, dass das, was ich sage, in dem Fall einfach Gesetz ist, und klar gemacht, dass ich darüber auch nicht diskutiere. Noch ein kurzer Anruf beim Datenschutzbeauftragten, der natürlich vorher von mir davon in Kenntnis gesetzt wurde, und die Sache war erledigt. Sowas setzt man nicht um, sondern durch.
my 2 cents
Liebe Grüße
Erik
Schlechte Idee.
Ist dagegen nur eine Sitzung pro User erlaubt, wird die Sitzung immer mitgenommen. Ein großer Vorteil, wie ich finde.
Richtig.
Nun haben wir aber auch relativ viele Bereiche, die sind mit einem Abteilungsuser an mehreren PC's angemeldet. An diesen PC's arbeiten sie dann mit einer Software, an der sich jeder User individuell anmeldet.
Eine individuelle Windowsanmeldung wird in diesen Bereichen schwer vermittel- und umsetzbar sein.
Eine individuelle Windowsanmeldung wird in diesen Bereichen schwer vermittel- und umsetzbar sein.
Die Auseinandersetzung hatte ich auch in einer Einheit, die ich übernommen habe. Geteilte Userkonten sind ein NoGo. Allein schon deshalb, weil man dann jedes Mal, wenn ein Mitarbeiter die Firma verlässt, das Passwort ändern muss. Die Auseinandersetzung lief so:
Ich: "Ab sofort kriegt jeder User einen persönlichen Zugang."
Stationsleiter: "So kann ich nicht arbeiten."
Ich: "Dann müssen Sie kündigen."
Ich habe dann noch auf die IT-Richtlinien verwiesen auch gegenüber der Einrichtungsleitung, dass das, was ich sage, in dem Fall einfach Gesetz ist, und klar gemacht, dass ich darüber auch nicht diskutiere. Noch ein kurzer Anruf beim Datenschutzbeauftragten, der natürlich vorher von mir davon in Kenntnis gesetzt wurde, und die Sache war erledigt. Sowas setzt man nicht um, sondern durch.
my 2 cents
Liebe Grüße
Erik
1
@ukulele-7
@eriko
Suchst du evtl. eine neue Herausforderung? So einen wie dich suchen wir zur Zeit für unser Projekt Team.
@AlbertMinrich
Gruß,
Dani
Bei FSLogix wird aber die 2te Sitzung dann mit einer temporären RW.VHDX angemeldet und diese beim Abmelden gelöscht und nicht mit der eigentlichen VHDX verschmolzen. So habe ich das unter 2012 R2 getestet, oder ist mir was entgangen?
Ja, ist dir. Es ist problemlos möglich die Profile zu mergen.@eriko
Suchst du evtl. eine neue Herausforderung? So einen wie dich suchen wir zur Zeit für unser Projekt Team.
@AlbertMinrich
Nun haben wir aber auch relativ viele Bereiche, die sind mit einem Abteilungsuser an mehreren PC's angemeldet. An diesen PC's arbeiten sie dann mit einer Software, an der sich jeder User individuell anmeldet.
Diese Fälle haben wir bei uns natürlich auch. Für diese Endgeräte gibt es einen gleichnamige Benutzer. Somit gehe wir, trotz dem Einsatz von FSLogix, dem technischen Problem aus dem Weg. An den Rechnern geht nichts außer die RDP Verbindung zum RD Gateway.Gruß,
Dani
Zitat von @Dani:
@ukulele-7
Dann muss ich mir das wohl nochmal anschauen wenn ich auf 2019 / 2022 migriere. Am meisten stört mich daran aber das die Temp-RW.VHDX dann auf dem jeweiligen RD-SH liegt, auf dem die Sitzung angemeldet wurde.@ukulele-7
Bei FSLogix wird aber die 2te Sitzung dann mit einer temporären RW.VHDX angemeldet und diese beim Abmelden gelöscht und nicht mit der eigentlichen VHDX verschmolzen. So habe ich das unter 2012 R2 getestet, oder ist mir was entgangen?
Ja, ist dir. Es ist problemlos möglich die Profile zu mergen.
Danke für die Antworten.
Aber das
kann doch nur funktionieren, wenn beide Sitzungen auf dem gleichen Terminalserver waren.
Dann gibt's nur eine vhdx, in die beide Sitzungen schreiben.
Hab ich eben getestet.
Bei Sitzungen auf unterschiedlichen Terminalservern landet nach Abmeldung aller Sitzungen, egal in welcher Reihenfolge, nur das in der vhdx, das in der zuerst gestarteten Sitzung gemacht wurde.
Auch gerade getestet, mit Windows Server 2019.
Gruß
Martin
Aber das
Zitat von @Dani:
@ukulele-7
@ukulele-7
Bei FSLogix wird aber die 2te Sitzung dann mit einer temporären RW.VHDX angemeldet und diese beim Abmelden gelöscht und nicht mit der eigentlichen VHDX verschmolzen. So habe ich das unter 2012 R2 getestet, oder ist mir was entgangen?
Ja, ist dir. Es ist problemlos möglich die Profile zu mergen.kann doch nur funktionieren, wenn beide Sitzungen auf dem gleichen Terminalserver waren.
Dann gibt's nur eine vhdx, in die beide Sitzungen schreiben.
Hab ich eben getestet.
Bei Sitzungen auf unterschiedlichen Terminalservern landet nach Abmeldung aller Sitzungen, egal in welcher Reihenfolge, nur das in der vhdx, das in der zuerst gestarteten Sitzung gemacht wurde.
Auch gerade getestet, mit Windows Server 2019.
Gruß
Martin
Moin,
Gruß,
Dani
kann doch nur funktionieren, wenn beide Sitzungen auf dem gleichen Terminalserver waren.
meines Wissens nach nicht. Hab ich eben getestet.
In Kombination mit FSLogix und dem richtigen Modus?Gruß,
Dani
