Deploying a 2012 / 2012R2 Remote Desktop Services (RDS) farm

Deploying a 2012 / 2012R2 Remote Desktop Services (RDS) farm

Applies to: Windows Server 2012 and 2012 R2

A lot of people were pretty excited when Microsoft released RDS for 2012 and for good reason. Not only did they overcome the shortcomings of the previous release of RDS on Windows 2008 R2, they have also made it very easy to setup and configure. One of the many great features of 2012 and 2012 R2 is the ability to push roles and features to multiple servers in an environment from a single Server Manager console. Not only does this save time when rolling out a new RDS environment, it also makes it easy.

The following will cover the step by step process in deploying the base components of a RDS 2012 /2012 R2 farm. Before we begin the process, let’s look at the different roles we will be deploying.

 

Remote Desktop Connection Broker (RD Connection Broker):

Connects or reconnects a client device to RemoteApp programs, session-based desktops and virtual desktops.

 

Remote Desktop WebAccess (RD Web Access)

Enables users to connect to resources provided by session collections and virtual desktop collections by using the Start menu or a web browser.

 

Remote Desktop Session Host (RD Session Host RDSH):

Enables a server to host RemoteApp programs or session-based desktops.

 

Remote Desktop Gateway (RD Gateway):

Enables authorized users to connect to virtual desktops, RemoteApp programs, and session-based desktops on the corporate network or over the Internet.

In our deployment, we will be logged into a single server and through Server Manager we will deploy our new Remote Desktop farm. Each of the servers designated in the environment are virtual, domain joined and were created from a template with the latest Windows updates. No other special changes or configurations were done to any of the servers with the exception of the RD Session Host servers. Some applications were installed on the RD Session Host servers in order for us to deploy our RemoteApp programs.

Here is a list of the servers which will be deployed in our RD Farm:

RDBROKER01:

RD Connection Broker and RD Web Access Server

RDBROKER02:

RD Connection Broker which will be used at later time for configuring HA for the RD connection brokers in the farm.

RDSH01:

RD Session Host servers

RDSH02:

RD Session Host servers

RDGWY01:

RD Gateway Server

Log into a domain joined 2012 or 2012 R2 server and launch Server Manager.

From the Dashboard, let’s create a new server group. This is not a requirement, however this is a good practice and helps organize the servers you will be managing.

Enter a name for the server group. Here we will call it RDS Farm.

Go to the Active Directory tab and search for the designated RD servers.

Once we find our servers, add them and hit ok.

Once the servers are added, you will see a new node in Server Manager with the server group name RDS Farm.

Now that we have all of our designated RD servers organized, go to the top right of Server Manager, click Manage and select Add Roles and Features.

On the before you begin screen, hit Next.

Here, Microsoft has separated the option of deploying Remote Desktop Services from all other roles and features. Select the option Remote Desktop Services Installation and hit next.

There are two different deployment types: Standard and Quick Start. Quick start is an option to be used mainly for testing purposes or for a proof of concept. The Quick start option will deploy each role for Remote Desktop Services on a single server. In this case we are doing a full deployment and will use the standard deployment option. Select Standard deployment and hit next.

There are two different deployment scenarios. The first is for a Virtual machine-based desktop deployment (VDI). Since we are focusing on the traditional form of Remote Desktop Services, we will choose the Session-based desktop deployment option. Click next.

On the Review Role Services screen it will list a description of the three minimum roles required for the deployment. Review the items and hit next.

Now we need to specify which server will be our RD Connection Broker. In our environment we have already determined the server RDBROKER01 will be our RD Connection Broker. Select and add RDBROKER01 and hit next.

The RD Web Access server has a very small footprint and a lot of times it is easier and more practical to share this role on the designated RD Connection Broker server(s). In some big environments, the RD Web Access role can be installed on its own servers, however for our environment we will be adding the role to our designated RD Connection Broker server RDBROKER01. To do this, check the box listed to install the RD Web Access role service on the RD Connection Broker server and hit next.

