NEW RDS deployment model: Personal Session Desktops!

With Windows Server 2016 (at this moment still Technical Preview 2) a new RDS deployment model will be available. Currently in Windows Server 2012 R2 we have 2 deployment options. There is Session-Based Desktop Deployments which is based on the RD Session Host role where each user runs a session on a shared Server OS, the traditional Terminal Server model. And there is Virtual machine-Based Desktop Deployment which is based on the RD Virtualization Host role where each user runs a dedicated Virtual Machine (either Pooled or Personal) based on a Client OS, mostly called VDI.

Starting with Windows Server 2016 / Technical Preview 2 Microsoft is introducing Personal Session Desktops or Server Based Personal Desktop. Basically this is combining the 2 currently available deployments resulting in a VDI scenario without using a client OS. So essentially every user will get a dedicated RD Session Host server as their “desktop”. Why is this interesting? Azure! (or Cloud / DaaS in general), because currently you cannot enroll a VDI Solution in Azure because in Azure you cannot control the hypervisor and you cannot license a client VM for VDI scenario’s.

Also added in Windows Server 2016 is improvement on the Desktop Experience feature. If you’re not familiar with this, Desktop Experience is feature in the Windows Server OS that allows you to make the Server OS look & feel like a client OS, very commonly used in a existing RDS deployments. In Windows Server 2016 additional improvements have been added to the feature to make the Server OS look even more as a (Windows 10) Client OS.

So with Personal Session Desktops or Server Based Personal Desktop (not entirely sure what the exact naming will be) you will essentially be able to do “VDI” in Azure where every user will have a fully persistent desktop with options to allow user installed applications or maybe even local admin privileges.

Let’s take a look at how to set that up. In my Azure subscription I set up 4 servers for this test.

DC01     (Domain Controller)

RDCB01 (RD Connection Broker, RD Web Access)

RDSH01 (RD Session Host)

RDSH02 (RD Session Host)

The new Deployment model cannot be created using the Remote Desktop Management Services (RDMS) console as part of Server Manager. Not entirely sure, but most likely this will change after Technical Preview 2, but for now the new Deployment Type can only be created and managed using PowerShell. Be aware, that today, even if you have set up the deployment and created a Session Collection using PowerShell, it will not show up in the RDMS console.

After deploying the above servers (all based on Windows Server technical Preview 2) and setting up a basic Active Directory we can start to create the deployment. We open up a PowerShell prompt with elevated permissions.

First, we import the RemoteDesktop PowerShell module and configure some basic variables we’ll use later on. So we will define the 2 RD Session Host servers, 2 of our test users, a name for the Session Collection and the RD Connection Broker server.

import-module RemoteDesktop

$RDSH1 = "RDSH01.rdsgurus.com"

$RDSH2 = "RDSH02.rdsgurus.com"

$User1 = "rdsgurus\rdstest1"

$User2 = "rdsgurus\rdstest2"

$CollectionName = "RDSHPDCOLL"

$ConnectionBroker = "rdcb01.rdsgurus.com"

Next, before we can create the actual Session Collection based on Server Based Personal Desktops, we need to have a RDS deployment first. To do so we create a RDS Deployment using the following command

New-RDSessionDeployment -ConnectionBroker $ConnectionBroker -WebAccessServer $ConnectionBroker -SessionHost $RDSH1

Now we are ready to add any additional RD Session Host servers to the deployment. In this example we’ll add our second RDSH server

Add-RDServer -Server $RDSH2 -Role "RDS-RD-Server" -ConnectionBroker $ConnectionBroker

We are now ready to create the Server Based Personal Desktops Collection. We do this using the existing command New-RDSessionCollection in combination with the new  -PersonalSessionCollection switch and we’ll also add the switch -GrantAdministrativePrivilege which allows users to be granted local administrator permissions on their personal Session Host. The full command is as follows

New-RDSessionCollection -CollectionName $CollectionName -ConnectionBroker $ConnectionBroker -SessionHost $RDSH1,$RDSH2 -PersonalSessionCollection -GrantAdministrativePrivilege

The result of the command looks like this and indicates a new Personal Session Collection with 2 RDSH servers added.

CollectionName Size ResourceType  CollectionDescription
-------------          ----------------            ---------------------
RDSHPDCOLL       2                             Remote Desktop

NOTE: The switch –PersonalSessionCollection will be renamed to –PersonalUnmanaged in the final release of Windows Server 2016.

The next step is to assign a Personal Session Host to a specific user. You can think of this as Personal VDI in terms of Virtual Machine-Based deployment. We can achieve this using the following command

Set-RDPersonalSessionDesktopAssignment -CollectionName $CollectionName -ConnectionBroker $ConnectionBroker -User $User1 -Name $RDSH1

Set-RDPersonalSessionDesktopAssignment -CollectionName $CollectionName -ConnectionBroker $ConnectionBroker -User $User2 -Name $RDSH2

Let’s now view what has been created

Get-RDPersonalSessionDesktopAssignment -CollectionName $CollectionName

The output is as follows, indicating that we have a collection with where 2 RDSH servers have been assigned to 2 users.

CollectionName            DesktopName                           User  

--------------                   -----------                                  ----

RDSHPDCOLL                 RDSH01.RDSGURUS.COM            RDSGURUS\rdstest1

RDSHPDCOLL                 RDSH02.RDSGURUS.COM            RDSGURUS\rdstest2

Let’s now take a look at what that looks like in action. For that we browse to RD Web Access and logon as one if the test users, in this case rdstest1. Notice that since this is still Technical Preview, the RD Web Access interface still says Windows Server 2012 R2 J

After logging on we now have a dedicated Personal Session Host assigned to us. Based on the assignment we configured, still user will always be redirected to this RD Session Host.

And when launching the assigned desktop the RD Connection Broker direct us to our assigned Personal RD Session Host, which looks like Windows 10 based on the Desktop Experience feature.

Since we used the Switch GrantAdministrativePrivilege the broker added the user account to the local administrators group. This obviously allows the user to have full control over his ‘Desktop”, and supports user installed applications etc.

Conclusion; Yes this new deployment, or rather new type of Session Collection definitely creates more options. Maybe not as the primary solution for every user, but maybe for a small subset of your user base that still needs a persistent desktop, where the majority could for example use (Azure) RemoteApp? Either way, it is interesting though that Microsoft decided to work around their own licensing issue and in stead of fixing it for the client OS, decided to make it easier for the Server OS. :)

Few week ago Benny Tritsch and I also presented a session at BriForum 2015 in London, where we very briefly covered Server Based Personal Desktops, see the slide below.

For more info, Clark Nicholson RDS Product Team member presented a session at Ignite 2015 in which he, amongst other topics, also covered Server Based Personal Desktop. Check out the session here: https://channel9.msdn.com/Events/Ignite/2015/BRK3859