Remote Desktops or Full Screen Applications?

Now that you know how to get your applications installed (and where to go for help when you run into trouble), we can look at some different strategies for making these applications available to your users. You'll need to create an application strategy that answers several questions, among them:

• Will your users run full remote desktops or will they simply connect to individual applications?

• If you decide to use only applications, will you configure only one copy of each application or multiple copies with different options for different users?

First be aware of how Terminal Server allows users to connect to servers and applications. The basic idea behind a Terminal Server is that it allows a user to launch a remote server desktop session. Within that session, the user can run applications and interact with the server as if it were his workstation. However, Terminal Server and the RDC client allow you (or the user) to specify an application that's launched on the server instead of launching the entire desktop, called an "initial program." These settings can be configured on the client allowing it to connect to different individual applications, even if the servers all reside in the same load-balanced cluster.

Things to Consider when Creating your Strategy

In order to help you create your application strategy, consider your answers to the following:

• What type of client hardware devices will be used?

• How many different applications will each user need?

• How many applications will be on each server?

• Will different types of users need to access the same application?

Client Hardware Devices

If your users are connecting from client devices that have a local Windows desktop such as Windows 95 or Windows XP clients, there is no need for them to run a remote desktop on your Terminal Server. Running a remote desktop in addition to a local desktop could actually be confusing because users would have two Start Menus, two recycle bins, etc. Most users may not understand the concept of having a "local" desktop and a "remote" desktop anyway.

However, if your users are connecting from client devices that do not have local Windows desktops, such as Windows CE or UNIX, running a remote Terminal Server desktop could make it easier for users to run their applications.

Number of Applications per User

If your users open and close several applications throughout the day, a remote desktop shell will probably be faster and easier to use as opposed to connecting and disconnecting to several individual applications.

If users only access a couple of applications and keep those applications open all day, then the full remote desktop is not needed. However, some non-Windows client devices only allow one RDP session at a time. If you want to allow users to multitask, they will need the ability to connect to a full Windows desktop on the Terminal Server, as they would not be able to connect to more than one individual application at a time.

Number of Applications per Server

With many applications installed on each of your Terminal Servers the chances are pretty high that all of a user's applications will be located on the same server. If this is the case, you will most likely want your users to connect to a full remote desktop.

However, if a user's applications are spread across multiple Terminal Servers then it doesn't make sense to force the user to connect to a full desktop on each server. Your users would have to navigate the full desktop shell for each different server—very confusing for them.

Different User Types for the Same Application

If all users for an application have the same configuration, you can create a single connection from the client for that application. At the same time,, there may be some situations in which different groups of users need to access the same application with different parameters. In this case, you may need to create multiple copies of the connection to the application.

Often, the configuration of these applications can be set with a text file referenced via the command line when the application is launched, or you could call a specific file from the command line such as an Access database. With applications like this you can create two different configuration files, one for each group, and then create two different connections to the application. You can specify a different configuration file in the command line of each published application

Consider, for example, a sales database application called "Sales Tracker" that has a different database for each region. The first connection to the application you could be for the North region:

• Connection Name: Sales Tracker - North

• Initial Program: c:\Program Files\Office10\ACCESS.EXE" "\\Server\Share\North.mdb

You could then configure a second copy of the application for the south region:

• Connection Name: Sales Tracker - South

• Initial Program: c:\Program Files\Office10\ACCESS.EXE" "\\Server\Share\South.mdb

Furthermore, if the application was a database application that could open a specific DSN, you could also configure it as shown below. The real trick is understanding the types of input and switches your applications can use.

• Connection Name: Sales Tracker - North

• Command Line: c:\SalesTrack\tracker.exe /d:north.dsn

You could then configure a second copy of the application for the south region:

• Connection Name: Sales Tracker - South

• Initial Program: C:\SalesTrack\tracker.exe /d:south.dsn

These configurations would allow you to run the applications off of the same Terminal Servers for different groups of users. You could then use file and share permissions to control access to the data files or even the application executables.

What are the Connection Strategy Options?

Despite the myriad considerations involved in creating your connection strategy, there are really only three options available:

• Initial program connections.

• Connections to the Windows desktop.

• Use-third party tools that enable seamless windows.

Option 1. Initial Program Connections

Your first option is to create connections to specific applications for your users. When you do this, users will need to connect separately to each application. Once a connection is launched it will immediately begin the application that has been configured and not allow the user access to the server desktop. Since users are not running the entire Windows desktop from a Terminal Server, individual applications can be easier to secure. Some of the local security policies that affect access to items such as the Start menu and "My Computer" do not need to be used since the server's Start menu and "My Computer" are not available to the user when an initial program is specified. You then use GPOs to really secure the server's desktop from the end users.