For the RD Session Host servers, we have 2 designated servers. Add both servers RDSH01 and RDSH02 and hit next.

On the confirmation screen we can see our proposed configuration. A message will appear stating the RD Session Host servers may require a restart. In order to proceed from this screen, you must check the box to “Restart the destination server automatically if required”. Once checked, hit Deploy.

During the deployment, you will be able to view the progress of each role as it is being deployed. Should there be any issues, it will list the issue along with an error. Wait for the deployment to be completed and hit close.

Go back to Server Manager and you will notice a new node called Remote Desktop Services. Go ahead and click on the Remote Desktop Services node.

In the Remote Desktop Services node, you will see the entire configuration for the new farm. This is where you can begin publishing RemoteApps or session based desktops, add more session host servers, configure HA for the RD Connection Brokers, etc…  It is your single console for managing and configuring the Remote Desktop Farm. THANK YOU MICROSOFT!

Now that we have our farm deployed, we will need to install certificates. A Remote Desktop deployment requires certificates for server authentication, single sign on, and establishing secure connections. These certificates should be created prior to the RDS deployment. Since there are multiple roles which require a certificate, you can use a wildcard certificate to make things easier. In our deployment, I’ve already generated a wildcard certificate and placed it in the following location: \\dc01\d$\Certs\. To begin installing the certs, click on the Tasks drop-down and select the option “Edit Deployment Properties”

Highlight the Role service RD Connection Broker – Enable Single Sign On. Then click on the “Select Existing certificate” button.

On the select existing certificate window, click on the browse button.

Locate and select the certificate and hit the open button.

Enter the password for the certificate and check the box “Allow the Certificate to be added to the Trusted Root Certification Authorities store on the destination computers”.  Hit OK.

Back on the deployment properties screen, hit apply.

Once the certificate is applied for the single sign on role service, go ahead and highlight the RD Connection Broker – Publishing option and click on the Select existing certificate button.

Browse and locate the certificate. Once found hit the open button.

 

Enter the password for the certificate and check the box “Allow the Certificate to be added to the Trusted Root Certification Authorities store on the destination computers”.  Hit OK.

Back on the deployment properties screen, hit apply.

Once the certificate is applied for the publishing role service, go ahead and highlight the RD Web Access role service and click on the Select existing certificate button.

Browse and locate the certificate. Once found hit the open button.

 

Enter the password for the certificate and check the box “Allow the Certificate to be added to the Trusted Root Certification Authorities store on the destination computers”.  Hit OK.

Back on the deployment properties screen, hit apply.

Once completed, hit OK.

You have successfully deployed a 2012 RDS farm. Now on to publishing RemoteApp programs.

User Profile Disks for RDS 2012 / 2012 R2

User Profile Disks for RDS 2012 / 2012 R2

Applies to: Windows Server 2012 and 2012 R2

Managing user profiles can be a big headache in any RDS deployment. Let’s face it, if you are not using a 3^rdparty solution to manage user settings, you are more likely to run into problems.  The most common setup we see is the dreaded roaming profile solution. Well, Microsoft finally understands the issues people run into with profiles. So, with Server 2012 they have created their own solution which integrates directly into RDS as well as VDI. This new solution is called User Profile Disks.

User profile disks centrally store user and application data on a single virtual disk that is dedicated to one user’s profile. When the user logs on, their profile disk is attached to their session and detached when the user logs out. With this process, there is no copying of files on logon or logoff. Is this the most ideal solution for capturing user settings? No, but it’s simple, free, and better than using roaming profiles. The following will cover the process of enabling and configuring User Profile Disks for an RDS environment.

Requirements:

File Share per RDS Collection

RDS Collection

In a previous article, we looked at Collections, which give you the ability to group a set of RD Session Host servers with a common set of applications and publish them to users. These can be RemoteApp programs or Session Host and VDI desktops. Within these collections, you can enable and configure user profile disks. This can be done either at the creation of the collection or at a later time after the collection has been created. For our example, we will configure our user profile disks after the collection has been created.

