Application publishing refers to the installation and configuration of applications on a multiuser server (or server farm), so they can be accessed readily by users. MetaFrame enhances the basic application publishing capabilities of TSE by providing a Published Application Manager to facilitate the process of fielding an application.
The objective of the Published Application Manager is not only to ease the burden of administrators, but also to shield users from the complexities of setting up applications for use on their clients. When an application is published using the Published Application Manager utility, user access is simplified in three ways:
Application addressing Instead of connecting to a MetaFrame server by its IP address or server name, users can connect to a specific application by whatever name has been assigned to the application itself. Connecting to applications by name eliminates the need for users to remember which servers contain which applications.
Application navigation With applications published under MetaFrame, the user does not need to possess knowledge of the Windows NT 4.0, Windows 2000, or Windows Server 2003 desktop (Windows NT Explorer or Program Manager) to find and start applications after connecting to MetaFrame servers. Instead, published applications present the user with the desired application in an ICA session.
User authentication Instead of logging on and logging off multiple MetaFrame servers to access applications, Program Neighborhood allows users to authenticate themselves a single time to all servers and obtain immediate access to all applications configured for their user group or specific username. Also, publishing applications for the special Anonymous user group allows user authentication processes to be eliminated completely. This can be a useful time-saver when publishing applications for general use by all users on the network.
User Accounts
MetaFrame application publishing provides ICA session access to two types of user accounts: anonymous and explicit. Before publishing an application, it is important to first consider who the users will be, what they will be doing when they run the application, and where they will be connecting from. This will define whether the users should be anonymous or explicitly defined (named users with full authentication).
The total number of users, whether anonymous or explicit, who can be logged on to the MetaFrame server at the same time is contingent upon an organization's licensed user count and on server and bandwidth limitations. These limitations need to be clearly understood before proceeding with application publishing (Chapter 11 discusses server and farm sizing in detail).
Anonymous User Accounts
During MetaFrame installation, the Setup program creates a special user group called "Anonymous." By default, this local Windows 2003 account contains 15 user accounts with account usernames in the format Anon000 through Anon015. Anonymous users are afforded guest permissions by default.
Note Anonymous user accounts are local user accounts (non-domain), and although there are 15 of them created by default, additional ones will be created on the fly by the server to ensure that each Anon connection remains unique. If Anon connections are not going to be used, it is recommended that the accounts be disabled (but not necessarily deleted, due to possible future use) for security reasons.
If an application that is to be published on the MetaFrame server is intended to be accessed by guest-level users, the application can be configured using the Published Application Manager to allow access by anonymous users. When a user starts an anonymous application, the MetaFrame server does not require an explicit username and password to log the user on to the server, but selects a user from a pool of anonymous users who are not currently logged on. Anonymous user accounts are granted minimal ICA session permissions, including
Ten-minute idle (no user activity) time-out.
Automatic End Session on broken connection or time-out.
No password requirement.
Password cannot be changed by user.
Anonymous user accounts do not have a persistent identity. That is to say, no user information is retained when an anonymous user session ends. Any desktop settings, user-specific files, or other resources created or configured by the user are discarded at the end of the ICA session. Because of the inherent permission limitations of anonymous user accounts, the 15 anonymous user accounts created during MetaFrame installation usually do not require any further maintenance.
Explicit User Accounts
Explicit users, which are created and maintained via the Active Directory User Manager, have a "permanent" existence. Their desktop settings, security settings, and so on, are retained between sessions for each user in a user profile.
Explicit users can be of any user class and are generally created for a specific purpose. Their access permissions may be changed by using the Active Directory User Manager.
Identifying what groups of users will have access to an application that is about to be published will aid in server and link resource planning and may even expedite the publishing process. Administrators can capitalize on group settings and extend application access to multiple users concurrently. Conversely, using the Anonymous group is a handy way to make general-purpose applications available to the broadest possible user community in the least amount of time.
MetaFrame Password Manager
Citrix MetaFrame Password Manager (CMPM) is a single sign-on solution designed specifically for MetaFrame XP and MetaFrame Secure Access Manager. CMPM provides password security and single sign-on access to Windows, web, proprietary, and host-based applications running in the MetaFrame Access Suite environment. Users authenticate once with a single password, and MetaFrame Password Manager does the rest, automatically logging in to any password-protected information system, enforcing password policies, monitoring all password-related events, and automating end-user tasks, including password changes.
CMPM is comprised of three components:
A Directory Service to centrally store the password and user information. Three choices are available: File Sync (comes native with CMPM), Microsoft Active Directory, and LDAP, which consists of Sun ONE Identity Server and Novell eDirectory.
The MetaFrame Presentation Server Agent—a 32-bit agent that runs on MetaFrame servers or on a local client workstation
MetaFrame Password Manager Console
Once a user has logged in and authenticated to a directory service, the agent intercepts any future password requests with a query, asking if the user would like the password manager to manage this password. If the user answers yes, then the password information is stored in the central directory service store and handed back to the client workstation when the workstation queries for that password again.
MetaFrame Password Manager enhances security by centralizing security policies, providing an encrypted file for each user's credentials, and allowing IT administrators to automatically generate passwords that are more difficult to crack and to change them more frequently, if needed.
CMPM can either be purchased with the Access Suite Bundle or individually.
Application Publishing Security
In addition to considering the user population for an application, administrators also need to consider the security requirements of the applications they are planning to publish. MetaFrame XP provides additional methods, beyond those of Microsoft operating systems, for securing access to applications published on the MetaFrame server.
Limiting Users to Published Applications
Users of a specific connection type (dial-up, for example) can be restricted to running published applications only. By allowing users to solely access predefined applications, unauthorized users are prevented from obtaining access to the Windows desktop or a command prompt as their initial application unless published by an administrator. This type of security may be obtained by using the Advanced Connection Settings dialog box in the Connection Configuration utility.
It is important to note however that many applications and utilities have major security holes (for example, some applications permit a user to launch other applications [explorer.exe or cmd.exe] from within them). Thus a significant amount of time must be spent putting in place policies, profiles, and registry changes to more securely lock down the operating system and applications. Enterprise environments should consider a lockdown application (two popular lockdown application companies that are certified to work in an SBC environment are triCerat RES and AppSense, covered in more depth in Chapters 11, 13 and 15) to specifically automate the lockdown tasks.
Limiting Applications
The Citrix Management Console allows an administrator to restrict an application to specified users or groups of users, assuming they have been given explicit user access.
Firewall Security and Limited Access from Non-Authorized External Users
With security at the forefront of most enterprise activities, the Internet firewall has become non-optional for every enterprise to protect their resources from non-authorized Internet intrusion. But, since the Internet is such a necessary access method for many users, the firewall often poses a very difficult trade-off—full security versus easy access. MetaFrame Secure Gateway solves this trade-off by providing both easy access and industry recognized security. MetaFrame Secure Gateway is covered in much more depth later in this chapter, as well as in Chapter 16.
Usernames and Passwords
As long as explicit user accounts are specified, MetaFrame XP supports a large number of authentication approaches. For starters, strong password authentication is essential for security (see Chapter 8 for a more detailed password discussion). Even better, consider a second factor authentication approach (using not only something a user knows, but a second authentication method such as something unique that only a specific user has), such as a smart card, token, or biometric). MetaFrame XP FR-3 is fully integrated with RSA and Secure Computing's second factor authentication, as well as a large variety of authentication tools (biometric, smart card, and so on) that integrate with RSA and Secure Computing's authentication software. Additionally, companies like Secure Computing provide a method to integrate the second factor authentication with MetaFrame Web Integration access, Program Neighborhood access, and Windows 2000 Active Directory access, to make authentication seamless to the user community. See Chapter 8 for more detail and discussion on security.
ACLcheck Utility
An ACLcheck utility supplied with MetaFrame examines the security ACLs associated with MetaFrame XP files and directories. This utility can be used to report on any potential security breaches.
Application Execution Shell
The Application Execution Shell (App) in MetaFrame allows administrators to write application execution scripts that perform actions before and after application execution. These scripts can be used in connection with other security utilities to check the security of MetaFrame servers and clients.
MetaFrame as a Web Application Access Center
In these days of electronic business and the Internet, companies are also porting applications to intranets, extranets, and to the Internet, where they can be used by business partners and even consumers. MetaFrame XP facilitates this objective with MetaFrame Web Interface, Web Interface Extensions, and MetaFrame Secure Access Manager. One thing common to all versions of Web Interface is the ability to use pass- through or single sign-on for multiple applications.
MetaFrame Secure Gateway
In our view, one of the most significant new features developed by Citrix in the past three years is MetaFrame Secure Gateway, which is included in all editions of MetaFrame XP. Although Citrix has long provided access via the Internet, enterprise organizations often struggled with providing Internet access to SBC environments due to security concerns. Although both Citrix's ICA and Microsoft's RDP support 128-bit encryption, both protocols also require that firewall ports be opened, at both the client and data-center sides of the Internet. This firewall change creates both logistical and security challenges for companies, especially in instances where the far-side firewall may not be influenced. One example of this is when a company's employees are housed on other company's campuses (either temporarily or for the duration of a longer project), and, as such, often cannot affect the firewall rules at their location.
Secure Gateway solves this problem by converting ICA traffic from port 1494 to port 443 (SSL) in the data-center DMZ. Since SSL is a widely supported standard and utilized for many other web purposes, it provides a very standard and accepted transmission method for traffic traversing firewalls and the Internet. Secure Gateway requires several additional server hardware components. See Figure 3-4 for a diagram of a Secure Gateway implementation.
Figure 3-4: MetaFrame Secure Gateway example deployment
Web Interface for MetaFrame
MetaFrame XP includes MetaFrame Web Interface for (formerly NFuse Classic) with the XPs and XPa editions. This product enables users to integrate applications and data that are published into customized web portals for the end user, who then can access applications via a web browser.
In addition to publishing applications to the familiar web browser interface, another popular use of MetaFrame Web Interface for is to deploy the ICA client itself. MetaFrame Web Interface provides for automatic download and updates of the ICA client, largely transparent to the user, upon user login. This provides a very fast and clean deployment and update mechanism for first-time Citrix users and remote users.
Using MetaFrame Web Interface, the presentation layer elements of multiple applications can be combined on a single page for exposure to the end user as a single, unified application. A simple wizard is provided to aid the administrator in defining the portal contents, which may include applications hosted on MetaFrame XP and MetaFrame for UNIX servers. Support for MetaFrame for UNIX enables the Web Interface for MetaFrame portal to be used to integrate both Windows and UNIX-based applications and data.
Web Interface for MetaFrame access centers can be customized to meet the needs of individual users, who access their applications in accordance with a user or group account login, or general, purpose access centers that can be fielded for access by anonymous users. Either way, the access centers, like other MetaFrame applications, are managed via the same set of MetaFrame utilities used to manage and control other applications published through MetaFrame.
MetaFrame Web Interface Extensions
MetaFrame Web Interface Extension (formerly Citrix Enterprise Services for NFuse (ESN)) is included with XPe and performs the same tasks as Web Interface for MetaFrame XP with the additional feature of multiple farm aggregation.
Web Interface Extension for MetaFrame XP enables highly scaled application provisioning from MetaFrame by aggregating application sets from multiple farms. When combined with MetaFrame Secure Gateway, it provides a simple, secure, single point to access business-critical applications.
MetaFrame Web Interface Extension provides the following solutions:
Multiple farms operating in the enterprise can be used more efficiently and managed more easily.
Administrators don't have to rely on web programming skills to control the operation of Web Interface for MetaFrame XP.
Users only have to provide credentials once, not for each application accessed via MetaFrame XP.
Administrators and users can set values for each MetaFrame XP application instead of being restricted to single global values for all users and all applications.
MetaFrame Secure Access Manager
MetaFrame Secure Access Manager (MSAM) is a stand-alone application that, while able to enhance MetaFrame, does not require MetaFrame. MSAM is a member of the MetaFrame Access Suite, and can be purchased individually or bundled with the suite. It is not included with MetaFrame XP. MSAM is a full-blown Access Solution, comparable to portal products like Microsoft SharePoint Portal Server or Plumtree Corporate Portal. MSAM differs from MetaFrame Web Interface in that it is designed to be a common interface for the aggregation of many different types of corporate data and applications rather than just thin deployment of Windows and UNIX applications. MSAM differentiates itself from Portal products by providing a wizard-based tool with content delivery agents (CDAs) that automate such tasks as placing MetaFrame ICA icons within the web access page, or grabbing Microsoft Exchange content and placing it within the web page.
MSAM can quickly, and through a wizard-based tool, create a single, secured web interface that has a portion of the window showing a message from the president of the company, another portion of the window showing the number of customers in a call queue for support, another portion of the window that is a customer information lookup for pertinent data, a portion of the window showing applications available (both ICA and web based), and a final tag across the top that shows the corporate stock price. All of these sections are dynamically controlled based on the role of the user. Figure 3-5 shows a screenshot of a simple MSAM portal page.
Shadowing
In addition to providing tools for managing application publishing, MetaFrame delivers a utility targeted at reducing administrative costs by enabling the remote support of users of published applications. Session Shadowing enables the administrator (or help-desk personnel) to remotely join, or take control, of another user's ICA session. When activated, Session Shadowing displays the user's screen on the administrator's console. Optionally, the administrator can assume control of the remote user's mouse and keyboard, which enables demonstrations.
In addition to facilitating help desk and troubleshooting processes, Session Shadowing can also be used in online interactive teaching and call-center applications.
Additional security has been added to MetaFrame XP to limit or disable shadowing during installation that cannot be reversed. Administrators can disable shadowing of ICA sessions on all servers in a server farm if legal privacy requirements prohibit the shadowing of users' sessions. Alternatively, it may be necessary to disable shadowing on servers that host sensitive applications, such as personnel or payroll applications, in order to protect confidential data. MetaFrame XP Setup provides options on the Shadowing Setup page for an administrator to limit or disable shadowing at installation time. When shadowing is enabled, an administrator has the option to select the following restrictions:
Prohibit remote control of ICA sessions. By default, MetaFrame XP gives administrators the ability to input keystroke and mouse control during session shadowing. Select this option if you want administrators to be able to shadow without input. In some cases, shadowing without input hides administrator presence.
Prohibit shadow connections without notification. By default, MetaFrame XP notifies users with a prompt when an administrator is attempting to shadow their sessions. Select this option to deny administrators the ability to shadow sessions without sending this notification.
Prohibit shadow connections without logging. Events such as shadowing attempts, successes, and failures can be logged in the Windows event log and examined using Event Viewer. Select this option to enable logging.
Do not allow shadowing of ICA sessions on this server. This option permanently disables shadowing by anyone of all ICA sessions on the server.
Configuring Session Shadowing
Session Shadowing is configured at the time of connection configuration. The shadowing settings in the Advanced Connection Settings dialog box control the behavior of shadowing for all sessions on the connection. Setting options include
Enabled Specifies that sessions on the connection can be shadowed.
Disabled Specifies that sessions on the connection cannot be shadowed.
Input On Allows the shadower to input keyboard and mouse actions to the shadowed session.
Notify On Specifies that the shadowed user gets a message asking if it is OK for the shadowing to occur.
Session Shadowing Initiation
The initiation of Session Shadowing can be accomplished via the Shadow taskbar, the Citrix Management Console, or from a command line. Each interface is well documented and reasonably self-explanatory.
Citrix MetaFrame Conferencing Manager
Citrix MetaFrame Conferencing Manager adds intuitive application conferencing to MetaFrame XP. This application is a new member of the MetaFrame Access Suite and can be purchased as an individual package or bundled with the Suite. Conferencing Manager integrates three components: a Microsoft Exchange/Outlook calendar form; a new Conferencing Manager interface that initiates, cancels, and manages the users and applications of the conferences; and MetaFrame XP's session shadowing features. These three components create an intuitive interface by which users create and join a collaborative conference session among multiple people. Because shadowing cannot occur across multiple MetaFrame XP servers, each conference is limited to the number of sessions that one server can support (typically about 100 people on a four-processor MetaFrame XP server running Microsoft PowerPoint).
Conferencing Manager eliminates the geographical distance between team members, increases the productivity of meetings, and allows easy collaboration. Teams can utilize Conferencing Manager to share application sessions, work together on document editing, and conduct online training, regardless of the location of individual team members or the access devices or network connections they're using.
MetaFrame Licensing
The MetaFrame license is more than an agreement describing the cost to the user and revenue to the vendor. It is a technical licensing implementation in which licenses are pooled by the MetaFrame servers themselves and used to calculate authorized use of the product (see Tables 3-3 and 3-4). In short, if the license provides for 20 users to connect to a MetaFrame server, user number 21 will be locked out by the server.
Table 3-3: List Pricing (New Customer) Connection Licenses
With Subscription Advantage
Without Subscription Advantage
MetaFrame XPs
$290
$250
MetaFrame XPa
$345
$300
MetaFrame Xpe
$400
$350
Table 3-4: List Pricing (Upgrades) Connection Licenses
Upgrading From
Upgrading To
With Subscription Advantage
Without Subscription Advantage
MetaFrame XPs
MetaFrame XPa
$100
$55
MetaFrame XPa
MetaFrame XPe
$105
$55
MetaFrame XPs
MetaFrame XPe
$160
$110
Citrix delivers MetaFrame licenses in three ways: the shrink wrap method, corporate licensing, and ASP licensing.
The Shrink-Wrap Method
Administrators can purchase the base product and licenses for 20 concurrent users.
As configurations expand, bulk user packs can be purchased to meet changing needs. Additional MetaFrame XP user licenses can be added in increments of 5, 10, 20, or 50 concurrent users.
Easy Licensing
Easy Licensing is designed for customers with up to 500 concurrent licenses that wish to take advantage of electronic licensing. On-demand licensing allows administrators to purchase what is needed when it is needed. This licensing also allows for auto activation for rapid deployment. Another advantage to Easy Licensing is that it does not have a complex paper contract, but rather uses a "click to accept" online agreement (similar to opening packaged products).
Corporate Licensing
Corporate licensing programs are available for large license quantities. This program uses a point-based system with four discount levels for corporations and a special education discount level. In addition, special pricing is available for corporate customers who adopt a "long-term strategic use" posture. In this case, cumulative purchases drive discounts. This program is designed for customers with 500 to 5000 concurrent seats.
Flex Licensing
Flex licensing is designed for companies with more than 5000 concurrent seats. Flex Licensing requires a custom contract, called a Global 2000 agreement, reserved for enterprise customers. The advantage of Flex licensing, in addition to a very significant discount, is that Citrix provides additional license automation to make it easier to install and activate MetaFrame licensing across a large quantity of servers.
Subscription Advantage
Subscription Advantage provides customers with a convenient way to keep their Citrix software current and maximize their server-based computing investments. Customers receive software upgrades, enhancements, and maintenance releases that become available during the term of your subscription. Subscription Advantage is for a one-year term and can be renewed each year.
MetaFrame Presentation Center for Unix
Although this book is primarily focused on MetaFrame XP for Windows 2003, UNIX-based applications continue to be a mainstay of many large enterprise environments, and Windows and UNIX users alike can benefit from seamless, single point, webified access to these applications. Because of the overall value of server-based computing in providing web-based seamless access to all applications from any device, for all users, the authors felt strongly that MetaFrame for UNIX should be covered in this book. A large majority of the features and infrastructure discussed in these pages will apply equally to MetaFrame Presentation Server for UNIX and MetaFrame XP for Windows 2003. Features and tools such as MetaFrame Web Interface, MetaFrame Secure Gateway, load management, and any-device access are further promoted by bringing the UNIX applications to the Citrix SBC infrastructure fold.
Although some long-time UNIX administrators argue that UNIX has supported multiuser functionality for years through X-Window, and thus MetaFrame for UNIX is not needed, they are missing out. Due to the feature-rich GUI environments of most UNIX desktops and applications, X-Windows (even compressed X) is very network-intensive. Because of this nature, costly WAN topologies need to be implemented, and low bandwidth connections are almost non-supportable due to performance issues. Additionally, X-Windows does not support such MetaFrame features as shadowing, copy and paste of both text and graphics between the local client and remote server environments, autocreation of local printers and client drive mapping, and most importantly, Web Interface integration with Windows and web applications.
Based in part on the success and popularity of MetaFrame XP in the Windows application hosting environment, Citrix recently announced the latest version of the MetaFrame product suite aimed at the hosting of UNIX, X-Window, and Java applications: MetaFrame for UNIX Version 1.2. The product, which at present supports IBM AIX, Sun Solaris, and HP-UX platforms, as well as virtually any custom or commercially packaged UNIX applications, offers the same value as MetaFrame XP, but with a UNIX/ Java twist: low-bandwidth, universal client access over any network connection to any UNIX or Java application.
At the core of the MetaFrame for UNIX product is a modified X11R6.3 server. This does not replace the X11 server supplied with most UNIX operating systems but is specifically used to enable ICA-connected sessions running on MetaFrame for UNIX. MetaFrame for UNIX runs all standard X11 applications using the modified X server rather than the native X11 server.
In operation, the modified X11 server talks to a UNIX-ported ICA stack (Winstation Driver, Protocol Driver, and Transport Driver), which performs an X-to-ICA conversion. This is key to delivering applications seamlessly to clients from all MetaFrame platforms.
In addition to the modified X11 server and ported ICA stack, MetaFrame for UNIX also provides an ICA browser for use in load balancing and client browsing, a "listener" to intercept incoming ICA connections, and a "Frame Manager," which manages all the sessions currently running on the server.
The same core functionality used by MetaFrame for UNIX to deploy X11 and other applications hosted on UNIX servers can also be applied to Java applications. At first, this capability may seem redundant: in theory, Java applications are already portable to any device. In reality, however, Java client-side application deployments still confront numerous challenges.
Downloading Java applications entails the use of the available client-server network protocol, which is often not optimized for low-bandwidth connections. This results in the major complaint about Java applications—that they are sometimes incredibly slow to download for operation. Operating the Java application, which is executed locally on a server, over a bandwidth-optimized ICA connection provides a higher performance solution to this issue.
Java applications also fall prey to peculiarities in the Java Virtual Machine that runs on the client system. Not all JVMs are the same, and it is often the case that a Java application that runs perfectly in one JVM behaves very differently in another. MetaFrame for UNIX solves this problem by executing Java applications within the server's JVM environment.
Utilizing a single, server-based JVM also saves time and money when developing and testing Java applications developed in-house. Once the application is working in the server JVM, it can be deployed instantly to any ICA client device.
It should also be noted that the Java Virtual Machine is typically a large piece of software. While the development of an embedded JVM is under way, ultra-thin client devices lack the capacity to run a JVM that offers sufficient features or performance. This issue is removed through the use of the MetaFrame for UNIX solution.
In summary, MetaFrame for UNIX Operating Systems can be an important adjunct to Windows-based MetaFrame servers in heterogeneous server environments. MetaFrame for UNIX can be included in server farm and load-balancing schemes, and applications hosted on MetaFrame for UNIX systems may be published individually or as part of integrated Web Interface Access Centers for integrated access by end users.
Thursday, December 20, 2007
Citrix MetaFrame Access Suite
Overview
Citrix MetaFrame XP Access Suite is a complementary product suite to Microsoft's Terminal Services (included with Windows NT 4.0 Terminal Services Edition, Windows 2000 Server, and Windows Server 2003) discussed in Chapter 2. Today, Citrix serves nearly fifty million users, facilitating a seamless user experience in heterogeneous computing environments, as well as application delivery across bandwidth-restricted connections.
Citrix MetaFrame Access Suite is comprised of five software products:
MetaFrame XP Presentation Server (MetaFrame XP)
MetaFrame Presentation Server for UNIX (MetaFrame for UNIX)
MetaFrame Password Manager
MetaFrame Conferencing Manager
MetaFrame Secure Access Manager (MSAM)
Citrix Password Manager and Conferencing Manager
Password Manager and Conferencing Manager are the newest members of the Citrix MetaFrame Access Suite. Password Manager provides a simple and elegant single sign-on solution for MetaFrame XP environments (although it also works in non-Metaframe environments), and Conferencing Manager provides an all-inclusive collaborative conference interface that leverages the shadow features of MetaFrame XP. These two products further enhance the user experience of the server-based computing environment.
In this chapter, we discuss the evolution of the MetaFrame Access Suite and dissect its Independent Computing Architecture (ICA) protocol. We also cover the enhancements that MetaFrame Access Suite brings to Terminal Services, including:
Secure, encrypted access for all enterprise users from any location, without having to open firewall holes. MetaFrame Secure Gateway provides a secure infrastructure by which users can access the SBC environment literally from anywhere, any time, any place, regardless of the firewall configurations (assuming the environment allows SSL [port 443] traffic). Although Terminal Services RDP traffic is encrypted, it requires that port 3389 be open both on the Data Center firewall and at the user's location(s).
True Application Load Management. Microsoft's built-in Network Load Balancing can be effective for environments with 100 users or less, but enterprise environments absolutely require a more robust and flexible approach to determining which users are placed on which servers under what circumstances.
MetaFrame Web Interface wizard-based deployment tool (formerly called NFuse). Not only does this tool provide an automated approach to deploying access to the SBC environment, but, just as handy, it provides an automated approach to deploying the ICA client itself. Conversely, the deployment and installation of the Remote Desktop Client with Terminal Services can be a daunting task when thousands of users need an update to the client.
Universal Access to applications from any client device, to applications on Windows or UNIX platforms. Although Microsoft now supports client access from Macintosh OS X and Windows clients, Citrix not only provides support for Mac and Windows, but also support for over 200 client operating systems, including most flavors of UNIX and Linux, DOS, and embedded devices.
Enterprise management tools. Citrix provides Resource Manager, Installation Manager, and Network Manager, as well as a host of embedded management tools that present administrators with critical information as well as the automation of enterprise SBC server environments.
Table 3-1 shows the value-add features that Citrix MetaFrame XP add to a Windows Server 2003 environment.
Table 3-1: Citrix ICA Value-Add Features Application publishing
One-to-many shadowing
Customized billing reports
User collaboration
Program Neighborhood
Cross-server shadowing
Track user access to applications
Panning and scaling (handhelds)
Anonymous user support
Shadowing indicator
Centrally install applications
Pass-through authentication
Content publishing
Auto client update
Distribute service packs
Seamless windows
Content redirection
Universal print driver
Package customized install
Multimonitor support
Novell NDS support
Web-based client install
Web Interface for MetaFrame
Application save position
Delegated administration
Support for multiple farms
Non-Windows client access
End-to-end security
Centralized management console
Auto client printer detection
Integration with Network Management consoles
MetaFrame Secure Gateway
Connection control
Resource-based Load Management
Support for direct asynch
SSL/TLS 128-bit encryption
CPU prioritization
Schedule application availability
Client drive remapping
Support for digital certificates
Support for 1000+ servers in farm
Specify client IP range
Text-entry prediction
Socks 4 and 5 proxy support
Many-to-one shadowing
Application monitoring
Instant mouse-click feedback
SpeedScreen 4 browser acceleration
The Evolution of MetaFrame
The Microsoft Windows NT operating system developed from a single-user operating system architecture and continued, for nearly a decade, only to be limited in certain applications by that fact. Windows NT provided real-time multiprocessing capabilities comparable to those of rival UNIX operating systems, but did not provide functions within its OS kernel to support concurrent multiuser access to applications hosted on NT platforms.
Given the dominant business computing architecture of the late 1980s and early 1990s, which featured increasingly capable desktop computers (so-called fat-client PCs) that provided much of the same processing as client-server applications, it may well be that the need for multiuser computing platforms (similar in concept to mainframe computing environments) was not of primary concern to Microsoft designers. In Microsoft's preferred computing model, information processing was conceived as inherently distributed and individualized: desktop computers were viewed as "peers" of server platforms. In fact, most early server systems were little more than highly configured PCs, typically featuring many of the same hardware components.
At that time, there was an interest in some niche areas for a server platform that would "host" applications and share them among several connected client devices, configured as dumb terminals. One such application was remote access: a technique by which one or more offsite users could access an application located on a corporate local area network (LAN). Ideally, the remote user would be able to perform useful work as though seated at a terminal directly attached to the LAN.
However, the mainstream architecture for business computing did not yet involve shared application use. Instead, the norm was a combination of Windows-based desktop computers, emphasizing locally stored and executed individual applications, and Novell, UNIX, or NT-based servers (or a combination of all of these) interconnected via a LAN, supporting client-server computing.
Multiuser Windows—MultiWin
The idea behind server-based computing on Windows NT can be traced to the X-Window System developed by MIT in 1984. By utilizing powerful UNIX servers, remote X-Window clients can send keyboard and mouse input to server-based applications running on central servers. The X-Window System on the server then tracks output from the applications and updates the appropriate remote client session screen.
The founder of Citrix Systems, Ed Iacobucci, originally conceived the idea of allowing different types of computers to run the same applications, even though they might not have the same operating system or adequate local resources. While working as head of the joint Microsoft/IBM design team on the OS/2 project, he approached both companies with the idea, but neither firm was interested. Iacobucci then formed Citrix Systems in 1989 and the technology behind the current Terminal Services was developed—MultiWin. MultiWin rode on top of the OS/2 kernel and allowed multiple simultaneous OS/2 sessions and desktops in a protected memory area for each individual user.
WinView
In 1993, Citrix shipped its first OS/2-based multiuser operating system, called WinView. WinView used the MultiWin technology and one of the first incarnations of a remote display client called Independent Computing Architecture (ICA). Citrix first worked to deliver multiuser extensions to the OS/2 operating system and subsequently worked on the delivery of applications across Novell and TCP/IP networks. Despite prevailing personal and client-server computing models, developers at Citrix believed that multiuser computing had a future, especially as applications moved off the desktop and "into the network." They convinced Microsoft that a market for multiuser NT could be cultivated and secured a license to add multiuser extensions to the NT operating system.
WinFrame
Whether or not Microsoft shared the Citrix vision of the future, the license agreement was certainly a "win-win" for Microsoft and Citrix. With the multiuser extensions provided by Citrix in the form of WinFrame, Microsoft would be able to answer criticisms from UNIX advocates regarding a purported "deficiency" of its server operating systems: they provided little or no support for multiuser computing requirements. If Citrix visionaries were correct, and a market for multiuser computing platforms could be cultivated, Microsoft would have a solution to offer that market.
Citrix WinFrame is a combination of Microsoft Windows NT 3.51 Server and Citrix MultiWin technology. WinFrame was a major upgrade to the OS/2-based WinView. At the time of its release, Windows 3.1 (and later, Windows 95) had become the desktop standard, and WinFrame surpassed WinView as a tool for installing and executing the standard corporate end-user applications.
Thin-Client Computing
In the mid-1990s, the argument for multiuser NT was reinforced by the findings of analysts such as the Gartner Group regarding the total cost of ownership of Windows PCs. Analysts claimed that fat-client PCs cost organizations between $7000 and $13,000 per PC per year in maintenance and support. This position touched off a firestorm of industry activity, mainly from longtime Microsoft rivals. The so-called SONIA set—an acronym for Sun Microsystems, Oracle Corporation, Netscape Communications, IBM, and Apple Corporation—led the charge to displace Microsoft PCs from corporate desktops, substituting their own "network computer" in their place. Despite the obvious self-interest inherent in the SONIA value proposition, and the subsequent failure of the network computer to take hold in the market, the underlying tenant of the SONIA argument took root. The Citrix concept of thin-client computing was introduced to the lexicon of modern business computing.
Thin-client computing advocates held that, as server capabilities grew, it was only natural for server hosts to become "fatter" and for desktop platforms to become "thinner." Application software, advocates argued, should reside on application servers rather than on individual PCs. Placing applications on a server would make them accessible by means of a variety of inexpensive client devices. The advent of the Internet and World Wide Web at about the same time reinforced this perspective. Many people adopted a view of computing in which all applications would be accessed via a universal, hardware-agnostic client such as a web browser.
Citrix Systems Synonymous with Thin
Citrix Systems, with its Independent Computing Architecture (ICA), emerged from the discussion of thin computing as the undisputed leader in a market it had long helped to facilitate. In an ICA-based solution, WinFrame-based application servers could host Windows-compliant applications, while end users, equipped with any of a broad range of client devices (whether network computers or Windows PCs), could access and use the applications over a network connection. Integral to the WinFrame approach was a remote presentation services protocol capable of separating the application's logic from its user interface, so that only keystrokes, mouse-clicks, and screen updates would travel the network. With the ICA protocol, Citrix claimed, the user's experience of the server-hosted application would be comparable in all respects to that of an application executing on the end user's own desktop PC.
Terminal Services and MetaFrame
Increased interest in the WinFrame solution encouraged Microsoft to license MultiWin, the core technology of WinFrame, from Citrix Systems in 1997 and to integrate the technology into its own operating systems soon after. As explained in Chapter 2, Microsoft first implemented MultiWin in a special Terminal Services Edition (TSE) of its NT 4.0 OS. With Microsoft's integration of Terminal Services, Citrix needed to raise the bar for scalability and management. This was accomplished with MetaFrame.
Introduction of MetaFrame 1.0/1.8
Unlike WinFrame, which had been a stand-alone product and a "replacement" operating system for NT, MetaFrame was an add-on to the Microsoft NT 4.0 TSE and Windows 2000 platform. One reason for the MetaFrame product was to continue to meet the needs of WinFrame customers who were interested in migrating their NT 3.51-based WinFrame environments to newer NT 4.0 TSE-based environments but who were afraid of losing application server connections with clients that were not supported by Remote Desktop Protocol (RDP). MetaFrame added ICA client and protocol support back into the Microsoft multiuser operating system offering, since ICA allowed for connectivity from many additional clients than RDP allowed.
MetaFrame XP
MetaFrame XP is the latest version from Citrix. With the release of Feature Release 3 (FR-3), XP is compatible with Microsoft's latest operating system: Windows Server 2003. In addition to the feature updates and changes, another very significant change that Citrix made with MetaFrame XP is the change in licensing; MetaFrame 1.0/1.8 Citrix required a server license for every server with Citrix installed as well as bump packs for additional users, while MetaFrame XP only requires one base license for each server farm (with bump packs for additional concurrent users). This change makes licensing far more flexible and convenient, and in most cases cheaper, as additional servers can be brought online as needed without additional Citrix software license expense (as long as no additional concurrent users are added).
With MetaFrame XP, customers have new version choices, including XPs, XPa, and XPe. All versions of XP are supported on Windows NT 4.0 TSE, Windows 2000 Server, and Windows Server 2003. MetaFrame XP supports full integration with Active Directory in Windows 2000 or Windows Server 2003.
Note Following the release of Feature Release 1, Citrix stopped adding any additional features or enhancements to MetaFrame XP for Windows NT 4.0 TSE.
XPs is the standard version for Citrix servers for stand-alone point solution implementations with one to five servers. XPs feature highlights include MetaFrame Web Interface for MetaFrame, user shadowing, Secure Gateway, Universal Print Driver II, client time zone support, Novell NDS support, client device support, and full ICA client support.
Although more than one server can be used with XPs, it is rare, as applications cannot be load balanced across servers and any application publishing will have to be done separately on each server with different names.
XPa is the advanced version that includes all of the XPs features, with the addition of Load Management. This upgrade is designed for use in farms with 2 to 100 servers.
As shown in Table 3-2, XPe contains all the features included with XPa, as well as some additional features required for enterprise management. These extended features include Resource Manager, Installation Manager, Web Interface Extension for MetaFrame XP (formerly Enterprise Services for NFuse), a plug-in for Microsoft Operations Manager (MOM), and Network Manager. XPe is designed for 20 or more servers and accommodates multiple Citrix Server farms.
Table 3-2: MetaFrame XP FR-3 Feature Grid MetaFrame XPs
MetaFrame XPa
MetaFrame XPe
UNPARALLELED MANAGEABILITY AND SCALE
Advanced Shadowing
Cross-server shadowing
X
X
X
Many-to-one shadowing
X
X
X
One-to-many shadowing
X
X
X
Shadowing indicator
X
X
X
Shadowing taskbar
X
X
X
Application Management
Anonymous user support
X
X
X
Application publishing
X
X
X
Content publishing
X
X
X
Program Neighborhood
X
X
X
TCP-based browsing
X
X
X
Application Packaging and Delivery
Centrally install and uninstall applications
X
Create logical server groups
X
Customizable project details
X
Delivery verification
X
Distribute service packs, updates, and files
X
MSI support
X
Package applications, files, and service packs
X
Package inventory
X
Packager rollback
X
Schedule package delivery
X
Server reboot support
X
Support for unattended installs
X
Centralized Administration
Active Directory support
X
X
X
Novell NDS support
X
X
X
User policies
X
X
X
Administrator toolbar
X
X
X
Centralized Data Store
X
X
X
Citrix administrative accounts
X
X
X
Citrix Management Console
X
X
X
Plug-in for Microsoft Operations Manager (MOM)
X
X
X
Citrix Web Console
X
X
X
Connection control
X
X
X
CPU prioritization
X
X
X
Windows Installer Support
X
X
X
Centralized License Management
Centralized license activation
X
X
X
Enterprisewide license pooling
X
X
X
Plug-and-play licensing
X
X
X
Client Management
Auto client update
X
X
X
Business Recovery
X
X
X
ReadyConnect
X
X
X
Web-based client installation
X
X
X
Network Management
Access CMC from third-party management consoles
X
SNMP monitoring agent
X
Printer Management
MetaFrame Universal Print Driver version II
X
X
X
Support for color and high-resolution printers with Universal Print Driver
X
X
X
Printer auto creation log
X
X
X
Printer driver access control
X
X
X
Printer driver replication
X
X
X
Printing bandwidth control
X
X
X
Resource-Based Load Balancing
Instant load-balancing feedback
X
X
Load balancing reconnect support
X
X
Schedule application availability
X
X
Specify client IP range
X
X
Scalability
Enterprise-class scalability
X
X
X
Cross-subnet administration
X
X
X
System Monitoring and Analysis
Application monitoring
X
Customized reporting
X
Summary database and reporting
X
Perform system capacity planning
X
Real-time graphing and alerting
X
Server farm monitoring
X
Track user access to applications
X
User-definable metrics
X
Watcher window
X
ICA session monitoring
X
TOTAL" NET" LEVERAGE
Web Application Access
Web Interface for MetaFrame
X
X
X
Federal Information Processing Standards (FIPS) 140 security compliance
X
X
X
Support for RSA Secure ID and Secure Computing Premier Access second factor authentication solutions
X
X
X
Multiple server farm support
X
X
X
Application filtering and caching
X
X
X
Support for MetaFrame Secure Access Manager
X
X
X
Web Interface Extension for MetaFrame XP
X
ULTIMATE FLEXIBILITY
Access to Local System Resources
Auto printer creation
X
X
X
Automatic drive redirection
X
X
X
Client drive mapping
X
X
X
Clipboard redirection
X
X
X
COM port redirection
X
X
X
Performance
Instant mouse-click feedback
X
X
X
Persistent bitmap caching
X
X
X
Priority packet tagging
X
X
X
SpeedScreen browser acceleration
X
X
X
SpeedScreen 3
X
X
X
Text-entry prediction
X
X
X
Seamless User Experience
High-/true-color depth and resolution
X
X
X
16-bit audio support
X
X
X
Application save position
X
X
X
Auto client reconnect
X
X
X
Client printer management utility
X
X
X
Client time zone support
X
X
X
Content redirection
X
X
X
Multimonitor support
X
X
X
Panning and scaling
X
X
X
Pass-through authentication
X
X
X
Roaming user reconnect
X
X
X
Seamless windows
X
X
X
Win 16 multi-session support
X
X
X
Universal Connectivity
Universal client access
X
X
X
Support for direct asynch dial-up
X
X
X
Support for TCP/IP, IPX, SPX, and NetBIOS
X
X
X
User Collaboration
User collaboration
X
X
X
END-TO-END SECURITY
Security
MetaFrame Secure Gateway
X
X
X
Delegated administration
X
X
X
SSL 128-bit encryption
X
X
X
TLS encryption
X
X
X
Smart card support
X
X
X
SecureICA 128-bit encryption
X
X
X
SOCKS 4 and 5 Support
X
X
X
Ticketing
X
X
X
The centralized computing using MetaFrame XP provides us with the ability to completely customize which applications are provided to which users. This ensures that all users have access to the necessary resources required for their daily tasks. Software changes and upgrades are performed at the server effective instantaneously for all users. Overall, we have been able to expand and grow our IT projects ahead of estimated schedules with the seamless deployment of applications and minimum maintenance time required for our Citrix Farm.
—Michael P. Miller
Network & Systems Administrator
Primary Care Partners, P.C.
MetaFrame XP is Active Directory compliant. Thus, Active Directory groups may be used to configure permissions and users. Citrix does not change or add to the schema of Active Directory, and MetaFrame allows single sign-on for Active Directory, Novell NDS, and Novell e-Directory environments.
Web interface for MetaFrame is provided by Citrix, with all three MetaFrame XP versions to publish Windows applications to web pages on intranets and the public Internet. This tool also allows customization so that a number of applications can be combined into an "application portal." Additionally, MetaFrame Secure Gateway provides a secure method of application access delivered directly to the end user via a browser, over SSL, providing increased security while reducing problems with Firewall and VPN configurations.
With MetaFrame XP, access to applications can be provided across a variety of networks, including wide area networks, remote access dial-up connections, local area networks, the Internet, and wireless networks. Over 200 types of clients, including Windows PCs, Windows terminals, UNIX workstations, handheld devices, network computers, and numerous others, are supported as ICA clients. These client choices improve dramatically on the RDP client support inherent in Windows NT 4.0 TSE, Windows 2000 Server, and Windows Server 2003.
Independent Computing Architecture (ICA)
ICA is an architecture for server-based computing that competes with and/or complements other architectures such as Microsoft's Remote Desktop Protocol (RDP) and Sun Microsystems/X-Open's X-Window protocol. All of these architectures share in the goal to provide a means to extend resources, simplify application deployment and administration, and decrease the total cost of application ownership.
With all of these server-based computing architectures, applications are deployed, managed, supported, and executed completely on a server. Client devices, whether fat or thin, have access to business-critical applications on the server without application rewrites or downloads.
For everything that ICA, RDP, and the X-Window System have in common, they vary significantly from each other at the component level. Since very little new development is currently being done with the X-Windows System, we will focus our comparisons on ICA and RDP, although the "MetaFrame for UNIX" section provides a brief discussion on ICA versus X-Windows.
ICA Presentation Services Protocol
As depicted in Figure 3-1, the ICA presentation services protocol transports only key-strokes, mouse-clicks, and screen updates to the client. The protocol has been demonstrated to operate consistently with 20 kilobits per second of network bandwidth and provide real-time performance with 30 kilobits per second for office automation applications. This enables even the latest 32-bit applications to be operated remotely across low-bandwidth links while delivering performance comparable to local execution on existing PCs, Windows-based terminals, network computers, and a host of evolving business and personal information appliances.
Figure 3-1: ICA presentation services
The ICA protocol was designed with low-bandwidth connections in mind, making it a robust performer on both large- and small-capacity links. Moreover, the ICA protocol responds dynamically to changing network, server, and client operating conditions. It takes advantage of available network and server resources and adapts automatically when conditions are more restrictive, often without generating any noticeable changes in the end user's experience. Much of the performance of the ICA protocol can be attributed to the use of intelligent caching and data compression techniques, and to technologies such as SpeedScreen. ICA is a non-streaming protocol, meaning that if a user's screen has not changed and they have not moved the mouse or keyboard, no traffic will be passed. This feature can substantially help larger environments operating over a WAN link as many users will not be using any bandwidth at certain instances, allowing much better utilization of the bandwidth as a whole.
Citrix MetaFrame enables us to deploy Windows applications to our students in both a very cost-effective and expeditious manner. This is true whether they are working on a PC or Windows terminal on campus, or working offsite using an Internet connection.
—Tony Holland,
Director of Computing Services,
Stanford Business School
SpeedScreen
SpeedScreen is a technology for improving the performance of application delivery across ICA links. It improves performance by reducing the amount of data that must traverse an ICA connection as an end-user interacts with a MetaFrame server-based application. SpeedScreen targets the repainting function of a hosted application. With many applications, entire screens are repainted with each keyboard entry (or mouse-click) made by the end user. SpeedScreen uses an intelligent agent technology to compare information previously transmitted to the ICA client with information that is about to be transmitted, then transmits only the changed information. This is visually represented in Figure 3-2. By limiting repaint operations to specific sections of a screen affected by user interaction, the amount of traffic that must traverse the connection is dramatically reduced. Citrix's latest release of SpeedScreen, SpeedScreen 4, also called SpeedScreen Browser Acceleration, specifically focuses on major performance and usability improvements for end users connecting to published applications that embed JPEG and GIF images within Microsoft HTML pages. Supported applications include Internet Explorer v5.5 or later, Microsoft Outlook and Outlook Express.
Figure 3-2: How SpeedScreen improves link performance
With some applications, bandwidth consumption may be reduced by as much as 30 percent through the implementation of SpeedScreen, while total packets transmitted may be reduced by 60 percent. The result is lower latency in the network and better application performance for the end user—especially across low-bandwidth connections.
With the SpeedScreen Latency Reduction (SLR) manager, the end-user experience can be enhanced in two ways. First, local text echo can be enabled to give immediate feedback by having the local client render the text. The normal way text is transferred when using MetaFrame is by sending the keystroke to the server, which is processed and then rendered back to the client. This is convenient for users that type quickly, as even the slightest delay can be annoying. Second, SLR can provide for instant feedback for mouse-button clicks.
Connectivity Options
A broader range of connectivity options are supported by MetaFrame and ICA than by RDP, so a more diversified set of users can access and utilize hosted applications. Figure 3-3 depicts the connectivity options enabled by ICA, which include dial-up, ISDN, multiple LANs, wireless LANs, numerous WANs, and the Internet. RDP, by contrast, is limited in its support to only TCP/IP LAN/WAN environments.
Figure 3-3: ICA's connectivity options
Additionally, using MetaFrame and the ICA protocol breaks the barriers imposed by RDP by extending application access beyond Windows PCs. The ICA protocol supports more than 200 clients, providing flexibility in access options far surpassing that of RDP.
The ICA Client Environment
In addition to the contributions of MetaFrame and the ICA protocol to application delivery performance, MetaFrame also enhances the basic multiuser client-server environment. MetaFrame XP embodies numerous innovations designed to facilitate a broad range of hosted application environments. Considerable effort has been invested by MetaFrame XP designers to enable all applications, whether remote or local, to operate and interoperate as though they were local to the end user. This approach increases the user's comfort level and decreases the required training time.
The MetaFrame ICA Desktop
The MetaFrame ICA desktop is designed to provide a user experience that is on par with a Windows PC running locally installed and executed applications. MetaFrame enables complete access to local system resources, such as full 16-bit stereo audio, local drives, COM ports, and local printers, if available.
The mapping of local resources can be performed automatically or by means of administrative utilities. Specialized client capabilities such as modem dial-up are also supported.
Additionally, mapped resources can be shared with the MetaFrame server, if desired. Configuration of these mappings is built into the standard Windows device redirection facilities. The client mappings appear as another network that presents the client devices as share points to which a drive letter or printer port can be attached.
Seamless Windows
Of course, not all MetaFrame XP implementations utilize a full-fledged "remote desktop" model (one in which there are no applications locally installed on the client). Indeed, in many environments where MetaFrame XP is deployed, clients are themselves Windows PCs configured to provide a mixture of some locally installed applications and some remotely hosted applications. Seamless Windows is a feature of MetaFrame designed to accommodate this scenario.
Seamless Windows is a shorthand expression referring to the capability of the Citrix ICA Win32 client to support the integration of local and remote applications on the local Windows 95, Windows 98, Windows NT 4.0, Windows 2000, or Windows XP desktop. When configuring a connection to the MetaFrame XP server, an administrator or user can simply select the Seamless Windows option to enable this function.
With Seamless Windows, the user can gain access to hosted applications without having to load a remote desktop environment. While connected in a MetaFrame XP server session, the user can gain access to local applications using the Windows taskbar. Icons for both local and remote applications can be installed on the local Windows desktop, and both local and remote application windows can be cascaded on the local desktop.
Multiple Keyboards The Seamless Windows environment supports the definition of multiple keyboards to facilitate command entry in local and remote application environments. This prevents specially mapped key combinations used by MetaFrame (such as ALT-TAB) from interfering with similar key combinations used by locally executing applications.
Windows Clipboard Seamless Windows supports the use of the Windows Clipboard in conjunction with both local and MetaFrame-hosted applications. Users can cut, copy, and paste information between applications running remotely on the server or locally from the desktop. Rich text format cut-and-paste is fully supported.
Note The local/remote clipboard is part of MetaFrame XP's overall solution set. It can be used independently of Seamless Windows or Program Neighborhood.
Program Neighborhood
Building on the concept of a Seamless Windows environment, MetaFrame also delivers an easy-to-use method for accessing remotely hosted applications. Similar in concept to the Microsoft Windows Network Neighborhood, MetaFrame pushes links to published applications into a client-based Program Neighborhood facility.
In operation, Program Neighborhood presents application sets to MetaFrame client users. An application set is a user's view of the applications published on a given MetaFrame server or server farm, which that user is authorized to access. A single user- authentication operation (usually initiated when the user launches Program Neighborhood or a MetaFrame-hosted application displayed in the Start menu or as an icon on the local desktop) identifies the user to all MetaFrame servers. Based on the user's individual or group account parameters, the Program Neighborhood is populated with an application set containing each application configured for the specific user account or user group. Published applications appear as icons and are preconfigured with such properties as session window size, color depth, and supported level of encryption, as well as audio and video appropriate to the user and his or her client device.
Program Neighborhood technology is especially useful as a means to quickly publish hosted applications that are intended for use by groups of users. Users can click the Program Neighborhood icon on their Windows desktop (or click the corresponding entry in their Windows Start menu) to review a list of hosted applications available for use. No special client configuration is required to launch and use these published applications.
Management Features
The primary management tool for MetaFrame XP farms is the Citrix Management Console (CMC). The CMC is a Java tool that provides the user interface to control permissions, licensing, published applications, the load management feature of XPa, and the advanced features of XPe for both resource management and network management. The CMC is also the interface to monitor and manage printers, users, and servers. Java was chosen rather than using the Microsoft standard of the Microsoft Manager Console (MMC) for cross-platform compatibility. With the introduction of FR-1, Citrix made available the Citrix Web Console (CWC), which is not as feature-rich as the CMC, but is more convenient to use at all times.
The CMC can provide a significant load on the server farm if not used properly. It is recommended that the auto refresh feature not be used, especially in larger farms. It is also important to publish or use the CMC from the Zone Data Control (ZDC) server. Zone Data Control is further explained later in this chapter. The information that the CMC needs is located in the database on the ZDC, therefore if the CMC is run from a server other than the ZDC server, the server needs to download the information from the ZDC and this adds one more link to the puzzle. Another way to increase efficiency in using the CMC is to create folders within the CMC to categorize published applications and servers. This allows the CMC to refresh without gathering more information than is needed. Another method to reduce load on the CMC is to use the command-line tools that only query very specific data, and thus use the CPU and network bandwidth efficiently.
With MetaFrame XP Feature Release 3, Citrix released the MetaFrame XP Management Pack for MOM. This is a plug-in for Microsoft Operations Manager (MOM) that allows administrators to effectively manage the health and performance of MetaFrame XP servers from the MOM console. Since this interface is not Java based, it tends to be faster and less resource intensive. For users who are already using MOM for server management, this will make a great management tool.
From a client management perspective, MetaFrame XP brings to the administrative tool kit the Automatic ICA Client Update utility and a tool called ReadyConnect to facilitate rapid application deployment. Together, these features can save administrators many hours of tedious client configuration tasks.
The Automatic ICA Client Update utility provides the means to update Citrix ICA client software centrally, from the MetaFrame server itself. The latest versions of ICA client software are identified by the administrator, who then uses the update tool to schedule download and installation on appropriate client devices. This utility reduces the need to travel from client to client throughout the enterprise in order to install and configure the latest version of ICA client software.
ReadyConnect enables client connections to be predefined at the server. By capturing ICA client connection data, including phone numbers, IP addresses, server names, and other connection options, applications can be mass-deployed throughout the enterprise with speed and agility. Users can access applications across predefined connection points through a simple point-and-click operation.
Note While these tools are convenient, we recommend that Web Interface for MetaFrame be used instead to deploy and manage client versions and configurations. This technique will be thoroughly discussed in the "Web Interface for MetaFrame" section of this chapter and later in Chapter 16.
Zone Data Collectors
Understanding zone data collectors is critical to optimizing larger farm performance. Zone data collectors (ZDC) are used to keep information within a server farm up-to-date between member servers and other ZDCs. Every server farm has at least one zone that is set up by default. The trick is to design the right number of zones in a farm so that each ZDC does not get overloaded with traffic from its member servers. In larger farms with 50 or more servers, the ZDC is best served by a MetaFrame XP server that does not accept ICA connections.
Generally, zones start degrading performance between 100 and 300 servers, depending on the number of logins, applications served, and changes in server load. Performance can be maintained in larger farms by creating additional zones. The trade-off of adding more zones is the open link (and thus the bandwidth required) to maintain updates between each ZDC so that all updated data can be propagated throughout the farm. For optimal performance, it is best to keep the number of zones to a minimum, but still keep each zone small enough to be efficient.
The ZDC tracks data that is dynamically collected from the farm to include server load, license utilization, and session information. The more static data for a farm is maintained by the IMA data store including total licensing, published applications, administrators, permissions, server names in the farm, and trust relationships.
The ZDC is chosen with an election process. The variables used for the election process are first the software version, second the administrator-defined preference, and third the host ID. The important thing to keep in mind is that the software version overrides even the administrator-defined preference. Because of the amount of communication that takes place between ZDCs, we do not recommend setting up zones that cross WAN links. The zone traffic data that is sent across WAN links is not manageable within Citrix, but appliances like the Packeteer PacketShaper can manage this bandwidth utilization.
Independent Management Architecture
MetaFrame XP introduced the Independent Management Architecture (IMA) to replace the ICA browser service. IMA is a tremendous improvement over the ICA browser with respect to speed, scalability, and reliability of enterprise server farms.
IMA contains two components. The IMA data store is responsible for keeping information about licenses, published applications, load-balancing parameters, printer options, and security. The IMA protocol is responsible for communications between MetaFrame XP servers that maintain accurate information about server load, license usage, and user connections.
The IMA service runs on all MetaFrame XP servers to communicate with the Citrix Management Console, other MetaFrame XP servers, and the IMA data store. Each Citrix farm has one IMA data store connected to an ODBC database. The databases that are presently supported are MS Jet (FR-3 replaced Jet support with MSDE support), Microsoft SQL Server 7 or later, IBM DB2, and Oracle 7.3.4 or later. Additional licensing is required from Microsoft, IBM DB2, or Oracle if MSDE is not used. Each server downloads its configuration updates each time it is started (when the IMA services start); it also checks for changes every ten minutes. When an administrator is doing testing and maintenance, it is sometimes necessary to have more immediate response for changes. This can be done by executing the dsmaint recreatelhc command from a command prompt on the MetaFrame XP server. When each server queries the IMA data store, it only downloads relevant changes, which reduces the amount of traffic on the network. The local server stores this data in its Local Host Cache. This is helpful for increasing performance of local queries, and the data is retained for 96 hours in case of communications problems with the centralized IMA data store. the zone data collector is also involved in this communication and will be addressed in the next section.
Access to the data store can be done via "direct" or "indirect" mode. Direct mode means that each server directly accesses the database using ODBC, whereas in the indirect mode the servers aggregate queries through one MetaFrame server and it communicates to the data store. When using MS Jet (or MSDE in Feature Release 3) for the data store indirect mode must be used because of performance and locking issues. Direct or indirect mode can be used with SQL, IBM DB2 or Oracle. For small farms (50 servers or less), MSDE can work but has the disadvantage of requiring indirect mode (single point of failure), is much more likely to get corrupted data, and can be a performance bottleneck. For farms that are mission-critical and larger than ten servers, using direct mode with SQL, IBM DB2, or Oracle is recommended. The SQL, IBM DB2 or Oracle server does not need to be dedicated to the data store, since these databases support more than one database per server, assuming, of course, that sufficient server resources are available.
Data store replication is a concern in larger farms. When a server queries the data store (especially over slow link speeds) other servers could timeout and cause problems. SQL, IBM DB2, and Oracle contain integrated replication capabilities that are effective in solving this problem (the dual-commit model is recommended). When planning the resources for the data store, a good rule of thumb is to allocate about 200KB of disk space for each MetaFrame XP server.
Resource Manager
MetaFrame XPe is required when using Resource Manager (RM). This product equips administrators with a full-featured management tool suite for analyzing and tuning Citrix MetaFrame XPe servers. RM adds real-time monitoring, historic reports, and a central repository of usage information and statistics to the MetaFrame product suite.
Resource Manager keeps data for 96 hours with an internal database (15-second server snapshots) and integrates with Microsoft SQL and Oracle databases to store long-term statistics. The local database will utilize about 7MB of data for each metric to maintain data for 96 hours. The local database is only compressed when the IMA service is started; this provides one more reason to script reboot the MetaFrame XP servers every 24 to 48 hours. The link http://www.citrix.com/download contains a group of predefined free crystal reports available for use with a Microsoft SQL/Oracle database.
While monitoring the server statistics, RM can send out e-mail, pages, or SNMP traps when predefined loads are met (for example, when CPU utilization reaches 60 percent, RM can send the Citrix administrator group an e-mail). RM uses metrics to define monitored parameters, alert thresholds, and configurations. Metrics, once defined, can be applied to servers or published applications. Hundreds of example metrics are included with the RM installation. Citrix recommends, for performance reasons, not to have more than 50 metrics per server.
The farm metric server is the central server that manages all of the metrics on each of the servers and published applications. By default, the first server in the farm to have RM installed on it becomes the farm metric server, although this can be moved by the administrator at any time. Better performance can be achieved by having the farm metric server on the same machine as the zone data collector. RM can be installed on a second server in the farmer, which will automatically become the backup farm metric server for use if the primary goes offline. The metric data can be stored on the same SQL or Oracle server as the IMA data store if the server has sufficient resources. The database connection server is responsible for communicating with each MetaFrame server and the summary database (SQL or Oracle) if data needs to be retained past 96 hours.
Each defined metric has six possible states:
Green indicates the metric is operating within acceptable limits.
Yellow indicates the metric has exceeded the time and value limit.
Red indicates the yellow limit has been exceeded and administrator action has been executed (e-mail, page, SNMP traps, and so on).
Blue indicates a new metric that is not completely defined.
Grey indicates a metric that is paused (snooze) for a predetermined amount of time; in this state, data is still collected, but alerts are not processed.
Black is a sleep state; data is still collected, but alerts are not processed.
Network Manager
Network Manager (NM) is used for limited management through SNMP and to view MetaFrame XP statistics from HP OpenView, Tivoli NetView, and CA Unicenter. This tool can be useful for companies that have existing SNMP management software. NM is a component of XPe only. Since security can be compromised through SNMP, security is a primary configuration concern. If possible, SNMP should be left read-only (the default setting for Window 2000/Windows Server 2003) and all MetaFrame XP management should be done through the CMC or MOM plug-in. If it is critical to restart, terminate processes, disconnect sessions, log off sessions, send messages, and shut down, SNMP requires read-create or read-write permissions. In this case, SNMP should be locked down by limiting these SNMP privileges to only the IP address of the SNMP management server. SNMP is discussed in further depth in Chapter 9.
Installation Manager
Citrix Installation Manager (IM) is designed to automate the application installation process and facilitate application replication across MetaFrame XP servers throughout the enterprise. Through the use of IM, applications can be distributed across multiple servers in minutes rather than days or weeks. IM is available as a part of MetaFrame XPe only. IM is fully integrated into the CMC.
IM is especially useful in organizations utilizing more than 10 MetaFrame XP servers, or having numerous and frequently updated applications. In these environments, the automation offered by IM can yield significant cost and administrative time-savings.
IM contains two components: the Packager and the Installer. With the Installer deployed to all Citrix servers in the enterprise, the Packager makes replicating applications a simple two-step "package and publish" process.
The Packager runs on its own PC or server, while the Installer runs as a background service on each MetaFrame XP server and is transparent to the user.
The Packager provides the administrator with a wizard that supports the step-by-step process of installing and configuring an application. The result is a "package" that contains all application files and a "script" that describes the application setup process.
To "push" an application to MetaFrame XP servers equipped with the Installer, publish the script to those servers. The application will then be distributed and automatically installed onto MetaFrame XP servers across the enterprise.
IM also helps to sort out uninstall issues associated with many applications. For example, with many uninstall programs, application components can be left behind on the server. With IM, the Installer component tracks every application component installed and completely uninstalls the components when the administrator elects to "unpublish" the application on a specific server. This simplifies the relocation of applications from one server to another.
Load Management
Load management is available inMetaFrame XPa and XPe versions to assist administrators in maximizing the utilization of server resources and maintaining optimum user experience. Load management is a concept familiar to many administrators of Microsoft Terminal Server Edition, but it has a special meaning in the context of MetaFrame XP server operation.
With Microsoft's NT Server 4.0 TSE, Windows 2000, and Windows Server 2003 operating systems, multiuser computing capabilities are viewed as a service, much like SQL or Exchange services. Due to this orientation, Microsoft's approach to balancing system load across multiple servers focuses less on the nature and requirements of the load itself (application sessions in the case of multiuser computing), and more on the distribution of the session load across multiple systems. In effect, clients are presented with a virtual IP address representing multiple servers with replicated resources and services. As each server reaches a load threshold, incoming client session requests are forwarded to a server with available resources.
MetaFrame XP takes load managing from the server level to the application level, adding features such as automatic session reconnection and enhanced manageability to terminal services, fine-tuning the concept of load management considerably.
With MetaFrame XP Load Management, an application can be published for execution on any or all MetaFrame servers in a server farm. When an application or desktop session that has been configured for multiple servers is launched by an ICA client, MetaFrame XP Load Management selects which server will run the application based on a set of tunable parameters. Administrators have access to load management variables via the Citrix Management Console (CMC).
How the Load Manager Works
Administrators use the CMC to set load-management parameters. Load management makes decisions based on administrator-defined rules that define lower and upper limits on a number of variables that are defined by load evaluators tracked on each server. Load evaluators are numbers between 0 (free) and 10,000 (fully utilized). The zone data collectors are responsible for keeping track of each server's load evaluators and directing users to the least-busy servers. When more than one rule is applied to a load evaluator, the evaluator with the highest load value defines the load of the server.
Load evaluators can have up to 12 rules. These rules can be broken into four categories: moving average, moving average compared to high threshold, incremental, and Boolean. These categories are explained in more detail next.
Moving average uses rules based on percentage values to calculate load values. The administrator defines a low threshold where the load manager reports no load and a high threshold that the load manager reports a full load. When the moving average is between the low and high thresholds, the load is determined as the percentage multiplied by 10,000. Two-rule types operate with the moving average: CPU utilization, constituting the average usage of CPUs; and memory usage, which is the average of the physical and virtual memory in the server.
The moving average compared to the high threshold reports no load when the moving average is below the low threshold. When the moving average is at or above the high threshold, the load manager reports a full load. When the moving average is between the low and high thresholds, the load manager reports a load value based on the upper threshold value and 0. The lower threshold value is not used in calculating the load. There are five rules that use moving average compared to the high threshold. Context Switches calculate load based on CPU context switches, meaning the OS switches between processes. Disk Data I/O calculates load based on all I/O throughput in kilobytes of disks. Disk Operations calculates load based on disk operations per second for all disks. Page Faults calculates load based on the number of page faults per second, which is the number of pages that the Operating System accesses that have been flushed to disk. Page Swap calculates load based on the number of page swaps per second, which happens when the OS swaps physical memory to virtual memory on disk.
The incremental rules are user friendly and do not require performance monitor or calculations between upper and lower thresholds. All calculations are based on a full load maximum value specified by the MetaFrame XP administrator. When the maximum number specified is reached, the load manager reports full load. Otherwise, the load manager reports a percentage based on the maximum. The load value is calculated by dividing 10,000 by the rule value, then multiplying that value by the current counter. Three rules are in this classification; Application User Load calculates the load based on the number of users connected to an application. Server User Load calculates the load based on the number of users connected to a server. License Threshold calculates load based on the number of assigned connection license counts in use on the server.
Boolean rules are based on conditions being either true or false. If the conditions are met, or found to be "true," access is allowed. Otherwise, it is denied. These rules can be used in conjunction with other load evaluator rules, because they have no associated load values. If no other rules are applied in conjunction with a Boolean rule, all connections are directed to the same server. When one of these rules takes effect, it does not enforce the rule on users already connected. For instance, if the Scheduling rule disables an application at a certain hour, users employing the application can stay connected. However, if the users log off, they cannot reconnect to the application during the hours it is disabled. Boolean rules have two evaluators. IP Range enables or disables access to a server or published application based on source IP address. IP Range rules do not function in mixed mode. Scheduling enables or disables access to a server or published application during specific time periods. Scheduling, like all load evaluators, is checked only during login/application launch.
Load Management in a Mixed Citrix Environment
The MetaFrame XP farm needs to be kept in mixed mode to allow the use of load management when MetaFrame 1.8 or MetaFrame for UNIX servers are to coexist with MetaFrame XP servers. When operating in mixed mode, MetaFrame XP servers communicate with MetaFrame 1.8 servers through the ICA Browser and Program Neighborhood services. MetaFrame XP servers communicate with each other using IMA, but the ICA Browser service is responsible for application resolution and communication with MetaFrame 1.8 and MetaFrame for UNIX servers. For load balancing to work correctly in mixed mode, a MetaFrame XP server must be the master ICA Browser. The following differences exist between operating in native mode:
In mixed mode, application load evaluators and IP Range rules are ignored.
qfarm reports load information from MetaFrame XP servers only. Use qserver/load to view load information in a mixed-mode environment.
The load monitor tool reports MetaFrame XP information only.
Published applications must have the same name (case-sensitive) in both farms for load balancing to work.
Citrix MetaFrame XP Access Suite is a complementary product suite to Microsoft's Terminal Services (included with Windows NT 4.0 Terminal Services Edition, Windows 2000 Server, and Windows Server 2003) discussed in Chapter 2. Today, Citrix serves nearly fifty million users, facilitating a seamless user experience in heterogeneous computing environments, as well as application delivery across bandwidth-restricted connections.
Citrix MetaFrame Access Suite is comprised of five software products:
MetaFrame XP Presentation Server (MetaFrame XP)
MetaFrame Presentation Server for UNIX (MetaFrame for UNIX)
MetaFrame Password Manager
MetaFrame Conferencing Manager
MetaFrame Secure Access Manager (MSAM)
Citrix Password Manager and Conferencing Manager
Password Manager and Conferencing Manager are the newest members of the Citrix MetaFrame Access Suite. Password Manager provides a simple and elegant single sign-on solution for MetaFrame XP environments (although it also works in non-Metaframe environments), and Conferencing Manager provides an all-inclusive collaborative conference interface that leverages the shadow features of MetaFrame XP. These two products further enhance the user experience of the server-based computing environment.
In this chapter, we discuss the evolution of the MetaFrame Access Suite and dissect its Independent Computing Architecture (ICA) protocol. We also cover the enhancements that MetaFrame Access Suite brings to Terminal Services, including:
Secure, encrypted access for all enterprise users from any location, without having to open firewall holes. MetaFrame Secure Gateway provides a secure infrastructure by which users can access the SBC environment literally from anywhere, any time, any place, regardless of the firewall configurations (assuming the environment allows SSL [port 443] traffic). Although Terminal Services RDP traffic is encrypted, it requires that port 3389 be open both on the Data Center firewall and at the user's location(s).
True Application Load Management. Microsoft's built-in Network Load Balancing can be effective for environments with 100 users or less, but enterprise environments absolutely require a more robust and flexible approach to determining which users are placed on which servers under what circumstances.
MetaFrame Web Interface wizard-based deployment tool (formerly called NFuse). Not only does this tool provide an automated approach to deploying access to the SBC environment, but, just as handy, it provides an automated approach to deploying the ICA client itself. Conversely, the deployment and installation of the Remote Desktop Client with Terminal Services can be a daunting task when thousands of users need an update to the client.
Universal Access to applications from any client device, to applications on Windows or UNIX platforms. Although Microsoft now supports client access from Macintosh OS X and Windows clients, Citrix not only provides support for Mac and Windows, but also support for over 200 client operating systems, including most flavors of UNIX and Linux, DOS, and embedded devices.
Enterprise management tools. Citrix provides Resource Manager, Installation Manager, and Network Manager, as well as a host of embedded management tools that present administrators with critical information as well as the automation of enterprise SBC server environments.
Table 3-1 shows the value-add features that Citrix MetaFrame XP add to a Windows Server 2003 environment.
Table 3-1: Citrix ICA Value-Add Features Application publishing
One-to-many shadowing
Customized billing reports
User collaboration
Program Neighborhood
Cross-server shadowing
Track user access to applications
Panning and scaling (handhelds)
Anonymous user support
Shadowing indicator
Centrally install applications
Pass-through authentication
Content publishing
Auto client update
Distribute service packs
Seamless windows
Content redirection
Universal print driver
Package customized install
Multimonitor support
Novell NDS support
Web-based client install
Web Interface for MetaFrame
Application save position
Delegated administration
Support for multiple farms
Non-Windows client access
End-to-end security
Centralized management console
Auto client printer detection
Integration with Network Management consoles
MetaFrame Secure Gateway
Connection control
Resource-based Load Management
Support for direct asynch
SSL/TLS 128-bit encryption
CPU prioritization
Schedule application availability
Client drive remapping
Support for digital certificates
Support for 1000+ servers in farm
Specify client IP range
Text-entry prediction
Socks 4 and 5 proxy support
Many-to-one shadowing
Application monitoring
Instant mouse-click feedback
SpeedScreen 4 browser acceleration
The Evolution of MetaFrame
The Microsoft Windows NT operating system developed from a single-user operating system architecture and continued, for nearly a decade, only to be limited in certain applications by that fact. Windows NT provided real-time multiprocessing capabilities comparable to those of rival UNIX operating systems, but did not provide functions within its OS kernel to support concurrent multiuser access to applications hosted on NT platforms.
Given the dominant business computing architecture of the late 1980s and early 1990s, which featured increasingly capable desktop computers (so-called fat-client PCs) that provided much of the same processing as client-server applications, it may well be that the need for multiuser computing platforms (similar in concept to mainframe computing environments) was not of primary concern to Microsoft designers. In Microsoft's preferred computing model, information processing was conceived as inherently distributed and individualized: desktop computers were viewed as "peers" of server platforms. In fact, most early server systems were little more than highly configured PCs, typically featuring many of the same hardware components.
At that time, there was an interest in some niche areas for a server platform that would "host" applications and share them among several connected client devices, configured as dumb terminals. One such application was remote access: a technique by which one or more offsite users could access an application located on a corporate local area network (LAN). Ideally, the remote user would be able to perform useful work as though seated at a terminal directly attached to the LAN.
However, the mainstream architecture for business computing did not yet involve shared application use. Instead, the norm was a combination of Windows-based desktop computers, emphasizing locally stored and executed individual applications, and Novell, UNIX, or NT-based servers (or a combination of all of these) interconnected via a LAN, supporting client-server computing.
Multiuser Windows—MultiWin
The idea behind server-based computing on Windows NT can be traced to the X-Window System developed by MIT in 1984. By utilizing powerful UNIX servers, remote X-Window clients can send keyboard and mouse input to server-based applications running on central servers. The X-Window System on the server then tracks output from the applications and updates the appropriate remote client session screen.
The founder of Citrix Systems, Ed Iacobucci, originally conceived the idea of allowing different types of computers to run the same applications, even though they might not have the same operating system or adequate local resources. While working as head of the joint Microsoft/IBM design team on the OS/2 project, he approached both companies with the idea, but neither firm was interested. Iacobucci then formed Citrix Systems in 1989 and the technology behind the current Terminal Services was developed—MultiWin. MultiWin rode on top of the OS/2 kernel and allowed multiple simultaneous OS/2 sessions and desktops in a protected memory area for each individual user.
WinView
In 1993, Citrix shipped its first OS/2-based multiuser operating system, called WinView. WinView used the MultiWin technology and one of the first incarnations of a remote display client called Independent Computing Architecture (ICA). Citrix first worked to deliver multiuser extensions to the OS/2 operating system and subsequently worked on the delivery of applications across Novell and TCP/IP networks. Despite prevailing personal and client-server computing models, developers at Citrix believed that multiuser computing had a future, especially as applications moved off the desktop and "into the network." They convinced Microsoft that a market for multiuser NT could be cultivated and secured a license to add multiuser extensions to the NT operating system.
WinFrame
Whether or not Microsoft shared the Citrix vision of the future, the license agreement was certainly a "win-win" for Microsoft and Citrix. With the multiuser extensions provided by Citrix in the form of WinFrame, Microsoft would be able to answer criticisms from UNIX advocates regarding a purported "deficiency" of its server operating systems: they provided little or no support for multiuser computing requirements. If Citrix visionaries were correct, and a market for multiuser computing platforms could be cultivated, Microsoft would have a solution to offer that market.
Citrix WinFrame is a combination of Microsoft Windows NT 3.51 Server and Citrix MultiWin technology. WinFrame was a major upgrade to the OS/2-based WinView. At the time of its release, Windows 3.1 (and later, Windows 95) had become the desktop standard, and WinFrame surpassed WinView as a tool for installing and executing the standard corporate end-user applications.
Thin-Client Computing
In the mid-1990s, the argument for multiuser NT was reinforced by the findings of analysts such as the Gartner Group regarding the total cost of ownership of Windows PCs. Analysts claimed that fat-client PCs cost organizations between $7000 and $13,000 per PC per year in maintenance and support. This position touched off a firestorm of industry activity, mainly from longtime Microsoft rivals. The so-called SONIA set—an acronym for Sun Microsystems, Oracle Corporation, Netscape Communications, IBM, and Apple Corporation—led the charge to displace Microsoft PCs from corporate desktops, substituting their own "network computer" in their place. Despite the obvious self-interest inherent in the SONIA value proposition, and the subsequent failure of the network computer to take hold in the market, the underlying tenant of the SONIA argument took root. The Citrix concept of thin-client computing was introduced to the lexicon of modern business computing.
Thin-client computing advocates held that, as server capabilities grew, it was only natural for server hosts to become "fatter" and for desktop platforms to become "thinner." Application software, advocates argued, should reside on application servers rather than on individual PCs. Placing applications on a server would make them accessible by means of a variety of inexpensive client devices. The advent of the Internet and World Wide Web at about the same time reinforced this perspective. Many people adopted a view of computing in which all applications would be accessed via a universal, hardware-agnostic client such as a web browser.
Citrix Systems Synonymous with Thin
Citrix Systems, with its Independent Computing Architecture (ICA), emerged from the discussion of thin computing as the undisputed leader in a market it had long helped to facilitate. In an ICA-based solution, WinFrame-based application servers could host Windows-compliant applications, while end users, equipped with any of a broad range of client devices (whether network computers or Windows PCs), could access and use the applications over a network connection. Integral to the WinFrame approach was a remote presentation services protocol capable of separating the application's logic from its user interface, so that only keystrokes, mouse-clicks, and screen updates would travel the network. With the ICA protocol, Citrix claimed, the user's experience of the server-hosted application would be comparable in all respects to that of an application executing on the end user's own desktop PC.
Terminal Services and MetaFrame
Increased interest in the WinFrame solution encouraged Microsoft to license MultiWin, the core technology of WinFrame, from Citrix Systems in 1997 and to integrate the technology into its own operating systems soon after. As explained in Chapter 2, Microsoft first implemented MultiWin in a special Terminal Services Edition (TSE) of its NT 4.0 OS. With Microsoft's integration of Terminal Services, Citrix needed to raise the bar for scalability and management. This was accomplished with MetaFrame.
Introduction of MetaFrame 1.0/1.8
Unlike WinFrame, which had been a stand-alone product and a "replacement" operating system for NT, MetaFrame was an add-on to the Microsoft NT 4.0 TSE and Windows 2000 platform. One reason for the MetaFrame product was to continue to meet the needs of WinFrame customers who were interested in migrating their NT 3.51-based WinFrame environments to newer NT 4.0 TSE-based environments but who were afraid of losing application server connections with clients that were not supported by Remote Desktop Protocol (RDP). MetaFrame added ICA client and protocol support back into the Microsoft multiuser operating system offering, since ICA allowed for connectivity from many additional clients than RDP allowed.
MetaFrame XP
MetaFrame XP is the latest version from Citrix. With the release of Feature Release 3 (FR-3), XP is compatible with Microsoft's latest operating system: Windows Server 2003. In addition to the feature updates and changes, another very significant change that Citrix made with MetaFrame XP is the change in licensing; MetaFrame 1.0/1.8 Citrix required a server license for every server with Citrix installed as well as bump packs for additional users, while MetaFrame XP only requires one base license for each server farm (with bump packs for additional concurrent users). This change makes licensing far more flexible and convenient, and in most cases cheaper, as additional servers can be brought online as needed without additional Citrix software license expense (as long as no additional concurrent users are added).
With MetaFrame XP, customers have new version choices, including XPs, XPa, and XPe. All versions of XP are supported on Windows NT 4.0 TSE, Windows 2000 Server, and Windows Server 2003. MetaFrame XP supports full integration with Active Directory in Windows 2000 or Windows Server 2003.
Note Following the release of Feature Release 1, Citrix stopped adding any additional features or enhancements to MetaFrame XP for Windows NT 4.0 TSE.
XPs is the standard version for Citrix servers for stand-alone point solution implementations with one to five servers. XPs feature highlights include MetaFrame Web Interface for MetaFrame, user shadowing, Secure Gateway, Universal Print Driver II, client time zone support, Novell NDS support, client device support, and full ICA client support.
Although more than one server can be used with XPs, it is rare, as applications cannot be load balanced across servers and any application publishing will have to be done separately on each server with different names.
XPa is the advanced version that includes all of the XPs features, with the addition of Load Management. This upgrade is designed for use in farms with 2 to 100 servers.
As shown in Table 3-2, XPe contains all the features included with XPa, as well as some additional features required for enterprise management. These extended features include Resource Manager, Installation Manager, Web Interface Extension for MetaFrame XP (formerly Enterprise Services for NFuse), a plug-in for Microsoft Operations Manager (MOM), and Network Manager. XPe is designed for 20 or more servers and accommodates multiple Citrix Server farms.
Table 3-2: MetaFrame XP FR-3 Feature Grid MetaFrame XPs
MetaFrame XPa
MetaFrame XPe
UNPARALLELED MANAGEABILITY AND SCALE
Advanced Shadowing
Cross-server shadowing
X
X
X
Many-to-one shadowing
X
X
X
One-to-many shadowing
X
X
X
Shadowing indicator
X
X
X
Shadowing taskbar
X
X
X
Application Management
Anonymous user support
X
X
X
Application publishing
X
X
X
Content publishing
X
X
X
Program Neighborhood
X
X
X
TCP-based browsing
X
X
X
Application Packaging and Delivery
Centrally install and uninstall applications
X
Create logical server groups
X
Customizable project details
X
Delivery verification
X
Distribute service packs, updates, and files
X
MSI support
X
Package applications, files, and service packs
X
Package inventory
X
Packager rollback
X
Schedule package delivery
X
Server reboot support
X
Support for unattended installs
X
Centralized Administration
Active Directory support
X
X
X
Novell NDS support
X
X
X
User policies
X
X
X
Administrator toolbar
X
X
X
Centralized Data Store
X
X
X
Citrix administrative accounts
X
X
X
Citrix Management Console
X
X
X
Plug-in for Microsoft Operations Manager (MOM)
X
X
X
Citrix Web Console
X
X
X
Connection control
X
X
X
CPU prioritization
X
X
X
Windows Installer Support
X
X
X
Centralized License Management
Centralized license activation
X
X
X
Enterprisewide license pooling
X
X
X
Plug-and-play licensing
X
X
X
Client Management
Auto client update
X
X
X
Business Recovery
X
X
X
ReadyConnect
X
X
X
Web-based client installation
X
X
X
Network Management
Access CMC from third-party management consoles
X
SNMP monitoring agent
X
Printer Management
MetaFrame Universal Print Driver version II
X
X
X
Support for color and high-resolution printers with Universal Print Driver
X
X
X
Printer auto creation log
X
X
X
Printer driver access control
X
X
X
Printer driver replication
X
X
X
Printing bandwidth control
X
X
X
Resource-Based Load Balancing
Instant load-balancing feedback
X
X
Load balancing reconnect support
X
X
Schedule application availability
X
X
Specify client IP range
X
X
Scalability
Enterprise-class scalability
X
X
X
Cross-subnet administration
X
X
X
System Monitoring and Analysis
Application monitoring
X
Customized reporting
X
Summary database and reporting
X
Perform system capacity planning
X
Real-time graphing and alerting
X
Server farm monitoring
X
Track user access to applications
X
User-definable metrics
X
Watcher window
X
ICA session monitoring
X
TOTAL" NET" LEVERAGE
Web Application Access
Web Interface for MetaFrame
X
X
X
Federal Information Processing Standards (FIPS) 140 security compliance
X
X
X
Support for RSA Secure ID and Secure Computing Premier Access second factor authentication solutions
X
X
X
Multiple server farm support
X
X
X
Application filtering and caching
X
X
X
Support for MetaFrame Secure Access Manager
X
X
X
Web Interface Extension for MetaFrame XP
X
ULTIMATE FLEXIBILITY
Access to Local System Resources
Auto printer creation
X
X
X
Automatic drive redirection
X
X
X
Client drive mapping
X
X
X
Clipboard redirection
X
X
X
COM port redirection
X
X
X
Performance
Instant mouse-click feedback
X
X
X
Persistent bitmap caching
X
X
X
Priority packet tagging
X
X
X
SpeedScreen browser acceleration
X
X
X
SpeedScreen 3
X
X
X
Text-entry prediction
X
X
X
Seamless User Experience
High-/true-color depth and resolution
X
X
X
16-bit audio support
X
X
X
Application save position
X
X
X
Auto client reconnect
X
X
X
Client printer management utility
X
X
X
Client time zone support
X
X
X
Content redirection
X
X
X
Multimonitor support
X
X
X
Panning and scaling
X
X
X
Pass-through authentication
X
X
X
Roaming user reconnect
X
X
X
Seamless windows
X
X
X
Win 16 multi-session support
X
X
X
Universal Connectivity
Universal client access
X
X
X
Support for direct asynch dial-up
X
X
X
Support for TCP/IP, IPX, SPX, and NetBIOS
X
X
X
User Collaboration
User collaboration
X
X
X
END-TO-END SECURITY
Security
MetaFrame Secure Gateway
X
X
X
Delegated administration
X
X
X
SSL 128-bit encryption
X
X
X
TLS encryption
X
X
X
Smart card support
X
X
X
SecureICA 128-bit encryption
X
X
X
SOCKS 4 and 5 Support
X
X
X
Ticketing
X
X
X
The centralized computing using MetaFrame XP provides us with the ability to completely customize which applications are provided to which users. This ensures that all users have access to the necessary resources required for their daily tasks. Software changes and upgrades are performed at the server effective instantaneously for all users. Overall, we have been able to expand and grow our IT projects ahead of estimated schedules with the seamless deployment of applications and minimum maintenance time required for our Citrix Farm.
—Michael P. Miller
Network & Systems Administrator
Primary Care Partners, P.C.
MetaFrame XP is Active Directory compliant. Thus, Active Directory groups may be used to configure permissions and users. Citrix does not change or add to the schema of Active Directory, and MetaFrame allows single sign-on for Active Directory, Novell NDS, and Novell e-Directory environments.
Web interface for MetaFrame is provided by Citrix, with all three MetaFrame XP versions to publish Windows applications to web pages on intranets and the public Internet. This tool also allows customization so that a number of applications can be combined into an "application portal." Additionally, MetaFrame Secure Gateway provides a secure method of application access delivered directly to the end user via a browser, over SSL, providing increased security while reducing problems with Firewall and VPN configurations.
With MetaFrame XP, access to applications can be provided across a variety of networks, including wide area networks, remote access dial-up connections, local area networks, the Internet, and wireless networks. Over 200 types of clients, including Windows PCs, Windows terminals, UNIX workstations, handheld devices, network computers, and numerous others, are supported as ICA clients. These client choices improve dramatically on the RDP client support inherent in Windows NT 4.0 TSE, Windows 2000 Server, and Windows Server 2003.
Independent Computing Architecture (ICA)
ICA is an architecture for server-based computing that competes with and/or complements other architectures such as Microsoft's Remote Desktop Protocol (RDP) and Sun Microsystems/X-Open's X-Window protocol. All of these architectures share in the goal to provide a means to extend resources, simplify application deployment and administration, and decrease the total cost of application ownership.
With all of these server-based computing architectures, applications are deployed, managed, supported, and executed completely on a server. Client devices, whether fat or thin, have access to business-critical applications on the server without application rewrites or downloads.
For everything that ICA, RDP, and the X-Window System have in common, they vary significantly from each other at the component level. Since very little new development is currently being done with the X-Windows System, we will focus our comparisons on ICA and RDP, although the "MetaFrame for UNIX" section provides a brief discussion on ICA versus X-Windows.
ICA Presentation Services Protocol
As depicted in Figure 3-1, the ICA presentation services protocol transports only key-strokes, mouse-clicks, and screen updates to the client. The protocol has been demonstrated to operate consistently with 20 kilobits per second of network bandwidth and provide real-time performance with 30 kilobits per second for office automation applications. This enables even the latest 32-bit applications to be operated remotely across low-bandwidth links while delivering performance comparable to local execution on existing PCs, Windows-based terminals, network computers, and a host of evolving business and personal information appliances.
Figure 3-1: ICA presentation services
The ICA protocol was designed with low-bandwidth connections in mind, making it a robust performer on both large- and small-capacity links. Moreover, the ICA protocol responds dynamically to changing network, server, and client operating conditions. It takes advantage of available network and server resources and adapts automatically when conditions are more restrictive, often without generating any noticeable changes in the end user's experience. Much of the performance of the ICA protocol can be attributed to the use of intelligent caching and data compression techniques, and to technologies such as SpeedScreen. ICA is a non-streaming protocol, meaning that if a user's screen has not changed and they have not moved the mouse or keyboard, no traffic will be passed. This feature can substantially help larger environments operating over a WAN link as many users will not be using any bandwidth at certain instances, allowing much better utilization of the bandwidth as a whole.
Citrix MetaFrame enables us to deploy Windows applications to our students in both a very cost-effective and expeditious manner. This is true whether they are working on a PC or Windows terminal on campus, or working offsite using an Internet connection.
—Tony Holland,
Director of Computing Services,
Stanford Business School
SpeedScreen
SpeedScreen is a technology for improving the performance of application delivery across ICA links. It improves performance by reducing the amount of data that must traverse an ICA connection as an end-user interacts with a MetaFrame server-based application. SpeedScreen targets the repainting function of a hosted application. With many applications, entire screens are repainted with each keyboard entry (or mouse-click) made by the end user. SpeedScreen uses an intelligent agent technology to compare information previously transmitted to the ICA client with information that is about to be transmitted, then transmits only the changed information. This is visually represented in Figure 3-2. By limiting repaint operations to specific sections of a screen affected by user interaction, the amount of traffic that must traverse the connection is dramatically reduced. Citrix's latest release of SpeedScreen, SpeedScreen 4, also called SpeedScreen Browser Acceleration, specifically focuses on major performance and usability improvements for end users connecting to published applications that embed JPEG and GIF images within Microsoft HTML pages. Supported applications include Internet Explorer v5.5 or later, Microsoft Outlook and Outlook Express.
Figure 3-2: How SpeedScreen improves link performance
With some applications, bandwidth consumption may be reduced by as much as 30 percent through the implementation of SpeedScreen, while total packets transmitted may be reduced by 60 percent. The result is lower latency in the network and better application performance for the end user—especially across low-bandwidth connections.
With the SpeedScreen Latency Reduction (SLR) manager, the end-user experience can be enhanced in two ways. First, local text echo can be enabled to give immediate feedback by having the local client render the text. The normal way text is transferred when using MetaFrame is by sending the keystroke to the server, which is processed and then rendered back to the client. This is convenient for users that type quickly, as even the slightest delay can be annoying. Second, SLR can provide for instant feedback for mouse-button clicks.
Connectivity Options
A broader range of connectivity options are supported by MetaFrame and ICA than by RDP, so a more diversified set of users can access and utilize hosted applications. Figure 3-3 depicts the connectivity options enabled by ICA, which include dial-up, ISDN, multiple LANs, wireless LANs, numerous WANs, and the Internet. RDP, by contrast, is limited in its support to only TCP/IP LAN/WAN environments.
Figure 3-3: ICA's connectivity options
Additionally, using MetaFrame and the ICA protocol breaks the barriers imposed by RDP by extending application access beyond Windows PCs. The ICA protocol supports more than 200 clients, providing flexibility in access options far surpassing that of RDP.
The ICA Client Environment
In addition to the contributions of MetaFrame and the ICA protocol to application delivery performance, MetaFrame also enhances the basic multiuser client-server environment. MetaFrame XP embodies numerous innovations designed to facilitate a broad range of hosted application environments. Considerable effort has been invested by MetaFrame XP designers to enable all applications, whether remote or local, to operate and interoperate as though they were local to the end user. This approach increases the user's comfort level and decreases the required training time.
The MetaFrame ICA Desktop
The MetaFrame ICA desktop is designed to provide a user experience that is on par with a Windows PC running locally installed and executed applications. MetaFrame enables complete access to local system resources, such as full 16-bit stereo audio, local drives, COM ports, and local printers, if available.
The mapping of local resources can be performed automatically or by means of administrative utilities. Specialized client capabilities such as modem dial-up are also supported.
Additionally, mapped resources can be shared with the MetaFrame server, if desired. Configuration of these mappings is built into the standard Windows device redirection facilities. The client mappings appear as another network that presents the client devices as share points to which a drive letter or printer port can be attached.
Seamless Windows
Of course, not all MetaFrame XP implementations utilize a full-fledged "remote desktop" model (one in which there are no applications locally installed on the client). Indeed, in many environments where MetaFrame XP is deployed, clients are themselves Windows PCs configured to provide a mixture of some locally installed applications and some remotely hosted applications. Seamless Windows is a feature of MetaFrame designed to accommodate this scenario.
Seamless Windows is a shorthand expression referring to the capability of the Citrix ICA Win32 client to support the integration of local and remote applications on the local Windows 95, Windows 98, Windows NT 4.0, Windows 2000, or Windows XP desktop. When configuring a connection to the MetaFrame XP server, an administrator or user can simply select the Seamless Windows option to enable this function.
With Seamless Windows, the user can gain access to hosted applications without having to load a remote desktop environment. While connected in a MetaFrame XP server session, the user can gain access to local applications using the Windows taskbar. Icons for both local and remote applications can be installed on the local Windows desktop, and both local and remote application windows can be cascaded on the local desktop.
Multiple Keyboards The Seamless Windows environment supports the definition of multiple keyboards to facilitate command entry in local and remote application environments. This prevents specially mapped key combinations used by MetaFrame (such as ALT-TAB) from interfering with similar key combinations used by locally executing applications.
Windows Clipboard Seamless Windows supports the use of the Windows Clipboard in conjunction with both local and MetaFrame-hosted applications. Users can cut, copy, and paste information between applications running remotely on the server or locally from the desktop. Rich text format cut-and-paste is fully supported.
Note The local/remote clipboard is part of MetaFrame XP's overall solution set. It can be used independently of Seamless Windows or Program Neighborhood.
Program Neighborhood
Building on the concept of a Seamless Windows environment, MetaFrame also delivers an easy-to-use method for accessing remotely hosted applications. Similar in concept to the Microsoft Windows Network Neighborhood, MetaFrame pushes links to published applications into a client-based Program Neighborhood facility.
In operation, Program Neighborhood presents application sets to MetaFrame client users. An application set is a user's view of the applications published on a given MetaFrame server or server farm, which that user is authorized to access. A single user- authentication operation (usually initiated when the user launches Program Neighborhood or a MetaFrame-hosted application displayed in the Start menu or as an icon on the local desktop) identifies the user to all MetaFrame servers. Based on the user's individual or group account parameters, the Program Neighborhood is populated with an application set containing each application configured for the specific user account or user group. Published applications appear as icons and are preconfigured with such properties as session window size, color depth, and supported level of encryption, as well as audio and video appropriate to the user and his or her client device.
Program Neighborhood technology is especially useful as a means to quickly publish hosted applications that are intended for use by groups of users. Users can click the Program Neighborhood icon on their Windows desktop (or click the corresponding entry in their Windows Start menu) to review a list of hosted applications available for use. No special client configuration is required to launch and use these published applications.
Management Features
The primary management tool for MetaFrame XP farms is the Citrix Management Console (CMC). The CMC is a Java tool that provides the user interface to control permissions, licensing, published applications, the load management feature of XPa, and the advanced features of XPe for both resource management and network management. The CMC is also the interface to monitor and manage printers, users, and servers. Java was chosen rather than using the Microsoft standard of the Microsoft Manager Console (MMC) for cross-platform compatibility. With the introduction of FR-1, Citrix made available the Citrix Web Console (CWC), which is not as feature-rich as the CMC, but is more convenient to use at all times.
The CMC can provide a significant load on the server farm if not used properly. It is recommended that the auto refresh feature not be used, especially in larger farms. It is also important to publish or use the CMC from the Zone Data Control (ZDC) server. Zone Data Control is further explained later in this chapter. The information that the CMC needs is located in the database on the ZDC, therefore if the CMC is run from a server other than the ZDC server, the server needs to download the information from the ZDC and this adds one more link to the puzzle. Another way to increase efficiency in using the CMC is to create folders within the CMC to categorize published applications and servers. This allows the CMC to refresh without gathering more information than is needed. Another method to reduce load on the CMC is to use the command-line tools that only query very specific data, and thus use the CPU and network bandwidth efficiently.
With MetaFrame XP Feature Release 3, Citrix released the MetaFrame XP Management Pack for MOM. This is a plug-in for Microsoft Operations Manager (MOM) that allows administrators to effectively manage the health and performance of MetaFrame XP servers from the MOM console. Since this interface is not Java based, it tends to be faster and less resource intensive. For users who are already using MOM for server management, this will make a great management tool.
From a client management perspective, MetaFrame XP brings to the administrative tool kit the Automatic ICA Client Update utility and a tool called ReadyConnect to facilitate rapid application deployment. Together, these features can save administrators many hours of tedious client configuration tasks.
The Automatic ICA Client Update utility provides the means to update Citrix ICA client software centrally, from the MetaFrame server itself. The latest versions of ICA client software are identified by the administrator, who then uses the update tool to schedule download and installation on appropriate client devices. This utility reduces the need to travel from client to client throughout the enterprise in order to install and configure the latest version of ICA client software.
ReadyConnect enables client connections to be predefined at the server. By capturing ICA client connection data, including phone numbers, IP addresses, server names, and other connection options, applications can be mass-deployed throughout the enterprise with speed and agility. Users can access applications across predefined connection points through a simple point-and-click operation.
Note While these tools are convenient, we recommend that Web Interface for MetaFrame be used instead to deploy and manage client versions and configurations. This technique will be thoroughly discussed in the "Web Interface for MetaFrame" section of this chapter and later in Chapter 16.
Zone Data Collectors
Understanding zone data collectors is critical to optimizing larger farm performance. Zone data collectors (ZDC) are used to keep information within a server farm up-to-date between member servers and other ZDCs. Every server farm has at least one zone that is set up by default. The trick is to design the right number of zones in a farm so that each ZDC does not get overloaded with traffic from its member servers. In larger farms with 50 or more servers, the ZDC is best served by a MetaFrame XP server that does not accept ICA connections.
Generally, zones start degrading performance between 100 and 300 servers, depending on the number of logins, applications served, and changes in server load. Performance can be maintained in larger farms by creating additional zones. The trade-off of adding more zones is the open link (and thus the bandwidth required) to maintain updates between each ZDC so that all updated data can be propagated throughout the farm. For optimal performance, it is best to keep the number of zones to a minimum, but still keep each zone small enough to be efficient.
The ZDC tracks data that is dynamically collected from the farm to include server load, license utilization, and session information. The more static data for a farm is maintained by the IMA data store including total licensing, published applications, administrators, permissions, server names in the farm, and trust relationships.
The ZDC is chosen with an election process. The variables used for the election process are first the software version, second the administrator-defined preference, and third the host ID. The important thing to keep in mind is that the software version overrides even the administrator-defined preference. Because of the amount of communication that takes place between ZDCs, we do not recommend setting up zones that cross WAN links. The zone traffic data that is sent across WAN links is not manageable within Citrix, but appliances like the Packeteer PacketShaper can manage this bandwidth utilization.
Independent Management Architecture
MetaFrame XP introduced the Independent Management Architecture (IMA) to replace the ICA browser service. IMA is a tremendous improvement over the ICA browser with respect to speed, scalability, and reliability of enterprise server farms.
IMA contains two components. The IMA data store is responsible for keeping information about licenses, published applications, load-balancing parameters, printer options, and security. The IMA protocol is responsible for communications between MetaFrame XP servers that maintain accurate information about server load, license usage, and user connections.
The IMA service runs on all MetaFrame XP servers to communicate with the Citrix Management Console, other MetaFrame XP servers, and the IMA data store. Each Citrix farm has one IMA data store connected to an ODBC database. The databases that are presently supported are MS Jet (FR-3 replaced Jet support with MSDE support), Microsoft SQL Server 7 or later, IBM DB2, and Oracle 7.3.4 or later. Additional licensing is required from Microsoft, IBM DB2, or Oracle if MSDE is not used. Each server downloads its configuration updates each time it is started (when the IMA services start); it also checks for changes every ten minutes. When an administrator is doing testing and maintenance, it is sometimes necessary to have more immediate response for changes. This can be done by executing the dsmaint recreatelhc command from a command prompt on the MetaFrame XP server. When each server queries the IMA data store, it only downloads relevant changes, which reduces the amount of traffic on the network. The local server stores this data in its Local Host Cache. This is helpful for increasing performance of local queries, and the data is retained for 96 hours in case of communications problems with the centralized IMA data store. the zone data collector is also involved in this communication and will be addressed in the next section.
Access to the data store can be done via "direct" or "indirect" mode. Direct mode means that each server directly accesses the database using ODBC, whereas in the indirect mode the servers aggregate queries through one MetaFrame server and it communicates to the data store. When using MS Jet (or MSDE in Feature Release 3) for the data store indirect mode must be used because of performance and locking issues. Direct or indirect mode can be used with SQL, IBM DB2 or Oracle. For small farms (50 servers or less), MSDE can work but has the disadvantage of requiring indirect mode (single point of failure), is much more likely to get corrupted data, and can be a performance bottleneck. For farms that are mission-critical and larger than ten servers, using direct mode with SQL, IBM DB2, or Oracle is recommended. The SQL, IBM DB2 or Oracle server does not need to be dedicated to the data store, since these databases support more than one database per server, assuming, of course, that sufficient server resources are available.
Data store replication is a concern in larger farms. When a server queries the data store (especially over slow link speeds) other servers could timeout and cause problems. SQL, IBM DB2, and Oracle contain integrated replication capabilities that are effective in solving this problem (the dual-commit model is recommended). When planning the resources for the data store, a good rule of thumb is to allocate about 200KB of disk space for each MetaFrame XP server.
Resource Manager
MetaFrame XPe is required when using Resource Manager (RM). This product equips administrators with a full-featured management tool suite for analyzing and tuning Citrix MetaFrame XPe servers. RM adds real-time monitoring, historic reports, and a central repository of usage information and statistics to the MetaFrame product suite.
Resource Manager keeps data for 96 hours with an internal database (15-second server snapshots) and integrates with Microsoft SQL and Oracle databases to store long-term statistics. The local database will utilize about 7MB of data for each metric to maintain data for 96 hours. The local database is only compressed when the IMA service is started; this provides one more reason to script reboot the MetaFrame XP servers every 24 to 48 hours. The link http://www.citrix.com/download contains a group of predefined free crystal reports available for use with a Microsoft SQL/Oracle database.
While monitoring the server statistics, RM can send out e-mail, pages, or SNMP traps when predefined loads are met (for example, when CPU utilization reaches 60 percent, RM can send the Citrix administrator group an e-mail). RM uses metrics to define monitored parameters, alert thresholds, and configurations. Metrics, once defined, can be applied to servers or published applications. Hundreds of example metrics are included with the RM installation. Citrix recommends, for performance reasons, not to have more than 50 metrics per server.
The farm metric server is the central server that manages all of the metrics on each of the servers and published applications. By default, the first server in the farm to have RM installed on it becomes the farm metric server, although this can be moved by the administrator at any time. Better performance can be achieved by having the farm metric server on the same machine as the zone data collector. RM can be installed on a second server in the farmer, which will automatically become the backup farm metric server for use if the primary goes offline. The metric data can be stored on the same SQL or Oracle server as the IMA data store if the server has sufficient resources. The database connection server is responsible for communicating with each MetaFrame server and the summary database (SQL or Oracle) if data needs to be retained past 96 hours.
Each defined metric has six possible states:
Green indicates the metric is operating within acceptable limits.
Yellow indicates the metric has exceeded the time and value limit.
Red indicates the yellow limit has been exceeded and administrator action has been executed (e-mail, page, SNMP traps, and so on).
Blue indicates a new metric that is not completely defined.
Grey indicates a metric that is paused (snooze) for a predetermined amount of time; in this state, data is still collected, but alerts are not processed.
Black is a sleep state; data is still collected, but alerts are not processed.
Network Manager
Network Manager (NM) is used for limited management through SNMP and to view MetaFrame XP statistics from HP OpenView, Tivoli NetView, and CA Unicenter. This tool can be useful for companies that have existing SNMP management software. NM is a component of XPe only. Since security can be compromised through SNMP, security is a primary configuration concern. If possible, SNMP should be left read-only (the default setting for Window 2000/Windows Server 2003) and all MetaFrame XP management should be done through the CMC or MOM plug-in. If it is critical to restart, terminate processes, disconnect sessions, log off sessions, send messages, and shut down, SNMP requires read-create or read-write permissions. In this case, SNMP should be locked down by limiting these SNMP privileges to only the IP address of the SNMP management server. SNMP is discussed in further depth in Chapter 9.
Installation Manager
Citrix Installation Manager (IM) is designed to automate the application installation process and facilitate application replication across MetaFrame XP servers throughout the enterprise. Through the use of IM, applications can be distributed across multiple servers in minutes rather than days or weeks. IM is available as a part of MetaFrame XPe only. IM is fully integrated into the CMC.
IM is especially useful in organizations utilizing more than 10 MetaFrame XP servers, or having numerous and frequently updated applications. In these environments, the automation offered by IM can yield significant cost and administrative time-savings.
IM contains two components: the Packager and the Installer. With the Installer deployed to all Citrix servers in the enterprise, the Packager makes replicating applications a simple two-step "package and publish" process.
The Packager runs on its own PC or server, while the Installer runs as a background service on each MetaFrame XP server and is transparent to the user.
The Packager provides the administrator with a wizard that supports the step-by-step process of installing and configuring an application. The result is a "package" that contains all application files and a "script" that describes the application setup process.
To "push" an application to MetaFrame XP servers equipped with the Installer, publish the script to those servers. The application will then be distributed and automatically installed onto MetaFrame XP servers across the enterprise.
IM also helps to sort out uninstall issues associated with many applications. For example, with many uninstall programs, application components can be left behind on the server. With IM, the Installer component tracks every application component installed and completely uninstalls the components when the administrator elects to "unpublish" the application on a specific server. This simplifies the relocation of applications from one server to another.
Load Management
Load management is available inMetaFrame XPa and XPe versions to assist administrators in maximizing the utilization of server resources and maintaining optimum user experience. Load management is a concept familiar to many administrators of Microsoft Terminal Server Edition, but it has a special meaning in the context of MetaFrame XP server operation.
With Microsoft's NT Server 4.0 TSE, Windows 2000, and Windows Server 2003 operating systems, multiuser computing capabilities are viewed as a service, much like SQL or Exchange services. Due to this orientation, Microsoft's approach to balancing system load across multiple servers focuses less on the nature and requirements of the load itself (application sessions in the case of multiuser computing), and more on the distribution of the session load across multiple systems. In effect, clients are presented with a virtual IP address representing multiple servers with replicated resources and services. As each server reaches a load threshold, incoming client session requests are forwarded to a server with available resources.
MetaFrame XP takes load managing from the server level to the application level, adding features such as automatic session reconnection and enhanced manageability to terminal services, fine-tuning the concept of load management considerably.
With MetaFrame XP Load Management, an application can be published for execution on any or all MetaFrame servers in a server farm. When an application or desktop session that has been configured for multiple servers is launched by an ICA client, MetaFrame XP Load Management selects which server will run the application based on a set of tunable parameters. Administrators have access to load management variables via the Citrix Management Console (CMC).
How the Load Manager Works
Administrators use the CMC to set load-management parameters. Load management makes decisions based on administrator-defined rules that define lower and upper limits on a number of variables that are defined by load evaluators tracked on each server. Load evaluators are numbers between 0 (free) and 10,000 (fully utilized). The zone data collectors are responsible for keeping track of each server's load evaluators and directing users to the least-busy servers. When more than one rule is applied to a load evaluator, the evaluator with the highest load value defines the load of the server.
Load evaluators can have up to 12 rules. These rules can be broken into four categories: moving average, moving average compared to high threshold, incremental, and Boolean. These categories are explained in more detail next.
Moving average uses rules based on percentage values to calculate load values. The administrator defines a low threshold where the load manager reports no load and a high threshold that the load manager reports a full load. When the moving average is between the low and high thresholds, the load is determined as the percentage multiplied by 10,000. Two-rule types operate with the moving average: CPU utilization, constituting the average usage of CPUs; and memory usage, which is the average of the physical and virtual memory in the server.
The moving average compared to the high threshold reports no load when the moving average is below the low threshold. When the moving average is at or above the high threshold, the load manager reports a full load. When the moving average is between the low and high thresholds, the load manager reports a load value based on the upper threshold value and 0. The lower threshold value is not used in calculating the load. There are five rules that use moving average compared to the high threshold. Context Switches calculate load based on CPU context switches, meaning the OS switches between processes. Disk Data I/O calculates load based on all I/O throughput in kilobytes of disks. Disk Operations calculates load based on disk operations per second for all disks. Page Faults calculates load based on the number of page faults per second, which is the number of pages that the Operating System accesses that have been flushed to disk. Page Swap calculates load based on the number of page swaps per second, which happens when the OS swaps physical memory to virtual memory on disk.
The incremental rules are user friendly and do not require performance monitor or calculations between upper and lower thresholds. All calculations are based on a full load maximum value specified by the MetaFrame XP administrator. When the maximum number specified is reached, the load manager reports full load. Otherwise, the load manager reports a percentage based on the maximum. The load value is calculated by dividing 10,000 by the rule value, then multiplying that value by the current counter. Three rules are in this classification; Application User Load calculates the load based on the number of users connected to an application. Server User Load calculates the load based on the number of users connected to a server. License Threshold calculates load based on the number of assigned connection license counts in use on the server.
Boolean rules are based on conditions being either true or false. If the conditions are met, or found to be "true," access is allowed. Otherwise, it is denied. These rules can be used in conjunction with other load evaluator rules, because they have no associated load values. If no other rules are applied in conjunction with a Boolean rule, all connections are directed to the same server. When one of these rules takes effect, it does not enforce the rule on users already connected. For instance, if the Scheduling rule disables an application at a certain hour, users employing the application can stay connected. However, if the users log off, they cannot reconnect to the application during the hours it is disabled. Boolean rules have two evaluators. IP Range enables or disables access to a server or published application based on source IP address. IP Range rules do not function in mixed mode. Scheduling enables or disables access to a server or published application during specific time periods. Scheduling, like all load evaluators, is checked only during login/application launch.
Load Management in a Mixed Citrix Environment
The MetaFrame XP farm needs to be kept in mixed mode to allow the use of load management when MetaFrame 1.8 or MetaFrame for UNIX servers are to coexist with MetaFrame XP servers. When operating in mixed mode, MetaFrame XP servers communicate with MetaFrame 1.8 servers through the ICA Browser and Program Neighborhood services. MetaFrame XP servers communicate with each other using IMA, but the ICA Browser service is responsible for application resolution and communication with MetaFrame 1.8 and MetaFrame for UNIX servers. For load balancing to work correctly in mixed mode, a MetaFrame XP server must be the master ICA Browser. The following differences exist between operating in native mode:
In mixed mode, application load evaluators and IP Range rules are ignored.
qfarm reports load information from MetaFrame XP servers only. Use qserver/load to view load information in a mixed-mode environment.
The load monitor tool reports MetaFrame XP information only.
Published applications must have the same name (case-sensitive) in both farms for load balancing to work.
Windows Terminal Services
The Terminal Services Family
Microsoft Windows 2000 and 2003 Terminal Services allow multiple users to log on to a Windows 2000 or Windows 2003 server, have their own desktop environment, and execute programs that stay resident. User logons effectively get their own protected memory space for applications and data. Users can have a Windows desktop and run Windows- based applications without the need to load the applications on their local PC. A server running Terminal Services can host hundreds of concurrent users (the specifics of server sizing will be covered in later chapters). In this chapter, we will use the generic term Terminal Server to refer to a server running Windows 2000 Server or Windows Server 2003 with Terminal Services enabled.
The client computing device used to communicate with the Terminal Server can be a PC or a specially designed terminal made to work with the Terminal Server display protocol. The PC or terminal runs a relatively small program that enables a logon and accepts redirected screen output from the Terminal Server. The Microsoft Terminal Services client program relies on a protocol originally developed for Microsoft's NetMeeting, called Remote Desktop Protocol (RDP). RDP is based on the International Telecommunications Union's (ITU) T.120 protocol. The T.120 protocol is a standard multichannel conferencing protocol that is tuned for enterprise environments and supports session encryption.
Terminal Services History—It Started with Windows NT 4.0 Server, Terminal Server Edition
Microsoft's Windows NT 4.0 Server, TSE, was the implementation of Citrix MultiWin (which will be discussed in Chapter 3) on the Windows NT 4.0 Server platform. Although Windows NT 4.0 is no longer officially supported by Microsoft or Citrix, it is worth discussing the beginnings of Terminal Services technology to further understand where it is today. For those still running Windows NT 4.0 TSE, we strongly recommend upgrading to Windows 2003 (see the upcoming "Windows 2003 Server" section for justification). If support for 16-bit applications is required, NT 4.0 Terminal Services Edition (TSE) is still necessary, as Windows 2000 and 2003 do not effectively support 16-bit applications.
Because of the MultiWin-inspired kernel of TSE, users could log on to virtual Windows NT 4.0 sessions with the same desktop and application look and feel of Windows NT 4.0 Workstation. With TSE, Microsoft created a separate code base for the operating system in order to overcome some of the memory management limitations of Windows NT 4.0 Server and to generally tune it for multiuser access.
Microsoft included their Terminal Server client, which is the client portion of the Remote Desktop Protocol, with TSE. This RDP client supported a variety of Windows desktops over TCP/IP networking, including Windows 95 and 98, Windows CE, Windows NT Workstation, Windows 2000, and Windows XP.
TSE Internals
In order to achieve the multiuser capabilities required in TSE, the Citrix MultiWin technology needed to be integrated into the Windows NT 4.0 Server kernel. This integration meant that several components, services, and drivers were added or modified in the original Windows NT 4.0 Server core operating system. Windows NT 4.0 components such as the Virtual Memory Manager (VMM) and Object Manager (OM) were modified to perform in a multiuser environment.
Virtual Memory Manager The VMM in TSE mapped virtual addresses in the process's address space to physical pages in the computer's memory. In Windows NT, a process's address space was divided into two 2GB address ranges: user (process-specific addresses) and kernel (system-specific addresses). For the user address space, the VMM provided an individualized view of the physical memory to each process, ensuring that a call for system resources (a thread) within a process can access its own memory, but not the memory of other processes.
SessionSpace The kernel address space in TSE was common for all processes within the system, thus providing a consistent means for accessing all kernel services. The fact that all processes in Windows NT 4.0 shared the kernel address space resulted in kernel resource limitations when supporting multiple interactive sessions on a single server. In TSE, these limitations were addressed by creating a special address range in the kernel, called SessionSpace, which could be mapped on a per-session basis. Each process was associated with a SessionSpace via a SessionID. When a remote user connected to Terminal Server, a new SessionID was generated, and all of the processes created for that connection inherited that SessionID and unique session space, as shown next. Other process groups, with a different SessionID, point to a separate set of memory-mapped objects and physical pages at the same virtual address.
The Windows NT 4.0 Terminal Server made all objects required for multiuser capability virtual so that the applications and system programs from different user sessions do not collide. Every object name created within a session is appended with a unique identifier number associated with the individual user session (SessionID) that created it. For example, if a user started an application in the first session on the Terminal Server, the session would be seen as session1 and the application seen as application1, as shown in Figure 2-1.
Figure 2-1: Execution of a multiuser Windows application
The Remote Desktop Protocol was designed to support TCP/IP over LAN or WAN communication links. Due to the multisession nature of the protocol, a special user mode extension (RDPWSX), as depicted in Figure 2-2, is needed to receive all incoming client packets. RDPWSX manages sessions and calls WINLOGON to authenticate them. In addition, RDPWSX will validate the client license with the license server and negotiate client-server encryption keys.
Figure 2-2: An RDP session
Upon successfully establishing a session, the MultiWin subsystem gained control over session management. A virtual session was created by localizing a copy of WIN32K.SYS with all the necessary device drivers. The TERMDD (Terminal Server Device Driver) then provided the run-time environment of a session-specific protocol driver in order to service multiple client session requests. To support the mouse and keyboard commands sent to each session's copy of the WIN32K.SYS subsystem, the RDPWD (Remote Desktop Winstation Driver) was loaded.
The console session was always the first to load, and was assigned a special client connection ID of 0. The console session launched at system startup with the system-configured Windows NT display, mouse, and keyboard drivers loaded. The Terminal Server service contacted the Windows NT session manager (SMSS.EXE) and loaded the RDP user mode protocol extension RDPWSX to create two idle client sessions right after the creation of the console session. These two idle sessions listened on TCP service port 3389 for RDP protocol packets from the client.
Code Sharing Terminal Server also implemented memory code sharing (also known as Copy on-Write Page Protection). This feature allowed one copy of executable code, such as Microsoft Word, to be loaded into physical memory, and to have multiple users run the same copy of the program code. If a user loaded a private copy of a Word document, a separate memory space would be set aside and marked as read/write under the protection of Virtual Memory Manager. No other process could access this private memory space. This was extremely useful and efficient when a large number of users were using the same programs.
Note Code sharing cannot be utilized in 16-bit applications, since they need to run inside a separate DOS VDM (Virtual Dos Machine). For this reason, approximately 20 percent more memory is used by 16-bit and DOS applications than by comparable 32-bit applications. In order to properly size the RAM requirement in TSE, a live functional test should be conducted to observe the total working set of memory consumed by a specific application, because many 32-bit applications contain 16-bit code.
Windows 2000 Terminal Services
In Windows 2000 Terminal Services, SessionSpace remains. The layout on the memory map has been modified to further tune the system and enable a common layout for all Windows 2000 systems, whether or not Terminal Services has been installed. The main modification is that SessionSpace has been reduced to 60MB and starts at the memory address location A0000000. Moving SessionSpace up to A0000000 allows all system drivers (win32k.sys), video drivers, and printer drivers to be loaded in a common virtual address location, whether they are accessed through a Terminal Services session or on a session without Terminal Services. Microsoft redesigned the memory mapping to eliminate the need for a separate version of the operating system to support Terminal Services, as was necessary with Windows NT 4.0 Server and TSE. Among other obvious advantages, service packs for Terminal Services no longer lag behind those for the base operating system as they did with TSE.
A new Windows 2000 service, appropriately called Terminal Services (termsrv.exe), is the controlling process in the Terminal Server architecture. It is primarily responsible for session management, initiation, and termination of user sessions and session event notification. The Terminal Server service is entirely protocol independent, so it can function using RDP or a third-party add-on protocol such as ICA from Citrix.
A user mode protocol extension provides assistance to the Terminal Server service. It is the responsibility of this component to provide protocol-specific functions and services, such as licensing, session shadowing, client font enumeration, and so forth. Each Terminal Server session protocol (for example, RDP and ICA) has its own protocol extension, providing a variety of services.
Note For RDP, this user mode extension is called wsxtshar.dll.
Windows 2003 Server
Windows Server 2003 is now the flagship product for Terminal Services. Packaged with the release of Windows Server 2003 is a new client connection program. The new Terminal Services client, first released with Windows XP, is called Remote Desktop Connection (RDC) and provides substantial improvements over previous releases, including greater functionality through a simplified user interface. RDC can also be used to connect to a Windows XP Professional-based computer running Remote Desktop, and can be used to connect to previous versions of Terminal Services (Windows NT 4—Terminal Server Edition and Windows 2000 Server). RDC utilizes a new version of RDP and a new licensing model that provides for user and device licensing of Terminal Services and NT CAL's rather than just device licensing that had been required (see the "Licensing" section later in this chapter). This licensing change represents a tremendous win for all Windows SBC environments, as it dramatically reduces the costs for environments where users have more than one device they connect from. For example, under the Windows 2000 licensing model, if a user connected to a Terminal Services server or farm from a laptop, desktop, and home computer, Microsoft required the user's organization to purchase three Windows Terminal Services client access licenses and three Windows 2000 Server client access licenses for this one user. Under the new per-user licensing, the organization will only need to purchase one license for that user.
Windows 2003 Editions Comparison
Windows Server 2003 comes in six releases and four named editions; Standard, Enterprise, Datacenter, and Web. The Web edition will run on small-footprint servers. As the name implies, this edition is for web servers only—systems running IIS 6.0 and web applications. This edition will make an excellent and cost-effective platform for web services such as MetaFrame Web Interface and MetaFrame Secure Access Manager, as discussed in Chapter 16.
The Standard edition is the general-purpose version intended for traditional Windows Server tasks such as file and print serving, security, and Terminal Services. This is the server upon which a Citrix MetaFrame XP installation is most likely to be based.
The Enterprise edition is a "hardened" version of the operating system. Microsoft has added a number of features to this edition to increase its value as an application server platform. We envision that this server will be used for three potential purposes: large Terminal Services Farms, clustering, transaction processing, or server consolidation.
Finally, the Datacenter edition is the "big iron" version of the operating system. It is designed for the most demanding application and availability requirements where hardware cost is not a concern. This version requires a minimum of eight CPUs in a system and can run on systems containing up to 32 CPUs. System administrators who covet the chance to work on a Windows "mainframe" will be running this.
As mentioned, there are actually six releases. The additional two are the 64-bit versions of the Enterprise and Datacenter editions designed for the Intel Itanium processor. Because of the emphasis by the Microsoft SQL Server team on 64-bit computing, these releases will be targeted at high-volume database or transaction processing applications, but not much else.
Table 2-1 compares the features of the four named editions.
Table 2-1: Windows 2003 Editions Comparison Feature
Standard Edition
Enterprise Edition
Datacenter Edition
Web Edition
Scalability
64-bit support for Intel Itanium-based computers
+
+
Hot add memory [1], [2]
+
+
Non-Uniform Memory Access (NUMA)[2]
+
+
Datacenter program
+
Maximum RAM Support
2GB
+
+
+
+
4GB
+
+
+
32GB
+
+
64GB [3]
1/2
+
512GB [4]
1/2
Maximum Symmetric Multiprocessing Support (SMP)
2-way
+
+
+
+
4-way
+
+
+
8-way
+
+
32-way
+
64-way
+
Directory Services
Active Directory
+
+
+
1/2
Metadirectory Services (MMS)
+
+
support
Security Services
Internet connection firewall
+
+
+
Public Key Infrastructure, certificate services, and smart cards
1/2
+
+
1/2
Terminal Services
Remote Desktop for Administration
+
+
+
+
Terminal Server
+
+
+
Terminal Server Session Directory
+
+
Clustering Technologies
Network load balancing
+
+
+
+
Cluster service
+
+
Communications and Networking Services
Virtual private network (VPN) support
+
+
+
1/2
Internet Authentication Service (IAS)
+
+
+
Network bridge
+
+
+
Internet Connection Sharing (ICS)
+
+
IPv6
+
+
+
+
File and Print Services
Distributed File System (Dfs)
+
+
+
+
Encrypting File System (EFS)
+
+
+
+
Shadow Copy Restore
+
+
+
+
Removable and remote storage
+
+
+
Fax service
+
+
+
Services for Macintosh
+
+
+
Management Services
IntelliMirror
+
+
+
1/2
Group policy results
+
+
+
1/2
Windows Management Instrumentation (WMI) command line
+
+
+
+
Remote OS installation
+
+
+
+
Remote Installation Services (RIS)
+
+
+
Windows System Resource Manager (WSRM)
+
+
.NET Application Services
.NET Framework[1]
+
+
+
+
Internet Information Services (IIS) 6.0
+
+
+
+
ASP.NET[1]
+
+
+
+
Enterprise UDDI services
+
+
+
Multimedia Services
Windows Media Services
+
+
+
Key: + = Feature included 1/2 = Feature partially supported
Remote Desktop Protocol (RDP)
In this part of the chapter, we describe in more detail how the Remote Desktop Client performs session management and other functions.
Session Connection
When a client initiates a session, the TCP/IP transport driver passes the request to the TERMDD program on the Terminal Server. TERMDD then passes the request to RDPWSX, which in turn signals the Terminal Server service to create a thread to handle the incoming session request. In addition, RDPWSX is responsible for initiating session negotiation with the client and capturing all necessary client information, such as compression, encryption level, client version number, and license details. As each client connection is accepted and assigned an idle SessionSpace, a new idle session is created. The session manager also executes the client-server run-time subsystem process (csrss.exe), and a new SessionID is assigned to that process. The CSRSS process then invokes the Windows Logon (winlogon.exe) and the graphic device interface (GDI) module (win32k.sys) to render the initial logon screen information and present it to the particular user SessionID, as shown in Figure 2-3.
Figure 2-3: The connection process in an RDP session
Note For use under heavy session logon activity, a registry setting can increase the two idle session numbers. The values are contained in the following key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\IdleWinstationCount\.
Network Load Balancing on Session Connections
RDC can utilize Network Load Balancing (NLB), available in Windows Server 2003 Standard, Enterprise, and Datacenter Server Editions, as well as Windows 2000 Advanced Server and Datacenter Server. NLB utilizes a round-robin approach for session connectivity to multiple Terminal Servers. NLB can detect downed servers, thus sending a client to one of the remaining live servers, and effectively eliminating a single point of failure if one server is down. Note though that this service is not the same as Citrix's load balance service, which utilizes server parameters rather than the network round robin that NLB utilizes. It is the opinion of the authors that NLB is not a sufficient tool for load balancing or effective redundancy in an enterprise server farm environment, but it may be sufficient for smaller environments (less than four servers in the farm).
Session Disconnection
When a user disconnects from an active session without logging off, the GDI stops taking commands from the user by stopping all drawing operations from reaching the display driver. A disconnected desktop object is created and represented in the Terminal Services Manager application (Start Menu | Administrative Tools | Terminal Services Manager), as shown in Figure 2-4.
Figure 2-4: The Terminal Services Manager application showing a disconnected session
During the disconnection timeout period, the RDP stack is unloaded, but TERMDD is still active because win32k.sys maintains an active handle to it for keyboard and mouse control. Before the timeout period expires, the user can be reconnected to the same session. The session disconnect process is shown in Figure 2-5.
Figure 2-5: The disconnection process in an RDP session
Session Reconnection
When a user initiates a connection to the same server, a brand-new connection is created. The RDP stack is loaded, and SessionSpace is assigned. The user is presented with a logon screen. Thus far, the process is identical to a new session connection. However, when WINLOGON scans the user ID and determines that the user has a disconnected session, TERMDD is instructed to perform a session reconnection. The user session is then switched back to the disconnected session.
Data Transmission
RDP packets are formed in the presentation layer of the Open System Interconnect (OSI) model. The packets are encrypted and frames packaged according to the requirements of the network protocol. Currently, only TCP/IP is supported by RDP. The RDP data content may include keyboard input and mouse movement coordinates, as well as graphical bitmaps and printer redirection output. The return RDP packet goes in reverse through the same protocol stack, is decrypted, and unwrapped, and the TCP/IP header information is stripped for the specific client session. Some of the data transmission optimization features of RDP include the following:
Intelligent encoding The redrawing of graphical images can be encoded to tell the client to redraw changes only since the last refresh took place. In other words, only the changes are sent.
Glyph and bitmap caching A glyph is a graphical representation of a character. The RDP client automatically reserves a minimum of 1.5MB of memory space to cache the required set of glyphs needed in the display of common text. Bitmaps of different sizes are also cached in memory. Whenever a command is issued from the Terminal Server, the client can redraw the required text and bitmaps very quickly by extracting the elements from cache.
Bulk compression A client-side option optimizinga low-speed connection will turn on bulk compression, which can reduce the packet count by 50 percent.
Image Display
RDP uses a highly efficient encoding algorithm to encapsulate screen data, similar to the X-Window protocol. Most common or repetitive drawings are sent as a command rather than an actual bitmap. This method greatly reduces the amount of data required to paint a new screen or refresh an old one. Microsoft has published the exact bandwidth requirements to paint a common Windows screen, but lab tests from Mainstream Networks show that RDP 4.0 used up to 40 Kbps on a dial-up connection (with compression). There is a significant improvement in bandwidth utilization on the Windows 2000 version of RDP—version 5.0. These improvements continue with the Remote Desktop Client released with Windows 2003.
RDP updates the screen as follows. A user starts an application, which informs the GDI where and how to draw the application window. The GDI relays the command to the RDP display driver (RDPDD) by way of standard Win32 API calls. This is the same process used in a Windows NT system without Terminal Services, and is similar to the way a print job is rendered. The main API calls sent to RDP include the following:
TextOut() This call results in the display of text information ona client screen. GDI informs RDP of the location and the glyphs (a graphical representation of a character). RDP tells the client which glyph to cache and which cache entry to use next time the same text is called for.
PatBlt() Pattern Block Transfer is used by RDP to tell the client how to draw a block of color. This translates into a small command and is the alternative to sending a block of bitmaps and consuming a large amount of bandwidth.
LineTo() This command allows RDP to tell the client the beginning and ending coordinates of a 3-D beveling line. The line can be used to form boxes. This command can be as small as 6 bytes to complete a line drawing.
Windows 2000 Graphical Enhancements
RDP version 5.0 not only improved the protocol communication efficiency, it also expanded its feature set and offers some of the benefits contained in the ICA protocol.
Remote control This feature allows an administrator or authorized person to take over the screen, keyboard, and mouse movement of any user session running to the same physical machine.
Clipboard redirection The RDP version 5.0 protocol synchronizes the server-side application clipboard to the client-side clipboard buffer. This allows applications running on the Terminal Server to cut and paste data to applications running on the client workstation.
Client printer autocreation Local client COM and LPT ports can be remapped automatically from the server. The local default printer will be created in the Terminal Server session, and print jobs produced by applications running in a server session will be printed on the client's local default printer.
Bitmap cache Windows 2000 RDP provides additional persistent bitmap cache over version 4.0, which only used RAM cache. Upon successful bitmap transmission, the server instructs the client where to store persistent cache information. When the same data is needed again, only the location coordinate for this bit is sent to the client. This improvement is especially important in low-speed dial-up or wireless WAN connections.
Windows 2000 Terminal Services Client Architecture
Windows 2000 with RDP 5.0
With the introduction of Windows 2000, Microsoft significantly improved the capabilities of the core operation system to have Terminal Services integrated with all server platforms. Enhancements were also made to the RDP client allowing for better performance and additional features. The major advantages to this integration were the availability of standard services packs for Windows and Terminal Services and the requirement for software vendors to address compatibility with the multiuser environment. Between the releases of Windows 2000 Server and Windows Server 2003, Microsoft released Terminal Services Advanced Client (TSAC) which superceded the RDP client that shipped with Windows 2000. The TSAC, is based on the RDP 5.0 feature set, but comes in the form of an ActiveX control. The performance of the TSAC is comparable to the previous client, but offers far more flexibility in its deployment. It can be downloaded and executed within Microsoft Internet Explorer, or any application that can make use of ActiveX controls, such as those written in the Visual Basic or Visual C++ development systems. In addition to the downloadable ActiveX control, it is also available in the form of an MSI (Windows Installer) package, which looks and feels to the end user like the traditional RDP 5.0 client. Finally, the client is also available as an MMC snap-in, for administrators to use to assist with server administration.
Windows 2003 and RDC
Microsoft continues to improve functionality with the release of Windows Server 2003. The additional features of Windows Server 2003 allow integrated detailed control of security in a Terminal Services environment that previously were left to the creativity of the administrator and third-party applications. Remote Desktop Client (RDC) provides for better performance with streaming video, security, and client resource availability, and is now ported to the Mac OS X platform.
RDC using RDP now supports the following four operating system platforms:
The Win32 platform, which includes Windows XP, Windows 2000, Windows NT, Windows 95, 98, and Windows Millennium (available for download at http://www.microsoft.com/windowsxp/remotedesktop/)
The Win16 platform, which includes Windows and Windows for Workgroups 3.11
The WinCE platform, which includes many new thin-client devices with WinCE running as the embedded operating system
A Macintosh Remote Desktop Client (RDC) for MAC OS X (available for download at http://www.microsoft.com/mac/download/misc/rdc.asp)
Microsoft's design goals for RDC are to minimize bandwidth utilization, minimize memory usage, and speed up screen transmission. RDC represents a striking improvement over both RDP version 4.0 and RDP version 5.0 in both speed and features.
Table 2-2 shows a comparison of some of the major features of RDP and RDC.
Table 2-2: RDP Version 5.0 vs. RDC Feature
Description
RDP 5.0
RDC for Windows 2003 and Windows XP
Clients
32-bit clients for Windows 95, 98, NT, 2000 and 2003
Yes
Yes
16-bit client for Windows 3.11
Yes
Yes
Windows CE-based clients
Yes
Yes
Browser client
With TSAC
With TSAC
Transport protocol
TCP/IP
Yes
Yes
Audio
System beeps
Yes
Yes
Print stream compression
Compression of print jobs executed in a Terminal Services session
No
Yes
Terminal Services: slow link performance optimizations
Improved performance of high latency and slow throughput connections
No
Yes
Local printer redirection
Print to client-attached printer
Yes
Yes
Local drive mapping
Local client drive access from session
Yes
Yes
Cut and paste
Cut and paste between server session and client session
Yes
Yes
Remote control
Remote viewing and control of a session
Yes
Yes
Bitmap caching
Bitmap caching in memory
Yes
Yes
Bitmap caching to disk
Yes
Yes
Time zone redirection
Remote client clock shows correct time, regardless of whether client is in different time zone from Terminal Server
No
Yes
Macintosh client
Client for Mac OS X
No
Yes
Preconfigured client
Predefined client with IP address, server name, and connection information
Yes
Yes
RDP Client Software Architecture
The RDP client software is installed on the server under the directory %systemroot%\system32\clients\tsclient. The client disk creator program under Start | program | Administrative tools | Terminal Server Client Creator will make the necessary disk set for distribution to client PCs.
When the Terminal Server client starts, the user interface calls the core API to set up a session with a server name or IP address. The default TCP/IP port is set to 3389. The security layer in turn calls the network layer to set up a socket with the goal of establishing a connection to the server. Once the TCP/IP connection is set up, the security layer starts to negotiate an encryption level with the server. Then the core protocol will negotiate bitmap cache, printer, and COM port redirection. Upon successful negotiation, an active session is launched, and the user is presented with the Windows logon screen. It is important to note that if the traffic is passing through a firewall, port 3389 must be open outbound from the client and inbound to the server.
Client Caching Client cache is negotiated during session setup. By default, 1.5MB of RAM is set aside for bitmap caching. In addition, the RDC sets up persistent caching to improve communication speed over slow links. When a bitmap is to be sent to the client, the RDP device driver (RDPDD) compresses the bitmap image, then sends the bitmap across the network. RDPDD also instructs the client regarding which cache cell to store the bitmap in. When the client requests the same bitmap again, the server simply sends the cache cell reference number to the client.
The RDP client employs yet another technique to make use of screen cache in a remote control session. Windows drop-down menus make up much of the display. Most frequently used menus are cached in RAM when activated for the first time. Additional clicking on the same menu display will retrieve the screen cache from RAM rather then retrieving it over the network.
Remote Desktop Client Encryption RDC supports three levels of encryption: low, medium, and high. Low-level encryption uses a 40-bit algorithm on client data being sent to the server. Medium-level encryption uses a 56-bit algorithm to encrypt data flow in both directions. Finally, high-level encryption uses a 128-bit RC4 two-way algorithm on both client and server. Terminal Services configuration on the server determines the lowest level of encryption allowed. For example, if the server enforces high-level 128-bit encryption, then only a 128-bit encryption client can connect to the server. However, if the server only requires 40-bit encryption, then 128-bit, 56-bit and 40-bit clients are all able to connect.
Remote Desktop Client Remote Control Microsoft introduced remote control first in RDP version 5.0 with Windows 2000, and has continued to enhance it with RDC and Windows Server 2003. Remote control allows administrators to view and take control of another user's session running on the same server. By setting special permissions in the Terminal Services Configuration/Connections (TSCC), help desk personnel can use the remote control feature to assist users by taking over their screen. To use the Terminal Services Manager (Start Menu | Administrative Tools | Terminal Services Manager), highlight the desired user, and click the Remote Control option. The screen resolution and color depth of the shadowing session needs to be equal to, or higher than, the shadowed session.
Tip Remote control in Windows Server 2003, unlike in Windows 2000, can now take over the server console session.
In a shadowed session connection, TERMDD establishes a shadow pipe in which RDP packets are sent to both the shadowing and the shadowed sessions, as shown in Figure 2-6. In this way, input is accepted from both sessions, and results are returned to both sessions.
Figure 2-6: Remote Desktop Client remote control process
Note If an administrator wants to remotely control a session from the server console, an RDP virtual session must be launched first, using the Terminal Services server as the "client." From inside the virtual client session, the administrator can then take remote control of a session.
Remote Desktop Client Session Administration The Terminal Services Configuration/Connections (TSCC) program can be used to control inactivity timeouts (when no activity is seen from the keyboard or mouse for a set amount of time). The same interface can also automatically reset a disconnected session when the disconnect timeout value expires. By default, these two values are not set. This means no timeout will be triggered when a user leaves the client session unattended or the session is otherwise disconnected. For security reasons, and to conserve server resources, we strongly recommend that a reasonable value be set for both of these parameters, as shown in Figure 2-7. A new feature with the Remote Desktop Client is session directory, which, when used in conjunction with the Network Load Balancing on a Terminal Server farm, allows users to reconnect to the specific disconnected session they've left within a farm, rather than just being directed to the next available server when they reconnect.
Figure 2-7: Setting timeout values for RDP sessions
Note The systemwide session control in Figure 2-7 has the Active session timeout set for Never, the disconnection timeout set for 30 minutes, and the idle timeout set for two hours. These settings should be sufficient for most disconnect situations. Any adjustments of these values should be made according to company policy and user behavior. Generally, we do not recommend setting an active session timeout, as this will disconnect users who may be working.
For the settings in Figure 2-7, if a session detects no keyboard or mouse input for two hours, the session is disconnected. In this case, a user needs to log on to the system again to connect to the suspended session, and no data loss is likely. If a user fails to log on within 30 minutes after the two-hour inactivity timeout however, the system will reset the disconnected session, and any data not saved will be lost.
New Features for Terminal Services in Windows Server 2003
The Terminal Services component of Microsoft Windows Server 2003 builds on the solid foundation provided by the application server mode in Windows 2000 Terminal Services, and includes the new client and protocol capabilities of Windows XP.
Table 2-3 lists the new features and benefits provided by Windows Server 2003.
Table 2-3: Windows Server 2003 New Features and Benefits Terminal Services licensing model and management improvements
Support has been added for the new user-based license model (device-based licensing and a hybrid approach utilizing both user- and device-based licensing are also supported).
Additionally, improvements have been made to the Terminal Services License Manager Wizard, including a new Internet connection method for activating licenses, new error messages, and a new method for handling reactivation of upgraded Windows 2000 license Terminal Services.
Printers
All printers installed on the client are visible to the server—including network printers. With Windows 2000 Terminal Services, only locally connected printers were redirected. Redirected printers are given names that are easier to read. For example, users might see "printername on printserver (from clientname) in session 9"; whereas in Windows 2000, they would have seen "_printserver_printername/clientname/Session 9." Printer redirection also works when connecting to Windows 2000-based servers.
Printer driver mapping has been enhanced to provide better matching in near-miss cases.
When a driver match cannot be made, the Trusted Driver Path lets you specify other standard printer drivers that you sanction on your Terminal Servers.
The print stream is compressed for better slow-link performance between a server and client.
Client error messages
More than 40 new client error messages make it easier to diagnose client connection problems.
Security enhancements
The Terminal Server access model now conforms better to Windows server management paradigms.
Software restriction policies
Software restriction policies in Windows Server 2003 enable administrators to use group policies to simplify locking down Terminal Servers (and any other Windows Server 2003-based computer) by only allowing certain programs to be run by specified users.
This built-in Windows feature replaces the AppSec (Application Security) tool used in previous versions of Terminal Services.
Session directory
Terminal servers can be organized into "farms." This configuration allows clusters of load-balanced computers to appear to their users as a fault-tolerant service.
The new Session Directory feature in Terminal Services allows users to reconnect to the specific disconnected session they've left within a farm, rather than just being directed to the next available server when they reconnect.
Session Directory can use the Windows Network Load Balancing Service, or a third-party load balancer, and the service can run on any Windows Server 2003-based computer. However, members of the Terminal Server farm must be running Windows Server 2003, Enterprise Edition.
FIPS compliance
An additional encryption level, labeled "FIPS Compliant," has been added to Terminal Server in Windows Server 2003. This level of security encrypts data sent from the client to the server, and from the server to the client, with the Federal Information Processing Standard (FIPS) encryption algorithms using Microsoft cryptographic modules. This new level of encryption is designed to provide compliance for organizations that require systems to be compliant with FIPS 140–1 (1994) and FIPS 140–2 (2001) standards for Security Requirements for Cryptographic Modules.
128-bit encryption
By default, connections to Terminal Servers are secured by 128-bit, bi-directional RC4 encryption—when used with a client that supports 128-bit. (RDC is 128-bit by default.) It is possible to connect with older clients using encryption lower than 128-bit, unless it is specified that only high-encryption clients are allowed.
Single session policy
Configuring the single session policy lets an administrator limit users to a single session, regardless of whether it is active or not—even across a farm of servers.
Terminal Services Manager
An improved Terminal Services Manager allows for easier management of larger arrays of servers, by reducing automatic server enumeration. This gives direct access to arbitrary servers by name, and provides for a list of favorite servers.
Slow link performance optimizations
Terminal Services optimized slow-link performance allows terminal client users to specify, via their user interface, the type of connection that exists between the client computer and the server. Based on this selection, Terminal Server dynamically adjusts desktop features to deliver the best possible user experience over the chosen network connection speed. This improves the remote desktop user experience over a variety of network connection speeds.
The four options for network connection speeds are modem (56 Kbps, 28.8 Kbps), broadband (128 Kbps to 1.5 Mbps), LAN (10 Mbps or higher), and custom. The custom setting allows users maximum flexibility over what desktop features are disabled. These optimizations apply only when the user is connected remotely at sub-LAN connection speeds. At all other times, the computer has the full-featured desktop functionality.
Clients running the following operating systems may utilize this feature: Windows XP, Windows 2000, Windows 95, Windows 98, Windows Me, and Windows CE.
Time zone redirection
This feature allows a remote desktop session's time zone to be specified by the client computer's time zone. For example, an IT administrator who has deployed Terminal Services for a particular group of users located in several locations around the world can use Group Policy and Windows Management Instrumentation (WMI) on the server to turn on time zone redirection. This allows end users of Terminal Services to utilize their computer's local time zone rather than the time zone of the Terminal Services server. Clients currently capable of time zone redirection include Windows XP and Windows CE (Version 5.1).
Smart card sign-on
A smart card that contains Windows logon credentials can provide those credentials to a Windows Server 2003 remote session for logon. This feature requires a client OS that can recognize the smart card first: Windows 2000, Windows XP, and Windows CE .NET.
Ports
Client serial ports can be mounted to the server. This enables a variety of hardware on the client computer to be accessed by software on the server.
File system
Client drives, including network drives, are mounted inside the server session. This lets users open or save files on their own computers' disk drives, in addition to opening and saving files on the server.
Integration with Active Directory Services Interface
This feature provides the ability to script Terminal Services user configuration settings using the Active Directory Services Interface (ADSI). For instance, an IT administrator who upgrades a domain from Windows NT 4.0 to Windows Server 2003 can use ADSI to script the creation of user accounts within Active Directory and copy all user properties, including Terminal Services user configuration information.
Terminal Services in the Enterprise
In this part of the chapter, we discuss some issues that will likely be encountered when adding Terminal Services to an enterprise organization.
Domain Considerations
The standard principles for installing a Terminal Server apply equally to Windows 2000 and Windows 2003 Terminal Services. If Active Directory is installed on the network, simply join the Active Directory domain. There is no longer a primary domain controller (PDC) or backup domain controller (BDC) in Active Directory setup. For legacy support, a PDC Emulator will be created in the Windows 2000 domain controller when a Windows NT Domain client attempts to log on. Therefore, it is possible to mix TSE servers with Windows 2000 and Windows 2003 servers running Terminal Services.
Migrating to Windows Server 2000 or Windows 2003 Server from an Existing Windows NT 4.0 PDC
If a Windows 2003 server is installed in an existing network that employs backup domain controllers, the new Windows 2003 server operates as a "mixed mode" domain controller. In this case, the Windows 2003 DC will be migrated first to Active Directory and will emulate a Windows NT 4.0 PDC. The old PDC-to-BDC security database synchronization will continue until all BDCs are migrated to Active Directory and "mixed mode" has been switched to "native mode."
Application Considerations
Most applications are written to run on a single-session platform such as Windows 95, 98, or Windows NT Workstation with a single user. Terminal Services requires significant changes to be made to the kernel and operating system to accommodate multiuser access. Because of these changes, both programmers and administrators must fully understand the issues and possible solutions in order to configure the system so that single-session applications can be executed in a multisession environment. We discuss some of the problems and possible solutions in this section.
Terminal Services makes special demands on how an application is written and how the application uses the Windows NT operating system. The Windows NT Registry is used by many programs to store variables during an installation, changes while the program executes, and changes that normally occur when users with differing logons access the application. On a typical Windows 2000 Professional workstation, an application may put data into the HKEY_LOCAL_MACHINE registry hive, assuming only one user will access the application at a time. On Terminal Server, this could prove disastrous, as changes to this registry hive would affect all users of this Terminal Server, not just the user executing the application making the change.
Many problems occur with applications that store local data constructs in global locations. In addition to separating global and local information in the registry, global and local file-based data constructs should also be maintained separately. For example, user preference files should not be stored in a main system directory (/%systemroot%) or program directory (\Program Files). Instead, preference files or other user-specific local data should be stored in the user's home directory or a user-specified directory. This consideration also applies to temporary files used to store interim information (such as cached data) or to pass data on to another application. User-specific temporary files must also be stored on a per-user basis.
Some specific issues that may cause an application to fail in a multiuser environment include
Incorrect registry entries Many applications write a global INI file to the system root for user-specific information. Thus, when one user changes or opens the INI file, other users may not be able to access the same file. Some applications add shortcuts to only the installer's menu during installation; because of this, other users may not see the shortcut. Still, many applications point the data files, temporary files, or cache files to the same location for all users. In this situation, only one user can run the application at a time.
Changed object name An object created in a session is named differently. The application may not be able to find the object using the expected name or location.
Incorrect file and object rights access An application normally locates libraries and executables in the Windows NT %SystemRoot% directory. Multiple users accessing the same file may create file-locking problems.
The following are some other application problems and issues to be aware of within a multiuser Terminal Services environment:
Do not assume the computer name, MAC address, or IP address equates to a single user. In the traditional distributed Windows client-server architecture, one user is logged on to one computer at a time. Thus, the computer name or Internet Protocol (IP) address assigned to either a desktop or server computer equates to one user. In the Terminal Services environment, the application can only see the IP or NetBIOS address of the server. Applications that use the computer name or IP address for licensing, or as a means of identifying an iteration of the application on the network will not work properly in the Terminal Services environment because the server's computer name or IP address can equate to many different desktops or users.
MS-DOS and 16-bit Windows applications require more RAM than native 32-bit Windows applications and may not execute at all in Windows 2000 Server or Windows Server 2003. Windows runs an emulation layer called the Virtual DOS Machine (VDM) as a process on the 32-bit operating system. Although this memory requirement may not show up as performance degradation on a high-powered desktop computer running the latest Windows operating system with 64MB of RAM, it may easily show up on a system running Terminal Services due to the multiplier effect of many user sessions.
Multiuser Application Issues
You may encounter several possible issues when running applications under Terminal Services that were not designed to run in a multiuser environment. Some of the most important issues are summarized here. We will discuss these and other application-related issues in more detail in Chapter 13.
Application Compatibility Scripts
Many of the issues discussed so far have been addressed by the creation of application compatibility scripts. After installing an application, an administrator is required to run the corresponding script to resolve the issues mentioned. Windows 2000 shipped with 27 native Application Compatibility Scripts, and since then scores of software manufacturers have created additional scripts to provide users with fixes for their software in a multiuser environment. At the time of this writing, Windows 2003 only has four scripts in the Application Compatibility Scripts folder. Since Microsoft requires an application be multiuser compatible before it can be certified for Windows 2003, our assumption at this time is that a large majority of application vendors have simply included the scripts in their install process, thus alleviating the need for scripts. Obviously there will be some stragglers, so the need for Application Compatibility Scripts will continue for the foreseeable future. Application compatibility scripts are located in the %SystemRoot%\Application Compatibility Scripts\Install folder.
DOS and 16-Bit Windows Programs
After over eight years of Microsoft operating system support for 32-bit applications, it seems logical that all application vendors would have completed their software porting to take advantage of the speed, stability and interface changes. Win32 allows code sharing and thus runs more efficiently in a multiuser environment. If additional users need to access the same Win32 application code, a pointer is created that shares the same code from the original copy loaded in the kernel and user modes. Code sharing cuts down the total amount of memory usage when multiplying a large number of sessions. On the other hand, 16-bit Windows and DOS applications need to run in their own VDM, and so no code sharing is possible. Also, Win16 applications often require 16- to 32-bit conversion programs ("thunking" and "context switching") that increase resource utilization even further. Even with all of these obvious advantages, and nearly ten years to get it done, there are still a few poorly run software vendors who have not ported their software to a 32-bit code. We highly recommend running only 32-bit Windows applications whenever possible, even if it requires a large investment in moving to another vendor. Because Windows 2000 and 2003 are not well suited for DOS or 16-bit application support (although there are some instances where it works), if 16-bit or DOS applications are required, consider dedicating a Windows NT 4.0 TSE server to those applications, while building the rest of the farm around Windows Server 2003.
Effective Use of the Registry
In a multiuser environment, applications should store common information pertaining to systemwide operation in the HKEY_LOCAL_MACHINE section of the registry. Such information includes the path used to load application components, and what components are needed during execution. User-specific information, such as the locations of custom dictionaries (custom.dic) and user templates (normal.dot), should be stored in HKEY_CURRENT_USER. Some applications incorrectly store information meant to be user specific in HKEY_LOCAL_MACHINE.
Application compatibility scripts, Group Policies, and user profiles can all address an unused drive letter to the home directory of each user. REG.INI then changes pointers to this drive to each user's home directory environment variable. In this way, each user gets her own copy of an initialization file.
Tip A utility in the Exchange Server Resource Kit, named profgen.exe, resolves common pointer issues arising from users trying to open the same e-mail post office box when a mandatory profile is used. This utility can be useful when enabling many users running Terminal Services to access the same Exchange server.
Application Install and Execute Modes
During installation, an application writes user-specific keys to the Administrator's HKEY_CURRENT_USER registry hive. Information such as Document Path and Autosave Path are missing from other users' HKEY_CURRENT_USER keys because they did not install the application. These keys are crucial in successfully using the application. Terminal Services provides a global Install mode to address this situation. During installation, the system is placed under Install mode by entering the command Change User /Install at the command prompt or by using Add/Remove Programs from the Control Panel. All user-specific keys generated by the application under the software hive are shadowed by a key hive in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNt\CurrentVersion\TerminalServer\Install.
This key hive is appropriately called the shadow key. Once installation is completed, the system can be switched back to normal execution mode by entering the command Change User /Execute at the command prompt. In the Execute mode of operation, the shadow key information is written back into each user's software key hive when the system finds that the keys are missing.
The same command addresses missing INI and DLL files in the case of 16-bit applications. These files are copied into each user's Windows directory (normally, %homedrive%\%homepath%\windows). This also applies to 32-bit applications if they use INI files. The %homedrive% and %homepath% variables are both solved when running chkroot.cmd and are replaced simply by %rootdrive%. The files that are copied to C:\WTSRV and C:\WINNT are copied to %rootdrive%\windows when a new user logs in.
User-Specific Application Data
Some settings, such as DocumentPath in the HKEY_CURRENT_USER Microsoft Word subkey, may only be created the first time the application is run. Therefore, the installer must execute the application in global Installation mode right after finishing the initial installation. By doing this, the system will generate these values and record them in the shadow key so that they can later be copied into each user's HKEY_CURRENT_USER registry hive.
Note Logging in as a user and changing settings in an application can cause problems for any user running that application. Making a change while logged in as a normal user on a production machine to store a user's name and initials would cause all future users to see that user's name and initials when they edit documents. Thus it is important to find where these paths are stored and to script or add them to the shadow INSTALL key mentioned earlier so that all users only get the changes the administrator wants them to have.
Sometimes an application creates a path pointer to a common location for all users. For example, the Microsoft Office 97 installation program sets a document template pointer to C:\Program Files\Microsoft Office\Template. When multiple users try to update or open the same file, errors will occur. To address this situation, the administrator needs to search the registry and change the pointer to each user's home folder, such as H:\Office 97\Template, then create the correct directory structure for each user in the logon script %SystemRoot%\System32\usrlogn2.cmd. This file is called by the usrlogon.cmd (if this file does not exist, create it using a text editor) and add the following simple statement to accomplish this task:
IF NOT EXIST H:\OFFICE 97\TEMPLATE MD H:\OFFICE 97\TEMPLATE
Note Most of the Microsoft Office installation issues discussed here have been resolved with Office 2000 and XP, or are easily resolved with the Office Resource Kit. These discussions still serve as an example of how to resolve similar problems with other applications.
A similar problem occurs when all users are directed to use the same cache files. The cache file pointer is set to a common location, such as C:\Temp\Cache. When multiple users attempt to write to the same location, the application will often halt, corrupt the cache, or simply crash the server. Again, the solution is to change the pointer in HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, then create the corresponding directory structure in each user's home directory to support an individual application cache.
File Security
Applications often store files in the system root directory. Security is normally set to Read-Only for regular users. When a user attempts to write to a file stored in this directory, execution of the application may fail. You can track down the particular file and reassign security to it by using the FILEMON utility (this freeware utility is available from Sysinternals at http://www.sysinternals.com). A better method is to relocate the file to each user's Windows directory.
Registry Security
Many issues arise due to registry security and incorrect use of the registry by legacy applications. REGMON is another tool available at the Sysinternals web site that administrators can use to track down registry keys that have the wrong security.
Application COM/DCOM Objects
The same application may create identical objects for multiple sessions. To separate the same object created by different sessions, a logon ID is appended to each object name. Session objects created in this way are called user global objects and are only visible inside the session in which they were created. If an object is created from the console, there will be no logon ID appended to the object name. This type of object is called a system global object. Because of this distinction, application objects to be used for multiple sessions should be generated as system global objects and installed from the console instead of a user session.
Note Always install software from the console because of the issues mentioned earlier that arise from running applications in a session.
Memory Utilization
Some applications do not return memory to the system upon exit. This situation is exacer-bated in a multiuser environment, and is difficult to track down when a large number of applications and users are involved. Although a nightly reboot with Windows 2000 or Windows 2003 should not be required if the applications are well written, real-world environments typically have at least one rogue application that is poorly authored. Many SBC environments implement a cyclical reboot program in order to clear memory and prevent memory leaks from causing erratic performance and server crashing. The frequency of the reboot depends on how active the memory utilization is. Citrix MetaFrame XPe has a reboot tool, and many of the resource web sites we list in the appendixes have example scripts as well.
DCOM Compliance
Most programs use traditional Open Database Connections (ODBC) to access network objects, such as a data source in a SQL database. To allow a common interface for communication between all system programs (objects) across a network, Microsoft developed the Distributed Component Object Model (DCOM).
In order to be certified by Microsoft as Windows 2000 or Windows 2003 compatible, an application must support DCOM. This ensures that software components can communicate and share functions over a network in an efficient and reusable manner. TSE inherited a subset of DCOM functionality from Windows NT 4.0. Therefore, some applications written for Windows NT 4.0 may not function properly under TSE's multiuser environment. Microsoft has addressed this issue in Windows 2000. All DCOM activation modes are fully supported, as shown in the following:
Run as Activator Local activation is the same whether Terminal Services is enabled or not. The server is activated on the same session as the activator.
Remote Activation When DCOM is activated remotely, the process is launched in a WindowStation with a special SessionID =0, not a session corresponding to the user. This modification preserves the implementation activity of a remote call.
Run as Named User The application is configured in the registry to run as a specified user. Local and remote activation of DCOM behaves in the same way.
Run as Windows NT-Based Service The application is configured to run as a service. This type of service is not tied to any session.
Run as Interactive User The application is configured to run in the security context of the user.
Licensing
Be sure to read all the way through this section, because the "Windows Server 2003 Licensing" section contains some great news that alleviates much of the licensing pain that SBC users have encountered.
In addition to the basic server operating system license required for every installed server, both Terminal Server RDP clients and Citrix ICA clients require two licenses to connect to a Terminal Server session. The first license is the standard Microsoft Client Access License (CAL) for accessing Windows NT files and print services.
The second license required to enable a client connection is a Windows Terminal Services License (TS CAL). If the session client is running on a computer with Windows 2000 Professional or Windows XP Professional when connecting to a Windows 2000 Server farm, it is not necessary to purchase a TS CAL for that client device or user. The server has a "built-in" pool of licenses it can provide to those client machines running Windows 2000 Pro or Windows XP Pro. In the case of Windows Server 2003, there is no "built-in" TS CAL pool. Owners of Windows XP Professional desktop licenses are eligible for free TS CALs, however. (Talk with your licensing provider to receive the free licenses as soon as possible since this offer from Microsoft is limited.) Although Windows NT 4.0 TSE does not enforce licensing, both Windows 2000 Server and Windows Server 2003 arduously enforce licensing of the TS CAL.
Note There is a special provision for an Internet Connector in Windows 2000. This license mode allows 200 anonymous, concurrent users to access Terminal Services on a single server. However, the End User License Agreement specifically states that anyone affiliated with the owner of the license cannot use it (in other words, vendors, customers, employees, contractors, and so on cannot use the license). This rule makes the license restrictive to the point of being useless. Fortunately, the Internet Connector is being replaced as described in the upcoming "Windows Server 2003 Licensing" section.
Windows 2000 Licensing
Windows 2000 enforces the use of the Terminal Services CAL. During any attempt to connect to a session, both the standard CAL and the TS CAL will be checked. If either license is missing or invalid, the connection is refused. If the connection is granted, a temporary or permanent TS CAL is assigned.
Note In a Windows NT Domain with Windows 2000 or Windows Server 2003 member Terminal Servers, Terminal Services licensing must be installed on a Windows 2000 or Windows Server 2003 member. When upgrading the Domain to Windows 2000 Server or Windows Server 2003 Active Directory, licensing must be reinstalled on a Domain Controller (DC). Failing to install Terminal Services licensing and the license codes on the new DC will cause a loss of terminal service capabilities (no license server available).
Windows 2000 Server comes with a license services server that tracks and allocates TS CAL licenses to clients at connection time. The license server needs to be installed on a Windows 2000 server and activated through Microsoft License Clearing House via a web browser, the telephone, or a process called Automatic Activation. When a client requests a connection to a Windows 2000 server, the request is forwarded to the central license server for validation. The license server uses the username and computer name to check for an existing license. If none is available, a new license will be issued to the client, and the connection is completed. If the license pool is exhausted, the connection is refused. A temporary license can be enabled that will expire after 90 days.
The significant issue with this licensing is that if a user connects one time from any device (a trade show kiosk, for example), a TS CAL is allocated (although it is not legitimate from the standpoint of the Microsoft Server 2000 licensing agreement to provide a license to a machine not owned by the person using it). Due to this execution of the licensing, the unclear license language, and technical problems (Microsoft provides no licensing option to deal with devices that aren't owned by the company whose user is using it), many customers found themselves continuously running out of TS licenses. In July of 2002, Microsoft responded to strong user feedback regarding the TS license execution by changing the licensing model slightly (via a hotfix patch) to allow the license server to expire leases after 90 days. To install this patch, install the Service Pack 2 Security Rollup package, or Service Pack 3 to your license server and all Terminal Servers in your environment.
Tip After installing Service Pack 2 Security Rollup or Service Pack 3, uninstall and reinstall all TS licenses and reactivate them in order to complete this fix.
Licensing and Terminal Services Execution Modes
Windows 2000 Terminal Services can be installed in two different modes. The remote administration mode does not require a TS CAL. The purpose of this mode is to allow administrators to do server maintenance remotely. Therefore, certain restrictions apply to running in this mode. Only two concurrent client sessions are permitted. Server application compatibility services are also disabled, such as the global install mode. The Application Server mode is the mode utilized for Terminal Services in a server-based computing environment. This mode is not restricted like the remote administration mode and requires the TS CALs as discussed earlier.
Windows Server 2003 Licensing
Probably the single most significant reason to move from Windows 2000 Server to Windows Server 2003 across the corporate environment is the new licensing options. Although the execution of the license server is identical to Windows 2000, the licensing choices are dramatically improved. Following are the changes made to licensing with Windows Server 2003:
Windows Server 2003 provides a 120-day grace period for renewals as opposed to 90 days with Windows 2000 Server.
Windows Server 2003 supports a new license option—Per User licensing, as well as the Per Seat licensing supported in Windows 2000 Server (Microsoft has renamed it in Windows 2003 to Per Device). Additionally, a hybrid may be used (some licenses may be allocated per device and some per user). The Per User licensing will work best for environments where users have multiple devices that connect to the Terminal Servers (that is, a single user connects from a desktop, laptop, CE device, home PC, trade show kiosk, and so on). The Per Device licensing works best for environments where multiple users share the same device (manufacturing floors, hospitals, 24/7 offices, and so on). Note that with this change the temporary fix we discussed earlier in this section, allowing Windows 2000 to expire the leases every 90 days, has been eliminated.
The Internet Connector License noted earlier is replaced in Windows 2003 with an External Connector (EC) license called the Terminal Server External Connector (TS-EC) to address the need previously mentioned: to enable external users to access a company's Terminal Servers, without the need to purchase individual TS CALs for them or their devices. An example of an external user is a person who is not an employee of the company or its affiliates. The EC allows organizations to effectively provide Windows and TS CALs for entities not owned by them—for example, e-business customers or supplier partners—in order to give those entities access to their networks and terminal servers. The EC may be the best solution when business partners or customers need access to a server or group of servers. This may be the best solution when a small number of business partners or customers need access to a server or group of servers. This license mode allows 200 anonymous, concurrent users to access Terminal Services.
Licensing and Terminal Services Execution Modes
Unlike Windows 2000 Server, which had a dual mode Terminal Services component, Windows Server 2003 separates the remote administration and Terminal Services functionality into separate configurable components. Remote Desktop for Administration is enabled through a check box on the system Control Panel's Remote tab. Terminal Services is enabled by adding the "Terminal Server" component using the Windows Components portion of the Add/Remove Programs Wizard.
In addition to the two virtual sessions available in Windows Server 2003 Terminal Services remote administration functionality, an administrator can also remotely connect to the console of a server. A significant outcome to this change is that applications that would not work in a virtual session before, because they kept interacting with "session 0," will now work remotely. To connect to the console, administrators can choose one of the following methods:
Use the Remote Desktop Microsoft Management Console (MMC) snap-in.
Run the Remote Desktop Connection (mstsc.exe) program with the /console switch.
Create Remote Desktop Web Connection pages that set the ConnectToServerConsole property.
Microsoft Windows 2000 and 2003 Terminal Services allow multiple users to log on to a Windows 2000 or Windows 2003 server, have their own desktop environment, and execute programs that stay resident. User logons effectively get their own protected memory space for applications and data. Users can have a Windows desktop and run Windows- based applications without the need to load the applications on their local PC. A server running Terminal Services can host hundreds of concurrent users (the specifics of server sizing will be covered in later chapters). In this chapter, we will use the generic term Terminal Server to refer to a server running Windows 2000 Server or Windows Server 2003 with Terminal Services enabled.
The client computing device used to communicate with the Terminal Server can be a PC or a specially designed terminal made to work with the Terminal Server display protocol. The PC or terminal runs a relatively small program that enables a logon and accepts redirected screen output from the Terminal Server. The Microsoft Terminal Services client program relies on a protocol originally developed for Microsoft's NetMeeting, called Remote Desktop Protocol (RDP). RDP is based on the International Telecommunications Union's (ITU) T.120 protocol. The T.120 protocol is a standard multichannel conferencing protocol that is tuned for enterprise environments and supports session encryption.
Terminal Services History—It Started with Windows NT 4.0 Server, Terminal Server Edition
Microsoft's Windows NT 4.0 Server, TSE, was the implementation of Citrix MultiWin (which will be discussed in Chapter 3) on the Windows NT 4.0 Server platform. Although Windows NT 4.0 is no longer officially supported by Microsoft or Citrix, it is worth discussing the beginnings of Terminal Services technology to further understand where it is today. For those still running Windows NT 4.0 TSE, we strongly recommend upgrading to Windows 2003 (see the upcoming "Windows 2003 Server" section for justification). If support for 16-bit applications is required, NT 4.0 Terminal Services Edition (TSE) is still necessary, as Windows 2000 and 2003 do not effectively support 16-bit applications.
Because of the MultiWin-inspired kernel of TSE, users could log on to virtual Windows NT 4.0 sessions with the same desktop and application look and feel of Windows NT 4.0 Workstation. With TSE, Microsoft created a separate code base for the operating system in order to overcome some of the memory management limitations of Windows NT 4.0 Server and to generally tune it for multiuser access.
Microsoft included their Terminal Server client, which is the client portion of the Remote Desktop Protocol, with TSE. This RDP client supported a variety of Windows desktops over TCP/IP networking, including Windows 95 and 98, Windows CE, Windows NT Workstation, Windows 2000, and Windows XP.
TSE Internals
In order to achieve the multiuser capabilities required in TSE, the Citrix MultiWin technology needed to be integrated into the Windows NT 4.0 Server kernel. This integration meant that several components, services, and drivers were added or modified in the original Windows NT 4.0 Server core operating system. Windows NT 4.0 components such as the Virtual Memory Manager (VMM) and Object Manager (OM) were modified to perform in a multiuser environment.
Virtual Memory Manager The VMM in TSE mapped virtual addresses in the process's address space to physical pages in the computer's memory. In Windows NT, a process's address space was divided into two 2GB address ranges: user (process-specific addresses) and kernel (system-specific addresses). For the user address space, the VMM provided an individualized view of the physical memory to each process, ensuring that a call for system resources (a thread) within a process can access its own memory, but not the memory of other processes.
SessionSpace The kernel address space in TSE was common for all processes within the system, thus providing a consistent means for accessing all kernel services. The fact that all processes in Windows NT 4.0 shared the kernel address space resulted in kernel resource limitations when supporting multiple interactive sessions on a single server. In TSE, these limitations were addressed by creating a special address range in the kernel, called SessionSpace, which could be mapped on a per-session basis. Each process was associated with a SessionSpace via a SessionID. When a remote user connected to Terminal Server, a new SessionID was generated, and all of the processes created for that connection inherited that SessionID and unique session space, as shown next. Other process groups, with a different SessionID, point to a separate set of memory-mapped objects and physical pages at the same virtual address.
The Windows NT 4.0 Terminal Server made all objects required for multiuser capability virtual so that the applications and system programs from different user sessions do not collide. Every object name created within a session is appended with a unique identifier number associated with the individual user session (SessionID) that created it. For example, if a user started an application in the first session on the Terminal Server, the session would be seen as session1 and the application seen as application1, as shown in Figure 2-1.
Figure 2-1: Execution of a multiuser Windows application
The Remote Desktop Protocol was designed to support TCP/IP over LAN or WAN communication links. Due to the multisession nature of the protocol, a special user mode extension (RDPWSX), as depicted in Figure 2-2, is needed to receive all incoming client packets. RDPWSX manages sessions and calls WINLOGON to authenticate them. In addition, RDPWSX will validate the client license with the license server and negotiate client-server encryption keys.
Figure 2-2: An RDP session
Upon successfully establishing a session, the MultiWin subsystem gained control over session management. A virtual session was created by localizing a copy of WIN32K.SYS with all the necessary device drivers. The TERMDD (Terminal Server Device Driver) then provided the run-time environment of a session-specific protocol driver in order to service multiple client session requests. To support the mouse and keyboard commands sent to each session's copy of the WIN32K.SYS subsystem, the RDPWD (Remote Desktop Winstation Driver) was loaded.
The console session was always the first to load, and was assigned a special client connection ID of 0. The console session launched at system startup with the system-configured Windows NT display, mouse, and keyboard drivers loaded. The Terminal Server service contacted the Windows NT session manager (SMSS.EXE) and loaded the RDP user mode protocol extension RDPWSX to create two idle client sessions right after the creation of the console session. These two idle sessions listened on TCP service port 3389 for RDP protocol packets from the client.
Code Sharing Terminal Server also implemented memory code sharing (also known as Copy on-Write Page Protection). This feature allowed one copy of executable code, such as Microsoft Word, to be loaded into physical memory, and to have multiple users run the same copy of the program code. If a user loaded a private copy of a Word document, a separate memory space would be set aside and marked as read/write under the protection of Virtual Memory Manager. No other process could access this private memory space. This was extremely useful and efficient when a large number of users were using the same programs.
Note Code sharing cannot be utilized in 16-bit applications, since they need to run inside a separate DOS VDM (Virtual Dos Machine). For this reason, approximately 20 percent more memory is used by 16-bit and DOS applications than by comparable 32-bit applications. In order to properly size the RAM requirement in TSE, a live functional test should be conducted to observe the total working set of memory consumed by a specific application, because many 32-bit applications contain 16-bit code.
Windows 2000 Terminal Services
In Windows 2000 Terminal Services, SessionSpace remains. The layout on the memory map has been modified to further tune the system and enable a common layout for all Windows 2000 systems, whether or not Terminal Services has been installed. The main modification is that SessionSpace has been reduced to 60MB and starts at the memory address location A0000000. Moving SessionSpace up to A0000000 allows all system drivers (win32k.sys), video drivers, and printer drivers to be loaded in a common virtual address location, whether they are accessed through a Terminal Services session or on a session without Terminal Services. Microsoft redesigned the memory mapping to eliminate the need for a separate version of the operating system to support Terminal Services, as was necessary with Windows NT 4.0 Server and TSE. Among other obvious advantages, service packs for Terminal Services no longer lag behind those for the base operating system as they did with TSE.
A new Windows 2000 service, appropriately called Terminal Services (termsrv.exe), is the controlling process in the Terminal Server architecture. It is primarily responsible for session management, initiation, and termination of user sessions and session event notification. The Terminal Server service is entirely protocol independent, so it can function using RDP or a third-party add-on protocol such as ICA from Citrix.
A user mode protocol extension provides assistance to the Terminal Server service. It is the responsibility of this component to provide protocol-specific functions and services, such as licensing, session shadowing, client font enumeration, and so forth. Each Terminal Server session protocol (for example, RDP and ICA) has its own protocol extension, providing a variety of services.
Note For RDP, this user mode extension is called wsxtshar.dll.
Windows 2003 Server
Windows Server 2003 is now the flagship product for Terminal Services. Packaged with the release of Windows Server 2003 is a new client connection program. The new Terminal Services client, first released with Windows XP, is called Remote Desktop Connection (RDC) and provides substantial improvements over previous releases, including greater functionality through a simplified user interface. RDC can also be used to connect to a Windows XP Professional-based computer running Remote Desktop, and can be used to connect to previous versions of Terminal Services (Windows NT 4—Terminal Server Edition and Windows 2000 Server). RDC utilizes a new version of RDP and a new licensing model that provides for user and device licensing of Terminal Services and NT CAL's rather than just device licensing that had been required (see the "Licensing" section later in this chapter). This licensing change represents a tremendous win for all Windows SBC environments, as it dramatically reduces the costs for environments where users have more than one device they connect from. For example, under the Windows 2000 licensing model, if a user connected to a Terminal Services server or farm from a laptop, desktop, and home computer, Microsoft required the user's organization to purchase three Windows Terminal Services client access licenses and three Windows 2000 Server client access licenses for this one user. Under the new per-user licensing, the organization will only need to purchase one license for that user.
Windows 2003 Editions Comparison
Windows Server 2003 comes in six releases and four named editions; Standard, Enterprise, Datacenter, and Web. The Web edition will run on small-footprint servers. As the name implies, this edition is for web servers only—systems running IIS 6.0 and web applications. This edition will make an excellent and cost-effective platform for web services such as MetaFrame Web Interface and MetaFrame Secure Access Manager, as discussed in Chapter 16.
The Standard edition is the general-purpose version intended for traditional Windows Server tasks such as file and print serving, security, and Terminal Services. This is the server upon which a Citrix MetaFrame XP installation is most likely to be based.
The Enterprise edition is a "hardened" version of the operating system. Microsoft has added a number of features to this edition to increase its value as an application server platform. We envision that this server will be used for three potential purposes: large Terminal Services Farms, clustering, transaction processing, or server consolidation.
Finally, the Datacenter edition is the "big iron" version of the operating system. It is designed for the most demanding application and availability requirements where hardware cost is not a concern. This version requires a minimum of eight CPUs in a system and can run on systems containing up to 32 CPUs. System administrators who covet the chance to work on a Windows "mainframe" will be running this.
As mentioned, there are actually six releases. The additional two are the 64-bit versions of the Enterprise and Datacenter editions designed for the Intel Itanium processor. Because of the emphasis by the Microsoft SQL Server team on 64-bit computing, these releases will be targeted at high-volume database or transaction processing applications, but not much else.
Table 2-1 compares the features of the four named editions.
Table 2-1: Windows 2003 Editions Comparison Feature
Standard Edition
Enterprise Edition
Datacenter Edition
Web Edition
Scalability
64-bit support for Intel Itanium-based computers
+
+
Hot add memory [1], [2]
+
+
Non-Uniform Memory Access (NUMA)[2]
+
+
Datacenter program
+
Maximum RAM Support
2GB
+
+
+
+
4GB
+
+
+
32GB
+
+
64GB [3]
1/2
+
512GB [4]
1/2
Maximum Symmetric Multiprocessing Support (SMP)
2-way
+
+
+
+
4-way
+
+
+
8-way
+
+
32-way
+
64-way
+
Directory Services
Active Directory
+
+
+
1/2
Metadirectory Services (MMS)
+
+
support
Security Services
Internet connection firewall
+
+
+
Public Key Infrastructure, certificate services, and smart cards
1/2
+
+
1/2
Terminal Services
Remote Desktop for Administration
+
+
+
+
Terminal Server
+
+
+
Terminal Server Session Directory
+
+
Clustering Technologies
Network load balancing
+
+
+
+
Cluster service
+
+
Communications and Networking Services
Virtual private network (VPN) support
+
+
+
1/2
Internet Authentication Service (IAS)
+
+
+
Network bridge
+
+
+
Internet Connection Sharing (ICS)
+
+
IPv6
+
+
+
+
File and Print Services
Distributed File System (Dfs)
+
+
+
+
Encrypting File System (EFS)
+
+
+
+
Shadow Copy Restore
+
+
+
+
Removable and remote storage
+
+
+
Fax service
+
+
+
Services for Macintosh
+
+
+
Management Services
IntelliMirror
+
+
+
1/2
Group policy results
+
+
+
1/2
Windows Management Instrumentation (WMI) command line
+
+
+
+
Remote OS installation
+
+
+
+
Remote Installation Services (RIS)
+
+
+
Windows System Resource Manager (WSRM)
+
+
.NET Application Services
.NET Framework[1]
+
+
+
+
Internet Information Services (IIS) 6.0
+
+
+
+
ASP.NET[1]
+
+
+
+
Enterprise UDDI services
+
+
+
Multimedia Services
Windows Media Services
+
+
+
Key: + = Feature included 1/2 = Feature partially supported
Remote Desktop Protocol (RDP)
In this part of the chapter, we describe in more detail how the Remote Desktop Client performs session management and other functions.
Session Connection
When a client initiates a session, the TCP/IP transport driver passes the request to the TERMDD program on the Terminal Server. TERMDD then passes the request to RDPWSX, which in turn signals the Terminal Server service to create a thread to handle the incoming session request. In addition, RDPWSX is responsible for initiating session negotiation with the client and capturing all necessary client information, such as compression, encryption level, client version number, and license details. As each client connection is accepted and assigned an idle SessionSpace, a new idle session is created. The session manager also executes the client-server run-time subsystem process (csrss.exe), and a new SessionID is assigned to that process. The CSRSS process then invokes the Windows Logon (winlogon.exe) and the graphic device interface (GDI) module (win32k.sys) to render the initial logon screen information and present it to the particular user SessionID, as shown in Figure 2-3.
Figure 2-3: The connection process in an RDP session
Note For use under heavy session logon activity, a registry setting can increase the two idle session numbers. The values are contained in the following key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\IdleWinstationCount\.
Network Load Balancing on Session Connections
RDC can utilize Network Load Balancing (NLB), available in Windows Server 2003 Standard, Enterprise, and Datacenter Server Editions, as well as Windows 2000 Advanced Server and Datacenter Server. NLB utilizes a round-robin approach for session connectivity to multiple Terminal Servers. NLB can detect downed servers, thus sending a client to one of the remaining live servers, and effectively eliminating a single point of failure if one server is down. Note though that this service is not the same as Citrix's load balance service, which utilizes server parameters rather than the network round robin that NLB utilizes. It is the opinion of the authors that NLB is not a sufficient tool for load balancing or effective redundancy in an enterprise server farm environment, but it may be sufficient for smaller environments (less than four servers in the farm).
Session Disconnection
When a user disconnects from an active session without logging off, the GDI stops taking commands from the user by stopping all drawing operations from reaching the display driver. A disconnected desktop object is created and represented in the Terminal Services Manager application (Start Menu | Administrative Tools | Terminal Services Manager), as shown in Figure 2-4.
Figure 2-4: The Terminal Services Manager application showing a disconnected session
During the disconnection timeout period, the RDP stack is unloaded, but TERMDD is still active because win32k.sys maintains an active handle to it for keyboard and mouse control. Before the timeout period expires, the user can be reconnected to the same session. The session disconnect process is shown in Figure 2-5.
Figure 2-5: The disconnection process in an RDP session
Session Reconnection
When a user initiates a connection to the same server, a brand-new connection is created. The RDP stack is loaded, and SessionSpace is assigned. The user is presented with a logon screen. Thus far, the process is identical to a new session connection. However, when WINLOGON scans the user ID and determines that the user has a disconnected session, TERMDD is instructed to perform a session reconnection. The user session is then switched back to the disconnected session.
Data Transmission
RDP packets are formed in the presentation layer of the Open System Interconnect (OSI) model. The packets are encrypted and frames packaged according to the requirements of the network protocol. Currently, only TCP/IP is supported by RDP. The RDP data content may include keyboard input and mouse movement coordinates, as well as graphical bitmaps and printer redirection output. The return RDP packet goes in reverse through the same protocol stack, is decrypted, and unwrapped, and the TCP/IP header information is stripped for the specific client session. Some of the data transmission optimization features of RDP include the following:
Intelligent encoding The redrawing of graphical images can be encoded to tell the client to redraw changes only since the last refresh took place. In other words, only the changes are sent.
Glyph and bitmap caching A glyph is a graphical representation of a character. The RDP client automatically reserves a minimum of 1.5MB of memory space to cache the required set of glyphs needed in the display of common text. Bitmaps of different sizes are also cached in memory. Whenever a command is issued from the Terminal Server, the client can redraw the required text and bitmaps very quickly by extracting the elements from cache.
Bulk compression A client-side option optimizinga low-speed connection will turn on bulk compression, which can reduce the packet count by 50 percent.
Image Display
RDP uses a highly efficient encoding algorithm to encapsulate screen data, similar to the X-Window protocol. Most common or repetitive drawings are sent as a command rather than an actual bitmap. This method greatly reduces the amount of data required to paint a new screen or refresh an old one. Microsoft has published the exact bandwidth requirements to paint a common Windows screen, but lab tests from Mainstream Networks show that RDP 4.0 used up to 40 Kbps on a dial-up connection (with compression). There is a significant improvement in bandwidth utilization on the Windows 2000 version of RDP—version 5.0. These improvements continue with the Remote Desktop Client released with Windows 2003.
RDP updates the screen as follows. A user starts an application, which informs the GDI where and how to draw the application window. The GDI relays the command to the RDP display driver (RDPDD) by way of standard Win32 API calls. This is the same process used in a Windows NT system without Terminal Services, and is similar to the way a print job is rendered. The main API calls sent to RDP include the following:
TextOut() This call results in the display of text information ona client screen. GDI informs RDP of the location and the glyphs (a graphical representation of a character). RDP tells the client which glyph to cache and which cache entry to use next time the same text is called for.
PatBlt() Pattern Block Transfer is used by RDP to tell the client how to draw a block of color. This translates into a small command and is the alternative to sending a block of bitmaps and consuming a large amount of bandwidth.
LineTo() This command allows RDP to tell the client the beginning and ending coordinates of a 3-D beveling line. The line can be used to form boxes. This command can be as small as 6 bytes to complete a line drawing.
Windows 2000 Graphical Enhancements
RDP version 5.0 not only improved the protocol communication efficiency, it also expanded its feature set and offers some of the benefits contained in the ICA protocol.
Remote control This feature allows an administrator or authorized person to take over the screen, keyboard, and mouse movement of any user session running to the same physical machine.
Clipboard redirection The RDP version 5.0 protocol synchronizes the server-side application clipboard to the client-side clipboard buffer. This allows applications running on the Terminal Server to cut and paste data to applications running on the client workstation.
Client printer autocreation Local client COM and LPT ports can be remapped automatically from the server. The local default printer will be created in the Terminal Server session, and print jobs produced by applications running in a server session will be printed on the client's local default printer.
Bitmap cache Windows 2000 RDP provides additional persistent bitmap cache over version 4.0, which only used RAM cache. Upon successful bitmap transmission, the server instructs the client where to store persistent cache information. When the same data is needed again, only the location coordinate for this bit is sent to the client. This improvement is especially important in low-speed dial-up or wireless WAN connections.
Windows 2000 Terminal Services Client Architecture
Windows 2000 with RDP 5.0
With the introduction of Windows 2000, Microsoft significantly improved the capabilities of the core operation system to have Terminal Services integrated with all server platforms. Enhancements were also made to the RDP client allowing for better performance and additional features. The major advantages to this integration were the availability of standard services packs for Windows and Terminal Services and the requirement for software vendors to address compatibility with the multiuser environment. Between the releases of Windows 2000 Server and Windows Server 2003, Microsoft released Terminal Services Advanced Client (TSAC) which superceded the RDP client that shipped with Windows 2000. The TSAC, is based on the RDP 5.0 feature set, but comes in the form of an ActiveX control. The performance of the TSAC is comparable to the previous client, but offers far more flexibility in its deployment. It can be downloaded and executed within Microsoft Internet Explorer, or any application that can make use of ActiveX controls, such as those written in the Visual Basic or Visual C++ development systems. In addition to the downloadable ActiveX control, it is also available in the form of an MSI (Windows Installer) package, which looks and feels to the end user like the traditional RDP 5.0 client. Finally, the client is also available as an MMC snap-in, for administrators to use to assist with server administration.
Windows 2003 and RDC
Microsoft continues to improve functionality with the release of Windows Server 2003. The additional features of Windows Server 2003 allow integrated detailed control of security in a Terminal Services environment that previously were left to the creativity of the administrator and third-party applications. Remote Desktop Client (RDC) provides for better performance with streaming video, security, and client resource availability, and is now ported to the Mac OS X platform.
RDC using RDP now supports the following four operating system platforms:
The Win32 platform, which includes Windows XP, Windows 2000, Windows NT, Windows 95, 98, and Windows Millennium (available for download at http://www.microsoft.com/windowsxp/remotedesktop/)
The Win16 platform, which includes Windows and Windows for Workgroups 3.11
The WinCE platform, which includes many new thin-client devices with WinCE running as the embedded operating system
A Macintosh Remote Desktop Client (RDC) for MAC OS X (available for download at http://www.microsoft.com/mac/download/misc/rdc.asp)
Microsoft's design goals for RDC are to minimize bandwidth utilization, minimize memory usage, and speed up screen transmission. RDC represents a striking improvement over both RDP version 4.0 and RDP version 5.0 in both speed and features.
Table 2-2 shows a comparison of some of the major features of RDP and RDC.
Table 2-2: RDP Version 5.0 vs. RDC Feature
Description
RDP 5.0
RDC for Windows 2003 and Windows XP
Clients
32-bit clients for Windows 95, 98, NT, 2000 and 2003
Yes
Yes
16-bit client for Windows 3.11
Yes
Yes
Windows CE-based clients
Yes
Yes
Browser client
With TSAC
With TSAC
Transport protocol
TCP/IP
Yes
Yes
Audio
System beeps
Yes
Yes
Print stream compression
Compression of print jobs executed in a Terminal Services session
No
Yes
Terminal Services: slow link performance optimizations
Improved performance of high latency and slow throughput connections
No
Yes
Local printer redirection
Print to client-attached printer
Yes
Yes
Local drive mapping
Local client drive access from session
Yes
Yes
Cut and paste
Cut and paste between server session and client session
Yes
Yes
Remote control
Remote viewing and control of a session
Yes
Yes
Bitmap caching
Bitmap caching in memory
Yes
Yes
Bitmap caching to disk
Yes
Yes
Time zone redirection
Remote client clock shows correct time, regardless of whether client is in different time zone from Terminal Server
No
Yes
Macintosh client
Client for Mac OS X
No
Yes
Preconfigured client
Predefined client with IP address, server name, and connection information
Yes
Yes
RDP Client Software Architecture
The RDP client software is installed on the server under the directory %systemroot%\system32\clients\tsclient. The client disk creator program under Start | program | Administrative tools | Terminal Server Client Creator will make the necessary disk set for distribution to client PCs.
When the Terminal Server client starts, the user interface calls the core API to set up a session with a server name or IP address. The default TCP/IP port is set to 3389. The security layer in turn calls the network layer to set up a socket with the goal of establishing a connection to the server. Once the TCP/IP connection is set up, the security layer starts to negotiate an encryption level with the server. Then the core protocol will negotiate bitmap cache, printer, and COM port redirection. Upon successful negotiation, an active session is launched, and the user is presented with the Windows logon screen. It is important to note that if the traffic is passing through a firewall, port 3389 must be open outbound from the client and inbound to the server.
Client Caching Client cache is negotiated during session setup. By default, 1.5MB of RAM is set aside for bitmap caching. In addition, the RDC sets up persistent caching to improve communication speed over slow links. When a bitmap is to be sent to the client, the RDP device driver (RDPDD) compresses the bitmap image, then sends the bitmap across the network. RDPDD also instructs the client regarding which cache cell to store the bitmap in. When the client requests the same bitmap again, the server simply sends the cache cell reference number to the client.
The RDP client employs yet another technique to make use of screen cache in a remote control session. Windows drop-down menus make up much of the display. Most frequently used menus are cached in RAM when activated for the first time. Additional clicking on the same menu display will retrieve the screen cache from RAM rather then retrieving it over the network.
Remote Desktop Client Encryption RDC supports three levels of encryption: low, medium, and high. Low-level encryption uses a 40-bit algorithm on client data being sent to the server. Medium-level encryption uses a 56-bit algorithm to encrypt data flow in both directions. Finally, high-level encryption uses a 128-bit RC4 two-way algorithm on both client and server. Terminal Services configuration on the server determines the lowest level of encryption allowed. For example, if the server enforces high-level 128-bit encryption, then only a 128-bit encryption client can connect to the server. However, if the server only requires 40-bit encryption, then 128-bit, 56-bit and 40-bit clients are all able to connect.
Remote Desktop Client Remote Control Microsoft introduced remote control first in RDP version 5.0 with Windows 2000, and has continued to enhance it with RDC and Windows Server 2003. Remote control allows administrators to view and take control of another user's session running on the same server. By setting special permissions in the Terminal Services Configuration/Connections (TSCC), help desk personnel can use the remote control feature to assist users by taking over their screen. To use the Terminal Services Manager (Start Menu | Administrative Tools | Terminal Services Manager), highlight the desired user, and click the Remote Control option. The screen resolution and color depth of the shadowing session needs to be equal to, or higher than, the shadowed session.
Tip Remote control in Windows Server 2003, unlike in Windows 2000, can now take over the server console session.
In a shadowed session connection, TERMDD establishes a shadow pipe in which RDP packets are sent to both the shadowing and the shadowed sessions, as shown in Figure 2-6. In this way, input is accepted from both sessions, and results are returned to both sessions.
Figure 2-6: Remote Desktop Client remote control process
Note If an administrator wants to remotely control a session from the server console, an RDP virtual session must be launched first, using the Terminal Services server as the "client." From inside the virtual client session, the administrator can then take remote control of a session.
Remote Desktop Client Session Administration The Terminal Services Configuration/Connections (TSCC) program can be used to control inactivity timeouts (when no activity is seen from the keyboard or mouse for a set amount of time). The same interface can also automatically reset a disconnected session when the disconnect timeout value expires. By default, these two values are not set. This means no timeout will be triggered when a user leaves the client session unattended or the session is otherwise disconnected. For security reasons, and to conserve server resources, we strongly recommend that a reasonable value be set for both of these parameters, as shown in Figure 2-7. A new feature with the Remote Desktop Client is session directory, which, when used in conjunction with the Network Load Balancing on a Terminal Server farm, allows users to reconnect to the specific disconnected session they've left within a farm, rather than just being directed to the next available server when they reconnect.
Figure 2-7: Setting timeout values for RDP sessions
Note The systemwide session control in Figure 2-7 has the Active session timeout set for Never, the disconnection timeout set for 30 minutes, and the idle timeout set for two hours. These settings should be sufficient for most disconnect situations. Any adjustments of these values should be made according to company policy and user behavior. Generally, we do not recommend setting an active session timeout, as this will disconnect users who may be working.
For the settings in Figure 2-7, if a session detects no keyboard or mouse input for two hours, the session is disconnected. In this case, a user needs to log on to the system again to connect to the suspended session, and no data loss is likely. If a user fails to log on within 30 minutes after the two-hour inactivity timeout however, the system will reset the disconnected session, and any data not saved will be lost.
New Features for Terminal Services in Windows Server 2003
The Terminal Services component of Microsoft Windows Server 2003 builds on the solid foundation provided by the application server mode in Windows 2000 Terminal Services, and includes the new client and protocol capabilities of Windows XP.
Table 2-3 lists the new features and benefits provided by Windows Server 2003.
Table 2-3: Windows Server 2003 New Features and Benefits Terminal Services licensing model and management improvements
Support has been added for the new user-based license model (device-based licensing and a hybrid approach utilizing both user- and device-based licensing are also supported).
Additionally, improvements have been made to the Terminal Services License Manager Wizard, including a new Internet connection method for activating licenses, new error messages, and a new method for handling reactivation of upgraded Windows 2000 license Terminal Services.
Printers
All printers installed on the client are visible to the server—including network printers. With Windows 2000 Terminal Services, only locally connected printers were redirected. Redirected printers are given names that are easier to read. For example, users might see "printername on printserver (from clientname) in session 9"; whereas in Windows 2000, they would have seen "_printserver_printername/clientname/Session 9." Printer redirection also works when connecting to Windows 2000-based servers.
Printer driver mapping has been enhanced to provide better matching in near-miss cases.
When a driver match cannot be made, the Trusted Driver Path lets you specify other standard printer drivers that you sanction on your Terminal Servers.
The print stream is compressed for better slow-link performance between a server and client.
Client error messages
More than 40 new client error messages make it easier to diagnose client connection problems.
Security enhancements
The Terminal Server access model now conforms better to Windows server management paradigms.
Software restriction policies
Software restriction policies in Windows Server 2003 enable administrators to use group policies to simplify locking down Terminal Servers (and any other Windows Server 2003-based computer) by only allowing certain programs to be run by specified users.
This built-in Windows feature replaces the AppSec (Application Security) tool used in previous versions of Terminal Services.
Session directory
Terminal servers can be organized into "farms." This configuration allows clusters of load-balanced computers to appear to their users as a fault-tolerant service.
The new Session Directory feature in Terminal Services allows users to reconnect to the specific disconnected session they've left within a farm, rather than just being directed to the next available server when they reconnect.
Session Directory can use the Windows Network Load Balancing Service, or a third-party load balancer, and the service can run on any Windows Server 2003-based computer. However, members of the Terminal Server farm must be running Windows Server 2003, Enterprise Edition.
FIPS compliance
An additional encryption level, labeled "FIPS Compliant," has been added to Terminal Server in Windows Server 2003. This level of security encrypts data sent from the client to the server, and from the server to the client, with the Federal Information Processing Standard (FIPS) encryption algorithms using Microsoft cryptographic modules. This new level of encryption is designed to provide compliance for organizations that require systems to be compliant with FIPS 140–1 (1994) and FIPS 140–2 (2001) standards for Security Requirements for Cryptographic Modules.
128-bit encryption
By default, connections to Terminal Servers are secured by 128-bit, bi-directional RC4 encryption—when used with a client that supports 128-bit. (RDC is 128-bit by default.) It is possible to connect with older clients using encryption lower than 128-bit, unless it is specified that only high-encryption clients are allowed.
Single session policy
Configuring the single session policy lets an administrator limit users to a single session, regardless of whether it is active or not—even across a farm of servers.
Terminal Services Manager
An improved Terminal Services Manager allows for easier management of larger arrays of servers, by reducing automatic server enumeration. This gives direct access to arbitrary servers by name, and provides for a list of favorite servers.
Slow link performance optimizations
Terminal Services optimized slow-link performance allows terminal client users to specify, via their user interface, the type of connection that exists between the client computer and the server. Based on this selection, Terminal Server dynamically adjusts desktop features to deliver the best possible user experience over the chosen network connection speed. This improves the remote desktop user experience over a variety of network connection speeds.
The four options for network connection speeds are modem (56 Kbps, 28.8 Kbps), broadband (128 Kbps to 1.5 Mbps), LAN (10 Mbps or higher), and custom. The custom setting allows users maximum flexibility over what desktop features are disabled. These optimizations apply only when the user is connected remotely at sub-LAN connection speeds. At all other times, the computer has the full-featured desktop functionality.
Clients running the following operating systems may utilize this feature: Windows XP, Windows 2000, Windows 95, Windows 98, Windows Me, and Windows CE.
Time zone redirection
This feature allows a remote desktop session's time zone to be specified by the client computer's time zone. For example, an IT administrator who has deployed Terminal Services for a particular group of users located in several locations around the world can use Group Policy and Windows Management Instrumentation (WMI) on the server to turn on time zone redirection. This allows end users of Terminal Services to utilize their computer's local time zone rather than the time zone of the Terminal Services server. Clients currently capable of time zone redirection include Windows XP and Windows CE (Version 5.1).
Smart card sign-on
A smart card that contains Windows logon credentials can provide those credentials to a Windows Server 2003 remote session for logon. This feature requires a client OS that can recognize the smart card first: Windows 2000, Windows XP, and Windows CE .NET.
Ports
Client serial ports can be mounted to the server. This enables a variety of hardware on the client computer to be accessed by software on the server.
File system
Client drives, including network drives, are mounted inside the server session. This lets users open or save files on their own computers' disk drives, in addition to opening and saving files on the server.
Integration with Active Directory Services Interface
This feature provides the ability to script Terminal Services user configuration settings using the Active Directory Services Interface (ADSI). For instance, an IT administrator who upgrades a domain from Windows NT 4.0 to Windows Server 2003 can use ADSI to script the creation of user accounts within Active Directory and copy all user properties, including Terminal Services user configuration information.
Terminal Services in the Enterprise
In this part of the chapter, we discuss some issues that will likely be encountered when adding Terminal Services to an enterprise organization.
Domain Considerations
The standard principles for installing a Terminal Server apply equally to Windows 2000 and Windows 2003 Terminal Services. If Active Directory is installed on the network, simply join the Active Directory domain. There is no longer a primary domain controller (PDC) or backup domain controller (BDC) in Active Directory setup. For legacy support, a PDC Emulator will be created in the Windows 2000 domain controller when a Windows NT Domain client attempts to log on. Therefore, it is possible to mix TSE servers with Windows 2000 and Windows 2003 servers running Terminal Services.
Migrating to Windows Server 2000 or Windows 2003 Server from an Existing Windows NT 4.0 PDC
If a Windows 2003 server is installed in an existing network that employs backup domain controllers, the new Windows 2003 server operates as a "mixed mode" domain controller. In this case, the Windows 2003 DC will be migrated first to Active Directory and will emulate a Windows NT 4.0 PDC. The old PDC-to-BDC security database synchronization will continue until all BDCs are migrated to Active Directory and "mixed mode" has been switched to "native mode."
Application Considerations
Most applications are written to run on a single-session platform such as Windows 95, 98, or Windows NT Workstation with a single user. Terminal Services requires significant changes to be made to the kernel and operating system to accommodate multiuser access. Because of these changes, both programmers and administrators must fully understand the issues and possible solutions in order to configure the system so that single-session applications can be executed in a multisession environment. We discuss some of the problems and possible solutions in this section.
Terminal Services makes special demands on how an application is written and how the application uses the Windows NT operating system. The Windows NT Registry is used by many programs to store variables during an installation, changes while the program executes, and changes that normally occur when users with differing logons access the application. On a typical Windows 2000 Professional workstation, an application may put data into the HKEY_LOCAL_MACHINE registry hive, assuming only one user will access the application at a time. On Terminal Server, this could prove disastrous, as changes to this registry hive would affect all users of this Terminal Server, not just the user executing the application making the change.
Many problems occur with applications that store local data constructs in global locations. In addition to separating global and local information in the registry, global and local file-based data constructs should also be maintained separately. For example, user preference files should not be stored in a main system directory (/%systemroot%) or program directory (\Program Files). Instead, preference files or other user-specific local data should be stored in the user's home directory or a user-specified directory. This consideration also applies to temporary files used to store interim information (such as cached data) or to pass data on to another application. User-specific temporary files must also be stored on a per-user basis.
Some specific issues that may cause an application to fail in a multiuser environment include
Incorrect registry entries Many applications write a global INI file to the system root for user-specific information. Thus, when one user changes or opens the INI file, other users may not be able to access the same file. Some applications add shortcuts to only the installer's menu during installation; because of this, other users may not see the shortcut. Still, many applications point the data files, temporary files, or cache files to the same location for all users. In this situation, only one user can run the application at a time.
Changed object name An object created in a session is named differently. The application may not be able to find the object using the expected name or location.
Incorrect file and object rights access An application normally locates libraries and executables in the Windows NT %SystemRoot% directory. Multiple users accessing the same file may create file-locking problems.
The following are some other application problems and issues to be aware of within a multiuser Terminal Services environment:
Do not assume the computer name, MAC address, or IP address equates to a single user. In the traditional distributed Windows client-server architecture, one user is logged on to one computer at a time. Thus, the computer name or Internet Protocol (IP) address assigned to either a desktop or server computer equates to one user. In the Terminal Services environment, the application can only see the IP or NetBIOS address of the server. Applications that use the computer name or IP address for licensing, or as a means of identifying an iteration of the application on the network will not work properly in the Terminal Services environment because the server's computer name or IP address can equate to many different desktops or users.
MS-DOS and 16-bit Windows applications require more RAM than native 32-bit Windows applications and may not execute at all in Windows 2000 Server or Windows Server 2003. Windows runs an emulation layer called the Virtual DOS Machine (VDM) as a process on the 32-bit operating system. Although this memory requirement may not show up as performance degradation on a high-powered desktop computer running the latest Windows operating system with 64MB of RAM, it may easily show up on a system running Terminal Services due to the multiplier effect of many user sessions.
Multiuser Application Issues
You may encounter several possible issues when running applications under Terminal Services that were not designed to run in a multiuser environment. Some of the most important issues are summarized here. We will discuss these and other application-related issues in more detail in Chapter 13.
Application Compatibility Scripts
Many of the issues discussed so far have been addressed by the creation of application compatibility scripts. After installing an application, an administrator is required to run the corresponding script to resolve the issues mentioned. Windows 2000 shipped with 27 native Application Compatibility Scripts, and since then scores of software manufacturers have created additional scripts to provide users with fixes for their software in a multiuser environment. At the time of this writing, Windows 2003 only has four scripts in the Application Compatibility Scripts folder. Since Microsoft requires an application be multiuser compatible before it can be certified for Windows 2003, our assumption at this time is that a large majority of application vendors have simply included the scripts in their install process, thus alleviating the need for scripts. Obviously there will be some stragglers, so the need for Application Compatibility Scripts will continue for the foreseeable future. Application compatibility scripts are located in the %SystemRoot%\Application Compatibility Scripts\Install folder.
DOS and 16-Bit Windows Programs
After over eight years of Microsoft operating system support for 32-bit applications, it seems logical that all application vendors would have completed their software porting to take advantage of the speed, stability and interface changes. Win32 allows code sharing and thus runs more efficiently in a multiuser environment. If additional users need to access the same Win32 application code, a pointer is created that shares the same code from the original copy loaded in the kernel and user modes. Code sharing cuts down the total amount of memory usage when multiplying a large number of sessions. On the other hand, 16-bit Windows and DOS applications need to run in their own VDM, and so no code sharing is possible. Also, Win16 applications often require 16- to 32-bit conversion programs ("thunking" and "context switching") that increase resource utilization even further. Even with all of these obvious advantages, and nearly ten years to get it done, there are still a few poorly run software vendors who have not ported their software to a 32-bit code. We highly recommend running only 32-bit Windows applications whenever possible, even if it requires a large investment in moving to another vendor. Because Windows 2000 and 2003 are not well suited for DOS or 16-bit application support (although there are some instances where it works), if 16-bit or DOS applications are required, consider dedicating a Windows NT 4.0 TSE server to those applications, while building the rest of the farm around Windows Server 2003.
Effective Use of the Registry
In a multiuser environment, applications should store common information pertaining to systemwide operation in the HKEY_LOCAL_MACHINE section of the registry. Such information includes the path used to load application components, and what components are needed during execution. User-specific information, such as the locations of custom dictionaries (custom.dic) and user templates (normal.dot), should be stored in HKEY_CURRENT_USER. Some applications incorrectly store information meant to be user specific in HKEY_LOCAL_MACHINE.
Application compatibility scripts, Group Policies, and user profiles can all address an unused drive letter to the home directory of each user. REG.INI then changes pointers to this drive to each user's home directory environment variable. In this way, each user gets her own copy of an initialization file.
Tip A utility in the Exchange Server Resource Kit, named profgen.exe, resolves common pointer issues arising from users trying to open the same e-mail post office box when a mandatory profile is used. This utility can be useful when enabling many users running Terminal Services to access the same Exchange server.
Application Install and Execute Modes
During installation, an application writes user-specific keys to the Administrator's HKEY_CURRENT_USER registry hive. Information such as Document Path and Autosave Path are missing from other users' HKEY_CURRENT_USER keys because they did not install the application. These keys are crucial in successfully using the application. Terminal Services provides a global Install mode to address this situation. During installation, the system is placed under Install mode by entering the command Change User /Install at the command prompt or by using Add/Remove Programs from the Control Panel. All user-specific keys generated by the application under the software hive are shadowed by a key hive in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNt\CurrentVersion\TerminalServer\Install.
This key hive is appropriately called the shadow key. Once installation is completed, the system can be switched back to normal execution mode by entering the command Change User /Execute at the command prompt. In the Execute mode of operation, the shadow key information is written back into each user's software key hive when the system finds that the keys are missing.
The same command addresses missing INI and DLL files in the case of 16-bit applications. These files are copied into each user's Windows directory (normally, %homedrive%\%homepath%\windows). This also applies to 32-bit applications if they use INI files. The %homedrive% and %homepath% variables are both solved when running chkroot.cmd and are replaced simply by %rootdrive%. The files that are copied to C:\WTSRV and C:\WINNT are copied to %rootdrive%\windows when a new user logs in.
User-Specific Application Data
Some settings, such as DocumentPath in the HKEY_CURRENT_USER Microsoft Word subkey, may only be created the first time the application is run. Therefore, the installer must execute the application in global Installation mode right after finishing the initial installation. By doing this, the system will generate these values and record them in the shadow key so that they can later be copied into each user's HKEY_CURRENT_USER registry hive.
Note Logging in as a user and changing settings in an application can cause problems for any user running that application. Making a change while logged in as a normal user on a production machine to store a user's name and initials would cause all future users to see that user's name and initials when they edit documents. Thus it is important to find where these paths are stored and to script or add them to the shadow INSTALL key mentioned earlier so that all users only get the changes the administrator wants them to have.
Sometimes an application creates a path pointer to a common location for all users. For example, the Microsoft Office 97 installation program sets a document template pointer to C:\Program Files\Microsoft Office\Template. When multiple users try to update or open the same file, errors will occur. To address this situation, the administrator needs to search the registry and change the pointer to each user's home folder, such as H:\Office 97\Template, then create the correct directory structure for each user in the logon script %SystemRoot%\System32\usrlogn2.cmd. This file is called by the usrlogon.cmd (if this file does not exist, create it using a text editor) and add the following simple statement to accomplish this task:
IF NOT EXIST H:\OFFICE 97\TEMPLATE MD H:\OFFICE 97\TEMPLATE
Note Most of the Microsoft Office installation issues discussed here have been resolved with Office 2000 and XP, or are easily resolved with the Office Resource Kit. These discussions still serve as an example of how to resolve similar problems with other applications.
A similar problem occurs when all users are directed to use the same cache files. The cache file pointer is set to a common location, such as C:\Temp\Cache. When multiple users attempt to write to the same location, the application will often halt, corrupt the cache, or simply crash the server. Again, the solution is to change the pointer in HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, then create the corresponding directory structure in each user's home directory to support an individual application cache.
File Security
Applications often store files in the system root directory. Security is normally set to Read-Only for regular users. When a user attempts to write to a file stored in this directory, execution of the application may fail. You can track down the particular file and reassign security to it by using the FILEMON utility (this freeware utility is available from Sysinternals at http://www.sysinternals.com). A better method is to relocate the file to each user's Windows directory.
Registry Security
Many issues arise due to registry security and incorrect use of the registry by legacy applications. REGMON is another tool available at the Sysinternals web site that administrators can use to track down registry keys that have the wrong security.
Application COM/DCOM Objects
The same application may create identical objects for multiple sessions. To separate the same object created by different sessions, a logon ID is appended to each object name. Session objects created in this way are called user global objects and are only visible inside the session in which they were created. If an object is created from the console, there will be no logon ID appended to the object name. This type of object is called a system global object. Because of this distinction, application objects to be used for multiple sessions should be generated as system global objects and installed from the console instead of a user session.
Note Always install software from the console because of the issues mentioned earlier that arise from running applications in a session.
Memory Utilization
Some applications do not return memory to the system upon exit. This situation is exacer-bated in a multiuser environment, and is difficult to track down when a large number of applications and users are involved. Although a nightly reboot with Windows 2000 or Windows 2003 should not be required if the applications are well written, real-world environments typically have at least one rogue application that is poorly authored. Many SBC environments implement a cyclical reboot program in order to clear memory and prevent memory leaks from causing erratic performance and server crashing. The frequency of the reboot depends on how active the memory utilization is. Citrix MetaFrame XPe has a reboot tool, and many of the resource web sites we list in the appendixes have example scripts as well.
DCOM Compliance
Most programs use traditional Open Database Connections (ODBC) to access network objects, such as a data source in a SQL database. To allow a common interface for communication between all system programs (objects) across a network, Microsoft developed the Distributed Component Object Model (DCOM).
In order to be certified by Microsoft as Windows 2000 or Windows 2003 compatible, an application must support DCOM. This ensures that software components can communicate and share functions over a network in an efficient and reusable manner. TSE inherited a subset of DCOM functionality from Windows NT 4.0. Therefore, some applications written for Windows NT 4.0 may not function properly under TSE's multiuser environment. Microsoft has addressed this issue in Windows 2000. All DCOM activation modes are fully supported, as shown in the following:
Run as Activator Local activation is the same whether Terminal Services is enabled or not. The server is activated on the same session as the activator.
Remote Activation When DCOM is activated remotely, the process is launched in a WindowStation with a special SessionID =0, not a session corresponding to the user. This modification preserves the implementation activity of a remote call.
Run as Named User The application is configured in the registry to run as a specified user. Local and remote activation of DCOM behaves in the same way.
Run as Windows NT-Based Service The application is configured to run as a service. This type of service is not tied to any session.
Run as Interactive User The application is configured to run in the security context of the user.
Licensing
Be sure to read all the way through this section, because the "Windows Server 2003 Licensing" section contains some great news that alleviates much of the licensing pain that SBC users have encountered.
In addition to the basic server operating system license required for every installed server, both Terminal Server RDP clients and Citrix ICA clients require two licenses to connect to a Terminal Server session. The first license is the standard Microsoft Client Access License (CAL) for accessing Windows NT files and print services.
The second license required to enable a client connection is a Windows Terminal Services License (TS CAL). If the session client is running on a computer with Windows 2000 Professional or Windows XP Professional when connecting to a Windows 2000 Server farm, it is not necessary to purchase a TS CAL for that client device or user. The server has a "built-in" pool of licenses it can provide to those client machines running Windows 2000 Pro or Windows XP Pro. In the case of Windows Server 2003, there is no "built-in" TS CAL pool. Owners of Windows XP Professional desktop licenses are eligible for free TS CALs, however. (Talk with your licensing provider to receive the free licenses as soon as possible since this offer from Microsoft is limited.) Although Windows NT 4.0 TSE does not enforce licensing, both Windows 2000 Server and Windows Server 2003 arduously enforce licensing of the TS CAL.
Note There is a special provision for an Internet Connector in Windows 2000. This license mode allows 200 anonymous, concurrent users to access Terminal Services on a single server. However, the End User License Agreement specifically states that anyone affiliated with the owner of the license cannot use it (in other words, vendors, customers, employees, contractors, and so on cannot use the license). This rule makes the license restrictive to the point of being useless. Fortunately, the Internet Connector is being replaced as described in the upcoming "Windows Server 2003 Licensing" section.
Windows 2000 Licensing
Windows 2000 enforces the use of the Terminal Services CAL. During any attempt to connect to a session, both the standard CAL and the TS CAL will be checked. If either license is missing or invalid, the connection is refused. If the connection is granted, a temporary or permanent TS CAL is assigned.
Note In a Windows NT Domain with Windows 2000 or Windows Server 2003 member Terminal Servers, Terminal Services licensing must be installed on a Windows 2000 or Windows Server 2003 member. When upgrading the Domain to Windows 2000 Server or Windows Server 2003 Active Directory, licensing must be reinstalled on a Domain Controller (DC). Failing to install Terminal Services licensing and the license codes on the new DC will cause a loss of terminal service capabilities (no license server available).
Windows 2000 Server comes with a license services server that tracks and allocates TS CAL licenses to clients at connection time. The license server needs to be installed on a Windows 2000 server and activated through Microsoft License Clearing House via a web browser, the telephone, or a process called Automatic Activation. When a client requests a connection to a Windows 2000 server, the request is forwarded to the central license server for validation. The license server uses the username and computer name to check for an existing license. If none is available, a new license will be issued to the client, and the connection is completed. If the license pool is exhausted, the connection is refused. A temporary license can be enabled that will expire after 90 days.
The significant issue with this licensing is that if a user connects one time from any device (a trade show kiosk, for example), a TS CAL is allocated (although it is not legitimate from the standpoint of the Microsoft Server 2000 licensing agreement to provide a license to a machine not owned by the person using it). Due to this execution of the licensing, the unclear license language, and technical problems (Microsoft provides no licensing option to deal with devices that aren't owned by the company whose user is using it), many customers found themselves continuously running out of TS licenses. In July of 2002, Microsoft responded to strong user feedback regarding the TS license execution by changing the licensing model slightly (via a hotfix patch) to allow the license server to expire leases after 90 days. To install this patch, install the Service Pack 2 Security Rollup package, or Service Pack 3 to your license server and all Terminal Servers in your environment.
Tip After installing Service Pack 2 Security Rollup or Service Pack 3, uninstall and reinstall all TS licenses and reactivate them in order to complete this fix.
Licensing and Terminal Services Execution Modes
Windows 2000 Terminal Services can be installed in two different modes. The remote administration mode does not require a TS CAL. The purpose of this mode is to allow administrators to do server maintenance remotely. Therefore, certain restrictions apply to running in this mode. Only two concurrent client sessions are permitted. Server application compatibility services are also disabled, such as the global install mode. The Application Server mode is the mode utilized for Terminal Services in a server-based computing environment. This mode is not restricted like the remote administration mode and requires the TS CALs as discussed earlier.
Windows Server 2003 Licensing
Probably the single most significant reason to move from Windows 2000 Server to Windows Server 2003 across the corporate environment is the new licensing options. Although the execution of the license server is identical to Windows 2000, the licensing choices are dramatically improved. Following are the changes made to licensing with Windows Server 2003:
Windows Server 2003 provides a 120-day grace period for renewals as opposed to 90 days with Windows 2000 Server.
Windows Server 2003 supports a new license option—Per User licensing, as well as the Per Seat licensing supported in Windows 2000 Server (Microsoft has renamed it in Windows 2003 to Per Device). Additionally, a hybrid may be used (some licenses may be allocated per device and some per user). The Per User licensing will work best for environments where users have multiple devices that connect to the Terminal Servers (that is, a single user connects from a desktop, laptop, CE device, home PC, trade show kiosk, and so on). The Per Device licensing works best for environments where multiple users share the same device (manufacturing floors, hospitals, 24/7 offices, and so on). Note that with this change the temporary fix we discussed earlier in this section, allowing Windows 2000 to expire the leases every 90 days, has been eliminated.
The Internet Connector License noted earlier is replaced in Windows 2003 with an External Connector (EC) license called the Terminal Server External Connector (TS-EC) to address the need previously mentioned: to enable external users to access a company's Terminal Servers, without the need to purchase individual TS CALs for them or their devices. An example of an external user is a person who is not an employee of the company or its affiliates. The EC allows organizations to effectively provide Windows and TS CALs for entities not owned by them—for example, e-business customers or supplier partners—in order to give those entities access to their networks and terminal servers. The EC may be the best solution when business partners or customers need access to a server or group of servers. This may be the best solution when a small number of business partners or customers need access to a server or group of servers. This license mode allows 200 anonymous, concurrent users to access Terminal Services.
Licensing and Terminal Services Execution Modes
Unlike Windows 2000 Server, which had a dual mode Terminal Services component, Windows Server 2003 separates the remote administration and Terminal Services functionality into separate configurable components. Remote Desktop for Administration is enabled through a check box on the system Control Panel's Remote tab. Terminal Services is enabled by adding the "Terminal Server" component using the Windows Components portion of the Add/Remove Programs Wizard.
In addition to the two virtual sessions available in Windows Server 2003 Terminal Services remote administration functionality, an administrator can also remotely connect to the console of a server. A significant outcome to this change is that applications that would not work in a virtual session before, because they kept interacting with "session 0," will now work remotely. To connect to the console, administrators can choose one of the following methods:
Use the Remote Desktop Microsoft Management Console (MMC) snap-in.
Run the Remote Desktop Connection (mstsc.exe) program with the /console switch.
Create Remote Desktop Web Connection pages that set the ConnectToServerConsole property.
Subscribe to:
Posts (Atom)