Remote Desktop Services (RDS) is an outstanding way to provide users with access to applications and data, without those applications and data needing to reside on their local workstations. Formerly known as Terminal Services, this technology enables companies to retain control of all data and apps on centralized Remote Desktop servers, which users connect to from their workstations in order to access these items. There are two primary means of providing this information to users. The first is through a remote session, where users log into a Remote Desktop Session Host (RDSH) server and end up landing inside a session hosted on the server. This session looks and feels like a regular desktop computer to the user, as they have a full desktop and Start button and are able to launch any application available to them within that session. They are also able to save documents inside their session, keeping everything centralized. This is the most common flavor of RDS that I see used in the field and is where we will focus the majority of our administrative tasks that we discuss today.
A second way to provide data to users via RDS is RemoteApp. This is a neat function that is able to provide only the application itself remotely to the user's computer, rather than a full desktop session. This is a nice way to further restrict the access that is being provided to the user and simplifies the steps the user must take in order to access those resources.
An RDS environment has the potential to contain many servers, enough to fill its own book. Given that, let's work together to get a simple RDS environment online that you can start testing with, and provide you with knowledge of some common administrative tasks that will be useful in an environment like this.
In this chapter, you'll be taking a look at the following recipes:
- Building a single server Remote Desktop Services environment
- Adding an additional RDSH server to your RDS environment
- Installing applications on a Remote Desktop Session Host server
- Disabling the redirection of local resources
- Shadowing another session in RDS
- Installing a printer driver to use with redirection
- Removing an RD Session Host server from use for maintenance
- Publishing WordPad with RemoteApp
- Tracking user logins with Logon/Logoff scripts
I would like to take a minute and describe the different parts and pieces that could potentially make up your RDS environment. We won't be covering the installation or use of all components that might be involved with a full RDS deployment, but you should at least be aware of the components and their intended functions:
- Remote Desktop Session Host: This is the most common type of RDS server, as it is the one hosting the programs and sessions that users connect to. Depending on the size of your environment, there may be many of these servers running concurrently.
- Remote Desktop Connection Broker: This is like the load balancer for RDS servers. It distributes users evenly across RDSH servers, and helps users to reconnect to existing sessions rather than creating fresh ones.
- Remote Desktop Licensing: This is responsible for managing the licenses that are required for RDS use in a network.
- Remote Desktop Gateway: This is a gateway device that can bring remote users out on the Internet into an RDS environment. For example, a user at home could utilize the connection provided by an RD Gateway in order to access work information.
- Remote Desktop Web Access: This enables users to access desktops and applications by using the local Start menu on their Windows 7, 8, or 10 computers. Users can also utilize this to access applications via a web browser.
- Remote Desktop Virtualization Host: This is a role that integrates with Hyper-V in order to provide virtual desktop sessions to users. The difference here is that resources given to those users are spun up from Hyper-V, rather than shared resources such as an RDSH.
Many of these roles can be placed together on a single server, which is what we will be doing in our recipe to bring a simple RDS environment online. As your deployment grows and you continue to add users and servers, it is generally a good idea to make these roles decentralized and redundant when possible.