10
Vor- und Nachteile Desktopbereitstellung vs. Remoteapps bei Session basiertem RDS-Server
Guten Abend liebe Kollegen,
ich bin gerade dabei mir Gedanken über einen Terminal - Server Design zu machen.
Dabei geht es mir aktuell in erster Linie um die Vor und Nachteile der Desktopbereitstellung gegenüber den Remotapps.
Es soll einen Broker geben der sich um die 3 Rollen (Broker, Webaccess, Lizenzserver) kümmert. Ein RD-Gateway ist soweit ich es verstanden habe für interne Zwecke nicht notwendig.
Da es 2 ESXi Server gibt, möchte ich zwei SessionHosts bereitstellen. Hier muss ich mich dann allerdings um die User Profile dann auch noch kümmern.
Terminalserver: 2012 R2
User: 20
Programme: Office 2013 Standard VL sowie ein paar Client / Server Anwendungen
Domäne: 2008 R2 historisch gewachsen auf einer 2003er.
Allgemeine Überlegungen
Desktopbereitstellung:
- Umstellung für die Benutzer, da diese jetzt 2 "Desktops" haben.
- Nicht alle Programme können auf dem Terminalserver installiert werden. Es gibt einige Programme die nur der eine oder andere User benutzt, die eigentlich nicht auf den Terminalserver sollen.
- Servermanager und Powershell können nur über Scripts entfernt werden
-pro: Benutzer-Profil-Datenträger sollten das Problem der Synchronisierung zwischen den beiden SessionHosts erschlagen
-pro: Klare Trennung zwischen Terminalserver und lokaler Arbeitsstation
RemoteApp über Webfeed.aspx:
-pro: Die Programme werden in das Windows System des Clients importiert, somit kaum Umstellung für die User.
-pro: Dateien lassen sich verlinken und somit ganz normal über Doppelklick starten.
- Soweit ich das gesehen habe, gibt es ziemliche Verwirrung bei "Speichern unter...", da hier der Desktop ein anderer Desktop ist, als der Desktop der lokalen Maschine. Außerdem werden standardmäßig alle Laufwerke der lokalen Maschine auf dem RDS-Server eingebunden. Hier benötigt man wohl einiges an GPOs um das sauber und klar strukturieren.
- Ich muss mit Ordnerumleitung oder ähnliches arbeiten um obiges Problem zu lösen.
- Drag & Drop scheint nicht zu funktionieren.
-- Beide varianten gleichzeitig zu verwenden wird vermutlich nicht sauber möglich sein?
--> Welche Vor & Nachteile gibt es noch zu beachten? Für welche variante habt ihr euch entschieden?
Umgang mit den User Profilen
- Remote Profile sind meiner Meinung nach nicht geeinigt wegen der "letzte gewinnt" on Logout. Außerdem werden ja die Profile immer komplett kopiert.
- User Profile Disks hören sich nicht schlecht an. Allerdings lösen diese nicht mein Problem bei der Bereitstellung über Weebfeed mit den unterschiedlichen Profilen nicht.
- Ordnerumleitung hört sich ganz brauchbar an, da hier keine Daten kopiert werden, sonder nur darauf zugegriffen wird. Ich frage mich ob es hier auch eine sinnvolle Kombination mit User Profile Disks geben kann.
- Work Folders hören sich recht interessant an, aber ob dies in Verbindung mit dem Terminalserver funktioniert? Hierfür benötige ich dann eben einen eigenen 2012er R2 Server.
--> Welche Variante ist hier die beste? Hat hier jemand schon Work Folders in Verbindung mit dem Terminal Server benutzt?
ich bin gerade dabei mir Gedanken über einen Terminal - Server Design zu machen.
Dabei geht es mir aktuell in erster Linie um die Vor und Nachteile der Desktopbereitstellung gegenüber den Remotapps.
Es soll einen Broker geben der sich um die 3 Rollen (Broker, Webaccess, Lizenzserver) kümmert. Ein RD-Gateway ist soweit ich es verstanden habe für interne Zwecke nicht notwendig.
Da es 2 ESXi Server gibt, möchte ich zwei SessionHosts bereitstellen. Hier muss ich mich dann allerdings um die User Profile dann auch noch kümmern.
Terminalserver: 2012 R2
User: 20
Programme: Office 2013 Standard VL sowie ein paar Client / Server Anwendungen
Domäne: 2008 R2 historisch gewachsen auf einer 2003er.
Allgemeine Überlegungen
Desktopbereitstellung:
- Umstellung für die Benutzer, da diese jetzt 2 "Desktops" haben.
- Nicht alle Programme können auf dem Terminalserver installiert werden. Es gibt einige Programme die nur der eine oder andere User benutzt, die eigentlich nicht auf den Terminalserver sollen.
- Servermanager und Powershell können nur über Scripts entfernt werden
-pro: Benutzer-Profil-Datenträger sollten das Problem der Synchronisierung zwischen den beiden SessionHosts erschlagen
-pro: Klare Trennung zwischen Terminalserver und lokaler Arbeitsstation
RemoteApp über Webfeed.aspx:
-pro: Die Programme werden in das Windows System des Clients importiert, somit kaum Umstellung für die User.
-pro: Dateien lassen sich verlinken und somit ganz normal über Doppelklick starten.
- Soweit ich das gesehen habe, gibt es ziemliche Verwirrung bei "Speichern unter...", da hier der Desktop ein anderer Desktop ist, als der Desktop der lokalen Maschine. Außerdem werden standardmäßig alle Laufwerke der lokalen Maschine auf dem RDS-Server eingebunden. Hier benötigt man wohl einiges an GPOs um das sauber und klar strukturieren.
- Ich muss mit Ordnerumleitung oder ähnliches arbeiten um obiges Problem zu lösen.
- Drag & Drop scheint nicht zu funktionieren.
-- Beide varianten gleichzeitig zu verwenden wird vermutlich nicht sauber möglich sein?
--> Welche Vor & Nachteile gibt es noch zu beachten? Für welche variante habt ihr euch entschieden?
Umgang mit den User Profilen
- Remote Profile sind meiner Meinung nach nicht geeinigt wegen der "letzte gewinnt" on Logout. Außerdem werden ja die Profile immer komplett kopiert.
- User Profile Disks hören sich nicht schlecht an. Allerdings lösen diese nicht mein Problem bei der Bereitstellung über Weebfeed mit den unterschiedlichen Profilen nicht.
- Ordnerumleitung hört sich ganz brauchbar an, da hier keine Daten kopiert werden, sonder nur darauf zugegriffen wird. Ich frage mich ob es hier auch eine sinnvolle Kombination mit User Profile Disks geben kann.
- Work Folders hören sich recht interessant an, aber ob dies in Verbindung mit dem Terminalserver funktioniert? Hierfür benötige ich dann eben einen eigenen 2012er R2 Server.
--> Welche Variante ist hier die beste? Hat hier jemand schon Work Folders in Verbindung mit dem Terminal Server benutzt?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 391942
Url: https://administrator.de/forum/vor-und-nachteile-desktopbereitstellung-vs-remoteapps-bei-session-basiertem-rds-server-391942.html
Ausgedruckt am: 22.04.2025 um 02:04 Uhr
10 Kommentare
Neuester Kommentar
Moin,
grundsätzlich liegt die Entscheidung bei Dir. Beides hat Vor- und Nachteile.
Das ist durchaus eine entscheidende Frage. Wie groß ist der Umfang der anderen Anwendungen, die noch auf dem TS laufen sollen?
Nein, haben sie dann nicht mehr. Wenn man das richtig macht, dann wird nach dem Systemstart gleich die Verbindung mit dem TS hergestellt und der User landet auf dessen Desktop. Langfristig werden die Maschinen gegen Thin Clients getauscht. Wenn Desktopbereitstellung, dann auch in der Regel alles.
Das spricht deutlich gegen diese Variante. Programme mal hier und mal da würde ich allenfalls versierten Powerusern zumuten. Normale User verwirrt das. Aber Du könntest das Problem mit entsprechenden Softwareeinschränkungen lösen, so dass nur diese User auf die entsprechenden Programme Zugriff haben.
Nein. Den Servermanager "entfernst" Du mit Hilfe einer Gruppenrichtlinie. Und warum um alles in der Welt willst Du den armen Usern die Powershell wegnehmen?
Damit habe ich eher schlechte Erfahrung gemacht und das klassisch mit Roaming Profiles gelöst.
Welchen Vorteil hat das?
Na, wenn Du Dich da mal nicht täuschst.
Das funktioniert auf dem bereitgestellten Desktop auch.
Genau das ist es, was die User vollständig verwirrt. Das lokale Datenlaufwerk D: heißt in der RD-Anwendung X:, der Drucker heißt anders usw. Ich habe jahrelang ein solches System geschult. Das war das Schwerste, den Leuten beizubringen, was in welcher Umgebung wie heißt und doch das Selbe ist.
Das musst Du so oder so.
Von wegen keine Umstellung für die User.
In derselben Bereitstellung ist es gar nicht möglich. Entweder oder. Wenn Du Dir das wirklich antun möchtest, beides parallel zu betreiben, brauchst Du zwei Bereitstellungen.
Wie schon oben gesagt: Die Entscheidung ist höchst individuell. Ich betreibe hier auf unseren Systemen die Desktop-Variante.
Ja und? Loggen sich die User mehrfach von verschiedenen Stationen aus gleichzeitig auf dem TS ein? Wenn ja, dann kann man diesen Usern das beibringen, wie sie sich bei Änderungen am Profil ausloggen müssen.
Das ist das Gleiche in grün. Auch bei der Variante gewinnt das letzte Logout.
Ordnerumleitung ist bei solchen Systemen Muss.
hth
Erik
grundsätzlich liegt die Entscheidung bei Dir. Beides hat Vor- und Nachteile.
Das ist durchaus eine entscheidende Frage. Wie groß ist der Umfang der anderen Anwendungen, die noch auf dem TS laufen sollen?
Allgemeine Überlegungen
Desktopbereitstellung:
- Umstellung für die Benutzer, da diese jetzt 2 "Desktops" haben.
Desktopbereitstellung:
- Umstellung für die Benutzer, da diese jetzt 2 "Desktops" haben.
Nein, haben sie dann nicht mehr. Wenn man das richtig macht, dann wird nach dem Systemstart gleich die Verbindung mit dem TS hergestellt und der User landet auf dessen Desktop. Langfristig werden die Maschinen gegen Thin Clients getauscht. Wenn Desktopbereitstellung, dann auch in der Regel alles.
- Nicht alle Programme können auf dem Terminalserver installiert werden. Es gibt einige Programme die nur der eine oder andere User benutzt, die eigentlich nicht auf den Terminalserver sollen.
Das spricht deutlich gegen diese Variante. Programme mal hier und mal da würde ich allenfalls versierten Powerusern zumuten. Normale User verwirrt das. Aber Du könntest das Problem mit entsprechenden Softwareeinschränkungen lösen, so dass nur diese User auf die entsprechenden Programme Zugriff haben.
- Servermanager und Powershell können nur über Scripts entfernt werden
Nein. Den Servermanager "entfernst" Du mit Hilfe einer Gruppenrichtlinie. Und warum um alles in der Welt willst Du den armen Usern die Powershell wegnehmen?
-pro: Benutzer-Profil-Datenträger sollten das Problem der Synchronisierung zwischen den beiden SessionHosts erschlagen
Damit habe ich eher schlechte Erfahrung gemacht und das klassisch mit Roaming Profiles gelöst.
-pro: Klare Trennung zwischen Terminalserver und lokaler Arbeitsstation
Welchen Vorteil hat das?
RemoteApp über Webfeed.aspx:
-pro: Die Programme werden in das Windows System des Clients importiert, somit kaum Umstellung für die User.
-pro: Die Programme werden in das Windows System des Clients importiert, somit kaum Umstellung für die User.
Na, wenn Du Dich da mal nicht täuschst.
-pro: Dateien lassen sich verlinken und somit ganz normal über Doppelklick starten.
Das funktioniert auf dem bereitgestellten Desktop auch.
- Soweit ich das gesehen habe, gibt es ziemliche Verwirrung bei "Speichern unter...", da hier der Desktop ein anderer Desktop ist, als der Desktop der lokalen Maschine. Außerdem werden standardmäßig alle Laufwerke der lokalen Maschine auf dem RDS-Server eingebunden. Hier benötigt man wohl einiges an GPOs um das sauber und klar strukturieren.
Genau das ist es, was die User vollständig verwirrt. Das lokale Datenlaufwerk D: heißt in der RD-Anwendung X:, der Drucker heißt anders usw. Ich habe jahrelang ein solches System geschult. Das war das Schwerste, den Leuten beizubringen, was in welcher Umgebung wie heißt und doch das Selbe ist.
- Ich muss mit Ordnerumleitung oder ähnliches arbeiten um obiges Problem zu lösen.
Das musst Du so oder so.
- Drag & Drop scheint nicht zu funktionieren.
Von wegen keine Umstellung für die User.
-- Beide varianten gleichzeitig zu verwenden wird vermutlich nicht sauber möglich sein?
In derselben Bereitstellung ist es gar nicht möglich. Entweder oder. Wenn Du Dir das wirklich antun möchtest, beides parallel zu betreiben, brauchst Du zwei Bereitstellungen.
--> Welche Vor & Nachteile gibt es noch zu beachten? Für welche variante habt ihr euch entschieden?
Wie schon oben gesagt: Die Entscheidung ist höchst individuell. Ich betreibe hier auf unseren Systemen die Desktop-Variante.
Umgang mit den User Profilen
- Remote Profile sind meiner Meinung nach nicht geeinigt wegen der "letzte gewinnt" on Logout. Außerdem werden ja die Profile immer komplett kopiert.
- Remote Profile sind meiner Meinung nach nicht geeinigt wegen der "letzte gewinnt" on Logout. Außerdem werden ja die Profile immer komplett kopiert.
Ja und? Loggen sich die User mehrfach von verschiedenen Stationen aus gleichzeitig auf dem TS ein? Wenn ja, dann kann man diesen Usern das beibringen, wie sie sich bei Änderungen am Profil ausloggen müssen.
- User Profile Disks hören sich nicht schlecht an. Allerdings lösen diese nicht mein Problem bei der Bereitstellung über Weebfeed mit den unterschiedlichen Profilen nicht.
Das ist das Gleiche in grün. Auch bei der Variante gewinnt das letzte Logout.
- Ordnerumleitung hört sich ganz brauchbar an, da hier keine Daten kopiert werden, sonder nur darauf zugegriffen wird. Ich frage mich ob es hier auch eine sinnvolle Kombination mit User Profile Disks geben kann.
Ordnerumleitung ist bei solchen Systemen Muss.
hth
Erik
Danke für deine Antwort.
Programme die auf den RDS-Server laufen sollen:
- Datenbankanwendung die über ODBC auf einen Server zugreift
- Ein weiterer Client der auf einen Server zu greift (Protokoll bin ich mir gar nicht sicher, die Software ist uralt, läuft aber auf dem Terminalserver).
- Telefonsoftware
- Office 2013 (sind aktuell alle gewöhnt), gekauft haben wir aber Office 2019
Programme die mir etwas sorgen machen:
- Banksoftware (nutzt nur eine Person)
- Diverse Fibu Programme ( nutzt nur eine Person)
- Software zur Bearbeitung der Zeit (nutzt auch nur eine Person)
- Lohnprogramm (nutzt auch nur eine Person).
--> Die Programme haben alle eine lokale Datenbank auf C:\ .
Was sowie nicht gehen wird:
- CAD Programm (3 Benutzer)
- Ich bin mir jetzt unschlüssig welche Richtung ich gehen soll. Ich habe die GF gefragt, die möchten von mir jetzt vor & nachteile aufgelistet... Bis auf die Vor / Nachteile die ich oben schon aufgelistet habe, fallen mir keine ein. Außerdem sind die "Nachteile" ja mehr oder weniger mit Aufwand in beiden fällen technisch lösbar.
Ich habe mich auf meinem Testsystem für die Ordnerumleitung jetzt entschieden. Beim Einloggen dauert es jetzt bei Richtline "Folder Redirection" wird übernommen, relativ lange. Kann man dem System hier Beine machen?
Programme die auf den RDS-Server laufen sollen:
- Datenbankanwendung die über ODBC auf einen Server zugreift
- Ein weiterer Client der auf einen Server zu greift (Protokoll bin ich mir gar nicht sicher, die Software ist uralt, läuft aber auf dem Terminalserver).
- Telefonsoftware
- Office 2013 (sind aktuell alle gewöhnt), gekauft haben wir aber Office 2019
Programme die mir etwas sorgen machen:
- Banksoftware (nutzt nur eine Person)
- Diverse Fibu Programme ( nutzt nur eine Person)
- Software zur Bearbeitung der Zeit (nutzt auch nur eine Person)
- Lohnprogramm (nutzt auch nur eine Person).
--> Die Programme haben alle eine lokale Datenbank auf C:\ .
Was sowie nicht gehen wird:
- CAD Programm (3 Benutzer)
- Ich bin mir jetzt unschlüssig welche Richtung ich gehen soll. Ich habe die GF gefragt, die möchten von mir jetzt vor & nachteile aufgelistet... Bis auf die Vor / Nachteile die ich oben schon aufgelistet habe, fallen mir keine ein. Außerdem sind die "Nachteile" ja mehr oder weniger mit Aufwand in beiden fällen technisch lösbar.
Ich habe mich auf meinem Testsystem für die Ordnerumleitung jetzt entschieden. Beim Einloggen dauert es jetzt bei Richtline "Folder Redirection" wird übernommen, relativ lange. Kann man dem System hier Beine machen?
Ich hab noch eine weitere Geschichte bei der Ordnerumleitung...
Kein User checkt, das es hier um den Desktop handelt. Irgendwie ist das alles nicht wie man es sich vorstellt:
Kein User checkt, das es hier um den Desktop handelt. Irgendwie ist das alles nicht wie man es sich vorstellt:
Moin,
Gruß,
Dani
Es soll einen Broker geben der sich um die 3 Rollen (Broker, Webaccess, Lizenzserver) kümmert. Ein RD-Gateway ist soweit ich es verstanden habe für interne Zwecke nicht notwendig.
Das RD Gateway ist vorallem dafür da, um nicht unnötig Löcher in die Firewalls reißen zu müssen. Zudem wird der gesammte Datenverkehr über HTTPS (Port 443) verschlüsselt. Was natürlich heute auch im LAN immer öfters gefordert wird.Nicht alle Programme können auf dem Terminalserver installiert werden. Es gibt einige Programme die nur der eine oder andere User benutzt, die eigentlich nicht auf den Terminalserver sollen.
Technisch werden die Programm wahrscheinlich auf dem RDS-Host laufen. Aber wie so oft wird die Lizenzierung ein Problem werden. Leider sind viele Hersteller inzwischen eigen und kleinlich.Servermanager und Powershell können nur über Scripts entfernt werden
Bitte nie, nie, nie entfernen. Solche Dinge lassen sich per Gruppenrichtlinien für Benutzer sperren.Benutzer-Profil-Datenträger sollten das Problem der Synchronisierung zwischen den beiden SessionHosts erschlagen
Du meinst User Profil Disks. Leider sind diese nur in Verbindung mit Collections (Sammlungen) und somit RemoteApps nutzen.Soweit ich das gesehen habe, gibt es ziemliche Verwirrung bei "Speichern unter...", da hier der Desktop ein anderer Desktop ist, als der Desktop der lokalen Maschine.
Logisch, oder? Du hast zwei Sitzungen auf verschiedenen Geräten.Ich muss mit Ordnerumleitung oder ähnliches arbeiten um obiges Problem zu lösen.
Versteh ich nicht. Warum muss ein Desktop umgeleitet werden? Dort werden auf einem RDS-Hosts keinerlei Daten abgelegt. Außerdem werden standardmäßig alle Laufwerke der lokalen Maschine auf dem RDS-Server eingebunden. Hier benötigt man wohl einiges an GPOs um das sauber und klar strukturieren.
Wir steuren per Gruppenrichtlinie z.B. dass die Netzlaufwerke im lokalen Client umgeleitet werden in die Sitzung und dafür dort keine Netzlaufwerke eingebunden werden.Remote Profile sind meiner Meinung nach nicht geeinigt wegen der "letzte gewinnt" on Logout.
Du kannst in den Eigenschaften der Benutzeri im Active Directory einen separaten Speicherplatz für RDS-Profile angeben. Somit sind diese sauber getrennt von den Profilen an den Arbeitsplätzen.Außerdem werden ja die Profile immer komplett kopiert.
Bei der ersten Anmeldung am RDS-Hosts wird ein neues Profil erzeugt - klar. Bei der Anmeldung wird dieses dann auch den definierten Pfad zurückgeschrieben. Meldet sich der Benutzer wieder an, werden die Änderungen zwischen servergespeicherten RDS und lokalen Profil übertragen. Das selbe in andere Richtung bei Abmeldung.User Profile Disks hören sich nicht schlecht an.
Wie gesagt funktioniert nur bei Verwendung von Collections.Allerdings lösen diese nicht mein Problem bei der Bereitstellung über Weebfeed mit den unterschiedlichen Profilen nicht.
Versteh ich nicht.Work Folders hören sich recht interessant an, aber ob dies in Verbindung mit dem Terminalserver funktioniert? Hierfür benötige ich dann eben einen eigenen 2012er R2 Server.
Den Gedankengang musst du mir erklären. Was hat Workfloders mit RDS-Hosts zu tun? Wobei zu beachten ist, dass du dafür unbedingt einen Windows Server 2012R2 Standard oder höher als Dateiserver haben musst.Gruß,
Dani
Hallo Dani, Danke für deine Antwort.
Wenn ich RemoteApps breitstellen möchte, dann macht in meinen Augen nur die Ordnerumleitung sinn.
- Alle Standardordner werden umgeleitet
- Der Zugriff auf C wird auf dem Terminalserver gesperrt + ausgeblendet
--> Wenn ich jetzt Word öffne (wird auf dem Terminal Server ausgeführt) und die Datei auf dem Desktop speichere, dann wird die Datei im umgeleiteten Ordner abgelegt. Also ist diese auch auf dem ThinClient auf dem Desktop zu finden.
--> Die lokalen Laufwerke lasse ich nicht an den Terminalserver übergeben. Ein Otto normal User checkt "C auf THIN-CLIENT01" nicht.
--> Jeder Benutzer hat sein persönliches Netzlaufwerk. Dieses wird auch beim Terminalserver übergeben. Hier soll der Benutzer seine Dateien idealerweise ablegen.
Die zweite Möglichkeit ist jetzt mit dem Terminal Server einen 2012R2 Desktop bereit zu stellen. D.h. der User connectet über mstsc zum Server und erhält einen Desktop.
- Hier kann man jetzt die User-Profil-Disks verwenden (zumindest wenn ich 2 Session Hosts benötige), oder man verwendet die von dir genannte Speicherplatz Methode für RDS-Profile in der AD. Das Resultat ist das gleiche.
-Alternativ kann aber auch die Ordnerumleitung verwendet werden. Es ist es natürlich komisch, wenn man den Desktop umleitet und die Dateien vom 2012R2 Server Desktop, auch auf dem Desktop, bzw. in den umgeleiteten Ordnern vom ThinClient landen.
Beide Möglichkeiten, also die Verteilung über Remoteapps und Desktopbereitstellung geht mit einer Collection nur mit der Ordnerumleitung.
Wenn ich RemoteApps breitstellen möchte, dann macht in meinen Augen nur die Ordnerumleitung sinn.
- Alle Standardordner werden umgeleitet
- Der Zugriff auf C wird auf dem Terminalserver gesperrt + ausgeblendet
--> Wenn ich jetzt Word öffne (wird auf dem Terminal Server ausgeführt) und die Datei auf dem Desktop speichere, dann wird die Datei im umgeleiteten Ordner abgelegt. Also ist diese auch auf dem ThinClient auf dem Desktop zu finden.
--> Die lokalen Laufwerke lasse ich nicht an den Terminalserver übergeben. Ein Otto normal User checkt "C auf THIN-CLIENT01" nicht.
--> Jeder Benutzer hat sein persönliches Netzlaufwerk. Dieses wird auch beim Terminalserver übergeben. Hier soll der Benutzer seine Dateien idealerweise ablegen.
Die zweite Möglichkeit ist jetzt mit dem Terminal Server einen 2012R2 Desktop bereit zu stellen. D.h. der User connectet über mstsc zum Server und erhält einen Desktop.
- Hier kann man jetzt die User-Profil-Disks verwenden (zumindest wenn ich 2 Session Hosts benötige), oder man verwendet die von dir genannte Speicherplatz Methode für RDS-Profile in der AD. Das Resultat ist das gleiche.
-Alternativ kann aber auch die Ordnerumleitung verwendet werden. Es ist es natürlich komisch, wenn man den Desktop umleitet und die Dateien vom 2012R2 Server Desktop, auch auf dem Desktop, bzw. in den umgeleiteten Ordnern vom ThinClient landen.
Beide Möglichkeiten, also die Verteilung über Remoteapps und Desktopbereitstellung geht mit einer Collection nur mit der Ordnerumleitung.
Moin,
Wo hast du das gelesen? UPDs in Verbindung mit Session Based Desktops kann man nach wie vor nicht konfigurieren.
Gruß,
Dani
Wenn ich jetzt Word öffne (wird auf dem Terminal Server ausgeführt) und die Datei auf dem Desktop speichere, dann wird die Datei im umgeleiteten Ordner abgelegt. Also ist diese auch auf dem ThinClient auf dem Desktop zu finden.
Warum verbietet (technisch als auch organisatorisch) du einfach nicht das Speichern auf dem Desktop? Das ist eine reine Erzierhungsmaßnahme.Die zweite Möglichkeit ist jetzt mit dem Terminal Server einen 2012R2 Desktop bereit zu stellen. D.h. der User connectet über mstsc zum Server und erhält einen Desktop.
- Hier kann man jetzt die User-Profil-Disks verwenden (zumindest wenn ich 2 Session Hosts benötige),Wo hast du das gelesen? UPDs in Verbindung mit Session Based Desktops kann man nach wie vor nicht konfigurieren.
--> Die lokalen Laufwerke lasse ich nicht an den Terminalserver übergeben. Ein Otto normal User checkt "C auf THIN-CLIENT01" nicht.
Bitte richtig lesen. Ich habe geschrieben, dass wir die Netzlaufwerke umleiten. Von lokalen Laufwerken war nicht die Rede. Beide Möglichkeiten, also die Verteilung über Remoteapps und Desktopbereitstellung geht mit einer Collection nur mit der Ordnerumleitung.
Grübel... was willst du uns mit dem Satz sagen?Gruß,
Dani
Wo hast du das gelesen? UPDs in Verbindung mit Session Based Desktops kann man nach wie vor nicht konfigurieren.
Warum soll das nicht gehen? Ich kann das auf dem Broker ganz normal aktivieren...
Beide Möglichkeiten, also die Verteilung über Remoteapps und Desktopbereitstellung geht mit einer Collection nur mit der Ordnerumleitung.
Grübel... was willst du uns mit dem Satz sagen?Ich würde gerne den Benutzern die einen sehr Leistungsstarken PC haben (CAD-User) die Apps als "Remoteapps" über Webfeed verteilen und den anderen Benutzern die nur Standardprogramme benutzen einen Desktop bereit stellen.
Warum verbietet (technisch als auch organisatorisch) du einfach nicht das Speichern auf dem Desktop? Das ist eine reine Erzierhungsmaßnahme.
Das gilt aber dann für alle Ordner (Dokumente, Musik...). Außerdem sind es die User gewöhnt. Du kennst unsere User nicht... ;)
Was spricht denn gegen die Ordnerumleitung? Gibt es Probleme wenn man die Ordner vom Client in den gleichen Ordner wie die des Terminalservers umleitet?
Moin,
Gerne.
Programme die auf den RDS-Server laufen sollen:
- Datenbankanwendung die über ODBC auf einen Server zugreift
Kein Problem.
Wahrscheinlich auch kein Problem.
Kein Problem.
Sowieso kein Problem.
Ist das dieselbe Person? Dann kann man ihr wahrscheinlich beibringen, dass diese Programme in einer anderen Umgebung laufen. Wir haben für unsere Buchhaltung z. B. eigene TS.
Eine andere Möglichkeit wäre, diese Programme per GPO (Softwareeinschränkung o. ä.) auf eine Gruppe zu beschränken. Das hätte den Vorteil, dass, wenn mal eine zweite Person dazu kommt, man diese einfach nur freischalten muss.
Das sollte auch kein Problem sein. Den Pfad würde ich aber, sofern möglich, anpassen.
Kommt darauf an, wieviel Hardware man draufwirft.
Das will auch gut überlegt sein. Nicht umsonst gibt es beide Möglichkeiten. Ein Vorteil der App-Bereitstellung wäre übrigens noch, dass im Falle des Ausfalls des TS zumindest noch ein Notbetrieb lokal möglich wäre.
Immer oder nur beim ersten Login? Ansonsten: Schnellere Hardware.
Liebe Grüße
Erik
Gerne.
Programme die auf den RDS-Server laufen sollen:
- Datenbankanwendung die über ODBC auf einen Server zugreift
Kein Problem.
- Ein weiterer Client der auf einen Server zu greift (Protokoll bin ich mir gar nicht sicher, die Software ist uralt, läuft aber auf dem Terminalserver).
Wahrscheinlich auch kein Problem.
- Telefonsoftware
Kein Problem.
- Office 2013 (sind aktuell alle gewöhnt), gekauft haben wir aber Office 2019
Sowieso kein Problem.
Programme die mir etwas sorgen machen:
- Banksoftware (nutzt nur eine Person)
- Diverse Fibu Programme ( nutzt nur eine Person)
- Software zur Bearbeitung der Zeit (nutzt auch nur eine Person)
- Lohnprogramm (nutzt auch nur eine Person).
- Banksoftware (nutzt nur eine Person)
- Diverse Fibu Programme ( nutzt nur eine Person)
- Software zur Bearbeitung der Zeit (nutzt auch nur eine Person)
- Lohnprogramm (nutzt auch nur eine Person).
Ist das dieselbe Person? Dann kann man ihr wahrscheinlich beibringen, dass diese Programme in einer anderen Umgebung laufen. Wir haben für unsere Buchhaltung z. B. eigene TS.
Eine andere Möglichkeit wäre, diese Programme per GPO (Softwareeinschränkung o. ä.) auf eine Gruppe zu beschränken. Das hätte den Vorteil, dass, wenn mal eine zweite Person dazu kommt, man diese einfach nur freischalten muss.
--> Die Programme haben alle eine lokale Datenbank auf C:\ .
Das sollte auch kein Problem sein. Den Pfad würde ich aber, sofern möglich, anpassen.
Was sowie nicht gehen wird:
- CAD Programm (3 Benutzer)
- CAD Programm (3 Benutzer)
Kommt darauf an, wieviel Hardware man draufwirft.
- Ich bin mir jetzt unschlüssig welche Richtung ich gehen soll. Ich habe die GF gefragt, die möchten von mir jetzt vor & nachteile aufgelistet... Bis auf die Vor / Nachteile die ich oben schon aufgelistet habe, fallen mir keine ein. Außerdem sind die "Nachteile" ja mehr oder weniger mit Aufwand in beiden fällen technisch lösbar.
Das will auch gut überlegt sein. Nicht umsonst gibt es beide Möglichkeiten. Ein Vorteil der App-Bereitstellung wäre übrigens noch, dass im Falle des Ausfalls des TS zumindest noch ein Notbetrieb lokal möglich wäre.
Ich habe mich auf meinem Testsystem für die Ordnerumleitung jetzt entschieden. Beim Einloggen dauert es jetzt bei Richtline "Folder Redirection" wird übernommen, relativ lange. Kann man dem System hier Beine machen?
Immer oder nur beim ersten Login? Ansonsten: Schnellere Hardware.
Liebe Grüße
Erik
Moin,
Gruß,
Dani
Warum soll das nicht gehen? Ich kann das auf dem Broker ganz normal aktivieren...
kannst du dazu einen Screenshot posten? Ich glaube nämlich wir reden nicht vom Selben.Ich würde gerne den Benutzern die einen sehr Leistungsstarken PC haben (CAD-User) die Apps als "Remoteapps" über Webfeed verteilen und den anderen Benutzern die nur Standardprogramme benutzen einen Desktop bereit stellen.
Grundsätzlich gute Ieee. Ich bin mir nicht sicher, ob Collection und Session Based Desktop mit eim und den selben RDS-Host funktioniert. Das gilt aber dann für alle Ordner (Dokumente, Musik...). Außerdem sind es die User gewöhnt. Du kennst unsere User nicht... ;)
Sorry, aber wer hat die Hosen bei euch an - die Anwender oder die IT? Das ist alles eine Erziehungsmaßnahme.Gruß,
Dani
Danke für eure Antworten.
Im Anhang der Screenshot...
Naja schnellere Hardware. Wir haben 2x HP G9 mit 256gb Ram. Viel mehr für die paar User...
Ist aber nur beim ersten Logon so langsam.
Die Überlegung geht jetzt hin zu 2 Collections mit je einem SessionHost. Die eine Collection soll RemoteApps bereitstellen, die andere Collection soll einen kompletten Desktop bereitstellen.
Es gibt dann zwei unterschiedliche Sicherheitsgruppen. Für die Sicherheitsgruppe RDS-Apps wird dann auch auf dem lokalen Rechner alle Benutzerordner umgeleitet. Die Gruppe RDS-Desktop benötigt das nicht.
Ansonsten werden die beiden Sessionhosts ziemlich gleich behandelt.
Im Anhang der Screenshot...
Naja schnellere Hardware. Wir haben 2x HP G9 mit 256gb Ram. Viel mehr für die paar User...
Ist aber nur beim ersten Logon so langsam.
Die Überlegung geht jetzt hin zu 2 Collections mit je einem SessionHost. Die eine Collection soll RemoteApps bereitstellen, die andere Collection soll einen kompletten Desktop bereitstellen.
Es gibt dann zwei unterschiedliche Sicherheitsgruppen. Für die Sicherheitsgruppe RDS-Apps wird dann auch auf dem lokalen Rechner alle Benutzerordner umgeleitet. Die Gruppe RDS-Desktop benötigt das nicht.
Ansonsten werden die beiden Sessionhosts ziemlich gleich behandelt.
