After we deployed our Remote Desktop Services infrastructure and licenses it, we can start publishing desktop connections and applications to our internal users. I’ve said internal users, because to make the applications and desktops available for users outside the company, we need to deploy at least one RD Gateway server, which I’m going to discuss in a future article. Once the applications and desktop connections are published, users can access them by using the web portal provided by our RD Web Access server or by using the RemoteApp option in Windows. From here on, they can work exactly like they’ve been working on a physical PC, but instead they might be working all the way across the world.
The first benefit in using a published application or desktop connection, starts with security. Since they run in our private datacenter, we can provide applications and desktops that handle sensitive data to our users because no data or details about the application/desktop will ever appear on the physical device it is accessed from. Plus, no one can see what they are transferring over the wire since all the traffic is encrypted.
The second benefit I can think of is the ease of management. If a new version of let’s say Office needs to be deployed to our users, all we need to do is upgrade the application on our RD Session Host servers and republish it. No more extra traffic on the network, no more deployment software needed for this and users can be offline while we upgrade the application(s).
The third benefit and the last one I want to mention here in order to keep it short, is the advantage to use mixed or legacy systems. Even tough Windows XP and server 2003 are EOL (End of Life) some organizations might still use them. Using RDS you can run remote desktops and applications from this systems or any other one for that matter, as long it runs Windows.
In this first section of the article we are going to publish desktop connections, and after we successfully done this we will continue by publishing applications for our users.
Now, if we open the web page portal of our RDS infrastructure we can see that is empty, no applications or desktops.
To fix this, first we need to create the so called session collections. Open Server Manager, click the Remote Desktop Service node and from the Overview page click the Create session collections link. We can also do this from the Collections node and click Tasks > Create Session Collection.
[notice]In order for this to work you must use the Server Manager console from where you deployed your RDS infrastructure. If you can’t remember which one is it, choose a random server from your environment that runs at least Windows server 2012 and add all the RDS servers to the server pool.[/notice]
The Create Collection wizard opens. In the Name field, type a name for this collection then provide a description. Bear in mind that the name you type here will be displayed to uses when they log in to the RD Web Access page, so make sure you put something descriptive. Click Next when you’re done.
From the servers pool list select the RD Session Host server(s) you want to add to this collection then click the right hand side arrow to add the server(s) to the Selected list. If we add to this collection more than one RD Session Host server, users will be balanced and evenly distributed across them. Later in the article I will show you how you can override this in case one of your servers has more resources and can handle a much higher number of users.
In the Users Groups window we can specify the users or groups that can access this collection. If the user is not in the list, or is not part of a group that is in this list it will not see the collection in the RD Web Access page.
Here we have the option to specify if we want a profile disk for our users (UPD -User Profile Disk-), and since we are on the subject I want to stop for a second here and explain this option so you better understand what’s with the user profile disk (UPD).
This will create a .vhdx file on the path we specify in the Location of users profile disk field for every user that logs on. This .vhdx file will keep the profile for that user, and every user that logged on once will have a file like this created. The name of the UPD will have the user’s SID in it. If we don’t specify a UPD, all changes and files from that user’s session will be lost once the user logs off. As you might notice, there is also a special file created there, the UVHD-template.vhdx file. This is the base template file and is created upon initial configuration of the UPD. By using this template the UPDs are created for every user that logs on for the first time, and when they log on, the .vhdx is mounted on the fly to C:\Users\<username>. From here on everything that will be stored in the user profile, is now immediately saved to the .vhdx that is tight to the user.
Bear in mind that if you specify a file server share in the Location of users profile disk field, every time a user logs on, logs off, or makes some changes in his profile, the profile changes will be transferred trough the network from the RD Session Host server to the file server and vice-versa. If that’s the case, a gigabit network is recommended.
Also, we can specify the size of the user profile disk (UPD) in the Maximum size (in GB) box. Don’t give them to much space here, instead try to educate the users to save their work on your files servers or any other file sharing platform that you have in the organization. It will save you a lot of headaches later on when you need to upgrade or troubleshoot something.
Now to finish the wizard and create our session collection, on the Confirmation screen click the Create button.
The operation will not take long and in the end we should have a Succeeded message status on the Progress page.
Now if we take a look in Server Manager, we can see our newly created session collection,
ad if we click on it we get a lot of details about the collection. On the right hand side, on the Connections section we can see who is logged in, who is disconnected, and we can also end users sessions by right clicking the user name then choose Log off. One other thing that we can notice here is that the load is automatically balanced between our RD Session Host servers.
In the Properties section if we click Tasks > Edit Properties we can change quite a few settings for the collection.
In the General window we can change the collection name, the description and also if we want it to show up in RD Web Access.
If we want to remove or add who has access to this collection, we can do this from the User Groups page. As a best practice is better to work with security groups here instead of just putting users directly in this list.
The Session page is quite useful especially for those that have a RD Session Host server with fewer resources. We can configure to log off the user after he disconnects so the server has enough resources to server another client. Also, we can set how much the users can stay connected or idle before they are automatically logged off.
In the Security page we can set the encryption level between clients and the RD Session Host server(s) that are part of this collection. For most environments the default setting will work just great, but if you need a much tighter security you can set it up here.
The next one it’s a setting that you should keep in mind in case you have more than one RD Session Host per collection and the servers are not equal in resources. We can manually configure how many connections a RD Session Host server should handle or we can modify the Relative Weight option. Relative Weight is simply a way to send fewer sessions to one server than the other (a ratio). For example, if you want half of the sessions to go to one server, you would set that server’s relative weight to 50 and leave the rest at 100.
On the Client Settings page we can set-up what resources the RDP client can access when connecting to our RD Session Host server(s).
The last page is the User Profile Disks page which we already saw when we created the collection, but here we have a few extra options. If we scroll down we can configure which user folders should be stored on the profile disk and which not. I don’t know if these extra options really help us because even if we configure not to store the Music folder on the profile disk, users can always save music and videos on the desktop. As you know, they are very intuitive when it comes to this kind of stuff. I think what really helps us here is the limit that we can set on the profile disk.
The last section that I want to talk about is the RemoteApp Programs. If we click the Publish RemoteApp programs link, we open the Publish RemoteApp Programs wizard. This allows us to publish applications that are installed on our RD Session Host servers and present them to our users trough the RD Web Access portal. On thing to keep in mind is that you can’t publish both, applications and remote desktops on the same RD Session Host server(s). If you do, the Remote Desktop will be unpublished and applications will take priority. There is a way to publish applications and remote desktops on the same RD Session Host server by modifying the registry, but then Microsoft might hang up on you if you’re calling for support.
To have the best of both worlds, we need to create another session collection and use different RD Session Hosts servers from our RDS environment. Once that was taking care of, we can go ahead an click the Publish RemoteApps Programs link to start publishing some applications for our users.
From the RemoteApp Programs list select the application(s) you want to publish then click Next. If the application is not in the list you can always click the Add button and search for it on the RD Session Host servers that are part of the collection. Usually when applications are not displayed in the RemoteApp Programs list it means they were not installed correctly. If that’s the case follow this article on how to do it.
In the Confirmation screen click the Publish button to publish the applications then hit Close when the wizard completes.
We can further configure each application individually by right-clicking it and choose Edit Properties.
From the General page we can change the application name users see in the web portal and we can also choose if we want it to show up in the portal. The last option here is the Remote App Program folder box. If we type a name in this box we are actually putting the application in a folder and users will have to click this folder in the web portal to see the application.
If we move down to the Parameters page we can set some command-lines parameters for the application, if it supports it. Maybe you want the application to be launched maximized for the users, or maybe you publish an application that needs some parameters before starting.
Here, on the User Assignment page we can configure who can see the application in the web portal and who can’t. By default all users that have access to the collection can see the application. The list here, if its populated with some users or groups, will override the collection access level.
The File Type Associations page is a good thing, but the downside is that file association will not work for applications launched from the RD Web Access page. It will only work if the program is launched via RemoteApp (I will talk about this in a future article) or Desktop Connection.
Now if we open the RD Web Access portal, we can see our published applications and remote desktops.
Implementing something like this in an environment saves us not only money, but also time. It also speed up things for users, because all we need to do is give those users access to the session collection or application(s) and they can start working. Pretty nice I’ll say.
Want content like this delivered right to your