Hybrid Clients

Regardless of whether PCs are used in a limited or widespread manner, many organizations have a certain number of hybrid clients on their networks. Hybrid clients can be divided into three categories:

• Simple A simple hybrid is a client device running just enough software to interact with the SBC environment. This usually means the ICA client, web browser, and possibly a client for the management software or framework in use at your company. No data is stored locally.

• Complex The complex hybrid is a client device that not only runs the ICA and management clients, but also local applications. It may also do local file sharing and have local peripherals.

• Mobile A mobile hybrid is similar to the complex hybrid, but usually has an even greater number of local applications. Although the need for local applications used to be unavoidable, with the new ubiquitous access to Internet bandwidth (Verizon, Sprint, AT&T, Nextel, City and Airport WiFi, and Boeing's Internet access now being deployed on board airlines) many users can now utilize SBC-based applications literally any time, anywhere from their laptop devices.

Full Desktop vs. Published Applications

Citrix provides SBC administrators the option of publishing to end users a full desktop interface to the MetaFrame servers—effectively providing desktop users with a window that looks identical to a desktop PC running Windows XP Professional—or providing the user with individual applications, launching from within their local desktop or web browser environment. Which to choose depends on the overall environment, the number of applications to be deployed, and whether thin clients or hybrid clients will be used. The decision to publish individual applications or the entire desktop has many ramifications, from end-user experience and performance to security. Both of these options are available in any client type or device scenario.

Publishing Individual Applications

In the case where a MetaFrame server farm is used to deploy only one application, or a small selection of applications to end users (hybrid clients), the published application option has many benefits. A published application can be published directly to a user's Windows desktop using Citrix Program Neighborhood or directly to a web browser interface using MetaFrame Web Interface.

Published applications have the added benefit of being more secure than granting access to a full desktop because of the lack of access to common system tools, such as the Start menu and the Control Panel. Additionally, publishing only an application as opposed to the full desktop ensures that users do not have access to applications not required for their job function (as an example, non-accounting users won't see the accounting applications). In a full desktop environment, these items could allow a user to potentially harm—unintentionally or otherwise—the SBC server environment. That said, additional steps still need to be taken to secure such integrative applications as Internet Explorer and MS Office, which can still leave back doors to system utilities if not locked down with proper security policies.

Aside from security reasons, published applications also have the side benefit of consuming system resources (memory, processor, etc.) more efficiently. The reason for this lies in the fact that because the entire Windows shell is not loaded, only those resource processes required to execute the application are started (per user). Under high user loads this could mean up to 20 percent additional resources are available for either additional user connections or a better user experience for those connected.

One significant downside to published applications is that they can be confusing to end users. Users may find it difficult to distinguish between applications that are running locally and those published from the MetaFrame farm. Additionally, the fact that users cannot access some system configurations, such as printer settings, can cause challenges.

To address this issue, Citrix released Program Neighborhood Agent (PN Agent) with Feature Release 1 to provide tighter integration between locally available resources and those in the SBC environment. With PN Agent, an administrator configures the client side agent to utilize a Web Interface server. As the user authenticates, desktop objects, start menu icons, system tray utilities, and/or client side MIME type mappings are pushed down from the Web Interface server. Just as with standard published applications, the administrator has the ability to leverage existing user control mechanisms (Active Directory, etc.) by creating access objects to allow user rights to only those features they require to fulfill their job role. There are even settings to allow users to customize their own environment variables, at the discretion of the SBC administrator. The user has the benefit of the same look and feel they have always had, but with the added benefit of server centric application management and control. This is an example of a complex but elegant hybrid application deployment scenario.

Publishing the Desktop

For environments in which all or most applications will be provided to users by the SBC environment, and environments with a majority of Windows terminals, we strongly recommend publishing the full desktop as opposed to just the applications. Although publishing the full desktop requires the desktop lockdown discussed in the next section, the published desktop is simpler and more intuitive for end users. With a published desktop, end users see the full interface they are accustomed to seeing, while from a hybrid client a user will see two Start menus (if the published desktop is set up to run as a percent of screen size), making it more obvious whether they are using an application locally or from the SBC farm. Additionally, Windows terminals based on Linux do not intuitively switch between published applications, whereas if the desktop is published, the normal hotkeys and windowing controls hold true to what users are accustomed to.

When using a published desktop, the ICA client can be published to the Desktop to provide access to other applications or servers not supported on the server in which a user is logged in (this is called the ICA Passthrough feature). It is important to note though that there is a significant performance penalty associated with using the ICA Passthrough, both for the end users and in terms of server resources. If users are complaining of slow screen scroll, make sure they are not running the application through ICA Passthrough.

Desktop Lockdown

Since most organizations will utilize PCs either in full thin-client mode, or in hybrid mode, locking down the PCs is critical to keep them from continuing to be an ongoing help-desk call. Additionally, these same methods are useful for locking down the published desktop environment of the MetaFrame farm. Although the tools we recommend for locking down PCs are quite good, and will dramatically reduce the administration and maintenance required, desktop hardware failure will still generate a help desk call.

According to several studies, including one by the Gartner Group cited in Chapter 4, the PC operating system is the source of most of the support requests from users. Even though the ICA client runs on a variety of operating systems, including MacOS and Linux, this discussion will be focused on Windows client devices since they are the most common (and, therefore, most in need of being locked down).

Registry Settings

The various Zero Administration Kits (ZAK) published by Microsoft for Windows 95, 98, NT Workstation, NT 4.0 TSE, and Windows 2000 Professional, contain a wealth of information on beneficial changes to the system registry. The strategy is to make changes to prevent the following:

• Installing applications Since the PC should come to users with the necessary local applications installed, along with the ICA client for running applications from the SBC, end-user application installation should be prohibited. Upgrades or requests for new applications should go through the help desk.

• Changing system settings Even more so than with applications, desktops should prohibit users from making changes to system settings. Setting appearance or screen savers seem innocuous at first, but simple changes like this can generate calls to the help desk when they conflict with the use of a given application. We recommend preventing any change to the system settings.

• Recognizing installed hardware If the client operating system has the ability to recognize new hardware, it can prompt the user to install drivers. The drivers may conflict with other drivers or system libraries and, again, generate calls to the help desk. Even if users know how to install hardware, the standard operating system image should prevent them from doing it. Even plug-and-play devices have no place in the corporate desktop. It may seem simple to plug in a USB device, for example, since it will be automatically recognized, but quite often even harmless peripherals can wreak havoc on a system and prompt an all-day service repair call while the technician performs investigative work to try to determine what changed and how to fix it.

The methods for locking down Microsoft desktops have evolved over the years, although as we discuss next, there is still ample room for third-party providers to intervene and offer good solutions. For Windows 2000 Professional and Windows XP Professional, user and group policies are reasonably powerful and easy to change through the Policy Editor. For older desktop operating systems (Windows NT 4.0, Windows 98, Windows 95, and so on) policy tools were lacking, and thus Microsoft released scripts provided in Zero Administration Kits. For example, the ZAK for NT Workstation contains command files to install NT in an unattended fashion (cmdlines.txt), make custom registry changes for applications (appcmds.cmd), and set restricted access to the file system (acls.cmd). Be warned, the settings chosen tend to be very restricted and may cause problems with specific or custom applications. The various client ZAKs are supplied free of charge from Microsoft's web site and should be evaluated as a way to restrict user activities on the desktop. At the very least they can provide a platform from which to build custom scripts.

Note

Administrators should always extract all of the contents of a ZAK and only use those parts that look applicable instead of allowing them to auto install. The auto install components may make major modification to file system permissions and other security structures that may not be the intention during the evaluation stage.

Third-Party Software for Desktop Lockdown

In the last three years, several software providers have built tools to automate the lockdown of PCs and the PC user environment. Providers of software for restricting user activities present a friendlier interface than Policy editor and Regedit32 and can track and roll back changes, as well as provide myriad management and performance optimization features. We have utilized tools from four software vendors that provide lockdown for both the server user environment and the desktop environment. Although there are many other vendors, the four that we have used and can recommend for desktop lockdown are RES, NCD ThinPath PC, triCerat, and AppSense. Applications from these providers make user profile, policy, or direct registry changes to a workstation based on either a standard image or a centralized rules database. The rules can be assigned by user, group, application, or even time schedule. Though the result of these applications' activities are to change the registry on the client device operating system—something that can be done manually—these vendors do it in a way that is easy to manage and scales across a large organization. Perhaps most important, these applications are compatible with both distributed and centralized application hosting. They can impose the same restrictions on an application hosted from a MetaFrame XP server farm as they can on one running on a local desktop.

Profiles

Although profiles will be the main topic of Chapter 15, they are worth a quick mention in this section, as they impact the overall client design. Windows Server 2000 and 2003 utilize user profiles to specify a variety of user environmental and applications settings. Important items like MAPI and ODBC settings are maintained in the user profile. Because of their importance to user functionality as well as their tendency to grow fast and large like pre-pubescent elephants, user profiles represent a difficult challenge in the design of the system. For instance, they can be configured as mandatory, roaming, or a hybrid of a mandatory and roaming profile. A great deal of industry work has gone into creating some best practices for hybrid user profiles, as well as development of best practices for roaming profiles. Even the lockdown applications discussed earlier address user profiles, and some of them claim to alleviate the need for roaming profiles all together.

We recommend using roaming user profiles, but have ourselves used the tips and tricks provided in Chapter 15 to keep a tight reign on the size and storage of the roaming profiles. For the purposes of design, be sure to follow the steps laid out in Chapter 6 for network design to ensure that sufficient network bandwidth and disk space are allocated to support roaming profiles. From a purely client device standpoint, it is nice to note that Windows terminals are not affected by user profiles, although any published applications they log into will be. On the Hybrid PC side, administrators should be careful to keep the PC profiles separated from the Terminal Services Profiles, as discussed in Chapter 15.

Software Distribution and Server-Based Computing

Since many enterprises today utilize software distribution applications like Microsoft SMS, the question arises about how these will integrate and how this function will be performed in an SBC environment. The answer is threefold:

1. One of the clear advantages of server-based computing is that we no longer need to install, configure, and maintain applications on the desktop. Thus, unless the desktops will be used in Hybrid mode, the software distribution headache and accompanying software tools will disappear at the desktop level.

2. The only exception to point 1 is the ICA client, which must be distributed, configured, and maintained on all client desktops. Although a software distribution tool can be used for this purpose, we recommend using Citrix Web Interface for MetaFrame to deploy the ICA client. When a desktop uses a web browser to navigate to the MetaFrame Web Interface site and clicks an application icon, the ICA client will download and self-configure.

3. Software distribution automation can be a significant time saver at the server level for large enterprises with a significant number of servers. In an SBC environment, the applications must be installed on all of the servers serving them, which can be a significant undertaking for organizations with 10–1000 MetaFrame servers. Citrix provides a tool for this purpose, MetaFrame Installation Manager, embedded in MetaFrame XPe, that we will cover in depth in Chapter 13.

The ICA Client for Hybrids

In Chapter 3, we presented the connectivity options of the ICA client, including Program Neighborhood, MetaFrame Web Interface, and MetaFrame Secure Gateway. In this section, we will focus on the differences between the various hybrid clients you might consider.

Significant Platform Differences

For purposes of this discussion, the 32-bit ICA client for Windows will be considered the functional base for all other client versions. Although in the past other clients typically contained fewer features or worked slightly differently, Citrix has dedicated significant resources to ensure that other devices have similar feature sets and performance.

• Macintosh The ICA client for the MacOS prior to OS X was missing many features such as support for audio, peripherals, and remapping of local ports. But with OS X, Citrix released a new, full-featured client that has nearly identical features to the Windows 32-bit client. Like all non-Windows ICA clients, the Mac client provides access to Windows key sequences through local key combinations.

• Linux/UNIX The Linux/UNIX clients offer complete functionality for any non-Windows ICA client, but not all features are supported on all flavors of UNIX. Check your platform against the feature list in Chapter 14 for specific support. The Program Neighborhood is not supported, but virtually all other functions are present. Windows key sequences are provided through local key combinations designed not to conflict with the ALT key sequences normally reserved for the X-Window System, though these can be reprogrammed if desired.

• Web Interface clients MetaFrame Web Interface allows administrators to configure the web site to provide a specific ICA client or an ICA client based on client operating system, or to allow the user to choose which ICA client they want to use. The 32-bit ICA client provides the most features, but with MetaFrame XP Feature Release 3, Citrix updated the Java client to provide nearly the same functionality as the full 32-bit client. This client can be very useful when being run from kiosks or other locked down environments.

Local Peripherals

Local peripherals can be automatically mapped from the desktop to the server, but not without a price. The data stream used by the device must travel over the network from the server farm to the client device. This can cause excessive bandwidth utilization unless measures are taken to control it. Bandwidth management and control methods are discussed in Chapters 6 and 17.

Note

The ICA COM and LPT port redirection provides support for a variety of local peripherals to be used, but many peripheral configurations require tuning and tweaking in a SBC environment because the ports do not work exactly as they would if they were local ports. For example, we have found that excessive latency over a WAN connection can cause redirected devices to behave erratically, and, in fact, the devices can exasperate the bandwidth problem and cause other network services to fail. Additionally, COM port and LPT port redirection aren't supported through ICA Passthrough connections.