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 that you can use when you publish applications for your users. You'll need to create an application publishing strategy that answers several questions, among them: Will you publish the full Windows desktop or multiple individual applications? If you decide to publish multiple applications, will you publish one copy of each application or multiple copies with different options for different users?
Things to Consider when Creating your Strategy
In order to help you create your application publishing strategy, consider the 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 NT clients, there is no need for them to run a remote desktop on your MetaFrame server. Running a remote desktop in addition to a local desktop could be confusing for your users because they would have two start menus, two recycle bins, etc. Most users probably would not understand the concept of having a "local" desktop and a "remote" desktop anyway. Besides, with local Windows desktops users can access published applications in "seamless" mode, allowing the applications to look and feel like local applications. (See Chapter 9 for details about seamless Windows.)
However, if your users are connecting from client devices that do not have local Windows desktops, such as Windows CE or UNIX, then running a remote MetaFrame XP desktop could make it easier for users to run their applications. Also, some non-Windows client devices only allow one ICA session at a time; if you want to allow users to multitask you will need to let them connect to a full Windows desktop on the MetaFrame XP server since they would not be able to connect to more than one individual published application at a time.
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 published applications. Of course if users only access a few applications and keep those applications open all day then the full remote desktop is not needed.
Number of Applications per Server
If you have a lot applications installed on each of your MetaFrame XP servers then 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 have the option of publishing the desktop for the user to access their applications.
However, if a user's applications are spread across multiple MetaFrame XP servers then it doesn't make sense to force the user to connect to a published desktop on each server. If you did this 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 of the users for an application have the same configuration you can publish a single copy of that application. However, there are some situations where different groups of users need to access the same application with different parameters. If this is the case, you may need to publish multiple copies of the application.
Often times, the configuration of these applications can be set with a text file referenced via the command line when the application is launched. If you have applications like this you can create two different configuration files, one for each group, and then publish two copies of the application. You can specify a different configuration file in the command line of each published application
Consider for example a sales application called "Sales Tracker" that has a different database for each region. The first copy of this application you publish could be for the North region.
Published Application Name: Sales Tracker - North
Command Line: "m:\SalesTrack\tracker.exe /d:north.dsn"
You could then publish a second copy of the application for the south region.
Published Application Name: Sales Tracker - South
Command Line: "m:\SalesTrack\tracker.exe /d:south.dsn"
This would allow you to run the applications off of the same MetaFrame XP servers for different groups of users. You could even set the permissions of the published application so that only users from the proper region had access to their application. That way your users would not be confused by seeing multiple copies of the application. The application's permissions would cause users to only see their own copy.
What are the Published Application Strategy Options?
Given everything that you need to consider when creating your published application strategy, there are really only two options available:
- Publish individual applications.
- Publish the Windows desktop.
Option 1. Publish Individual Applications
Your first option is to publish individual applications for your users. When you do this, users will need to separately connect to each application. Once the application is launched it will smoothly integrate with their local desktops. In fact, many users will not even realize that they are running a remote ICA application (which is a good thing). Users are not running the Windows desktop from a MetaFrame XP server, published applications can be easier to secure because 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 (the server's start menu and "My Computer" are not available to the user when an application is published).
A downside to having users connect directly to published 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. However, if a user can get to a server's remote desktop there would be no security in place. One famous example is with old versions of Microsoft Word. Even as a published application, a user could click "Help | About" from within Word. From there, they could launch the System Information utility, from where they could choose "File | Run." This would allow them to run explorer.exe, thus opening up a remote desktop shell session.
Another downside to running only published applications is that non-Windows users would not receive the full Windows experience. They would be forced to switch between ICA applications with their local client device, instead of the clean Windows interface.
Advantages of Publishing Individual Applications
- One user can use applications from multiple servers or multiple farms and geographic locations.
- Seamless windows.
- Can be easier to secure.
- Works well with NFuse web portals.
Disadvantages of Published Applications
- No desktop for non-Windows users.
- False sense of security.
- Many published applications to manage.
Option 2. Publish the Server Desktop.
In shear contrast to publishing individual applications only, you can choose to give users access to MetaFrame XP applications via a published desktop. This allows users connecting from non-Windows clients to get the full Windows experience (although only you can decide if this is actually a good thing). Users will be able to quickly switch between applications because they will all 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. There are, of course, some companies that use the full remote desktop and completely lock it down with policies. This protects the servers from users who would otherwise try to change important settings. Some of these locked down desktops have no icons, just a start menu with a few programs. (See chapter 5 for details.)
Remote desktops are not convenient if a user needs to connect to applications that are on multiple servers because the user would then need to run multiple remote desktops. Also, Windows-based clients already have a local start menu, so the duplicate start menu that is presented via the remote desktop ICA session can be confusing. With remote desktops, the ability for users to do those "little things" is a double-edged sword. End users could potentially have access to a lot 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 15 for details.)
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.
Applying Published Application Strategy in the Real World
In most environments, the manner in which end users access applications depends on many factors. Almost never is the configuration identical for all users across the board. For example, many companies have task-based workers that only use three or four applications per day, all day, every day. For these users, 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 more information about thin client devices and chapter 5 for more information about 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 ICA sessions. They often connect to the published applications directly (without first accessing a published desktop). These published applications fully integrate with their local desktop computers via Seamless Windows.
It's also possible to mix both of these scenarios in the same environment. In fact, many companies have these two environments mixed on the same servers with the same applications-some accessed directly as published applications and some accessed via published desktops.