Now that you understand the process that Terminal Services uses to create an environment that can assist applications in running for simultaneous users, we can look at how the actual softwareinstallation process works on a Terminal Services server. In a perfect world, all applications would follow the guidelines laid out in the Designed for Microsoft Windows XP logo specification.
This specification instructs programmers to take advantage of several Windows component services that would make the application natively compatible with WS2K3 and Terminal Services. The following list quotes and describes the elements of the specification that are of particular interest to the Terminal Services administrator:
• Do not read from or write to Win.ini, System.ini, Autoexec.bat, or Config.sys on any Windows operating system based on NT technology—Programs that don't obey this rule might store per-user settings in these per-machine configuration files.
• Install using a Windows Installer-based package that passes validation testing and Ensure that your application supports advertising—The Windows Installer service uses a process called advertising to ensure that per-user registry keys and files are installed for each user of a computer and not just the user who installed it.
• Default to My Documents for storage of user-created data—Compliance with this item ensures that per-user files (documents, macros, templates, and so on) are stored in a peruser location, not in the program's directory.
In the real world, however, systems administrators have to deal with many applications—both current and legacy—that don't adhere to these guidelines or were written before the specification was established. To assist in integrating these types of applications, Terminal Services utilizes registry mapping, INI file mapping, and application compatibility scripts.
Was this article helpful?