Clumsy Bird Flying

Wednesday, 4 July 2012

Windows Terminal Services has come a long way since its infancy and
has improved with every version of Windows, and Windows 2008 R2 is no
exception. There are even noticeable differences between Windows 2008
and Windows 2008 R2 and should be highly considered as a worthy upgrade
for those currently running older versions of the Windows component. I
first began working with Terminal Server technologies back in the day of
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;

In Windows 2008 R2, Terminal Server and its underlying components is
now referred to as Remote Desktop Services (RDS). The below table is a
snippet directly from TechNet outlining the renaming of Terminal Server
and it’s services;

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)

Before delving into the step by step guide I will quickly highlight
some of the enhancements and improvements that have been incorporated in
this release; This is by no means a comprehensive list, however I have
provided a number of links at the end of this post to TechNet articles
outlining What’s New in RDS.

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)

So let’s begin the installation by Navigating to Start /
Administrative Tools / Server Manager (This post is assuming that you
already have a dedicated Windows 2008 R2 server setup)
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.
Click Next
Select Remote Desktop Services as the role to install on this server.
Click Next.
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.
Click Next
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.

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.

Adding the Remote Desktop Gateway and or Remote Desktop Web Access
will prompt you to install other services that are prerequisites such as
IIS.
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/951608Do 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.
Click Next.
Specify your Licensing Mode
Click Next
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.
Click Next
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
Click Next
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.
Click Next
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.
Click Next
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.
Click Next
The next part of this wizard provides you with a primer on Network Policy and Access Services.
Click Next
Leave Network Policy Server selected….
Click Next
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.
Part2
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

Let’s begin by navigating to All Programs / Administrative Tools /
Remote Desktop Services / Remote Desktop Gateway Manager. You will be
presented with the below screen.
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.
Click Next
Select Yes, export the private key.
Click Next.
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

From a client machine running RDC 7, navigate to Start / All Programs
/ Accessories / Remote Desktop Connection or just search for mstsc.
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.
Step3:
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;

RD Web Access is a component within Remote Desktop Services in
Windows Server 2008 R2 which provides your remote users with the ability
to access network published applications via Internet Explorer over SSL
or commonly referred to as HTTPS. This type of access breaks all
barriers and restrictions where traditional VPN’s were IPSEC based or
L2TP and usually required special software to be installed on the client
machine which in itself required special configuration. Not only was
it cumbersome and problematic to setup for the non IT savvy, it usually
caused potential problems for remote workers that were connected behind
restricted Internet connections that only opened up a limited number of
ports, namely HTTP and HTTPS. This is where SSL based VPN’s such as RD
Gateway (introduced in part 2 of this series) and RD Web Access come into play.
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.)

Considering that this is a basic single server Remote Desktop Host
setup, we do not require to setup the RD Connection Broker, but I will
outline the steps for convenience if you decide to go down this path;
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.
Click Next.
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.
Click Finish.
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.