I’ll show you how you can set up RemoteApp publishing environment using three servers in about as much time as it takes to do it watch an episode of Dexter!
As crazy as it might sound, setting up a three server environment really doesn’t take much longer than a single server deployment but it offers you some fantastic flexibility and growth options. There two things that you’ll need in place before you start your timer:
- RDS in Windows Server 2012 requires Active Directory.
- Three servers running a fresh and updated install of Windows Server 2012 joined to that domain.
Once you’ve got that, break out your stop watch. I’ll race you!
We’ll be breaking out the three fundamental RDS roles, one on each server:
Remote Desktop Connection Broker. This is the “hub” of the RDS environment. It ensures that all user connections that are established to the various Session Hosts are maintained through disconnects and reconnects and play a key role in simplifying the single sign on experience.
Remote Desktop Web Access. A web site that simply hosts the list of available resources that can be reached through RDS. It also hosts an RSS feed that can be used in various places.
Remote Desktop Session Host. The server that actually runs the user processes. This is what people sometimes refer to as a Terminal Server, although that term has officially been depreciated. When a user runs a RemoteApp or connects to a Desktop, it’s running on a Session Host.
One of the great new features of the new Server Manager is that you can mange multiple servers from the one console. There is no better example of the power that this offers than in deploying and managing Remote Desktop Services.
From the new Server Manager, click the Manage menu and select Add Servers.
Search for your three servers that will be used for RDS and add them to the selected list by using the right arrow button.
Once they’ve been added to the Server Manager, click on the Manage menu and select Add Roles and Features.
In addition to being able to manage more than one server now, the new Server Manager also introduces scenario-based installation
. Remote Desktop Services is the only “scenario” installation type that is available, but that’s exactly what we want to do.
In order to use more than one server for RDS, we’ll do a Standard deployment
The Virtual Desktop Infrastructure (VDI) scenario will be used to allow each user to have their very own virtual machine, but we want to deploy the Session Virtualization
scenario which is analogous to what everyone thinks of with Terminal Services; multiple user sessions working independently on one server.
The next screen will just explain the various roles that will be deployed by using this wizard.
First we’ll select the Connection Broker
Then the Web Access server. Notice that you are given the option to install the RDWA on the Connection Broker server. This would allow you to do a Standard deployment with as few as two servers, but I prefer to leave the RDCB and RDWA on their own servers and later deploy the Gateway role to the same server running RDWA.
And finally we’ll select the Session Host server.
On the Confirmation page you’ll have to check the “Restart” option as the installation of the Session Host role requires a reboot. Then click Deploy.
After the roles are deployed and the session host reboots, the Server Manager should show you the status: Succeeded!
After clicking Close
, you’ll see a new “Remote Desktop Services
” page on the left. Select that then click on Collections
“Collections” is a new term that describes a set of services that the RDS deployment offers such as a collection of RemoteApps, Desktop Sessions or Virtual Desktops.
From the Tasks
button, select Create Session Collection
Enter a Collection Name, something clever like RemoteApps works well.
Now select your Session Host server and click the arrow to add it to the Selected list. There should only be the one server available here so it’s pretty straight forward.
The default group of users that are allowed to access the applications in this collection will be Domain Users. You can be more specific if you wish, but you can also be more specific on an individual application bases as you publish them later.
To keep things moving quickly, let’s skip the User Profile Disks for now. This is a very cool new feature of Windows Server 2012 (8 beta) that allows users on the session host to have their “local” data get automatically redirected to a different virtual hard drive instead of getting written to the actual session host server, but you can configure that later.
to finish the Collection wizard. When it’s done, you can click Close.
Now it’s time to publish the applications you really want to give users access to. From the Remote Desktop Services
page, select the new RemoteApps collection
you made and then from the Tasks
button by RemoteApp Programs, select Publish RemoteApp Programs
You can select a program from the list or click “Add Another Program
” to browse to an executable.
When you’re happy with your selection click Publish, then Close.
And that really completes the set up the Standard deployment. You now have a Web Access, Broker and Session Host deployed with applications published via RemoteApp. Way to go you!
So how to you test it out? If you want to test it from one of your new servers, let’s first, let’s turn off the IEESC. From the Server Manager, select the Local Server page and click the link next to IE Enhanced Security Configuration and set it to Off.
Now open Internet Explorer (run c:program files (x86)internet exploreriexplore.exe) and enter the HTTPS url for your RDWA server, appending /rdweb to the hostname. For this example…
This can be made easier to remember for you users by creating a DNS alias (CNAME) and even set up HTTP redirection later on.
After passing the certificate warning you’ll be promoted to run an ActiveX Control. Allow that to run and then log in.
Once connected you should see your custom list of applications that are available, so click on one of them to launch the RemoteApp.
You’ll be prompted by Internet Explorer with a warning that the Web Site is trying to start a program on your computer. It’s using the Active-X Control to launch the local RDP client (mstsc.exe). This warning can be suppressed by Group Policy once the web site certificate is replaced, but for now just click Connect.
Once connected, the application would look just like any locally installed application, but you’ll notice a new system tray icon will show that you are connected to a Remote Work Place.
And there you have it, RDS, Quick and Easy on three servers in about an hour.
Now you can install new applications and publish them to your Collection. Just like Windows 2008 R2, you can deliver these RemoteApps from RDWeb or by subscribing to the RemoteApp RSS feed.
If you want to make these applications available outside of your organization, the next step will be to deploy the RD Gateway role, or if you want to go bigger, try adding more Session Hosts, the equivalent to a RDS Farm.