Native RDS in Server2016 - Part 2 - RDVH

Part 1: The Basics
Part 2: RDVH (you are here)
Part 3: RDSH
Part 4: Scaling and HA

In part 1 of this series we took a look at the over all architecture of RDS in Server 2016 along with the required components  contrasting the function performed by each. If you're not new to RDS, things really haven't changed a great deal from Server 2012R2 from a basic architecture perspective. In this chapter we'll take a look at the RDVH role, what it does, how to get going and how to manage it.

Test Environment

Here is a quick rundown of my environment for this effort:

• Servers - 2 x Dell PowerEdge R610's, dual X5670 (2.93GHz) CPUs, 96GB RAM, 6 x SAS HDDs in RAID5 each
• Storage - EqualLogic PS6100E
• Network - 1Gb LAN, 1Gb iSCSI physically separated
• Software - Windows Server 2016 TP5 build 14300.rs1
• Features - Hyper-V, RDS, Failover Clustering

Installation

The first step is to create an RDS deployment within your environment. Consider this construct to exist as a farm that you will be able to install server roles and resources within. Once the initial RDS deployment is created, you can create and expand collections of resources. An RDS deployment is tied to RD Connection Broker(s) which ultimately constitute the farm and how it is managed. The farm itself does not exist as an explicitly addressable entity. My hosts are configured in a Failover Cluster which is somewhat inconsequential for this part of the series. I'll explain the role clustering plays in part 4 but the primary benefits are being able to use Cluster Shared Volumes, Live Migration and provide service HA.
On one of your management hosts that already has Hyper-V enabled, fire up the Add Roles and Features Wizard, select Remote Desktop Services installation and choose your deployment model. "Standard" would be what is chosen most often here unless doing a POC then "Quick Start" may be more appropriate. MultiPoint is something entirely different which carries a different set of requirements. You don't have to use this wizard but it is an easy way to get going. I'll explain another way in a moment.

      

Next choose whether you'll be deploying desktop VMs or sessions. Desktops require the RDVH role on the parent, sessions require RDSH and can be enabled within Server VMs. For this portion we'll be focusing on RDVH.

     

Next select the hosts or VMs to install the RD Connection Broker and Web Access roles. For POCs everything on one host is ok, for production it is recommended to install these RDS roles onto dedicated Server VMs. You'll notice that I pointed the wizard at my Failover Cluster which ultimately resolved to a single host (PFine16A).

         

The third piece in this wizard is identifying the host(s) to assume the RDVH role. Remember that RDVH goes on the physical compute host with Hyper-V. Confirm your selections and deploy.

    

The installation will complete and affected hosts or VMs will be restarted. In order to manage your deployment, all Hyper-V hosts and server VM roles that exist within your deployment must be added to the Servers tab within Server Manager. This can be done at the very beginning as well, just make sure it gets done or you will have problems.


At this point your RDS deployment should be available for further configuration with the option to create additional roles or a desktop collection. Unless you are building a new RDS deployment, when adding additional server roles, it is much easier to select the role-based installation method from the Add Roles and Features Wizard and choose the piece-parts that you need. This is especially true if adding singular roles to dedicated server VMs. There is no need to rerun the "Remote Desktop Services Installation" wizard, in fact it may confuse things.

Desktop VM Templates and Collections

Before we create a new collection, we need to have a template VM prepared. This can be a desktop or server OS but the latter requires some additional configuration. By default, the connection broker looks for a desktop OS SKU when allowing a template VM to be provisioned. If you try to use a Server OS as your template you will receive the following error:


To get around this, you must add the following registry key to any host that sources or owns the master template. Reboot and you will be allowed to use a Server OS as a collection template.

HKLM\System\CurrentControlSet\Services\VMHostAgent\Parameters\SkipVmSkuValidation   REG_DWORD     1

Your template should be a normal VM (Gen 1 or 2), fully patched, desired software installed and manually sysprepped. That's right, RDS does not integrate the ability to auto-clone a template VM to new unique VMs, you need to do this manually as part of your collection prep.


Make sure whatever template you intend to provision in your desktop collection is already added to your RDVH host or cluster and powered off.


Launch the Create Collection wizard within Server Manager, give the collection a name and select pooled or personal desktops.

    

Select the template VM to use to create the collection, if using a Server OS make sure you completed the steps above to make the template VM visible and selectable in the RD Collection wizard. Keep in mind that a template VM can only be used in a single collection, no sharing allowed. Provide an answer file if you have one or use the wizard to generate the settings for time zone and AD OU.
         

