Freigeben über

Remote Desktop Services (RDS) 2012 Session Host deployment scenarios

  • Artikel

Hello AskPerf!  Jason here from the Windows Reliability team.  As more customers migrate from Remote Desktop Services (Session Host)  on Windows 2008 R2 to Windows 2012 R2, we occasionally get calls requesting assistance with either migrating to, or deploying a new 2012 R2 RDS environment.  Versions prior to 2008 R2 installing the RDS Server role was fairly straight forward.  Windows 2008 R2 changed this method with the addition of a Connection Broker though if not using RemoteApp or VDI, the Connection Broker was not needed.  Even when using a Connection Broker, to deploy the RDS Hosts in a collection, you would install the RDS role on each RDS server.  All the familiar consoles are there.  Publishing of Applications in the application were still done on each server.
 
This is the first post in a multipart series to help Admins quickly determine which method to use for deploying RDS in 2012 R2.
 
So, what changed?  Well, a lot, and for the good.  Comparing 2008 R2 to 2012 R2 RDS components, the biggest change is the Connection Broker and the role that it plays.  Prior to 2012, the concept of collections did not really exist.  With the release of 2012, the Connection Broker database now includes all of the management data as well as connection data.  This made configuration of any sizable farm in 2008 R2 more tedious.  To publish apps you went to each RDS Host and published.  It was made a little easier by being able to export and import, but still was not as manageable as it could be.  Configuring certs for the different components and setting up RDS Gateway was definitely more complicated.  To me Server 2012 R2 is as it should be, centralized configuration and management.  Deploying a collection is very easy once you figure out not to deploy as an RDS role except for certain scenarios. Missing and different consoles, and not having consoles at all on the RDS Hosts is a big change from 2008.

Where did my Consoles go?!?  Good question!  I’ve heard the following statement more than once - “I deployed RDS role as I have always done.”  Along with changes to the Connection Broker, the consoles and their locations have changed as well.  The Connection Broker in Server Manager has all of the consoles now except for RDS Gateway and RDS Licensing which are still separate.  Deploying just the RDS role will actually not install any console at all except for the RD Licensing Diagnoser.
 
Windows 2012 R2 has 3 deployment methods, or 4 counting PowerShell, which are actually pretty easy - see links section below.  Hint, if you are wanting the short answer then do a Standard Deployment and get your consoles back.  Do EVERYTHING from the Connection Broker.  Add all servers being deployed to the Connection Broker All Servers First.  There are multiple ways to configure licensing in RDS 2012 and this can be confusing.  Group policy always takes precedence and will NOT show in the Connection Broker console if configured.  Do not mix methods of setting licensing.  For example, do not set in Group Policy and also in Server Manager GUI, as this may result in errors.  A more detailed post about licensing methods will be following this post series.
 
For Windows 2012 R2, the most typical scenario and best practice is to do a Standard Deployment.  Why? Well as previously mentioned, it gives you all the consoles for management of your collections.  It supports both all in one to multiple servers being deployed to.  It allows each role (RDWeb, Connection Broker, RDSH) to be installed on the same or different servers.  It has all the features required for RemoteApp, RDWeb, and Connection Broker.  Unlike previous versions, all deployment and management is performed from the Connection Broker.  In summary, if you are deploying RDSH for production to multiple servers, then this your option.
 
So, when would I use Quick Start?  Typically you wouldn’t.  It’s similar to a Standard Deployment which is the current best practice, except that it will only deploy the RDS components to a single server.  All components (Connection Broker, RDWeb, and RDSH) will be installed with no option to modify.  This would be good if setting up a quick POC, or maybe a lab environment, or if you are only going to deploy one server with all the components; for example, a small office.  If you want to split the components out to different machines, then chose Standard Deployment.
 
Ok, so why would I deploy just the Server Role?  There are a couple of scenarios for where deploying just the Server Role service makes sense.  This would be for non-typical setups such as using RDS in a workgroup, using RDS on a non RDS server, for example, on a SQL server to allow more than 2 concurrent sessions.  Another scenario would for deploying just the Server Role would be if you are deploying Citrix since it has its own management and consoles.  When just deploying the Server Role, you do not get the centralized management, management consoles, and the RemoteApp published application functionality.
 
Hopefully this clears up some of the confusion around deciding which way to deploy RDS in 2012R2.  Check the following links for more detailed information on the different installation methods.
 
RDS 2012 session deployment scenarios Server Role Deployment (coming soon)
RDS 2012 session deployment scenarios Standard Deployment (coming soon)
RDS 2012 session deployment scenarios Quick Start (coming soon)
RDS 2012 session deployment Licensing Methods (coming soon)
 
REFERENCE:
RDS Step by Steps to install RDS Session Deployment using Powershell.docx

-Jason

Comments

  • Anonymous
    April 02, 2015
    Hello AskPerf! Jason here from the Windows Reliability team. As more customers migrate from Remote Desktop