Identifying Ideal Candidates for Hosting

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

When choosing applications to host with Terminal Server, consider the compatibility of those applications with Terminal Server. Many desktop applications load and run correctly with Terminal Server. Applications that have been certified for Windows are generally compatible with Terminal Server. For more information about the Certified for Windows program, see the Certified for Windows link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

With any Windows-based application the definitive source of compatibility information should always be the application’s vendor or developer. For more information about application compatibility with Terminal Services, see "Program Compatibility" in Help and Support Center for Windows Server 2003. There are also application compatibility notes for some applications available on the VeriTest Catalog of Certified Windows Server Applications link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

Application Characteristics That Affect Performance with Terminal Server

Because Terminal Server is available for multisession (multiuser) use, and because the display and keystroke information travels over the network, applications that have certain characteristics might perform poorly with Terminal Server. When planning for your organization, establish a set of acceptable performance guidelines and determine through testing whether such applications run better on the user’s local computer. For example:

  • Multimedia applications or applications that have very large graphical output do not run well with Terminal Server. Because large amounts of display information travel over the network, the performance of these types of applications is often unacceptable, especially over low-bandwidth connections. Many computer-aided design (CAD) and streaming media applications fall into this category.

  • Running 16-bit programs with Terminal Server can reduce the number of users a processor supports and increases the memory required for each user. Windows Server 2003 translates 16-bit programs in enhanced mode through a process called Windows on Windows (WOW). This causes 16-bit programs to consume additional system resources. A similar situation exists with running 32-bit applications on the 64-bit versions of Windows Server 2003.

    Note

    • You can prevent 16-bit applications from running on Windows Server 2003 by enabling the Prevent access to 16-bit applications Group Policy setting. This setting is located in Administrative Templates/Windows Components/Application Compatibility. You can set this setting for both the computer and the user.

    There are third-party add-ons that you can use to help with the performance of 16-bit applications and other application compatibility issues. For more information about these add-ons, see the AppSense and Tame Software links on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

  • Applications that are based on the Microsoft® MS-DOS® operating system use keyboard polling that can consume all the available resources on a CPU.

  • Applications with features that run continuously in the background (for example automatic spelling and grammar checking in Microsoft® Word) can affect performance with Terminal Server. In some cases, you can restrict user or group access to certain application types, disable unnecessary features that require the most resources, or install applications on separate servers to minimize the performance effects.

  • Complex automation or macros can be CPU-intensive and are not recommended. If you use or plan to use macros with the applications you plan to host, test your plans thoroughly to ensure adequate performance.

  • If you plan to use Terminal Server to host custom applications or applications developed in-house, you need to consider the specification for applications for the Certified for Windows program. For more information about the Certified for Windows program, see the Certified for Windows link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources. For information about guidelines for developing applications for use with Terminal Server, see the Optimizing Applications for Windows 2000 Terminal Services link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

  • If you plan to host older applications with Windows Server 2003 Terminal Server, for example applications that you have hosted with the Microsoft® Windows® NT 4.0 Terminal Server Edition operating system, be aware that you might need to run Terminal Server in Relaxed Security mode, which allows access to system files and the registry on the server, in order for these applications to function properly. For more information about security modes, see "Designing the Terminal Server Configuration" later in this chapter.

After you choose the applications you want to host, analyze these applications for potential problems in a multiuser environment and thoroughly test them, including end-user testing and pilot testing, to ensure that they work in your environment. For more information about piloting and testing, see "Planning for Deployment" in Planning, Testing, and Piloting Deployment Projects of this kit.

Compatibility Scripts

You might have to modify or provide support for custom applications or applications that are not written to accommodate multiuser access. Such applications might not use per user data storage, the user-specific portions of the registry, or appropriate permissions. You can run compatibility scripts for these applications after you install the application. These scripts are available:

  • With the Windows Server 2003 operating system. These scripts are located in the systemroot\Application Compatibility Scripts\Install folder.

  • From your application vendor. These scripts might be available on the application CD, on the Web, or by special order from the company.

  • By developing them yourself. Use the scripts in the systemroot\Application Compatibility Scripts\Install\Template folder as a template.

Information about running these scripts is available in the "Designing Application Installation" section later in the chapter. For more information about the Windows Application Compatibility Toolkit, see "Testing Application Compatibility" in Automating and Customizing Installations of this kit.