Specify the users to be entitled to this collection and the number of desktops you wish to deploy along with the desired naming convention. For allocation, you can now decide how many VMs of the total pool to provision to each available physical host. Take note of this, VMM is not here to manage Intelligent Placement for you, you can accept the defaults or decide how many VMs to provision to a host.

    

     
Select where to store the VMs: this can be a local or shared drive letter, SMB share or CSV. The ability to use CSVs is one of the benefits of using Failover Clustering for RDS deployments. Next, if you intend to use UPDs for storing user settings, specify the path and size you want to allocate to each user. Again, CSVs work fine here. Confirm and deploy.
         

Behind the scenes, RDS is making a replica of your template VM's VHDX stored in the volume you specified, which it will then clone to the collection as new VMs.


The pooled VMs themselves are thin provisioned, snapped (checkpointed) and only consume a fraction of the storage consumed by the original template. When reverting back to a pristine state at log off, the checkpoint created during provisioning is applied and any changes to the desktop OS are discarded.


UPDs are ultimately VHDX files that get created for each user that connects to the collection. By default all user profile data is stored within a UPD. This can become unwieldy if your users make heavy use of the Desktop, Documents, Music, etc folders. You can optionally restrict which pieces should be stored within the UPD and use folder redirection for the others if desired.


When UPD is enabled for a collection, there is a template UPD created within the volume specified then each user gets a dedicated UPD with the SID of the user as the file name. Selected settings are saved within and follow the user to any session or desktop they log into within the collection. This file will grow up to the maximum allotted.

Managing the Collection

Depending on the speed of your hardware, your pooled VMs will deploy one by one and register with the broker. Once the collection is deployed it will become available for management in Server Manager. Entitlements, RD Web visibility, client settings and UPDs can be manipulated via the collection properties. Desktop VMs can be manipulated with a basic set of controls for power management, deletion and recomposition. RemoteApp Programs provides a way to publish applications running within the desktop pool to RD Web Access without requiring RDSH or RD Lics which may be useful in some scenarios. Virtual GPU can also be enabled within a desktop collection if the host is equipped with a supported graphics cards. Server 2016 adds huge improvements to the Virtual GPU stack.


Notice here that RDS is aware of which VMs are deployed to which hosts within my cluster. Should a VM move between physical hosts, RDS will see that too. When removing VMs from a collection, always do this from the Collections dialog within Server Manager as it's a cleaner process. This will turn off the VM and remove it from Hyper-V. If you delete a VM from Hyper-V manager, the RDS broker will report that VM as unknown in Server Manager. You will then need to delete it again from within Server Manager.

              

If you have an AD object that already exists with the same machine name, that VM will fail to provision. Make sure that if you redeploy any collection using the same names that AD is also cleaned up before you do so.


As is always the case when working with VMs in Hyper-V, manual file system cleanup is required. Deleting a VM from Hyper-V or RDS in Server Manager will not remove the files associated with the VM. You could always add them back if you made a mistake but otherwise you will need to manually delete or script an operation to do this for you.


RemoteApp Programs can be used to publish applications for users of a desktop collection. This does not require RDSH but it will only allow a single user to connect to a published resource, just like a desktop VM. If you use RemoteApp Programs within a desktop collection, you will be unable to publish the desktop collection itself. For example, I have Google Chrome published from one desktop within my collection, this prevents the entire collection from being presented in RD Web Access only allowing the published app. To make this collection visible in RD Web Access again, I have to unpublish all RemoteApp Programs from the collection then select to show the collection in RD Web Access. The same is true of session collections. You can publish apps or you can publish sessions but not both simultaneously within a single collection.

Connecting to Resources

Logging into RD Web Access is the easiest way to access published resources. By default this URL as created within IIS will be https://<RD Web Access name>/RDWeb and can be secured using a proper certificate. Depending on user entitlements, users will see published apps, sessions or desktops available for launching. To enable direct connection to a collection using the Remote Desktop Connection (RDC), a collection within RD Web can be right clicked which will trigger a download of the .rdp file. This file can be published to users and used to connect directly without having to log into RD Web first.


Editing the .rdp file in a text editor will reveal the embedded characteristics of the connection which include the client settings, connection broker, gateway and most importantly the collection ID which in this case is "RDC". 


At this point the connection broker does as the name implies and connects users to resources within the deployment while maintaining where VMs are running and which VMs users are logged in to. In the next section we'll take a look at integrating RDSH into this environment.

Part 1: The Basics
Part 2: RDVH (you are here)
Part 3: RDSH
Part 4: Scaling and HA