Another big "win" with this option is the ability to segregate applications. If your users must run conflicting applications, then these types of connections allow them to launch both applications without having to navigate multiple remote desktops.

A drawback to having users connect directly to applications is that it can give you a false sense of security. You might feel that the users' environment is secure because they don't have a desktop. But if a user can get to a server's remote desktop there would be no security in place. One famous example comes from old versions of Microsoft Word. Even when it ran as an initial program, users could click "Help | About" from within Word. From there, they could launch the System Information utility and choose "File | Run," allowing them to run "explorer.exe," thus opening up a remote desktop shell session.

Another disadvantage to running only this type of connection is that nonWindows users would not receive the full Windows experience. They would be forced to switch between server applications with their local client devices, instead of through the clean Windows interface.

Advantages of Initial program Connections

• One user can use applications from multiple servers or multiple clusters and geographic locations.

• Can be easier to secure.

• Connection settings can be stored centrally.

• Multiple connections to the same server can each have their own RDP settings (such as color depth, resolution, mapping, etc.).

Disadvantages of Initial program Connections

• No desktop for non-Windows users.

• False sense of security.

• Multiple connections (even to the same server) will each start their own RDP sessions.

Option 2. Server Desktop Connections.

In contrast to using initial program connections only, you can choose to give users access to server applications via Terminal Server desktop. This is the default choice and is what happens when an initial program is not specified. (This is also another reason to secure the desktop via a GPO). Users connecting from non-Windows clients with this option get the full Windows experience (although only you can decide if this is actually a good thing). They will be able to quickly switch between applications because all will be running in the same window of one server session. A full desktop will also allow users to do those "little things" that they do with desktops, like adjusting printers, using calculator, and editing files with notepad.

In general, users with access to the full desktop have a fair amount of power and often spend their entire day in remote desktop sessions. Some companies use the full remote desktop and completely lock it down with policies, protecting the servers from those who would otherwise try to change important settings. Some of these locked-down desktops have no icons, only a Start menu with a few programs. (See Chapter 6 for details.)

Remote desktops are not convenient if a user needs to connect to applications on multiple servers since that would require the user to run multiple remote desktops. Also, Windows-based clients already have a local Start menu, so the duplicate Start menu presented via the remote desktop session can be confusing. With remote desktops, providing users the ability to do those "little things" is a double-edged sword. End users could potentially have access to more than you intended. When giving users access to full desktops, even with policies in place, it is crucial that security is adequately addressed. (See Chapter 12.)

Advantages of the Published Desktop

• Quick switching between applications.

• Non-Windows client devices get the full Windows experience.

• Users can more easily do "the little things."

Disadvantages of the Published Desktop

• All applications must be on one server.

• Full Windows clients receive second Start menu and a duplicate desktop environment.

• Users can more easily do "the little things."

• Security must be carefully applied.

Option 3. Seamless Windows with Third-Party Tools

If you decide to use third-party tools, you can make applications available to users via "seamless" windows. Seamless windows are useful for users who connect from traditional Windows desktops. Terminal Server applications accessed via seamless windows look and feel just like local applications to the users. Unlike specifying an initial application for a Terminal Server, seamless applications can be dynamically resized and can fully integrate with the users' desktop.

Add-on products such as Citrix MetaFrame Presentation Server, Tarantella Canaveral iQ, DAT Panther, and Jetro CockpIT all add seamless windows functionality to Terminal Server. (A full feature-by-feature comparison of these products is available in the appendix.)

Connection Strategies in the Real World

In most environments, the manner in which end users access applications depends on many factors. Rarely is the configuration identical for all users across. Many companies have task-based workers that use only three or four applications per day, all day, every day. For these users' needs, it makes sense to use Windows-based thin client terminals configured to run remote Windows desktops. Of course, these desktops only have a handful of icons and no access to configuration information. (See Chapter 9 for about a discussion on thin client devices and Chapter 6 for information on creating the locked down desktops.)

Often, these same companies will also have users with legitimate needs for full PCs. These users, however, can still access specific applications through Terminal Server sessions. They often connect to the applications directly (without first accessing a server desktop). The applications run in a remote desktop window and allow access to the client workstation's drives, printers and COM ports.

It's possible to accommodate both scenarios in the same environment. Many companies have these two environments mixed on the same servers with the same applications—some accessed directly as applications and some accessed via full desktops.