Virtualization: VDI made easy
There are new options for deploying and managing your VDI environment with Windows Server 2012 RDS.
Kristin Griffin and Freek Berson
Every release of Terminal Services—renamed Remote Desktop Services (RDS) in Windows Server 2008 R2—has become more powerful since the first. That was Microsoft Terminal Services in Windows NT Server 4.0, Terminal Server Edition, back in 1999. It has gone from being a simple LAN-based desktop-sharing service to a complete solution offering secure local and remote access to both single applications and full desktops. It now presents applications, sound and even video over high-latency connections.
The latest version of RDS is similar to its predecessors in that it improves the UX over previous versions. What’s somewhat different is that a lot of work has gone into the manageability side. As RDS becomes more powerful in delivering virtual desktop infrastructure (VDI), it has also gained more management tools. This led to an awful lot of tools.
With Windows Server 2012, RDS has become more powerful in terms of what it can do, but also simpler to use. Many of the tools from previous versions have been combined into one. Now you don’t have to move from tool to tool to do related tasks.
VDI has also moved to a more results-oriented deployment model. It uses new wizard-driven, scenario-based installation options. Choose a desired end result, and the wizard will install and configure the required role services (even across multiple servers) to achieve the desired outcome.
Over the next few months, we’ll walk you through deploying and managing VDI in Windows Server 2012. We’ll start out with a single-server deployment you can use for basic testing. Then we’ll follow with a standard deployment using multiple servers. We’ll talk about how to manage VDI role services using Server Manager and Windows PowerShell. Once you’ve got basic virtual machines (VMs) or session-based desktops working, we’ll enable secure remote access with Remote Desktop Gateway (RD Gateway) and simplify the UX by publishing selected applications to Remote Desktop Web Access (RD Web Access).
We’ll also be looking at how RD Web Access can be branded and customized. Because certificates play an important role in setting up your environment securely, we’ll also devote an article specifically to installing and configuring SSL certificates for all the VDI role services. When the core components are working together, we’ll discuss how to make each role service highly available.
Once your servers are ready, you’re prepared to make VDI complete by delivering applications to your users. We’ll talk about user profile disks, which let you deliver a personalized environment for your users—including some settings you can’t store in the profile. Then we’ll talk about how to publish applications and desktops to users and look at the various ways users can access these.
Finally, for those delivering full desktops, we’ll show how to create a custom desktop, including how to manage the new Start screen. No discussion of VDI is complete without talking about licensing, so we’ll round off the series there. Look for these articles over the next few months in TechNet Magazine.
You may wonder why we’re referring to RDS as VDI. Microsoft is now using the term VDI when referring to any deployment that uses the RDS role services. It further describes two flavors of VDI, referred to as “deployment scenarios”:
- VDI session-based deployment: In the distant past, this was known as Terminal Services, or more recently as RDS. This means a deployment will use Remote Desktop Session Host (RD Session Host) servers, Remote Desktop Connection Broker (RD Connection Broker) and RD Web Access to deliver desktop sessions and RemoteApps housed on RD Session Host servers.
- VDI VM-based deployment: In Windows 2008 R2, this was called VDI or “pooled or personal VMs.” This new term refers to a deployment using the Remote Desktop Virtualization Host (RD Virtualization Host) and RD Connection Broker role services—as well as RD Web Access—to deliver VM-based desktop sessions and RemoteApps housed on VMs running Windows 7 or Windows 8.
The manner in which you deploy and manage your VDI scenario can be drastically different in Windows Server 2012. Deploying RDS in Windows 2008 R2 meant you first had to decide which role services your RDS session-based or VDI-based scenario required and which servers would house those services. Then you went from server to server installing role services and configuring each server to be able to communicate with the other servers. You can still do this type of installation in Windows Server 2012. It’s called role-based or feature-based installation.
However, Windows Server 2012 also provides a streamlined, wizard-driven approach to basic VDI installation. You tell the wizard what servers will be part of your deployment and their role in the scenario, and the wizard installs the required role services on each server and configures the servers to communicate with each other. This results-oriented type of deployment is called scenario-based installation.
The new VDI deployment wizard gives you two scenario-based VDI deployment options: Quick Start deployment and Standard deployment. You would typically use a Quick Start deployment to create a lab or test environment. This installs the basic components needed for either session-based deployment or VM-based deployment on one server. A Standard deployment deploys VDI role services across multiple, specified servers. You would use a Standard deployment to build a real environment with redundancy, secure access from outside the corporate network and high availability (HA).
Quick Start deployment
Now that we’ve discussed the different VDI deployment options, we’ll do a walk-through of a VDI Quick Start session-based deployment, which will:
- Install the RD Session Host role service on one server
- Install the RD Connection Broker role service on the same server
- Install the RD Web Access role service on the same server
- Create a Session Collection (a collection of servers grouped and managed together as part of a session-based or VM-based deployment) called QuickSessionCollection, to which you’ll publish three RemoteApp programs and add the Domain Users security group to the collection to allow that group access to servers in the collection.
Ensure that you’ve completed the following deployment prerequisites before you start deployment:
- The server on which you install a Quick Start deployment must be running Windows Server 2012.
- The server has to be a member of an Active Directory domain.
- You must be logged on with a Domain Admins group member account.
Now you can start the deployment. Open the Server Manager console on the server from which you’d like to manage your VDI deployment. If this server isn’t your ultimate Quick Start deployment destination server, then add the destination server to the Server Manager Console by selecting the “Add other servers to manage” link on the Server Manager Dashboard (see Figure 1).
Figure 1 Select “Add other servers to manage.”
Select the server from Active Directory and click the black arrow button to move that server to the selected panel on the right of the screen (see Figure 2). Then click OK.
Figure 2 In Active Directory, you can move servers to active status.
Now click the “Add roles and features” link from the Quick Start menu (see Figure 3).
Figure 3 Now you can add roles and features.
The “before you begin” dialog shows the basic prerequisite tasks you need to finish prior to installation. Verify you’ve completed the tasks and click Next.
On the next screen, you’ll select the installation type (see Figure 4). Recall that the “Remote Desktop Services installation” is the scenario-based installation option new in Windows Server 2012. Select that and click Next.
Figure 4 Choose the type of installation you’ll be doing.
On the next screen select the Quick Start deployment type and click Next. Then on the next screen select the “Session-based desktop deployment” scenario and click Next (see Figure 5).
Figure 5 Now select the deployment scenario.
Select the destination server you’ll use for this Quick Start deployment (see Figure 6). Make sure the destination server is the only server located in the right pane (if you need to remove a server from the right pane, right-click on the server and select Remove). Then click Next.
Figure 6 Select your destination server.
The wizard will now show you a confirmation screen that summarizes what you’ve selected thus far. It will also tell you the wizard will add the Domain Users security group to the Remote Desktop Users security group on the destination server (you’ll need to adjust this group membership later if this isn’t the group of users to which you want to provide access to this server). During installation, the wizard will need to restart the destination server. Check the box next to “Restart the destination server automatically if required.” Review the confirmation information and click Deploy (see Figure 7).
Figure 7 Finally, confirm your selections.
The wizard will install the RD Connection Broker, RD Web Access and RD Session Host role services, reboot the server and then perform the remaining configuration. You’ll need to log on to the server after the automatic reboot in order for Server Manager to launch and for the wizard to finish the installation. When the wizard is finished, it will show the status of each role service as Succeeded (see Figure 8). It will also show the RD Web Access Web site URL at the bottom of the page.
Figure 8 The wizard will give you installation status updates.
Write down the RD Web Access URL because you’ll use it to test your deployment. Click Close to close the wizard.
Once you’ve finished deployment, Server Manager will have a new category in the left-hand column called Remote Desktop Services. Click this option to open the Remote Desktop Management Server (RDMS) plug-in in the right pane. RDMS is where you’ll manage your deployment. The Deployment Overview gives you a map of your deployment (see Figure 9).
Figure 9 You’ll have a visual map of your deployment.
The gray icons are role services you’ve installed (except for the RD Virtualization Host icon, which is informational only). The green icons represent role services you can add in the future. If you right-click an installed role service, a menu appears with other options specific for that role service so you can further configure your environment. You can add more RD Web Access servers, configure RD Connection Broker for HA and add more RD Session Host servers. We’ll cover managing VDI deployments using RDMS in the future. For now, just know RDMS offers other installation and configuration options.
Test your deployment by accessing the three default published applications (Calculator, Microsoft Paint and WordPad) from the RD Web Access secure Web site. Open Internet Explorer and browse to the RD Web Access URL that the deployment wizard specified (it will look something like https://your-server-name.domainname.suffix/RDWeb).
First you’ll see a warning, “There is a problem with this Web site’s security certificate.” This is expected behavior. The installation creates a self-signed certificate and binds it to port 443 for the Web site. We’ll discuss RD Web Access in-depth in a later article. For now, click the “Continue to this Web site (not recommended)” link.
Next you’ll see a pop-up box telling you the Web site wants to run the “Microsoft Remote Desktop Services Web Access Con…” add-on (see Figure 10). Select Allow.
Figure 10 Click Allow when you see this pop-up appear.
On the Web site login page, enter a username that’s part of the Domain Users security group. Your login should take the form of: domain\username. Select the “This is a private computer” option and click Sign In. Once logged on, three published RemoteApps will be available (see Figure 11).
Figure 11 Once you’re logged on, you’ll see your RemoteApps.
Click one of the RemoteApps. There will be a pop-up dialog box with a yellow banner (see Figure 12).
Figure 12 A warning banner will appear once you try to run one of the RemoteApps.
This is expected behavior. It’s alerting you the RemoteApp isn’t digitally signed and therefore the “publisher” is unknown. We’ll show you how to sign RemoteApps and avoid this warning in a later article. Click Connect and the application will launch.
That’s a quick introduction to VDI in Windows Server 2012 and how to set up a VDI Quick Start session-based deployment. Next month, we’ll walk through a VDI session-based Standard deployment. We’ll also focus on managing, modifying and customizing VDI deployments using RDMS.
Kristin Griffin is a Remote Desktop Services MVP. She moderates a Microsoft forum dedicated to helping the server-based computing community (Remote Desktop Services) and maintains an RDS blog at blog.kristinlgriffin.com. She’s a contributor to Mark Minasi’s “Mastering Windows Server 2008” (Sybex, 2008) and “Mastering Windows Server 2008 R2” (Sybex, 2010). She also coauthored “Microsoft Windows Server 2008 Terminal Services Resource Kit” (Microsoft Press, 2008) and “Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit” (Microsoft Press, 2010) with Christa Anderson. She moderates and answers questions on the Microsoft RDS TechNet Forum.
Freek Berson is a Remote Desktop Services MVP. He’s an infrastructure specialist at Wortell, where one of his focus areas is desktop virtualization. Berson blogs at themicrosoftplatform.net. He also moderates and answers questions on Microsoft TechNet Forums and creates new content for TechNet Wiki.
- What’s New in Remote Desktop Services
- Test Lab Guide: Remote Desktop Services Session Virtualization Quick Start
- Windows 8 / Windows Server 2012: Remote Desktop Management Server
Q. How do we use the Remote Desktop Services (RDS) installation wizard if the server is part of a workgroup and not a domain member?
A. To use the new management capabilities for virtual desktop infrastructure (VDI) in Windows Server 2012, you’ll need an Active Directory Domain. The RDS deployment option also requires Active Directory. You can still deploy VDI role services on a server that’s part of a workgroup by running a role-based or feature-based installation. However, Remote Desktop Management Server (RDMS) won’t be available to manage or maintain your deployment. You’ll have to rely solely on Windows PowerShell. We recommend deploying Windows Server 2012 VDI capabilities on servers that are Active Directory Domain members.
Q. How come the Remote Desktop Gateway (RD Gateway) and Remote Desktop Licensing (RD Licensing) role services aren’t installed when I run a VDI session-based Quick Start deployment? How do I add them to a Quick Start deployment Session Collection?
A. The RD Gateway and RD Licensing role services aren’t included in the initial Quick Start and Standard deployments. However, you can easily add them to a session collection from the Deployment Overview panel of the RDMS console. Simply click on the role service you want to add and choose the server to which you want to deploy the role service. We’ll cover this process in more detail in the future.
Q. I’ve run through a Quick Start VDI session-based deployment, but it didn’t seem to work. There’s no session collection created in RDMS. How could this have happened, and how do I fix it?
A. This seems to be caused by logging back onto the server immediately after the automatic reboot initiated by the installation wizard. The Server Manager automatically launches when you log on (unless you’ve changed this default action). This causes the wizard to continue the Quick Start deployment and perform the post-installation configuration. However, in some cases not all RDS services are running yet. This can cause installation to fail, resulting in the error: “The post-installation configuration did not complete.”
When you close this dialog and try to open Server Manager and RDMS, you’ll get the message: “A Remote Desktop Services deployment doesn’t exist in the server pool.” To fix it, simply re-run the install. This will trigger a re-run of the post-installation configuration. Then the wizard should continue and finish correctly. For future installations, once the server reboots, wait approximately 30 seconds to log in or make sure Server Manager is configured not to start upon logon. Manually launch Server Manager after allowing all services to start.