Tuesday, June 2, 2015

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

13 comments:

  1. So, partially this solution was invented by Microsoft to circumvent their own licensing restrictions? ... mind blown ...

    ReplyDelete
    Replies
    1. Nothing new compare to Citrix or VMware solutions ... ;-)

      Delete
  2. Or alternatively, *this* model removes the need to have any conversation about licensing

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Also known as 'Server VDI' when using Citrix for example, has been around for a couple of years now, also used by Amazon, Workspaces if I'm not mistaken. Kind of surprised it took them this long to come up with something similar since everybody keeps complaining about their VDI (Cloud) license restrictions. Another (small) step forward I guess. But surly this will be build into Server Manager not to long from now.

    ReplyDelete
  5. We could always build user-specific RDSH servers if we used RDSH mode and not VDI mode. This even works in SPLA. So what's really new here? I like Desktop Experience, User profiles/disks, GPOs and shared DLLs. I like managing ONE core RDSH image for thousands of users in lieu of thousands of server images. I understand the single-OS image and layered-approach - but I don’t see mush advantage. I guess if we give everyone their own RDSH image, then MS will sell more Host Enterprise licenses? I’ll sit on the fence and watch the new SEVER VDI mature.

    ReplyDelete
  6. The real question is if the broker will be functional. 3 years in and there have been virtually no improvements to the stability and functionality of the broker and collections. The PowerShell cmdlets barely function when configured for HA. I want to see something that says, "The broker actually works this time." before I trust that it will keep track of the VM's in the collection.

    ReplyDelete
  7. I totally agree with the overall responses here that Microsoft is working around their own licensing issue and instead of fixing that, they provide ways to use the Server OS using their management solution. I guess technology teams are able to evolve faster than the licensing teams :). Let’s hope Windows 10 is the start of an inspiration to also evolve the SLPA licensing terms and have this single user RDSH solution as the fallback solution.

    ReplyDelete
  8. You've got to be kidding me! Why in the world would you want to deploy server OS for each user???

    Quit side stepping what the demand has been, let people virtualize desktop OS under SPLA. Why don't you just provide this? Everyone has been requesting this for YEARS.

    ReplyDelete
  9. I think they should have sorted out the Licencing issue, rather and over engineering a workaround. i would rather they made some massive improvements in in broker, powershell and RD Web Access and the general management tools for it all. that would have been better spent effort.

    ReplyDelete
  10. Hi,
    I got to the Work Resources and when click on the RDSHPDCOLL icon, it does NOT auto log in to the personal VM, it asks for a domain password which I used to log into my ThinPC. Any suggestion? Thank you

    ReplyDelete
  11. This comment has been removed by the author.

    ReplyDelete
  12. Hi,

    Great article. Thank you.

    I am running Windows Server 2016 Standard (Desktop Experience) and have followed what your steps above, the challenge i am facing is I cannot for the life me get the similar "Windows 10" Desktop Experience. My Domain User gains access to a Windows Server 2016 Desktop.

    What determines this desktop experience in the configuration?

    ReplyDelete