Now that Windows Server 2012 has been generally available for some time, it’s high time to take a look back at the past few months to see what Windows Server 2012, and particularly Session-Based Desktop Deployment, Powered by RDS has brought us. In this article I’ll share some of my experiences while putting Session-Based Desktop Deployment in production based on Windows Server 2012. We’ll discuss how the overall installation process and the new way of managing your Session-Based Desktop Deployment environment performs and works out. This is part 1 of a series of (at least) 2 parts.
Before we start
Before we start, let’s get a naming convention straightened out here. With Windows Server 2012 the overall name is “Virtual Desktop Infrastructure, Powered by Remote Desktop Services”. VDI now consists of two flavors; there is Session-Based Desktop Deployment, what we would previously refer to as Terminal Services and there is Virtual Machine-based Desktop Deployment, what we would previously refer to as Virtual Desktop Infrastructure. This naming convention will probably take some time in getting used to. For a long time many will probably still talk about RDS when they’re actually referring to Session-Based Desktop Deployment(Powered by RDS) just as since the name transition in Windows Server 2008 R2 many still refer to Terminal Services when they mean Remote Desktop Services. With Windows Server 2012 the two flavors of RDS have been brought together. They share many of the same RDS Roles and Components and are manageable from a single Server Manager Interface (the RDMS) which, I believe, justifies name change.
With Windows Server 2012 the new way of initially deploying the various roles that make up Remote Desktop Services is called Scenario Based Deployment. Although, the actual name Server Manager wizard uses is Remote Desktop Services Installation. Before the Beta Release when this release was still called Windows Server 8, the wizard would refer to this installation type as Scenario Based Installation, but this name changed in the GA release. So if you see me mentioning Scenario Based, I’m referring to the Remote Desktop Services Installation. So this new way of deployment changed compared to previous releases like for example, in Windows Server 2008 R2 where you would still do Role Based Deployment.
I’ve done several deployments of Session-Based Desktop Deployment over the last months. The new way of deployment definitely saves time as the three basic roles that are, RD Connection Broker, RD Web Access and RD Session Host can be installed remotely using a single wizard. If you’ve done RDS implementations on Windows Server 2008 (R2) you’re probably remember having to populate groups like TS Web Access Computers, Session Broker Computers etc. and configure various MMC snap-ins.
In all production deployments I have done, I have been using the Standard Deployment. As you might know, using the Standard Deployment you are able to select different servers for the various RDS roles, which is usually what you would do in production environments. Also, the Quick Deployment, in contrast to the Standard Deployment, creates and configures a basic Session Collection. That’s ideal for demo and lab environments, but in production environments you will most likely undo this basic configuration as it for instance, allows All Domain Users to access the environment, and it publishes Calculator, Paint and WordPad.
With Windows Server 2012 we now also have much broader support to deploy and configure RDS using PowerShell. For more information on that see my previous articles at Using PowerShell to control RDS in Windows Server 2012 (Part 1) and Using PowerShell to control RDS in Windows Server 2012 (Part 2).
As I mentioned before, with Windows Server 2012 all management can be performed centrally from the Server Manager Console. For Remote Desktop Services this is referred to as the Remote Desktop Management Services (RDMS). From my experience, it’s definitely easy to add additional roles to servers using RDMS. However, there are two roles that still require opening the traditional MMC snap-in. These are RD gateway and RD Licensing. These two roles can be installed remotely using the RDMS, however, for the configuration you still have to switch to the other consoles. Hopefully, this will be improved in the future. During the implementations of production environments, I ran into some options that feel to be missing from the RDMS. For example, being able to configure the farm name users connect to. As you might know, with Windows Server 2012 the RD Connection Broker now also serves as the initial connection (think of this as dedicated redirector mode). So by default, published applications and desktops will connect to the hostname of the RD Connection Broker. That name cannot be changed using the RDMS. To be able to change the name of the initial connection, you would have to prepare the RD Connection Broker for High Availability. During this preparation you can specify the RD Connection Broker DNS name. On the other hand, in all the production deployments I have done so far I’ve used RD Connection Broker HA (or at least prepared for HA) to create High Availability. The steps to create this RD Connection Broker High Availability have improved immensely compared to Windows Server 2008 R2, and the High Availability setup is now also Active-Active, which is great. As the RD Connection Broker plays a much more important role on Windows Server 2012 (basically you hardly cannot do without), I would advise to always configure RD Connection Broker HA if possible. Take into account though that it requires an instance of SQL Server of at least version 2008 R2.
If you’re used to managing your RDS environment on Windows Server 2008 R2 and moved to Windows Server 2012 for the first time, first thing you’ll notice on the configuration side will be the fact that most of the Remote Desktop MMC snap-ins are gone. Where we used to work with for example, Remote Desktop Session Host Configuration, Remote Desktop Connection Manager and RemoteApp Manager we can now perform most of these actions within the RDMS. What from my experience works great is the fact that you can now centrally publish your Remote Apps. Previously, you had to publish these on all your RD Session Host servers either manually or using an import/export function. What I’m also really happy with is the fact that you can now publish a Full Desktop as a Remote App that points to your farm. Previously, using the RemoteApp Manager, you had an option called “Show a Remote Desktop Connection to the RD Session Host server in RD Web Access”. The downside here was that, as the name suggests, it pointed to a single RD Session Host instead of the farm. With Windows Server 2012 you can now publish a full desktop on RD Web Access that points to your farm (and is fully Single Sign On) by creating a Session Collection of the type “Remote Desktop”. The downside that I have experienced here is that since you have to put the Session Collection in type “Remote Desktop”, you cannot publish both Full Desktop and Remote Apps inside the same Session Collection. In order to achieve this you would have to create an additional Session Collection, including an additional (set of) RD Session Host servers.
One function of RDS on Windows Server 2008 R2 that has also changed on Windows Server 2012 is the way to distribute Remote Apps or Desktops. Previously, you could use the RemoteApp Manager, and create .RDP and .MSI files to distribute the Remote Apps or Desktops you wanted to publish. The function to create these files does not exist in RDS on Windows Server 2012. The best way to publish Remote Apps and Desktops now is to use the Web Feed URL which can be configured using the corporate e-mail address. Personally, I did not create .RDP or .MSI files on many occasions, so I don’t really miss this functionality. But if you have been using it a lot in the past, beware that this functionality no longer exists. There are relatively easy ways to retrieve the .RDP files of course. For more information on that see Distribution of Remote Apps and desktops in Windows Server 2012 . In my experience the Web Feed URL functionality works very fluently in both the traditional Remote Desktop Client (mstsc) as well as the Modern UI Remote Desktop Client.
This concludes part I of this series. Feel free to share your experiences by adding a comment to this article or by sending me an e-mail. In the part 2, I’m going to discuss some more of my experiences on Session-Based Desktop Deployment on Windows Server 2012. Some of the topics I’ll be discussing in part 2 are User Profile Disks, the new Modern UI Start Screen, the Modern UI Remote Desktop Client and Remote Control.
If you would like to read the next part in this article series please go to Session-Based Desktop Deployment on Windows Server 2012, experiences so far (Part 2).