Geek of All Trades: Expand Beyond One

You can add a second RD Session Host server following these five relatively simple steps.

Greg Shields

Growth happens. Suddenly, you find you’re supporting more users than one server can handle. Maybe that too-powerful app starts to affect your users’ experience. Perhaps you’re protecting services when the boss demands they never go down. The solution for growth usually requires adding at least a second server. Doing that with Remote Desktop Services (RDS) is far from trivial.

Arguably the most important and challenging RDS expansion is making the jump from one Remote Desktop Services Host (RDSH) server to two. This stems from all the extra pieces you need to lay in place to support expanding past the first server.

Local user profiles are no longer an option. Previously simple GUI configurations suddenly make more sense deployed via Group Policy. Servers and applications now require extra care to deliver a consistent experience.

If you need to expand from one RDSH server to two or more, carefully consider the following steps. Not all are obvious, but all are important. Performing them correctly means making the jump so smooth, your users will never even know it happened.

Step 1: Build a Second RDSH Server

Your first task in adding a second server is—well—actually adding that second server. Build another Windows Server 2008 R2 and add the RDSH role within Server Manager. The server will then be configured for multiple user access, and its OS ready for the unique configurations required by RDS-hosted applications. Remember it’s extremely important to install the RDSH role service before installing any applications.

The RDS farm you’re about to create assumes each member server is configured the same way. The “farm” is a group of RDSH servers that each deliver the same application set. This unification of similarly configured servers beneath a single farm name is what facilitates seamless load balancing.

Once you’ve installed the RDSH role service, install whatever applications were already on the original server. These should be similarly configured as well. This configuration similarity is important, because incoming users can get routed to either server at any time. You don’t want their experience to change based on which server they’ve landed.

Step 2: Move Configuration Control to Group Policy

Use Group Policy and Group Policy Preferences to install and configure applications. Leaning on these tools to uniformly install apps and apply consistent settings makes adding future servers as simple as dropping accounts into the correct Organizational Unit. Check out September column, “The Curiosity that Killed the App,” for more details on this powerful automation.

Traditional Group Policy also helps you ensure consistent configuration of RDS settings. At this point, you’re only dealing with a second RDSH server. However, you may eventually need to add another. Shifting RDS settings to Group Policy control now ensures that later servers get the right configuration. And as you’re about to learn, RDS has almost as many control panels as configurations. Applying RDS settings with Group Policy may, in fact, be easier than doing it manually.

Pay particular attention to the settings you’ll find in Windows Components | Remote Desktop | Remote Desktop Session Host under both Computer Configuration and User Configuration. These are the core RDSH settings and nearly all of them require attention.

The settings for RDS and its applications are just the start. Windows treats users atop RDS differently than in any other access scenario. This is facilitated by controlling user settings at a policy level, just like computer settings.

Enable the Group Policy Loopback Policy setting in Merge Mode. The name of this policy setting, found in Computer Configuration | System | Group Policy is User Group Policy loopback processing mode. Enabling this policy setting in Merge Mode lets you control User Configuration settings via a Group Policy Object (GPO). Any settings that conflict with other user policies are overwritten.

Enabling the Loopback Policy setting gives you access to User Configuration settings. You can apply them only for situations when they log in to your RDS servers. You must plan for handling user profiles in a multi-server environment. Simply put, local profiles don’t work in RDS farms. Replacing them are RD Roaming Profiles. This is a special roaming profile that only comes into play when users log in to RDSH servers.

In the GPO you’ll apply to your RDSH servers, navigate to Computer Configuration | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Profiles. Enable the setting Set path for Remote Desktop Services Roaming User Profile and give it a path to a file share. By enabling this setting, your users will always get their profile settings regardless of the RDS server to which they connect.

You’ll use another Group Policy setting to protect RDS servers against unconstrained profile growth. Go to Computer Configuration | System | Profiles, and enable the setting Delete cached copies of roaming profiles. This instructs RDS servers to delete locally cached profile data the moment a user logs off, and ensures that RD roaming profiles don’t become a storage problem over the long haul.

Step 3: Install the RD Connection Broker and Assign RDSH Servers to a Farm

Now you’ve created two independent RDSH servers. Load balancing across them requires extra steps. The first is to install the RD Connection Broker role service. This handles the load-balancing sessions across multiple, otherwise-independent RDSH servers.

There is one problem with the RD Connection Broker role service. You can’t install it on a server that also hosts RDSH and is a member of a farm. Instead, find a relatively unused third server to host RD Connection Broker. This role service doesn’t consume many resources.

Once you’ve completed installation, navigate to Local Users and Groups on your newly created RD Connection Broker server. Add the computer accounts for both RDSH servers to the Session Broker Computers group. This will let the RD Connection Broker interact with your RDSH servers.

Your next task is to add each RDSH server to a farm. You will do this within the Server Manager RD Session Host Configuration node. Double-click on Member of farm in RD Connection Broker. Then click the Change Settings button (see Figure 1). Select Farm member and give the RD Connection Broker a fully qualified server name and farm name. Each member must use the same farm name.

Figure 1 Configure the RD Connection Broker settings.

Then you’ll see the Properties screen (see Figure 2). Check the box next to Participate in Connection Broker Load-Balancing. This lets you set the relative weight of this server in the farm. That relative weight quantifies that server’s capacity as compared to other farm members. For example, if your first server is “half as powerful” as the second, assign the first server’s value to be half the second server (for example:  50 and 100 or 5 and 10). The absolute value of this number is not important—only its relative value as compared to other servers.

