Remote Desktop Services

The words “Remote Desktop” usually bring to mind the simple Remote Desktop Connection client that we have utilized for decades to remotely control servers and workstations. Remote Desktop Services is much more powerful and has also been around for many years, but it was originally known as Terminal Services. By crafting a Remote Desktop Services (RDS) environment, ideally comprising multiple Windows Server instances, you are taking your first steps into the world of virtualized desktops and centralized computing. An RDS “farm,” as it is often lovingly called, provides users with access both inside and outside of the office to a secure virtual session, within which they can run the applications they need and access the data they require in order to do their jobs. Implementing RDS can be a way to provide work-from-home capabilities, even from personal devices, and can allow companies to utilize cheaper, thin-client workstations instead...

Wherefore art thou, role?

What is the first thing you typically need to accomplish on a Windows Server instance to make it do any kind of real work? Oh yeah, install a role. The trouble with this is that our fingers get so used to muscle-memorying their way through the Add Roles and Features Wizard screens that you may already be staring at the list of Windows Server roles and getting ready to click on the one called Remote Desktop Services. Stop!

Back up. If you slow down and pay attention when you launch the wizard to install your new role, you will notice that you normally blow right past a screen that asks whether you want to install an RDS component or any other Windows Server component. RDS has an entirely separate section of the Add Roles and Features Wizard. The easiest way to deploy RDS is to make use of this second option and continue forward from here.

Figure 15.1: Initial configuration wizard for RDS

Now that you are navigating down the correct role installation...

Components of an RDS environment

RDS contains many moving parts, and you may get your fingers stuck in them if you aren’t clear on what component serves which purpose. Let’s take a few pages to describe the different RDS server roles that we are going to be working with.

Remote Desktop Session Host

The most common type of RDS server is called a Remote Desktop Session Host (RDSH). These are the most common because there are usually more RDSH servers than there are servers of any other RDS component type. All user sessions will land on an RDSH server. These are the servers doing the real grunt work: everybody logs in to RDS and they land within virtual sessions that are running on top of RDSH servers. Since every user login consumes resources (CPU, RAM, etc.) and in almost all cases an RDSH server is intended to host multiple user sessions at once, RDSH servers are typically configured to have more resources than other RDS server types.

It is important to note...

Publishing RDS sessions

RDS is all about creating a centralized computing environment for users to take advantage of and leaving resource assignment and utilization to the servers, which greatly reduces the need to care about what kind of workstation or laptop somebody is using to connect. Two primary types of connections exist in an RDS environment: publishing full virtual desktops and publishing individual applications, which we will discuss near the end of this chapter.

We are going to build an RDS environment that contains all of the components we outlined earlier, and we are going to use this RDS farm to publish full virtual desktop sessions that users will be able to log in to and work from.

When building a fresh RDS environment, it is helpful to have all of the servers you intend to include already running and initially prepped. These servers should have a final hostname, have reserved or static IP addresses, and already be joined to your domain. For my lab today, I...

RDS licensing

Every incoming connection that lands on an RDS server must have a valid client access license (CAL). These licenses are available for purchase from any normal avenue through which you purchase your Windows Server licensing, so I cannot tell you the best place to go to get these licenses, only that you need them, and how they work. There are two types of RDS CAL, and we will describe both, but the reality is that almost every RDS farm in the world uses User CALs.

User CALs

User CALs are the normal way to go. As the name implies, every user who is connecting to your RDS farm needs to have a User CAL. These CALs are installed on your Remote Desktop Licensing server, which like inside our test lab might co-exist alongside some other RDS roles, and once licenses are installed the RDSH servers check in with the Remote Desktop License server to ensure there is sufficient licensing to allow the connection to happen.

User CAL limits are not restricted at a technical...

RDS user profiles

As a generalization, user profiles in the Microsoft Windows world are fairly straightforward. A user account authenticates, usually via Active Directory, and the user is permitted log in to whatever computer or server they are sitting in front of. If this is the first time this user has logged in to this computer, a new Windows user profile is created on that computer. These user profiles, unless you have done some significant tweaking to your operating systems, all reside inside a folder called C:\Users. Additionally, a new section of the registry is created to contain settings specific to this user account.

Local profiles

When RDS began life, it was known as Terminal Server, and this default user profile behavior of the Windows world was exactly what happened on terminal servers whenever a user would log in. This means that each Terminal Server had its own C:\Users directory, and that directory could contain hundreds of different user profiles, one for...

RemoteApp

You now understand RDS topology and the steps required to publish an RDS collection, upon which virtual sessions can land and users have access to an entire virtual desktop. This, however, is much more access than companies sometimes want to provide, and it can become overly complicated for some use cases. Perhaps you only want to provide access to one or two applications when users connect; they don’t need to have access to an entire desktop where they could potentially launch anything installed on the server, or to save files within their profile. Publishing RemoteApp programs through an RDS collection is a way to publish access to a single application or set of applications from within the Remote Desktop Web Access portal.

In fact, the perfect example of a use case for RemoteApps just came across my desk last week. A doctor’s office needed to allow their local hospital to have access to one of their on-premises healthcare systems. This doctor’...

RDS maintenance considerations

Maintaining and troubleshooting RDS servers can be an art of its own. They are Windows Server instances, yes, but in many ways you treat them more like workstations, since they are the place where users log in to utilize applications and save documents. However, many different users are logged in to these “workstations” at the same time, which creates complexities we do not normally face on workstations or other types of servers. This final section is a bit of a tips-and-tricks session for some of the common maintenance considerations you will doubtless face during your RDS administration tenure.

Install mode

There is no need to re-hash this; we already covered Install mode in detail earlier in this chapter. But if there is any one thing that I find administrators forgetting to do most often when dealing with RDS servers, it is placing them into Install mode before installing applications, and even more often forgetting to do so...

Summary

Remote Desktop Services has been around for more than 20 years and is still widely used around the world. It has seen many improvements over the years and continues to be a fantastic way to provide a multi-user virtual platform for your workers, where they don’t have to worry about what local computer they are using to perform the work, and you don’t have to worry about securing whatever that device looks like. You maintain complete control over the centralized RDS compute environment, providing secure access to the resources that employees need.

In fact, RDS is still so commonly used that it has carried over into one of the most common Azure-based resource pools that I find in the SMB market. Azure Virtual Desktop (AVD), formerly known as Windows Virtual Desktop, is a way to provide users with login from anywhere to Azure-based servers that contain virtual user sessions. The capabilities in AVD are extremely similar to RDS on-premises, with the exception...

Questions

1. What RDS component is responsible for distributing user sessions among multiple servers?
2. Are RDS-related certificates defined in RDS Collection Properties or RDS Deployment Properties?
3. What is the command you should run to prepare an RDSH server for application installation?
4. What type of RDS CALs are most common?
5. True or False: To prepare a fresh Windows Server instance to become an RDSH member of an existing collection, you must first log in to that server and install the Remote Desktop role.
6. What are the four types of RDS user profiles?
7. How can you launch the Remote Desktop Connection tool in a way that allows you to RDP directly into an RDSH server that is already part of a collection?
8. Bonus question: What animals live on an RDS farm?

Join our community on Discord

Join our community’s Discord space for discussions with the author and other readers:

https://packt.link/SecNet