Remote Desktop Services in Windows Server 2012/2012 R2 and Windows 8/8.1 (Part 2)

by [Published on 4 March 2014 / Last Updated on 4 March 2014]

In this part of our series we’ll look at how additional enhancements and additions have made RDS easier for IT pros to deploy, secure and manage.

If you would like to read the other parts in this article series please go to:

Introduction

In Part 1 of this series, we looked at how changes and improvements in Remote Desktop Services in Windows Server 2012/2012 R2 and Windows 8/8.1 have improved the overall experience for end-users. In Part 2, we’ll look at how additional enhancements and additions have made RDS easier for IT pros to deploy, secure and manage.

The server-based implementation of Remote Desktop was introduced in Windows NT 4.0 Terminal Services Edition back in 1998 and continued to be called Terminal Services when it was included in Windows 2000 Server, Windows Server 2003 and Windows Server 2008. When Microsoft introduced Windows Server 2008 R2, there was a complete overhaul of the entire set of services formerly called Windows Terminal Services, along with a plethora of name changes that served to confuse IT pros.

The terminal server role became the Remote Desktop Session Host, the TS Session Broker became the RD Connection Broker, the TS Gateway became the RD Gateway, TS Web Access became RD Web Access, and a brand new service, the RD Virtualization Host, appeared. This last, the RD Virtualization Host, was the component that enabled the new VDI functionality; installing the RD Virtualization Host role automatically installed Hyper-V on the server (if it wasn’t already installed) and took on the task of monitoring and preparing the virtual machines. In this article, we’ll look first at how Windows Server 2012 and 2012 R2 have improved VDI deployment and administration.

What’s new with Virtual Desktop Infrastructure (VDI)

Virtual Desktop Infrastructure is a way of providing users with a full virtualized desktop environment in a desktop session to which they connect via a remote display protocol (in this case, Remote Desktop Protocol or RDP). The difference between VDI and traditional terminal services is that with the latter, all of the different users’ sessions run within the same shared server operating system, such as Windows Server 2012. With VDI, each user has an individual desktop environment in a virtual instance of a desktop operating system (such as Windows 7 or 8).

Whereas terminal services sessions use fewer resources, VDI can give users a more personalized, customized desktop experience through persistent desktops (or you can implement non-persistent desktops where users’ changes are not saved). Because VDI sessions are in separate operating systems, they may be more secure than sessions on a shared OS. In addition, some applications won’t run – or won’t run well – in a shared terminal services environment.

VDI is also different from RemoteApp, which lets you deliver individual applications that run remotely on the server to users’ own local desktops. Where they can run side by side with local applications.

Microsoft introduced their VDI solution, which is based on the integration of Hyper-V and Remote Desktop Services in Windows Server 2008 R2 along with the many other changes to what had previously been known as Terminal Services. VDI gave IT admins the ability to “decouple” the hardware from the software (OS and applications) and data. Users can access their customized desktops from anywhere, with any computer or a thin client.

Windows Server 2012 makes the deployment of VDI faster and easier for IT professionals, by providing a new unified central experience. RDS previously required multiple administrative tools, but with Server 2012, most of them were combined into a single management console that’s built into the new Server Manager that was introduced in Windows Server 2012.

You can select from two deployment types: standard or “Quick Start” deployment, which installs all the Remote Desktop Services on one computer (normally the different roles would be deployed across multiple servers). To deploy VDI, you would select a virtual machine-based desktop deployment scenario, assign roles (in a standard deployment), and configure a machine pool, which is a collection of virtual desktops that can be assigned randomly and managed automatically. Pooled desktops can be rolled back after each session, or you can keep the personalized user settings for pooled desktops, by enabling the use of user profile disks (UDPs) where user settings and data are stored.

You don’t have to use a pooled collection, though; you can create a personal virtual desktop collection where admins assign the desktops to users manually. You can also use virtual desktop templates (that have already been configured in Hyper-V) to deploy and manage the virtual desktops.

 A wizard walks you through the steps to deploy your VDI; the full step by step process is described and illustrated here on the Canadian IT Pro Connection web site.

What’s new with Session Virtualization (formerly Terminal Services)

Session Virtualization is Microsoft’s new name for the old model of connecting to a desktop via Terminal Services. In other words, multiple users are sharing the same (Server) operating system and applications installed on that OS. As with pooled virtual desktop collections in a VDI deployment, this is appropriate where users don’t need their desktops to be personalized. Users also would not normally have administrative access to the operating system, since it is a shared OS.

Centralized management is the big thing with Windows Server 2012 RDS and this applies to session virtualization, too, where you get the same new unified and centralized deployment experience (starting with the same wizard referenced in the section on deploying VDI). You can use UPDs with session virtualization deployments, too. As with VDI, you can deploy in either Standard or Quick Start mode.

Because one of the drawbacks of session virtualization is the sharing of the operating system and applications, Microsoft has also built in a new feature called the Fairshare Experience. This feature attempts to prevent one user from interfering with the session of another user by disproportionately using the system resources and thus affecting the performance of others. It does this by dynamically spreading the available network bandwidth across all the active sessions, distributing disk I/O equally across active sessions and likewise distributing processor time more “fairly” across the active sessions.

As with Terminal Servers, multiple RD session hosts can be grouped together to publish session-based desktops and also RemoteApp programs. This was called a terminal server farm but is now referred to as a session collection.

What’s new with RDS management

Windows Server 2012 R2 brings back the feature called Session Shadowing, with which you’re able to monitor or take control of users’ active sessions on an RD session host server. This was not available in Windows Server 2012, but Microsoft responded to input from customers who missed the feature.

You can shadow a session in Windows Server 2012 R2 in one of two ways:

  • You can use the Server Manager if you prefer a graphical interface
  • You can use the command line if you prefer a text-based interface

In Server Manager, you can browse for the session collection in which the user whose session you want to control is active or if you know which collection it is, you can access it directly from the Collections section. You can select whether you want to control the session or just view it and also whether or not the user will receive a prompt. (If you choose to prompt the user, the user will see a dialog box giving him/her the option to accept your request to view/control the session or to reject it).

At the command line on a computer running Remote Desktop Client version 8.1 or above, type the following command:

mstsc /v:<server name> /shadow:<session ID>

In case you’re wondering how you’re supposed to know the session ID, you can find it out by running a PowerShell command (you must first import the Remote Desktop module if you haven’t already):

Get-RDUserSession

Note that the shadowing will start in View mode by default when you start it from the command line, so you need to add the /control parameter if you want to take control and the /noConsentPrompt parameter if you don’t want to ask the user for authorization.

In Server 2012 R2, there are some nice enhancements to shadowing. One is that you can shadow a session on a computer that’s using multiple monitors. You also have the ability to shadow a Remote App as well as a user session, and if the user is running multiple Remote Apps, you’ll be able to shadow them all since they run in the same session.

Note that you must have the appropriate permissions to shadow; otherwise you’ll get an “Access denied” error message.

Summary

In this, Part 2 of our series on improvements and additions to Remote Desktop Services in Windows Server 2012 and Windows Server 2012 R2, we discussed some of the new features and functionalities that will benefit IT professionals in deploying, managing and using various aspects of RDS on their networks. In Part 3, we’ll wrap it up by taking a look at changes to an important feature that benefits both end users and admins: RemoteFX.

If you would like to read the other parts in this article series please go to:

 

Featured Links