With the official release of Windows Server 2012 rapidly approaching, VDI administrators should take note of some changes to Remote Desktop Services.
Remote Desktop Services (RDS) in Windows Server 2008 R2 consists of numerous components that perform specialized roles to make virtual desktop infrastructure (VDI) possible. The deployment process and the components are the same in Windows Server 2012 RDS, so you'll feel right at home if you've deployed the previous version. What's different is some additional features for provisioning and managing virtual desktops with RDS.
Remote Desktop Services roles
Before we dive into the differences, let's review the components of RDS. Windows Server 2012 Remote Desktop Services offers the same basic roles as Windows Server 2008 R2 (Figure 1). These roles include:
- Remote Desktop Connection Broker: The connection broker connects users with remote desktops. If a user loses connectivity to a remote desktop, the connection broker allows the user to reestablish the connection without losing the virtual desktop's state.
- Remote Desktop Gateway: This component allows for connectivity to virtual desktops and RemoteApp programs over the Internet.
- Remote Desktop Licensing: This component tracks license usage for your RDS deployment.
- Remote Desktop Session Host: The Session Host allows a server to host session-based desktops or RemoteApp programs.
- Remote Desktop Virtualization Host: This is the component that hosts virtual desktops.
- Remote Desktop Web Access: This component lets users access remote desktops or RemoteApp programs either through a Web browser or the Start menu.
So what's new?
Most of the work Microsoft has done with Windows Server 2012 Remote Desktop Services is on the back end, particularly involving the virtual desktop provisioning process.
Simpler desktop collection creation
It's now possible to use a virtual machine (VM) that has been prepared with Sysprep to create an entire collection of virtual desktops, without the aid of System Center Virtual Machine Manager. Here's how:
- After running Sysprep on the VM, shut the VM down and detach the Windows installation media (typically a DVD drive).
- Open the Remote Desktop Services console on the Connection Broker.
- Click the Collections tab and then choose Create Virtual Desktop Collection.
- Windows will launch the Create Collection Wizard. Click Next to bypass the wizard's Welcome screen.
- Specify a name and an optional description for the collection you are creating.
- On the next screen, indicate that you want to create a pooled virtual desktop collection and that you want to automatically create and manage the virtual desktops.
- Click Next, and select the virtual desktop that you previously created.
- It will then prompt you to either provide unattended installation settings or to use a Sysprep answer file. The option that you choose here determines the path that the wizard takes.
Things get interesting when you reach the Specify Users and Groups screen. This screen lets you specify which users should be given access to the new virtual desktops and the total number of virtual desktops to create (Figure 2). You can even assign a prefix and suffix that will be used in the virtual desktop name.
Preserving pooled desktop states
The other big change in Windows Server 2012 RDS is a stateless pooling mechanism that ensures that pooled virtual desktops remain in a pristine state regardless of anything the previously logged-in user might do.
This feature is possible because Windows directs user operations to differencing disks, thereby keeping the virtual desktop's virtual hard disk in an unchanged state. The wizard even contains an option to automatically roll back changes when users log off the virtual desktop (Figure 3).
This functionality is certainly nice, but it begs the question of what happens to user profiles. User profiles can be stored on a user profile disk (which you can configure through the wizard's next screen). The advantage of using user profile disks is that they are centrally stored and readily accessible from any VM in the collection.
The disadvantage is that the servers in the collection must have full control over the user profile disk share and users must be members of the local admin's group on the server. That raises some security concerns because users will have access to the servers, so you may be better off redirecting user profiles to a file share instead.
On the surface, it doesn't appear that all that much has changed with Windows RDS. Once you dig into the remote desktop deployment process, however, you can see that Microsoft has implemented some very welcome changes in Windows Server 2012 Remote Desktop Services.