Application Strategies

The idea behind building an SBC environment in the first place is to provide a means of distributing common applications to users that is low in cost and complexity, but high in functionality and performance. It is important to keep this "end state" in mind when selecting or writing applications to be run in an SBC environment. An application that is not stable in a traditional distributed computing network isn't likely to work any better under server-based computing. In fact, it may exhibit new problems. It is also critical to take the client environment into account. If both PCs and Windows terminals are being evaluated, the capabilities and user experience of each are quite different and will affect application functionality.

All application installation and updates, even minor hotfixes, must be subjected to a strict systematic installation and testing methodology. From a high level, we suggest the following methodology:

1. Identify and confirm the requirement for the installation, update, or hotfix.

2. Research the manufacturer instructions and warnings for the software to be installed.

3. If the fix is simply a hotfix or software update, utilize MetaFrame Installation Manager (IM) to unpublish (uninstall) the current version of the software from the test environment. Reinstall the original application using IM. Although this process may seem unnecessary, it is critical, as it ensures a common starting point when the update is propagated to other servers.

4. Install the application in the test environment.

   • Run any postinstallation scripts or application compatibility tests.

   • Configure the application.

5. Perform the testing algorithm recommended in the "Application Testing Procedure" section of this chapter.

   • Make any necessary fixes, registry changes, or optimizations.

6. Following full testing, use IM to publish the application to one production server. If it is an update or hotfix, utilize the IM image that includes the full uninstallation and reinstallation as recommended in Step 3.

7. Re-perform the testing algorithm.

8. Publish to the remaining required production servers.

Application Features and Requirements

We have created the following list of features and requirements to aid you in the application selection process:

• Applications should be stable and perform well in a traditional, distributed computing environment.

• The application should have stated support from the manufacturer. In the early days of server-based computing technology, application support was hit or miss (more miss than hit). With Windows 2000 Server, and now Windows Server 2003, however, in order for a software package to gain the Microsoft Windows Certification, the application must also support execution under Terminal Services. As such, multiuser support has become the norm rather than the exception.

• Ideally, an application should execute in multithreaded fashion and make efficient use of memory and CPU resources when running in a multiuser environment. Note that this precludes DOS and all 16-bit applications, although there are tricks we will discuss later in this chapter that may allow them to limp by.

• The use of multimedia in applications should be kept to an absolute minimum. Sound, graphics, or video should be limited to mission-critical features only, because the complexity and cost of the extra network bandwidth consumed by these features must be justified.

• The application should make the most use of the Windows printing system and be as efficient as possible in the creation and distribution of print jobs. Here again, we issue a warning regarding graphic-intensive programs: they typically generate enormous print files that then travel over the LAN or WAN to the printer. This must be taken into account when planning for the management of the available bandwidth.

Application Optimization

We discuss the process of installing and configuring applications in later sections. But first, it is necessary to address some specific optimization issues for the following categories of applications.

DOS and 16-Bit Applications

In order for a DOS or 16-bit application to run under Windows NT 4.0, a separate resource pool must be created for that program. This is due to the fact that such applications cannot share memory in the same way as 32-bit programs that were created specifically to run on Windows NT. This resource pooling program is called "ntvdm" for "NT Virtual Dos Machine." It uses the partitioning capability of the Intel architecture to create a virtual 8086 environment in which each DOS program can run. When running a DOS or 16-bit Windows program on Windows NT, ntvdm will show up as the executable in the task manager, rather than the program executable itself.

Note

Windows 2000 Server and Windows Server 2003 do not effectively support ntvdm, so if DOS or 16-bit applications are required, plan to build a Windows NT 4.0 TSE/MetaFrame XP server environment and dedicate it to running these applications.

Because these older programs cannot share resources, they do not scale well. We have seen environments in which an application was being migrated from an older 16-bit version to a newer 32-bit version. The 16-bit program took two to three times the resources of its newer 32-bit cousin. We realize these older programs may still be required, particularly as part of a migration effort, but every effort should be made to phase them out completely.

DOS Program Keyboard Polling Another feature to look out for with DOS programs is keyboard polling. Most DOS programs were written to run in a single-user environment, and data entry screens typically do nothing until the user presses a key. In order to respond as quickly as possible, the program polls the keyboard, sometimes hundreds or thousands of times per second. In a multiuser environment this can wreak havoc with system performance. Even though Windows NT runs ntvdm to give such a program its own resource pool, it must still grant access to hardware components such as the keyboard, mouse, and video. In some cases, the keyboard polling can be adjusted to more reasonable levels by using a standard command like DOSKBD or a third-party utility such as Clip2F or Tame. If the DOS program will not respond to limiting the keyboard polling, it should not be used in an SBC environment. A problematic DOS application will often consume 100 percent of the available resources on a MetaFrame XP server. Again, DOS keyboard utilities are not available under Windows 2000 Server or Windows Server 2003, so Windows NT 4.0 TSE must be used to run a DOS application.

Tip

The DOSKBD (or other similar utility) can be run from the autoexec.nt file that is accessed for each DOS session. The autoexec.nt file is specified with the PIF editor. Issuing the following command at the command prompt can collect initial statistics on the DOS application: DOSKBD /StartMonitor SOMEPROG.EXE

32-Bit Applications and the Registry

Just because an application is written to be 32-bit does not mean it makes effective use of the registry. It is important that such an application use the registry to store its settings for a variety of reasons.

• Application packaging is much simpler when all changes made by the installation process are stored in a particular group of registry keys.

• The application installation process in Terminal Services (change user /install) makes a copy of the registry changes that an install program generates for each user (HKEY_CURRENT_USER). If an application uses an INI file or incorrectly writes user-specific information to the HKEY_LOCAL_MACHINE key, it is problematic to get that application functioning in a multiuser environment.

Custom Applications

Many custom applications work quite well in an SBC environment. Such applications should be 32-bit and avoid hard-coded values for elements such as network paths or data sources. Keep in mind any library dependencies such as those required by Visual Basic, too, since these libraries will have to be installed with the applications on each Terminal Server in the farm.

An application should write all user-specific information to the HKEY_CURRENT_USER registry key and all global system information to the HKEY_LOCAL_MACHINE key.