43

Like it now

Die RemoteApp-Technik von Microsoft ist mittlerweile auch schon altbewährt und wurde in den letzten Editionen immer ausgereifter, leider wurden aber auch gute Features (wie bspw. RemoteFX) wieder entfernt – Sicherheit geht vor. Aber unabhängig von dem Spezialthema mit der virtualisierten Grafikkarte bietet RemoteApp bzw. die gesamte RDS (= „Remote Desktop Services“) eine Bandbreite an nützlichen Features, um mit anderen Anbietern mitzuhalten.

Was benötigt man?

Nun, zum einen natürlich einen Windows Server (aktuell in der Version 2022) und die entsprechende Lizenz. Möchte man mehr als nur eine standalone „Out of the Box“-Umgebung, benötigt man schon zwei Maschinen (das darf logischerweise auch virtuell sein).
Zum anderen benötigt man die passende Anzahl an sog. „RDS-CALs“ (was eine „CAL“ ist, kann hier nachgelesen wesen: LINK), damit die Benutzer, die RemoteApp nutzen sollen auch entsprechend sauber lizenziert sind.

Die Unterschiede: „Standard Deployment“ vs. „Quick Start“

Bei der Installation auf dem ersten RDS-Server wird man beim Server-Manager direkt gefragt, wie man beginnen möchte:

• „Standard Deployment“
  Hier hat man direkt die Möglichkeit, alle notwendigen RDS-Rollen auf verschiedene Server zu verteilen und hat von Beginn an die volle Flexibilität.
• „Quick Start“
  Hier werden alle RDS-Rollen der Grundfunktion auf dem einen Server installiert. D.h. auf dem Host, auf dem dann die Anwender ihre Sitzung haben, ist auch die RDS-Konfiguration gespeichert.

Persönliche Meinung: Ich würde immer das Standard Deployment wählen und die Anwender auf den Sitzungshost verbinden lassen und somit getrennt von den Kern(-verwaltungs-)rollen der RDS-Umgebung halten.

Dennoch gehe ich hier auf beide Möglichkeiten ein:

Variante 1: Standalone bzw. „Quick Start“

Ich habe ein VM bereitgestellt mit „Windows Server 2022 Standard GUI“, welche 1 vCPU, bis zu 4GB vRAM und eine 30GB vDisk hat.
Nach der Grundinstallation mit dem Betriebssystem folgt die Vergabe der IP-Adresse, sowie des Hostnames („SVPWRD00-SOLO“) und die Aufnahme in die Domäne. Anschließend kann mithilfe des Server Managers die Installation der RDS-Rollen begonnen werden.

Hier als kurze Bildergalerie:

Variante 2: Flexible Farm bzw. „Standard Deployment“

Ich habe zwei VMs bereitgestellt:

1. SVPWRD01-RGW -> wird der erste Verwaltungsserver
2. SVPWRD10-SHAD -> wird der erste SessionHost

Beide VMs sind in der AD als Memberserver aufgenommen und haben als Ausstattung:

• vCPU: 1
• vRAM: 4GB dynamisch
• vDisk: 30GB
• vETH: 1x

Auf dem „SVPWRD01-RGW“ wird der Server-Manager als Administrator gestartet. Zuerst müssen alle beteiligte Server im Server-Manager hinzugefügt werden, anschließend kann mit der Installation der RDS-Rollen mit Hilfe des Rollen-Assistenten durchgeführt werden.

• Installation Type: Remote Desktop Services Installation
• Deployment Type: Standard deployment
• Deployment Scenario: Session-based desktop deployment

Anschließend werden nacheinander die zuständigen Server für die einzelnen Rollen ausgewählt:

• Rolle „RD Connection Broker“: Server „SVPWRD01-RGW“
• Rolle „RD Web Access“: Server „SVPWRD01-RGW“
• Rolle „RD Session Host“: Server „SVPWRD10-SHAD“

Nach Abschluss der Installation und des Neustarts wird dann noch direkt das „RD Gateway“ installiert; das kann mit auf den Server, der „RD Connection Broker“ und „RD Web Access“ ist. Alternativ kann man dafür auch einen eigenen Server nehmen – aber auf gar keinen Fall einen SessionHost!
Für das Gateway wird dann noch die Angabe eines externen DNS-Namens (also die URL, über die das Gateway erreichbar sein soll) benötigt.

Sofern im Netzwerk kein anderer Lizenzserver vorhanden ist, sollte der Vollständigkeit halber auch die Rolle „RD Licencing server“ installiert werden; das kann ebenfalls auf dem selben Server, wie die Rolle „RD Connection Broker“ sein.

Hier als kurze Bildergalerie:

---

Quelle des Beitragbildes: RDP-Header-600×259.png (600×259) (technipages.com)