Here is a screenshot of the User Profile Disk screen during the creation of the collection:

If the user profile disk was not configured while the collection was being created, you can go to the properties of the collection and edit the user profile disks there. But let’s not get ahead of ourselves yet. Before we begin configuring our user profile disks, we will first need a file share to house them. For this example I’ve created a new shared folder called: \\dc01\DemoLabOfficeApps. I named the folder the same name as my collection since user profile disks are for a single collection only. So if a user is connecting to resources from two different collections, the user will have two separate profiles. As a best practice measure, I named the share the same name as the collection which will make things easier in the event I need to troubleshoot an issue. When you create the folder share, you can use the default share permissions which is everyone: read.

After the shared folder is created, open Server Manager and within the Remote Desktop Services node, select the Collection. In the top right within the properties section, click on tasks and select Edit Properties.

In the user profile disk window, go ahead and enable user profile disks and enter the shared folder path. Then hit apply.

Once it’s completed, let’s go back and look at the security permissions of our profile disk share. Here you can see the RD Session Host RDSH01 which is the only server part of the collection, now has full control to the folder:

And if we look at the share permissions, RDSH01 has full control as well.

At any point, if I decide to add more RD Session Host servers to the collection, the wizard will automatically modify the security of the folder and give full control to the new session host servers’ computer account(s). That is one less thing for an admin to think about when they are adding new hosts into a collection.

Go ahead and open the folder. There you will see a new file called UVHD-template.vhdx.

This template will be used to create the user’s profile disk. After a user logs in for the first time, a new vhdx file will be created with the user’s SID as part of the file name.

So from the outside, when we look our user profile disk folder, we will just see a bunch of vhdx files with the user’s SID as the name. It would be nice to have an option to name the profile disks with the user’s username.

Lets go ahead and take a look inside the user’s profile disk. If we right click on the user’s vhdx file (disk), we can select the option to Mount the vhdx disk. (The disk will not mount if the user is currently logged into the collection. Also, if the share permissions are kept at the default which is read-only for everyone, you will need to go directly to the file location bypassing the shared folder)

Once the disk is mounted, it looks like nothing more than a regular user profile.  If the user is logged in and browses to their profile, it will be transparent to them as well. The icon is only slightly different.

When using the default settings, the user’s profile disk will contain everything that is in a user profile.

However, you have the option of changing this. If there were certain folders you wish to exclude from the user profile disk, you can do so by adding the path under the “Exclude the following folders” section. When a user logs out, any folder in the exclusion list will not be preserved.

Another option you have is to only store specific folders on the user profile disk. Lets look at a scenario where we only wanted to keep the user’s roaming data for the user’s profile. This means folders like appdata\local would automatically be excluded and not preserved when a user logs out. Here I have selected to only keep the user’s roaming profile and registry data.

When the user logs in, their profile will look normal within their session, but after the user logs out, their profile disk will look like the following:

And if we look under the appdata folder, we will only see the roaming directory.

This option is great since it is focusing on the real important pieces of a user’s profile, however in some cases this can cause problems, especially if the users are connecting to a desktop with a customized Start Screen. They will lose their settings once they log off because these settings are held within a file called appsFolder.itemdata-ms located in the directory (AppData\Local\Microsoft\Windows). Since we have the user profile disks configured for the roaming data of a user’s profile only, we will need to include this folder to our user profile disks. To do so, click on the add button and add the directory (AppData\Local\Microsoft\Windows).

Once completed, the directory (AppData\Local\Microsoft\Windows) will now be preserved in the user’s profile disk.

As you can see, user profile disks are very easy to setup and configure. Its a great out of the box feature for any 2012 RDS/VDI deployment. However, regardless of what profile solution is used, all common best practices should still be applied which includes the use of folder redirection.