You can create System Center 2012 Virtual Machine Manager service templates to deploy and manage remote desktop services with scale out.
A well-designed template is something you can use again and again. You can redeploy entire environments with just a few clicks. Exceptionally well-designed templates can also scale out a service by rapidly deploying new servers. System Center 2012 Virtual Machine Manager (VMM) service templates give you a bottom-up approach to constructing and provisioning IT services.
While awesome in their automation potential, VMM 2012 service templates suffer from a perception problem. Look through current Web content and you may end up thinking these templates are designed exclusively for Web services and Web developers. They’re not.
You can make any IT service that includes servers, applications and configurations into a VMM 2012 service template—if you’re willing to do the work. One such IT service you can make into a template is Remote Desktop Services (RDS).
As the only Windows Server service regular users log in to directly, it seems like you always have to rebuild your RDS servers. Because you have to do this regularly, the VMM 2012 automatic scale-out functionality can be a perfect fit for rapidly deploying additional Remote Desktop Session Host (RDSH) servers. We’ve all wished for a better way to deploy RDS servers. With VMM 2012, we’ve got the tools for the job.
Dig through the VMM 2012 interface and you’ll find an innocuous button called Scale Out. At face value, clicking that button does little more than add a new server to a service deployment’s machine tier. You can click it all you want. Clicking it without the proper preparations won’t get you far.
It’s much easier to explain that last statement with an example. Figure 1 shows a service template for a prototypical three-tier Web service you’ve probably already seen.
Figure 1 A prototypical three-tier VMM 2012 service template.
This Web service has one machine tier each for Web server, application server and database server. It also incorporates a Microsoft Network Load Balancing (NLB) virtual IP (VIP) template to load-balance incoming Web traffic among the servers in the service template’s Web tier.
Not every service or machine tier makes a good candidate for scale out. In this example, the tier most likely to be scaled out is the Web Tier. Scaling out an IIS 7 or IIS 8 Web server requires little more than creating a new server, installing the necessary IIS role services, then pointing IIS to a network location for its Web pages.
Contrast this simplicity with the up-front effort needed to scale out other tiers. Because they contain applications and data, other tiers tend to need a far more complex configuration if they’re to be automatically scaled out. The lesson with this example is worth restating: Not every service or every tier is a good scale-out candidate.
That same lesson holds true for RDS. A basic RDS deployment installs three role services onto a single server: Remote Desktop Web Access (RDWA), Remote Desktop Connection Broker (RDCB) and RDSH. Of these, the most-likely candidate for scale out is RDSH.
Microsoft has made some notable adjustments to RDS in Windows Server 2012 to simplify implementation. One such adjustment is the presumption that all RDSH servers in a deployment and collection are similarly configured. Each RDSH server in a Windows Server 2012 RDS deployment and collection is presumed to contain the same applications and configurations as the next.
While this requirement might initially seem constricting, it greatly simplifies deployment automation. More concurrent RDS users require more RDSH sessions. At some point, you’ll need more RDSH servers to support that increased user load. Because every RDSH server must be the same as the one before, each new server can start its life from a common virtual machine (VM) template.
That’s the good news. The bad news is you can’t simply click the VMM 2012 Scale Out button (see bottom right of Figure 2) and expect the new server to automatically begin serving up sessions. You’ll have to add newly provisioned RDSH servers into the existing RDS deployment and collection. In earlier versions of Windows, this step required manual intervention. In Windows Server 2012, you can automate this with a few well-positioned Windows PowerShell cmdlets.
Figure 2 The Scale Out button in VMM 2012.
Here’s a step-by-step process you can implement to build your own reusable—and scalable—RDS service template in VMM 2012. The first step is perhaps the easiest, because you’ve likely done it before. Create a VM template in VMM 2012. This is one of the most fundamental activities in VMM, and is documented in the TechNet Library article, “Creating Virtual Machine Templates in VMM.”
There’s obviously a bit of art in the science of creating this VM template. You’ll be using it to rapidly deploy RDSH servers in the steps that follow. That means your template must be ready for automatic deployment. You can choose to install applications directly into the template or deliver them on demand with an automated solution such as System Center Configuration Manager or App-V.
This VM template becomes the starting point for all the VMs you’ll provision to your RDS service. Make sure you configure the template’s hardware profile and guest OS profile to match whatever configuration any RDSH server should have when it’s deployed later.
This VM template is the basis for your VMM service template. That service template will contain two tiers: an Initial Host Tier and a second Scale-Out Tier. This separation is important because the service template only needs to scale out the RDSH role service. All other role services (and the initial RDSH instance) remain located in the Initial Server Tier.
Right-click Service Templates in the VMM 2012 Library view to create a new service template. Give the template a name and select the blank pattern. This creates an empty workspace for creating your RDS service template.
In the Service Template Designer, click the Add Machine Tier button. This launches the Create Machine Tier Template Wizard (see Figure 3). Select the option to customize a copy of an existing VM template and click the Browse button to specify the VM template you created in Step 1.
Figure 3 The wizard for creating a machine tier template.
Name this first tier the Initial Host Tier in the wizard’s Additional Properties page. Leave that page’s other settings unchanged. Select a hardware profile in the wizard’s Configure Hardware page and then a guest OS profile in the Configure Operating System page.
Pause for a minute on the Configure Operating System page and take a look at its value for Identity Information. This value defines the computer name of the VM you’ll deploy. It defaults to a wildcard (“*”). This wildcard value instructs VMM 2012 to generate a unique and random name for the VM upon deployment. Our forthcoming Windows PowerShell cmdlets, however, require that we know the computer name. Consequently, we’ll need to specify it in our deployment configuration by setting it as a service template variable.
VMM 2012 accomplishes this by surrounding the variable name with the “@” symbol (see Figure 4). Here, the computer name has been set to the variable @RDSFirstServerHostname@. This use of variables in VMM service templates is a key part of what makes them highly automated. Variables like this get their values as services and are configured for deployment.
Figure 4 Set the computer name as a variable using the “@” symbol.
You’ll also want to select the RDS role services to be installed on the Configure Operating System page. Select only the following checkboxes under Roles: Remote Desktop Services, Remote Desktop Connection Broker, Remote Desktop Session Host and Remote Desktop Web Access (see Figure 5). Doing so instructs VMM to install these roles and their prerequisites as part of the VM provisioning process.
Figure 5 Here are some of the roles you’ll need.
Here’s where we need to pause a second time. Remember that RDS is a special case in Windows Server 2012. Installing its role services accomplishes little until they’re assembled into a deployment and collection. This normally happens in the Server Manager GUI, but can also happen via a set of Windows PowerShell cmdlets.
You’ll create the RDS deployment and collection in the wizard’s Configure Applications page using a series of Pre-Install scripts. Microsoft somewhat cryptically refers to these as Generic Command Executions (GCEs). They can be actual VBScript, Windows PowerShell scripts, or batch scripts executed on the VM, or individual commands executed in a Deployment Order.
You’ll need five separate Pre-Install scripts. The first two force the VM to reboot … twice. Yes, you’ll need to reboot the computer twice to fully install the RDS role services prior to creating the deployment and collection.
The third Pre-Install script sets the Windows PowerShell execution policy to bypass. This bit of hacking ensures the fourth and fifth commands run silently. The fourth command (see Figure 6) launches Windows PowerShell with its -command switch to execute a specially configured New-RDSessionDeployment cmdlet. The fifth and final command launches Windows PowerShell again to execute its New-RDSessionCollection command.
Figure 6. Configure Windows PowerShell for RDS.
This list outlines the Pre-Install GCE specifics you’ll need to build this yourself. These five commands must be run in this order and with the following settings for RDS to successfully deploy:
You’ll also want to include a few extra settings in each Pre-Install GCE. First, configure each Pre-Install script with a VMM Run As account with Domain Administrator privileges. You’ll need this for the New-RDSessionDeployment cmdlet. Increase each script’s timeout setting to 3,600 seconds. Finally, click the Advanced button on the first two scripts and check the Restart Policy box, “Always restart after the script has finished running.” This should ensure the reboot occurs without generating an error.
You’ll see you’re using multiple variables (again surrounded by the “@” symbol) in these Windows PowerShell cmdlets. The variables provide the information the commands require, such as computer name (@ComputerName@) and collection name (@CollectionName@). You’ll be prompted for the @CollectionName@ value in the deployment configuration. The @ComputerName@ value is a built-in variable that automatically translates to the server’s fully qualified domain name (FQDN).
Click through to complete the wizard. You’ve now constructed a single-server RDS service template that you can use to test a deployment. To do so, click the designer’s Configure Deployment button and work through the deployment wizard (see Figure 7). Note the values for CollectionName and RDSFirstServerName that require specification under the Settings tab prior to deploying the service.
Figure 7 The deployment wizard for configuring deployments.
A VMM 2012 service template is designed to deploy a functioning service with the single click of a button. Accomplishing this feat requires populating the service template with all the configurations a deployment requires if it’s to complete successfully and silently. That’s why this requires a fair bit of effort. This becomes especially important if you intend to add later automations via System Center Operations Manager and System Center Orchestrator.
The VMM service template you just created only supports a single-server configuration, but you want a scale-out solution for RDSH. To get that scale out, you’ll need a second machine tier. Begin by deleting any deployed services associated with your RDS service template. You could also make a copy of that initial service template.
Right-click to open the template in the designer. Then click the Add Machine Tier button. In the first screen of the Create Machine Tier Template Wizard, choose to customize a copy of an existing VM template and select the VM template you created in Step 1.
This time the wizard’s Additional Properties page requires some extra attention (see Figure 8). This second tier will need the preferred deployment order and preferred servicing order set to 2. This ensures the VMs in this tier get provisioned after those in the first tier. This tier must also be configured for scale out with a default instance count of one and a maximum instance count of five (or whatever value your needs require).
Figure 8 You can set additional properties for the Scale Out Tier.
Configuring the tier like this instructs VMM to configure a single VM during initial deployment and allow a maximum of five VMs later on. Creating an availability set for the tier will help during later updates to VMs in this tier.
In the wizard’s Configure Hardware and Configure Operating System pages, you’ll use settings similar to those in the initial tier, with a few exceptions. For your first exception, set the identity information value to RDSH## (see Figure 9). Scale out requires that you use naming wildcards, which are set using the “#” operator. This setting gives each new VM in the tier the next available number, from 1 to 99.
Figure 9 Set the identity information for the Scale Out Tier.
For your second exception, select only the RDS and RDSH role services in this tier. As mentioned earlier, this tier only supports scaling out for RDSH. The other RDS role services need not apply.
The GCEs you’ll configure in this tier’s Configure Applications page are also slightly different. Unlike the first tier, where you created a new RDS deployment and collection, this time you’re merely adding a new server. Doing so requires slightly different cmdlets. Run these cmdlets in order and with their variables to successfully add the host:
As before, increase the script timeout on each command to 3,600 seconds and adjust the restart policy on the first two. Click through the remaining wizard pages to complete your Scale Out Tier.
Your service template should now look like the template in Figure 10. You can see the Initial Host Tier alongside the new Scale Out Tier. Click the designer’s Configure Deployment button to begin deploying this service to your Hyper-V host group or cluster.
Figure 10 Your multi-server RDS service template with scale out.
Deploying the two-server tier can take a while—as long as 30 minutes on some hardware. Once it’s deployed, test your work by navigating to the VMM 2012 VMs and Services view to inspect the service you just created (see Figure 11). Note the Scale Out button on the button bar. You can now click that button to deploy a new RDSH host to your RDS deployment and collection.
Figure 11 This is how your deployed RDS service should look.
There’s plenty of up-front work here, but the payback in investing the time to silently deploy these configurations is the ability to rapidly rebuild or scale the service whenever you want. You can now delete and recreate this service—a regular activity in many IT shops—with just a couple clicks in the VMM interface. You can also easily update your services. Just make changes to the VM template and then redeploy the service. You’ve never had it so easy in managing RDS.
Next time, I’ll show you how to scale in that same service. You’ll be able to integrate this process with Operations Manager and Orchestrator for even more automation for your RDS environment.
Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Geek of All Trades tips and tricks at ConcentratedTech.com.