Anfang des Jahres hat Microsoft ohne viel Trara einen HTML5-Client für RDS herausgebracht. Ich habe mir das Ding angeschaut und war vom ersten Test ziemlich begeistert. Besonderheiten der neuen Komponente in Kürze:
- einsetzbar nur für eine komplette RDS-Bereitstellung, nicht für den Zugriff auf einzelne Server
- ist fest verheiratet mit RDWeb (und ersetzt ihn, wenn man den Webclient produktiv veröffentlicht)
- erfordert zwingend den RD Gateway (und somit SSL-Zertifikate, denen ohne Wenn und Aber vertraut wird)
- Drucker- und Zwischenablagenumleitung werden unterstützt, Laufwerke und SmartCard (noch) nicht, von anderer Peripherie ganz zu schweigen
- Die RDS-Infrastruktur – Broker, RDWeb und Gateway – muss auf Server 2016 oder 2019 laufen (Worker können aus der 2012R2-Generation sein)
- RDSCALs müssen per User vergeben werden (Device CALs würden sonst sehr schnell verbraucht werden)
- Nach der offiziellen Guidance (https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin) muss jeder RDWeb-Server zum Zeitpunkt der Installation Zugang zum Internet, d.h. zur PowerShell Gallery, haben.
Da ich kein großer Freund von Previews bin, habe ich die Testumgebung mit Server 2016 aufgebaut. Deshalb muss ich auf meinem RDWeb-Server zunächst einmal das NuGet-Modul updaten:
Danach muss die PowerShell geschlossen und neu gestartet werden. So auf die neueste NuGet-Version gebracht, kann das Management-Modul für den Web Client installiert werden:
Das Modul exportiert 12 Cmdlets mit vielversprechender Funktionalität:
Schauen wir mal, was Find-RDWebClientPackage so findet… Das sieht vielversprechend aus:
Doch was ist das? Bereits durch dieses „Finden“ wurde der Ordner „C:\Program Files\RemoteDesktopWeb“ erzeugt, mit einem Ordner „Internal“, auf den ich gar keine Rechte habe! OK, „Deny Everyone Read“ ist ein bisschen plump, aber Internal ist Internal. Drin sind drei Ordner: „Clients“, „Config“ und „Temp“. Alle drei sind noch leer bis auf die „Config\deploymentSettings.js“, die folgenden Inhalt hat:
Echt jetzt? Es wird also früh vorgesorgt, dass die Telemetrie schön an ist. Weiter im Text. Sowohl Get-RDWebClientPackage als auch Install-RDWebClientPackage haben keinen Parameter, mit dem man einen lokalen Speicherort angeben kann, meine RDWeb-Server brauchen also wirklich Zugang zum Internet, damit ich den Web Client installiert bekomme. Im Moment hat mein RDWeb-Server Internet, also installiere ich:
(das ausgepackte Archiv aus dem Internet liegt nun unter „C:\Program Files\RemoteDesktopWeb\Internal\Clients\4csqnmex.0iv“…)
(das Zertifikat wurde nach „C:\Program Files\RemoteDesktopWeb\Internal\Config\brokercert.cer“ kopiert…)
Das war’s! Bereits im IE11 bekomme ich unter https://F.Q.D.N/RDWeb/webclient-test eine moderne Oberfläche angezeigt, verbunden mit dem Hinweis, dass Audio nicht geht: OK, IE11 ist nicht gerade ein HTML5-fähiger Browser…
In Chrome sieht es schon ganz anders aus:
Soweit, so gut. Sieht richtig gut aus, und die Performance haben die RDSGURUS ja auch positiv getestet. Schauen wir mal, was man so einstellen kann, denn oben rechts ist ja ein Zahnrad:
Na, da hat es sich ja richtig gelohnt, einen Dialog dafür zu basteln.
Freunde, diese Telemetrie-Einstellung ist gar nicht so harmlos wie sie aussieht. Wenn ich nämlich die Telemetrie anlasse und der Testumgebung den Internet-Zugang wegnehme, so startet der Web-Client gar nicht erst!
Hmm, das ist nicht schön. Zum Glück betrifft das den Rechner, von dem aus man den Browser öffnet, und nicht die gesamte Bereitstellung. Macht ja auch irgendwie Sinn, dass die am Frontend Telemetrie-Daten sammeln. Könnte diese Zeile sein:
Nicht umsonst hat Microsoft dem PowerShell-Modul das Cmdlet Set-RDWebClientDeploymentSetting mitgegeben, damit kann man nämlich auch ohne Internet-Zugang die Telemetrie ausschalten:
Und falls sich jemand die Frage gestellt hat, ob das Ganze auch auf anderen Betriebssystemen geht (z.B. weil er MacOS-User ist und von den ewigen Troubles mit dem RDP Client die Nase voll hat)…
Happy RDSing!
Antworten