Managing RDS/VDI with Windows Server 2012
Introduction
I have been test-driving Windows Server 2012 (back then still called Windows Server 8) and the Windows 8 client since their first beta and customer preview were released around this time last year. My primary focus point being everything related to Remote Desktop Services (RDS) / Virtual Desktop Infrastructure (VDI). I have been writing blog posts and articles based on those beta and RC releases but now that the Release to Manufacturing (RTM) version has been released the 4th of September I thought it would be a good time for a review.
There’s a good chance you’ve heard about what’s new on RDS/VDI in Windows Server 2012 / Windows 8. If not, some new videos on the Windows Server 2012 launch site contain high-level overviews of what’s new. In addition, several recorded sessions from previous Tech Ed 2012 events that discuss RDS/VDI are available through Channel9 as well.
There are three major pillars when it comes to improvements to RDS/VDI; Simplified Management, Best VDI Platform Value and Rich Experience Everywhere. In this review, I will be focusing on the first one, management, and more specifically management of Session-based VDI deployments.
Name changes
You probably noticed me using both the terms RDS and VDI. The reason for that is that there has been a name change with Windows Server 2012. The overall name is now “VDI, powered by RDS”. Within VDI, there are two flavors. Virtual Machine-Based Desktop Deployment and Session-Based Desktop Deployment. Virtual Machine-Based Desktop Deployment is based on RD Virtualization Host(s) and thus offers a VM per user whereas Session-Based Deployment is based on RD Session Host(s), what we previously knew as Terminal Services. To be honest, the first time I heard about this name change I wasn’t too excited. People were just getting used to what the terms VDI and RDS meant within the Microsoft stack, and now there were about to change again. However, after working with the environment for a while and seeing the integration of Virtual Machine-Based and Session-Based deployments within a single console, I must say it really makes sense.
Management of VDI/RDS
If you’re used to managing RDS/VDI in Windows Server 2008 (R2), without even looking at all the other new features, I think a move to Windows Server 2012 will be a big change on the managing side only.
Back in Windows Server 2008, new roles for RDS (back then still called TS) were introduced. That introduction led to Role Based deployment, a big improvement compared to the way Terminal Services was deployed up until Windows Server 2003. Windows Server 2012 takes this a big step further and introduces Scenario Based Deployment. Using Scenario Based Deployment, you’re able to perform a full VDI/RDS deployment from the single Server Manager console. With Windows Server 2008 (R2) you had to install all RDS roles separately, but more importantly after installing those roles, a huge amount of manual configuration had to be done. For example adding computers to several groups like TS Web Access Computers, TS Session Broker Computers, and configuring the source of RD Web Access etc. I really like the fact many of these configurations can now be performed centrally from within the Server Manager, and, depending on the type of deployment, many configurations are even configured for you. There are two types of wizard-driven Scenario Based Deployments (within the interface this is called Remote Desktop Services Installation). A Quick Start installs the RD Connection Broker, RD Session Host and RD WebAccess, creates a Session Collection for you, glues all roles together and even publishes some basic Remote Apps. You literally can run through this wizard in less than 10 mouse clicks! When the wizard finishes you’ll have a fully working demo-environment up and running. All roles are installed on a single server, which of course makes it less appropriate for (large) production environments; however, this is very useful for demo or lab environments or even maybe very small production environments as well. The other deployment type is the standard deployment. This deployment type again installs the RD Connection Broker, RD Session Host and RD WebAccess roles for you but this time, enables you to install these roles on separate servers. After that, you still have to do some configuration within the server manager e.g. create a Session Collection, however, since this is now possible using the central Server Manager console, I think this makes it very easy.
The fact that managing your RDS/VDI deployment is now moved to a central Server Manager Console also means that tools like the Remote App Manager and Remote Desktop Services Manager, which used to be available on a server running the RD Session Host role, are no longer available. Remote Apps are now also centrally managed, so no more exporting and importing .xml files between Remote App Manager Consoles to keep RD Session Host Servers equally configured, which I think is great! In addition, to deploy a RDS environment successfully you also need to set up SSL certificates for various roles. In contrast to Windows Server 2008 R2 where you had to configure these certificates using various different consoles, this is now also centrally managed using the Server Manager console.
Despite the fact that most of the installation and configuration activities can be performed from a central Server Manager console, it does not include all RDS roles (yet?). The RD Gateway Role and RD Licensing role can be installed remotely using the central Server Manager console, however, the configuration of the RD Gateway is still done using the traditional MMC snap in (RD gateway manager) and the RD Licensing Manager MMC snap in is also still there and needs to be used to manage RDS Client Access Licenses. Therefore, the RDS/VDI in Windows Server 2012 environment is not fully centrally manageable (yet), however personally I think this is a huge step in the right direction. A good first step would be to have a non-mandatory option to install the RD Gateway and RD Licensing Role using the initial Scenario Deployment. An as a next step, maybe integrate both MMC snap ins inside the central Server Manager Console.
It will definitely take some getting used to the new way of deploying and configuring, especially if you’ve been using RDS in Windows Server 2008 R2 a lot, but I really like the idea behind the central management and I think that once you’ve worked with it, you wouldn’t want to go back.
I’m also very excited about the High Availability (HA) options for the RD Connection Broker Role. In Windows Server 2008 (R2), High Availability for the RD Connection Broker role was possible, however setting it up required you to run through a big deployment document and also included Windows Clustering. In Windows Server 2012, HA for the Connection Broker no longer requires clustering. Instead, it uses a centrally stored SQL Server database, which means it no longer uses a locally stored database on the RD Connection Broker server! Even better, in contrast to with Windows Server 2008 R2, the HA configuration is now active-active. In addition, the RD Connection Broker is now also the handling the initial connection (what we used to know as RD Dedicated Redirector in Windows Server 2008 R2). I think this all makes a very robust, reliable and easy to configure HA solution.
With Windows Server 2012, we are also losing a feature that I’m less happy about. With Windows Server 2008 (R2), and even with Windows Server 2003 we were, as an admin, able to remotely view user sessions and even interact with that session (sometimes referred to as “shadowing sessions”.) I believe this is a widely used feature by helpdesk departments to help end users with all kinds of issues. The Remote Control (shadowing) feature has been removed from Windows Server 2012. Although there are workarounds available to overcome this, e.g., by using additional management tools, personally I think many will be surprised this feature is no longer available.
Last, but certainly not least, RDS/VDI management in Windows Server 2012 now has great support for PowerShell. A new PowerShell module called “RemoteDesktop” got introduced and contains many, many cmdlets. Anything you can do from within the Server Manager Console can also be performed using PowerShell. Whether it is running an initial deployment, adding additional roles or configuring RemoteApps it can all be done, that’s great!
Conclusion
To conclude, I think huge steps have been made on the management side of RDS/VDI. Being able to centrally deploy and manage these environments is a big improvement. Moreover, this is just one of the three pillars of improvement that I mentioned in the introduction.
In short, I’m excited!
Freek Berson (Wortell)
RDS [MVP]
themicrosoftplatform.net