Deploying Applications Using Terminal Services Web Access
Terminal Services Web Access (TS Web Access)
enables clients to connect to a terminal server through a Web page link
rather than by entering the terminal server address in the Remote
Desktop Connection client software. This enables you to deploy
applications through the publication of URLs, which can be distributed
through Group Policy.
Unlike the similar functionality that was
available in Windows Server 2003, TS Web Access in Windows Server 2008
does not rely on an ActiveX control to provide the Remote Desktop client
connection but instead uses the Remote Desktop Client (RDC) software
that is installed on client computers. This means that to use TS Web
Access, client computers need to be running Windows XP SP2, Windows
Vista, Windows Server 2003 SP1, or Windows Server 2008.
A
drawback to deploying TS Web Access in an enterprise environment is
that TS Web Access must be installed on the terminal server to which it
is providing access. It is not possible to connect to a second terminal
server by using TS Web Access installed on the first. When considered
from the perspective of planning the deployment of applications in an
enterprise environment, it means you must distribute a different set of
URLs to groups of clients as a method of limiting the number of
simultaneous connections to TS Web Access.
In general, you should not plan to use DNS round
robin or Network Load Balancing with TS Web Access. Although these
technologies will balance incoming connections, they will cause problems
with reconnections, with clients occasionally reconnected to servers
that are not hosting a currently active session. An exception to this
rule is TS Web Access servers located at branch office locations. If
your organization has single TS Web Access servers deployed at each
branch office location, using DNS round robin and Netmask Ordering will
ensure that branch office clients will be connected to their local TS
Web Access server.
Planning the Deployment of Applications by Using RemoteApp
RemoteApp differs from a normal terminal server
session in that instead of connecting to a window that displays a remote
computer’s desktop, an application being executed on the terminal
server appears as if it’s being executed on the local computer. For
example, Figure 4
shows WordPad running both locally and as a TS RemoteApp on the same
computer running Windows Vista. The visible difference between these two
is that one does not have the Windows Vista borders and retains the
Windows Server 2008 appearance.
When planning the deployment of applications by using RemoteApp, you can use one of three methods:
Create a Remote Desktop Protocol (RDP)
shortcut file and distribute this file to client computers. You can do
this by placing the RDP shortcut in a shared folder. This distribution
method is inefficient in enterprise environments, although it can work
well in smaller, branch office situations.
Create and distribute a Windows Installer package.
Have
clients connect to the TS Web Access Web site and launch the RemoteApp
application from a link on the page. The drawbacks of TS Web Access as
an application deployment platform in enterprise environments were
covered earlier in this lesson.
Planning the Deployment of Terminal Server Farms
The Terminal Server Session Broker (TS Session
Broker) role service simplifies the process of adding capacity to an
existing Terminal Services deployment. TS Session Broker enables load
balancing of terminal servers in a group and ensures the reconnection of
clients to existing sessions within that group. In TS Session Broker
terminology, a group of terminal servers is called a farm.
The TS Session Broker service is a database that
keeps track of terminal server sessions. TS Session Broker can work with
DNS round robin or with Network Load Balancing to distribute clients to
terminal servers. When configured with load balancing, the TS Session
Broker service monitors all terminal servers in the group and allocates
new clients to the terminal servers that have the largest amount of free
resources. When used with DNS round robin, clients are still
distributed; the main benefit is that TS Session Broker remembers where a
client is connected. Thus, a disconnected session is reconnected
appropriately rather than a new session being created on a different
terminal server. The limitation of the TS Load Balancing service is that
it can be used only with Windows Server 2008 terminal servers. Windows
Server 2003 terminal servers cannot participate in a TS Session Broker
farm.
When planning the deployment of TS Session Broker
load balancing in your organization, you must ensure that clients
support RDP 5.2 or later. It is also necessary to ensure that each
terminal server in a particular farm has the same application
configuration. Configure separate terminal server farms when it is
necessary to deploy different groups of applications. For example,
application A and application B conflict when deployed together on a
single terminal server and must be deployed on separate ones. It would
be necessary to plan the deployment of
two terminal server farms, one for each application, if you need to
extend client capacity by adding additional terminal servers to support
each application.
Planning the Deployment of Terminal Services Gateway Servers
Plan the deployment of Terminal Services Gateway
servers (TS Gateway) when you need to enable Remote Desktop Protocol
over HTTPS connections to RDP servers located on protected internal
networks to clients on the Internet or untrusted networks. TS Gateway
servers are not limited to screened subnets between internal networks
and the Internet but can also be deployed to enable access to servers
that are the subject of IPsec isolation policies. For example, there
might be several terminal servers in your organization that run highly
sensitive accounting software. One method of making these servers secure
is to apply an IPsec isolation policy to them so that they can respond
only to traffic from a very limited set of hosts. You can then deploy a
TS Gateway server on your network, applying the same IPsec isolation
policy to one of the server’s network adapters. This protects the
sensitive terminal servers with multiple layers of security. Client
access to the servers is not only mediated by authorization policies on
the terminal servers running the accounting software themselves but also
by the policies applied on the TS Gateway server they must connect
through to gain access to these sensitive terminal servers.
Planning Connection Authorization Policies
Terminal Services connection authorization
policies (TS CAPs) specify which users are allowed to connect through
the TS Gateway server to resources located on a protected network. This
is usually done by specifying a local group on the TS Gateway server or a
group within AD DS. Groups can include user or computer accounts. You
can also use TS CAPs to specify whether remote clients use password or
smart card authentication to access internal network resources through
the TS Gateway server. You can use TS CAPs in conjunction with network
access protection (NAP) to ensure that clients pass a system health
check before being allowed to connect to terminal servers on a protected
network.
Planning Resource Authorization Policies
Terminal Services resource authorization
policies (TS RAPs) determine the specific resources on a protected
network that an incoming TS Gateway client can connect to. When you
create a TS RAP, you specify a group of computers that you want to grant
access to and the group of users that you will allow this access to.
For example, you could create a group of computers called
AccountsComputers that will be accessible to members of the Accountants
user group. To be granted access to internal resources, a remote user
must meet the conditions of at least one TS CAP and at least one TS RAP.
For example, you might create a TS CAP that
specifies that the Accountants group, which has authenticated using
smart cards and whose computers have passed a health check and a TS RAP,
can access the group of terminal servers that are subject to an IPsec
isolation policy. In this situation, the accountants will be unable to
make a direct connection to the terminal servers because of the IPsec
isolation policy but, assuming they meet the specified conditions, will
be able to access the sensitive application published on the terminal
servers through the TS Gateway server.
Practice: Planning Terminal Services
Tailspin Toys is an Australian company
headquartered in Sydney. The company uses a single Active Directory
forest. Regional branches are located in each Australian state and
territory as well as on both of New Zealand’s islands. Each regional
branch has its own domain in the Tailspin Toys forest. Responsibility
for software purchasing and licensing is handled on a branch-by-branch
basis by a designated licensing officer. The licensing officer is
responsible for ensuring that his or her regional branch complies with
its licensing responsibilities.
Tailspin Toys has an existing Terminal Services
infrastructure, which you plan to expand as the need for applications
installed on terminal servers continues to grow. Although Tailspin Toys
has more than 10,000 employees spread across offices in Australia and
New Zealand, only a small percentage of employees ever need to access
applications hosted on terminal servers; however, they often do so from
multiple computers. These employees primarily use two applications.
Extensive testing has revealed that installing application Alpha and
application Beta on the same terminal server leads to application
instability. At present, terminal servers are deployed either with
application Alpha or application Beta in each regional office. There are
no plans to use Microsoft SoftGrid Application Virtualization at
Tailspin Toys.
Another application that runs from Terminal
Services, called application Gamma, is used with the company’s financial
database. This application is used at the Sydney office only. As a
method of protecting the company’s financial database, you are planning
to move all servers that support the database, including a terminal
server that hosts application Gamma, to an organizational unit (OU)
named Secure Servers. The Secure Servers OU has a Group Policy object
(GPO) applied that enforces a certificate-based IPsec server isolation
policy. This means that the servers in this OU can communicate only with
other hosts that also adhere to an appropriate certificate-based IPsec
isolation policy. This provides an added layer of security to these
servers, ensuring that the only computers that can communicate with them
are authorized to do so.
▸ Exercise Plan Tailspin Toys Terminal Services Deployment
In this exercise, you will review the business
and technical requirements to plan a Terminal Services deployment for
Tailspin Toys.
1. | Twenty
members of the accounting team need access to the front-end financial
application installed on the terminal server. Which steps can you take
to allow this access without giving these users access to any other
server that is subject to the IPsec isolation policy?
Install a TS Gateway server in the Sydney data center that has two network adapters. Configure an appropriate IPsec isolation policy for one network adapter so that it can communicate with the secured servers. Configure
a TS RAP and a TS CAP that allow only the 20 authorized users from the
accounting team to use the TS Gateway server to connect to the terminal
server that hosts the database front-end application.
|
2. | What
plans should you make for the deployment of Terminal Services license
servers on the Tailspin Toys network to mirror the company’s current
software purchasing arrangements and to ensure that a license server is
still accessible in the event of a hardware failure?
Place two license servers in each domain in the forest. Set the scope on each license server to Domain. License purchasing is done on a regional basis, and each domain represents a region. Instruct
the licensing officers to purchase Per User TS CALs. These are
appropriate because only a small number of users actually access
Terminal Services but often do so from multiple computers. Instruct the license administrator in each domain to install 50 percent of the licenses on each TS license server.
|
3. | Clients
connecting to TS Alpha and TS Beta at the Sydney head office site are
reporting that performance has degraded significantly. It is likely that
the number of users at the head office that need to use application
Alpha and application Beta will treble in the next financial year. What
changes can you implement to improve capacity on TS Alpha and TS Beta to
meet this projected growth in demand?
Install two terminal server farms, one for TS Alpha and one for TS Beta. Add terminal servers to each farm as required. It
is necessary to use separate farms because application Alpha and
application Beta conflict when installed on the same terminal server.
Each server in a terminal server farm must have an identical application
configuration.
|