Wanneer je een Remote Desktop omgeving opzet voor meerdere gebruikers en dus niet alleen zelf als administrator op een Windows Server werkt, zet je een Remote Desktop Services Deployment op.

Een Remote Desktop Services Deployment bestaat uit een aantal roles waarvan het niet altijd direct duidelijk is waar die roles voor dienen. Wat doet bijvoorbeeld een connection broker? Je vraagt je misschien ook af op welke server je welke role moet installeren. In dit artikel zoomen we daarop in en bekijken we uit welke onderdelen een Remote Desktop Services Deployment bestaat en op welke servers je welke roles installeert.

Onderdelen van een Remote Desktop Services Deployment

A picture is worth a thousand words, dus we kijken eerst naar een overzicht van een (complete) remote desktop-omgeving.

Remote Desktop Session Host

Simpel gezegd is een Remote Desktop (RD) Session Host een remote desktop server waarop één of meerdere eindgebruikers op een virtuele desktop werken via een remote desktop client (mstsc in Windows), of via Web Access gebruik maken van apps die beschikbaar worden gesteld op de RD Session Host (zie het voorbeeld onder RD Web Access). Om een optimale performance te garanderen, raden we aan om geen andere rollen op de RD Session Host te installeren.

Via een RD Session host kun je desktop-omgevingen of applicaties (meer gericht op RD Web Access) aan gebruikers aanbieden. Een of meerdere RD Session Hosts kun je verzamelen in een 'collection', die weer verder aan te passen zijn voor specifieke groepen of gebruikers. Zo kun je een groep toegang geven tot specifieke apps en andere die toegang ontzeggen, terwijl ze wijl beide toegang houden tot dezelfde Session Host.

Remote Desktop Connection Broker

Een Remote Desktop (RD) Connection Broker beheert inkomende remote desktop verbindingen naar RD Session Hosts (zowel voor desktop als app collecties).

RD Connection Brokers kunnen loadbalancing toepassen op servers in een collectie bij het opstellen van nieuwe verbindingen. Een verbroken verbinding vanuit de kant van de client wordt, wanneer die verbinding hersteld wordt, door de RD Connection Broker terug aan de RD Session Host gekoppeld waar die eerder mee verbonden was.

RD Gateway

Een RD Gateway versleutelt de verbinding tussen een client en server (de RD Session Host) met SSL. Hiervoor maakt de gateway gebruik van een HTTPS-verbinding (poort 443) naar de RD Gateway, die vervolgens de remote desktop verbinding doorzet (standaard poort 3389) naar de Remote Desktop Session Host. De RD Gateway maakt ook verbinding met de RD Connection Broker voor eventuele loadbalancing en om indien nodig verbindingen te herstellen.

Het is belangrijk dat je voor een RD Gateway een certificaat van een vertrouwde certificate authority (CA) gebruikt. Daarnaast moet de naam op het certificaat overeenkomen met het subdomein dat je gebruikt om met een RD Gateway te verbinden.

RD Web Access

Remote Desktop Web Access (RD Web Access) geeft gebruikers toegang tot remote desktops of applicaties via een web portaal (daar is het screenshot hierboven een voorbeeld van). De desktops of applicaties zijn in een collection vastgelegd en worden geopend via de native Remote Desktop client applicatie. Dit is bijvoorbeeld een handige manier om Windows desktops en applicaties aan zowel Windows als niet-Windows client devices (bijv een Macbook) aan te bieden.

RD Web access gebruikt IIS om via een HTTPS-verbinding een versleutelde verbinding tussen de client en RD Web Server op te zetten. De RD Web Access server moet toegankelijk zijn via een publiek IP-address die TCP-verbindingen op poort 443 toestaat.

RD Licensing

Zoals de naam suggereert, zorgt de RD Licensing role voor de verificatie van remote desktop-licenties. Je bent vrij als administrator om gratis op een Windows Server te werken (maximaal met twee administrators), maar voor het werken op Remote Destkop Session hosts moet voor iedere reguliere gebruiker een licentie aanwezig zijn (zie ook ons artikel 'Remote Desktop licenties installeren').

RD Virtualization Host

De RD Virtualization Host role maakt gebruik van Hyper-V om virtuele machines te leveren via Remote Desktop Connection en RemoteApp. Hyper-V wordt niet ondersteund op ons platform en deze role speelt dan ook geen verdere rol in de inrichting van een Remote Desktop Services Deployment op Windows-VPS'en.

Welke server geef ik welke role?

Niet iedere role is even intensief in hardware gebruik. De RD Licensing role vergt bijvoorbeeld zeer weinig van een server. Daarnaast wil of kan niet iedereen één Windows Server per role inzetten, aangezien dit ook een kostenplaatje met zich meebrengt. Wanneer je in deze situatie zit en je afvraagt welke server je het beste welke role kunt geven, raden we de volgende verdeling aan:

• RD session host: niet combineren met andere rollen.
• RD Connection broker: combineren met AD DS server (je Domain Controller)
• RD Gateway: combineren met RD Web Access en RD Licensing

Eventueel kun je nog verder kosten besparen door nog verder rollen te combineren. Zo kun je de RD Gateway, RD Web Access en RD Licensing role bijvoorbeeld combineren met een File Server. Wanneer je rollen combineert is het vooral belangrijk het hardwaregebruik van de server in de gaten te houden. In onze testsetup (die uiteraard een stuk lagere load heeft dan een praktijkomgeving) was het hardwareverbruik van een RD Gateway, RD Web Access, RD Licensing en File Server combinatie op een X4-VPS verwaarloosbaar.

Het hierboven omschreven scenario geldt voor omgevingen met meerdere Windows Servers. Wanneer je maar één Remote Desktop server inzet, ben je vrij om alle rollen op die ene server te installeren. Gebruik je daarnaast een file server, dan zou je voor het optimaliseren van de performance bijvoorbeeld alle rollen behalve de RD Session Host op de file server kunnen installeren.

Daarmee zijn we aan het eind gekomen van dit artikel over de onderdelen van een Remote Desktop Services Deployment.

Mocht je aan de hand van dit artikel nog vragen hebben, aarzel dan niet om onze supportafdeling te benaderen. Je kunt hen bereiken via de knop 'Neem contact op' onderaan deze pagina.