Figure 2 The RD Connection Broker properties.

There are two other required settings. Most RD Connection Broker implementations use IP address redirection for load balancing, so the default first setting (see Figure 2) is most likely appropriate. Select the appropriate IP address in the second setting. This will be used for session reconnection once users begin accessing this server.

There’s one more step you’ll have to complete in the Server Manager RemoteApp Manager node. Click the link marked Change next to RD Session Host Server Settings, and you’ll see a control panel (see Figure 3). Replace the RDSH server hostname under Connection settings with the fully qualified name of your farm.

Figure 3 You can configure and change the RemoteApp Deployment Settings.

Step 4: Enable Network Load Balancing

Your RDSH servers are now ready to work as a farm, as opposed to individual servers. In this step, you’ll enable load balancing to distribute users across your available servers. There are two common options. The first uses round-robin DNS entries to distribute connections. While this is a simple solution, round-robin DNS can’t recognize when a host goes down. It will continue to send users to an unavailable server.

A better solution involves adding the Network Load Balancing (NLB) feature to each RDSH host. NLB, unlike round-robin DNS, can identify when hosts become non-responsive and redirect incoming users. Within Server Manager, install this feature on each RDSH host.

Launch the NLB Manager from within Administrative Tools on your management workstation. Don’t try managing NLB on either RDSH server. You might receive a nasty error message. Within the manager, right-click Network Load Balancing Clusters. Choose to create a New Cluster. While the New Cluster wizard might appear complex at first, it requires only a small amount of configuration to get started.

There are five wizard pages required to create a new cluster. In the first, enter the IP address for one of your RDSH hosts. Click Next to accept the defaults in the wizard’s second screen. In the third, click the Add button and enter an unused IP address and subnet mask. This will be the NLB cluster’s address. Provide the fully qualified server name for that cluster address in the fourth screen.

The wizard’s fifth and final screen requires the most effort. This configures the NLB cluster for load balancing RDS traffic only. As such, edit the existing defined port rule (see Figure 4) to constrain load balancing to TCP port 3389 only. You’ll also adjust the filtering mode affinity to None, which ensures all incoming traffic is load balanced.

Figure 4 Add/Edit the Port Rule to configure Network Load Balancing.

Once you’ve finished with configuration, right-click on the NLB cluster you just created and choose Add Host to Cluster. Populate the wizard with the correct information to add your second RDSH host.

There’s one more task to complete the NLB configuration. Map the NLB cluster’s IP address—the one assigned to the cluster itself—to its DNS name. Using the DNS Manager, enter this final IP address and host name mapping into DNS.

Step 5: Update RD Web Access and RemoteApp and Desktop Connection

You’ve just joined two servers into a farm. As you can see, this requires a great number of configurations across a wide array of control panels and wizards. These settings are similarly exposed inside Group Policy. This complexity highlights the notion that these settings may be more consistently configured when applied via Group Policy.

However, you’re not done yet. RDS is now enabled for user load balancing, but you have to update your mechanism for directing users to the right RemoteApp to make it farm-aware. There are two user access controls in this step: RD Web Access and RemoteApp and Desktop Connection. The following assumes that both were already configured for your original single-server environment.

Navigate once again to Local Users and Groups on each server. Ensure the accounts for both the RD Web Access and RD Connection Broker servers are members of the TS Web Access Computers group. Then open Remote Desktop Connection Manager and click Add next to RD Web Access servers (see Figure 5). If you don’t see a window with RemoteApp and Desktop Connection properties, add the server name of your RD Web Access server in the bottom box and click Add.

Figure 5 Configure the RemoteApp and Desktop Connection properties.

Now click the “plus” next to Remote Desktop Connection Manager, then right-click RemoteApp Sources, and select Add RemoteApp Source (see Figure 6). Enter the fully qualified domain name for your RDS server farm as the RemoteApp source name. This configuration points RemoteApp and Desktop Connection to the farm, instead of an individual server.

Figure 6 Add the RemoteApp source.

There is one final step. Navigate to Administrative Tools | Remote Desktop Services | Remote Desktop Web Access Configuration and login with administrator credentials. In the Configuration screen (see Figure 7), select An RD Connection Broker server. Enter the fully qualified server name of that server into the Source name box. You should now be able to click through your list of RemoteApp programs and load balance user sessions across your RDSH farm.

Figure 7 Configure RD Web Access.

Almost as Many Control Panels

There is a ridiculous amount of configuration required to expand past a single server. There are almost as many control panels as there are configurations. I hope future versions consolidate this into a simpler, more unified interface. Until then, this is what you have to do.

Many of these are necessary only during your first addition. Far fewer are required during each subsequent addition. Using Group Policy may actually be easier than using all these individual GUI control panels.

Growth does indeed happen. It occurs with users, applications and the need for high availability. Recognizing that RDS can support this growth, and being able to configure and address that support, is what defines the successful geek of all trades.

Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-trades tips and tricks at ConcentratedTech.com.

Related Content

• Geek of All Trades: Behind the Scenes with RDS
• Geek of All Trades: No MED-V? P2V XP to W7 with MDT
• Geek of All Trades: Get to that Single Image