Remote Desktop Services in Windows Server 2016 - planning poster!

How cool is this? The Remote Desktop Services team have created a poster on RDS in Windows Server 2016!


Download URL: http://aka.ms/rdposter

RDS on Windows Server 2016 - documentation updates

New Microsoft articles & guidelines have been released this week related to Remote Desktop Services and the upcoming launch of Windows Server 2016!

Some examples (source: rdsgurus.com/../new-documentation.)

Upgrade your RDS deployment to Windows Server 2016.
Deploy a Storage Spaces Direct scale-out file server for UPD storage in Azure
Deploy a Remote Desktop Connection Broker cluster
Desktop hosting logical architecture
Understanding the desktop hosting environment
Azure services and considerations for desktop hosting

For more articles visit https://technet.microsoft.com/en-us/windows-server-docs/compute/remote-desktop-services/host-desktops-and-apps-in-remote-desktop-services

As we’ve heard earlier this week, Windows Server 2016 is now RTM, the evaluation version is available for download and we can expect it to hit general availability half October. Exciting times are ahead of us!

RDS on Azure IaaS using ARM & JSON part 2 – demo at Microsoft Ignite!

In one of my previous blog posts I described performing an entire High Available RDS deployment in Azure IaaS using Azure Resource Manager (ARM) and JSON. In that blog post I described the differences between deployment mechanisms in the classic Azure Portal and the new Azure Portal. I gave a brief introduction on what JSON is and how to use Visual Studio to build and deploy directly to Azure based on JSON templates. Also see Full HA RDS 2016 deployment in Azure IaaS in < 30 minutes, Azure Resource Manager FTW! In the mean time I have been expanding and improving this JSON deployment.

---

During the Microsoft Ignite event on September 30, fellow RDS MVP Benny Tritsch will be presenting a session called Get an independent insider’s view of desktop virtualization and session remoting. In this session he will also be showing some of my results of this deployment. If you are at Ignite be sure to join this session, it contains a lot of awesome content coming from various community members! The recording of the session will also become available online.

---

A few examples of what I have been adding to the deployment:

- I’ve added the ability to configure SSL for all of the RDS roles based on either self-signed certificates or publically trusted certificates. The deployment takes care of configuring SSL for all of the roles to allow for a smooth user experience when accessing the environment using public DNS names.



- As part of the deployment 2 Session Collections are created, based on provided parameters and a few example RemoteApps are also published to get immediately get started with the environment.



- The deployment now also allows you to configure various session timeout settings to further customize the session collections.



- The deployment now creates 2 separate storage accounts and spreads the High available RDS roles across these storage accounts to be fully compliant with High availability common practices in Azure IaaS.



In an upcoming blog post I’ll spend some more time on other features like User Profile Disk, RDSH Custom Images, RD Licensing and possibly other features!

Microsoft Mechanics video on RDS for Windows Server 2016

Microsoft has released a Mechanics video on Remote Desktop Services in Windows Server 2016.

”…We are getting close to the launch of RDS in Windows Server 2016!

As a preview to the great new capabilities coming in the latest update of your trusted desktop and app virtualization platform, we have released a new MS Mechanics video showcasing some of our greatest innovations in this release. Scott Manchester, Principal Group Program Manager on the Remote Desktop Services team, and our tech evangelist Simon May talk about and demonstrate the powerful new innovations in RDS for Windows Server 2016 across three key areas…”

Source en more information: https://blogs.technet.microsoft.com/enterprisemobility/2016/09/22/new-ms-mechanics-video-with-the-latest-updates-to-rds-for-windows-server-2016/

New default RD Gateway Resource Authorization Policies in Windows Server 2016

Remote Desktop Services is referred to by Microsoft as one of the “top 10” capability of the Windows Server 2016 release that is going to reach General Availability within a few weeks. Also see this blog post and video Ten reasons you’ll love Windows Server 2016 #4: Remote Desktop Services. The three key pillars of improvement are shown in the diagram below.


While test driving the Technology Preview 5 version I ran into a small new feature as part of the process of adding an RD Gateway server to a Remote Desktop Services Deployment using RDMS.

Since Windows Server 2012, Server Manager can be used to perform scenario based deployments of Remote Desktop Services. As part of this scenario based deployment, an RDS deployment is created consisting of an RD Connection Broker, RD Web Access and RD Session Host. This confirmation of what is created using the wizard is shown below.

After this initial deployment we are able to add additional servers and also add the RD Gateway role.


As part of the process of adding an RD Gateway server to a 2012 R2 deployment, two default policies are also added to the RD Gateway.

- A default Connection Authorization Policy (CAP) is added that simply allows access to the RD Gateway for the group Domain Users. This is to make sure that you can start using RD Gateway immediately, however in production environments I advise to modify this CAP to only allow access by a specific (Active Directory) group of users. This is not changed with Windows Server 2016.

- A default Resource Authorization Policy (RAP) is added that allows access through RD Gateway towards all computer objects of the domain (via the Domain Computers group). Again, this is added to allow easy setup and in production environments I advise to modify this RAP to only allow access to specific resources of your RDS deployment. Below is what this default RAP looks like.


Starting from Windows Server 2012, the RD Connection Broker became the default initial connection hander. This means that any user connecting to an RDS Deployment always makes an RDP connection to the RD Connection Broker first. The RD Connection Broker decides what’s the best RD Session Host to connect to, resulting in a second RDP connection from user to that RD Session Host server. Although this process is completely transparent for the end user, it does mean that the user must be able to access the RD Connection Broker via RDP. For RD Gateway usage, this means that the RD Connection Brokers must be added to the RD RAP as a resource.

The above scenario is where in the future, RDS on Windows Server 2016 helps out. We do the same scenario based deployment of RDS in Windows Server 2016 (TP5), as shown below.

And adding a RD Gateway server to this deployment the same way.

The deployments now adds an additional RD RAP out of the box called RDG_RDConnectionBrokers


This RD RAP provides access to an RD Gateway Managed Group of computers (called RDG_RDCBComputers) which is populated with the RD Connection Broker Server that is part of your deployment.


This is very helpful because adding the RD Connection Broker to the RD RAP, after removing / changing the RDG_AllDomainComputers RAP, is a task I see commonly forgotten in several environments.

But what about scenario’s where the RD Connection Broker is in High Availability (HA) mode or scenario’s with a single RD Connection Broker where the broker FQDN name was changed by using the Set-RDPublishedName.ps1 In those cases it’s even more tricky because the broker FQDN is not a member of the Domain Computers group, it’s not even a Kerberos object in AD.

When adding an RD Gateway to an RDS 2016 deployment where HA in in place, the wizard also takes case of this. In those case an additional RD RAP (RDG_HighAvailabilityBroker_DNS_RR) is added that provides access to an RD Gateway Managed group called RDG_DNSRoundRobin that holds the RD Connection Broker FQDN as shown below.


This matches the RD Connection Broker HA FQDN as configured in RDMS.

It’s a relatively small addition to the scenario based deployment of RDS on Windows Server 2016, but very helpful to provide smoother setup of the RD Gateway role in such environments.

Windows Server 2016 will hit General Availability during Microsoft Ignite in less than two weeks. I’m looking forward to the launch!