WinFrame which was a “special” version of Windows NT 3.5.1 that was developed by Citrix. Since then I have worked with all versions of Terminal Server from NT4 to the most recent Windows 2008 R2 which I am excited about.
This 3 part series will consist of the following articles and will provide you with step by step instructions in getting most of your Remote Desktop infrastructure in place;
- Part 1 – Installation of Remote Desktop Services
- Part 2 – Configuration of Remote Desktop Gateway and Remote Desktop Client
- Part 3 – Configuration of Remote Desktop Web Access
|Previous name (Windows 2008)||Name in Windows Server 2008 R2|
|Terminal Services||Remote Desktop Services|
|Terminal Server||Remote Desktop Session Host (RD Session Host)|
|Terminal Services Licensing (TS Licensing)||Remote Desktop Licensing (RD Licensing)|
|Terminal Services Gateway (TS Gateway)||Remote Desktop Gateway (RD Gateway)|
|Terminal Services Session Broker (TS Session Broker)||Remote Desktop Connection Broker (RD Connection Broker)|
|Terminal Services Web Access (TS Web Access)||Remote Desktop Web Access (RD Web Access)|
- Windows Server 2008 R2 is 64 bit only, meaning that RDS is also 64 bit.
- Forms based authentication for Remote Desktop Web Access
- Per user RemoteApp program filtering
- Enhancements to Remote Desktop Client experience such as multiple monitor support, Audio recording redirection and Audio and Video playback
- Windows Installer compatibility
- Introduction of Remote Desktop Virtualisation Host providing personal virtual desktops utilising Hyper-V (note: This technology will not be discussed in this series, however I will have a future post dedicated to this new inclusion)
Click on Roles located on the left navigation pane and then select Add Roles located on the right pane to invoke the Add Roles Wizard.
Select Remote Desktop Services as the role to install on this server.
The below introduction to Remote Desktop Services is displayed. Microsoft have done a great job in providing administrators with thorough documentation pertaining to the role being installed.
This is a single server setup so I will select all of the role services for Remote Desktop Services excluding Remote Desktop Virtualisation Host (this will be covered in a future post). I have provided Microsoft’s description of each service in the table below;
|Remote Desktop Session Host||RD Session Host, formerly known as Terminal Server, enables a server to host Windows-based programs or the full Windows desktop. Users can connect to an RD Session Host server to run programs, save files and use network resources on the that server|
|Remote Desktop Licensing||RD Licensing, formerly known as TS Licensing manages RDS CALs that are required to connect to an RD Session Host.|
|Remote Desktop Connection Broker||RD Connection Broker, formerly known as TS Session Broker, support session load balancing and session reconnection to the RD Session Host.|
|Remote Desktop Gateway||RD Gateway, formerly known as TS Gateway enables authorised users to connect to RD Session Host Servers over the Internet.|
|Remote Desktop Web Access||RD Web Access, formerly known as TS Web Access enables users to access RemoteApp and Desktop connection through Start Menu on a computer running Windows 7 or through a Web browser.|
Click Add Required Role Services
After you have the Selected Roles checked, click Next.
The below warning will appear advising that it is recommended to install the Remote Desktop Session Host prior to installing any “client” applications.
Because this is a new install of Windows 2008 R2, I can ignore this warning and click Next.
You will now be required to specify an Authentication Method for the Remote Desktop Session Host. The two options provided below are as follows;
Require Network Level Authentication: This is more secure as user authentication occurs before a full remote desktop session is established, however it is only supported by Remote Desktop Client 6 and greater running on Windows Vista or Windows XP SP3 (Windows 7 is equipped with Remote Desktop Client 7) as they are the only current operating systems that support Credential Security Support Provider (CredSSP) protocol. Please be aware that the CredSSP is turned off by default on Windows XP SP3 and must be turned on via the registry. Please refer to the following Microsoft KB article for more details http://support.microsoft.com/kb/951608
Do not require Network Level Authentication: This is less secure because authentication occurs later in the connection process, however is supported by all Remote Desktop clients and all versions of Windows.
More information can be found in the following TechNet article, Configure Network Level Authentication for Remote Desktop Services Connections; http://technet.microsoft.com/en-us/library/cc732713.aspx
We will select Require Network Level Authentication.
Specify your Licensing Mode
You will then be prompted to select user groups that you would like to provide access to the Remote Session Host Server. By Default, the “Administrators” group is added and I will also be adding a security group that I have created specifically for my Remote Desktop Users. Users or User groups added in this section will be automatically added to the local Remote Desktop Users group.
The next screen will allow you to configure the client experience providing your end users with similar functionality and visual experience found from a Windows 7 desktop.
I will be selecting all 3 options provided, with one of the enhancements to Remote Desktop Services in R2 being the ability to provide users with a much better Video playback experience than in previous releases. It does so by offloading the actual video playback to the local graphics processing unit. More information on Multimedia Redirection Improvements in Windows 7 and WS2008 R2 can be found here; http://blogs.msdn.com/rds/archive/2009/07/24/multimedia-redirection-improvements-in-windows-7-and-ws2008-r2-part-1.aspx
The next screen provides you with the ability to configure discovery scope for RD licensing. Following Microsoft’s recommendation, I will not configure a discovery scope for the license server and will utilise the inbuilt RDS Host configuration tool instead.
The next screen is requesting a server authentication certificate for SSL encryption. To simplify matters during the installation I will select create a self-signed certificate for SSL encryption and will discuss this in more detail in part 2 of this series. Note that using a self-signed certificate will create additional administrative overhead for administrators as the certificate will need to be exported and imported to your remote desktop client computers. Using a 3rd party certificate from a Trusted certificate authority will remove that administrative burden and provide end users with a seamless experience.
The next screen introduces Authorisation policies for the RD Gateway. Recall, the RD Gateway is designed to provide users with the ability to log onto a Remote Desktop Host via the Internet and SSL. Windows 2008 first introduced the TS Gateway which incorporated 2 types of policies TS CAP and TS RAP. These have been superseded in Windows 2008 R2 with; you guessed it, RD CAP and RD RAP.
Here is a brief primer on the two;
RD CAP (Remote Desktop Connection Authorisation Policy): Here you will specify users and groups who will have the ability to connect to a Remote Desktop Gateway Server. With an RD CAP you can also specify conditions for specific users and groups such as, you can only connect to this RD Gateway if you are using a smart card.
RD RAP (Remote Desktop Resource Authorisation Policy): After providing users and groups the ability to authenticate with an RD Gateway, RD RAP provides you with the ability to specify which computers located in the internal network are accessible to your user groups. This could be restricted to a number of Remote Desktop Servers depending on the user or group authenticating.
Add your users and groups that you would like to connect through the RD Gateway as per the below screen capture.
The next part of the wizard is all about creating your RD CAP and RD RAP. Don’t worry too much if you don’t get everything right in the wizard as all of these options are configurable post wizard installation.
Notice, I have created a specific Active Directory Group called “Remote Desktop Computers” in which I have added computers with Remote Desktop enabled.
The next part of this wizard provides you with a primer on Network Policy and Access Services.
Leave Network Policy Server selected….
The following screen provides you with an introduction to the Web Server Role that is required to be installed for Remote Desktop Web Access.
Click Next and Next again to accept the default role services options.
We are finally presented with a summary of the confirmed installation selections that we have made throughout this wizard. It is worthwhile printing and or saving this information via the available hyperlink to form part of your documentation. Kudos to Microsoft who in my own opinion have done a great job with their wizard based installations which eases the usual configuration pains associated with such an install.
Click Install. The installation process will now begin and you will be presented with the installation results screen below notifying you of completion. Click Close and then restart your server to complete the process.
Upon shutdown, restart and logon, Windows will proceed with the installation and configuration of our roles and services.
That’s it for now. In this first article of this series on RDS, we went through the process of adding and configuring the necessary roles and services associated with Remote Desktop Services via Windows 2008 R2 Server manager. In the next article, I will be discussing the Remote Desktop Gateway (RD Gateway) in some detail and will go through some of it’s configuration settings both at the server and remote desktop client level.
Welcome to the second article in this series on Remote Desktop Services in Windows 2008 R2. We were first introduced to the Remote Desktop (RD) Gateway in the first release of Windows 2008 and as previously mentioned in part 1 of this series, the RD Gateway was formerly known as Terminal Server (TS) Gateway. TS Gateway opened up Remote Access barriers providing access to our Terminal Servers via SSL or port 443, as opposed to the conventional “legacy” VPN access through either IPSEC or L2TP. In Windows Server 2008 R2, not much has changed and in today’s article I will provide you with a step by step guide on configuring your RD Gateway which will provide your remote users access to the Remote Desktop Host or RD Web Access via any Internet connection utilising Remote Desktop Connection client over HTTPS. If you missed part 1 of this series which discussed the installation of your Remote Desktop Role and services, you can access it here.
There are a number of prerequisites that are required in order for the RD Gateway to function and these were all setup in part 1 of this series. For reference I have listed these below;
- Remote procedure call (RPC) over HTTP Proxy
- Internet Information Services
In the left navigation pane of your RD Gateway Manager MMC console, click on your server and select properties under Actions. We will now go through each tab under the server properties and make any necessary configuration changes. Let’s refer to this process as post wizard configuration.
Under the General Tab, we are provided with the ability to configure the maximum number of connections that are allowed to connect to this RD Gateway. If you are concerned with server performance, we can set a hard limit of allowed simultaneous connections. We can also disable new connections if we are performing scheduled maintenance on our server.
The next tab allows us to secure the RD Gateway by using an SSL certificate. We can create a self-signed certificate (recall that this was completed during the initial install wizard in part 1 of this series), select an existing certificate that is located on the server under Certificates / Personal store or Import a certificate that we have requested via a 3rd Party Certification Authority (CA) or utilising an internal CA. It is deemed best practice to utilise a 3rd party CA that participates in the Microsoft Root Certification Members Programme alleviating the headache that is usually involved in exporting the root certificate, distributing them to your end users and then providing them with instructions on how to import them into their local machines. Utilising a self-signed certificate is usually reserved for testing purposes only, and not in a production environment, however it will suffice in this step by step guide.
The third tab introduces the RD CAP Store and provides us with the ability to utilise our local server running Network Policy Server (NPS) or the ability to specify a central server that is already configured and running NPS. This was also initially configured during the installation wizard of our Remote Desktop Services role in part 1.
The next tab, Server Farm, allows us to specify farm members for the RD Gateway. As a minimum we need to Add this RD Gateway server below as follows. You do so by entering the fully qualified domain name of the server and clicking on Add. It will then add it below under Remote Desktop Gateway server farm status as per the below screen capture.
You will notice the above warning regarding the registry not being updated. This warning will disappear and the status will change to OK after clicking on Apply.
The next tab allows you to select or deselect events that you would wish to log. These corresponding events are stored in Event Viewer under Application and Services Logs\Microsoft\Windows\Terminal Services-Gateway\. By default, all items under the Auditing tab are selected to be captured and logged. The below screen capture is an example of the TerminalServices – Gateway Event Viewer on our Windows 2008 R2 server.
SSL bridging is next and is required to be configured if you are utilizing Microsoft ISA Server to further secure the RD Gateway. Microsoft ISA Server is a great application level firewall which offers reverse proxy and can be configured to work hand in hand in providing secure access over SSL.
The last tab in the RD Gateway properties is Messaging which was not present in Windows 2008 TS Gateway. This is a welcome addition for administrators to utilise when pre-planning for system maintenance and wanting to advise users with a global system notification, and the also providing the ability to set a logon message such as the company’s logon policy.
The first area within the Messaging tab is the ability to set a timed system message with the ability to set a start date/time and end date/time.
When a user logs in via the RD Gateway, they will be presented with the following message that we configured above;
The second area under messaging allows you to specify a message such as your company’s logon policy that will appear each time a user logs into the RD Gateway remote computer. This is simply a text file with the contents within.
The below similar notice is what will appear when logging on to your Remote Desktop Host via the RD Gateway
You will notice that the system will not continue to login (the OK button is dimmed) unless you accept the terms of this policy.
The last option allows you to specify that connections to the Remote Desktop Host via the RD Gateway will be restricted to clients that support RD Gateway messaging which is anything greater than Remote Desktop Client version 7.
Now prior to connecting to the RD Gateway and testing our setup, we will need to export the self-signed SSL certificate located on the RD Gateway and install it on our client computer that we will be connecting from. The easiest way to accomplish this is to open the Certificates MMC snap-in, locate the certificate from the Personal / Certificates store, and right click, All Tasks / Export.
This will invoke the below Certificate Export Wizard.
Select Yes, export the private key.
Select, Include all certificates in the certificate path if possible
Click Next. Type and confirm a password and then click Next again.
Specify a name and location to export the pfx certificate file.
Click Next and then Finish.
We can now copy or email the exported certificate to our end users who will then install the certificate to their local personal store. This can be easily achieved by double clicking on the exported certificate and invoking the Certificate Import Wizard. Please ensure that when you come to the Certificate Store section of the Import Wizard that you select “Place all certificates in the following store” and select “Trusted Root Certification Authorities”.
Now that we have successfully imported the root self signed certificate authority, we can now test our setup and login to our remote computer via the RD Gateway. Before we begin, you need to ensure that you are running the latest Remote Desktop Connection client which is version 7. This version is already included with Windows 7 and is made available for download to Windows Vista SP1 and SP2 clients and to Windows XP SP3 clients. This can be downloaded from the Microsoft Support site; http://support.microsoft.com/kb/969084
The above article also provides you with a comprehensive list of new features and their explanations that are only possible with RDC 7 and Windows 2008 R2. I have listed these below for convenience;
- Web Single Sign-On (SSO) and Web forms-based authentication
- Access to personal virtual desktops by using RD Connection Broker
- Access to virtual desktop pools by using RD Connection Broker
- Status & disconnect system tray icon
- RD Gateway-based device redirection enforcement
- RD Gateway system and logon messages
- RD Gateway background authorization & authentication
- NAP remediation with RD Gateway
- Windows Media Player redirection
- Bidirectional audio
- Multiple monitor support
- Enhanced video playback
Click Options and then navigate to the advanced tab.
Click Settings and then select Use these RD Gateway server settings:
Enter your server name and logon method details as follows;
Then click OK. Ensure that Bypass RD Gateway server for local addresses is deselected. Navigate back to the General Tab and enter the Computer and User name details and then click Connect when ready.
The following Windows Security popup will appear asking you to authenticate prior to launching a full remote desktop session.
After entering your credentials and clicking OK, You will be prompted to accept the login policy that we specified earlier under the Messaging tab of the RD Gateway properties.
So that’s it, we are now logged in to the Remote Desktop Host via the RD Gateway. We can confirm this by clicking on the spanner located on the top toolbar which will output the Remote Computer and Gateway Server that we are connected to. It also states that the connection to the remote computer was made using a Remote Desktop Gateway server.
That’s it for now. In our next and final article I will discuss Remote Desktop (RD) Web Access and the publishing of Remote Desktop Applications, so stay tuned.
Welcome back to the 3rd and final article in this series in installing and configuring your Remote Desktop Services in Windows 2008 R2, with the focus of today’s article around Remote Desktop (RD) Web Services (formerly referred to as TS Web Services) and utilising RemoteApp to publish applications to our RD Web Access web page and to the client desktop. For those that missed the previous 2 articles, you can access these from the links below;
- Remote Desktop Services in Windows 2008 R2 -Part 1 – Installation
- Remote Desktop Services in Windows 2008 R2 – Part 2 – RD Gateway
To recap, we went through the process of installing the necessary components for Remote Desktop Services including the RD Session Host and RD Web Access role services in part 1 of this series, with today’s focus on completing and fine tuning the configuration of RD Web Access and then shifting our focus on publishing remote applications in the latter half of this post.
So let’s begin by confirming the operation of the RD Web Access role by navigating to Start / Administrative Tools / Remote Desktop Services / Remote Web Access Configuration.
Because we are running a self-signed certificate on the IIS web site you will receive the usual Internet Explorer Certificate warning. It’s safe for us to click on continue to this website.
The below RD Web Access login screen will appear. Enter your administrative network credentials and then click on sign in.
The configuration screen will be displayed in which you have the option to select a Remote Desktop (RD) Connection Broker server or specify individual RemoteApp sources.
Let me provide you with a primer on the RD Connection Broker Server. Recall this was installed back in part 1 of this series as one of the role services installed for Remote Desktop Services. Formerly known as TS Session Broker, RD Connection Broker provides enhancements and benefits to the users experiences when connecting to an RD Host Server and are accessing RemoteApp and or Remote Desktop connections. These are listed below;
- Support for load balancing amongst Remote Desktop Servers located within a single farm
- Support for seamless user reconnection with farm based setups
- A new feature in Windows 2008 R2 is the ability to combine RemoteApp sources from different Remote Desktop Session Host servers that may potentially be housing different RemoteApp programs for compatibility and segregation reasons.
- Also a new feature in Windows 2008 R2 is the Direct integration with the newly introduced Virtual Desktop Infrastructure (VDI) – (to be covered in a future post.)
1. The RD Connection Broker role service is required to be installed on a server. This could be on any server located on your network and does not necessarily need to be installed on a server running the Remote Desktop Host server or any of the other Remote Desktop Services Roles.
2. Add the RD Session Host servers that you would like to aggregate in your farm setup to the Session Broker Computers local group which is located on the RD Connection Broker server. (screen capture below)
3. Navigate to Start / Administrative Tools / Remote Desktop Services / Remote Desktop Session Host Configuration and configure each RD Session Host Server that will participate in the farm to become a farm member in the RD Connection Broker. (highlighted below)
4. Lastly, you can utilise DNS round robin with the RD Connection Broker to provide load balancing. This is as simple as creating an addition A record in DNS to point each Remote Desktop Host Server that is participating in the farm to the farm name. The farm name is specified in the Remote Desktop Session Host Configuration and is common on all Remote Desktop Host Servers. Recall that this is located under Remote Desktop Session Host configuration / RD Connection Broker / Member of farm in RD Connection Broker’s properties.
The above steps have outlined the configuration of an RD Connection Broker server and the necessary steps required to configure your farm . So going back to the RD Web Access Configuration screen we can either select “An RD Connection Broker server” as our source or individual RemoteApp sources (i.e. individual RD Host Servers).
As this is a single Remote Desktop Host setup, I will select one or more RemoteApp sources (which is selected by default), leave localhost as the source name as this is also our single RD Host Server and click OK.
The web page will then redirect to the RemoteApp Programs screen which currently is not populated with any published applications …. but not for long.
This brings us to the second part of this article, Publishing RemoteApp Programs. Windows 2008 was the first version of Windows that provided us with the ability to publish individual applications to the Desktop and to TS Web Access or should we now say RD Web Access.
Quite simply, we can only publish applications that are installed on the Remote Desktop Host. Installing client applications on a Terminal Server is not the same as installing on a client computer and to ensure Remote Desktop compatibility it is best practice to still utilise the “Install Application on Remote Desktop” mini wizard provided. This is to ensure that our applications are installed utilising RD Install mode which configures the correct registry entries for a multi user Remote Desktop environment. You can also utilise Windows command prompt to achieve the same;
Change user / install – prior to running setup.exe of the application
Change user /execute – after the application installation has completed.
For simplicity, you can access the wizard via Control Panel / Programs / Install Application on Remote Desktop.
This will initiate the wizard.
Click Next, complete the installation, and then click on Finish. Let’s install Office 2007 as our first client application on the Remote Desktop Host.
After installing Office 2007 utilising RD install mode, we now have our first application to publish to RD Web Access and to a Remote Computer desktop such as Windows 7. Lets start with the former first. Navigate to Start / Administrative Tools / Remote Desktop Services / Remote App Manager.
Under the Actions pane, click on Add RemoteApp Programs.
This will invoke the RemoteApp Wizard.
Choose the application that you would like to publish. I will select Microsoft Office Word 2007 in this example. Before clicking on next, let’s venture into the properties area as there is an enhancement made to Windows 2008 R2 over Windows 2008.
The first tab (properties) as you will see is identical to that provided in Windows 2008 with the ability to change the icon, provide additional command line arguments and a checkbox allowing us to make this published application available through RD Web Access.
The second tab (User Assignment) is new and a welcome enhancement to Windows 2008 R2 allowing us to specify users and or groups whom you want the published application to be visible to.
I will keep All authenticated domain users ticked and click OK.
Click Next to proceed with the wizard.
You will then be presented with the below summary of settings.
We have now published our first RemoteApp to RD Web Access.
If I now navigate to the RD Web Access URL from any internal client computer, usually in the form of https://servername/RDweb and login, our Microsoft Office 2007 icon will now be listed providing us with the ability to now launch published application singularly via a secure web interface.
In addition to publishing RemoteApp Programs to RD Web Access, we are also provided with the ability to publish applications via a Windows Installer Package or via the creation of an .rdp file which both can be assigned to Remote Computers running Windows 7 etc.
Quite simply, right click on the Microsoft Office Word 2007 under RemoteApp Programs within RemoteApp Manager and select either Create .rdp File or Create Windows Installer Package. You can also initiate both wizards under Actions on the right navigation pane. Both have advantages and disadvantages with the .rdp file providing you with flexibility in the distribution method in deploying applications to remote users by providing them with a single .rdp file, whereas the Windows Installer Package is more geared towards Group Policy Software installation with added benefits in specifying shortcuts locations such as specifying that the shortcut icon will appear on client computers Desktop or Start Menu Folder.
This ends the series on Remote Desktop Services. This is by no means an exhaustive complex setup but it gives you a taste of what is possible with the technology and how far it has come since the early days of Windows NT. Every setup will be different and even though I have installed all of the roles on a single server, depending on the size of your organization and deployment these can be easily split across multiple servers with farm configurations and so forth to accommodate for larger number of users.
This article has not gone into great depth or detail with regards to securing your RD Gateway and RD Web Access with trusted 3rd Party Certification Authority Certificates such as those provided by GoDaddy and Verisign, nor have we discussed potentially publishing both RD Web Access and RD Gateway using a reverse proxy firewall such as Microsoft’s Internet and Acceleration Server (ISA) 2006 and the recently announced Forefront Threat Management Gateway (TMG). Expect to see future articles on this topic.
Well, I hope you enjoyed this series and please feel free to comment about your experiences or questions you may have. As always, you can follow me on Twitter and or subscribe to my feed.