Installing and Configuring Applications

Since the operating system needs to allow multiple users to run and access applications (and thus application registry settings) simultaneously, a program must be installed in such a fashion that the registry changes are replicated for all users. There are two basic methods for installing an application on a MetaFrame XP server to cause this replication to take place. The recommended method is to use the Control Panel and run the Add/Remove Programs application. The other is to run the change user /install and change user /execute commands from a command prompt.

Using Add/Remove Programs

The advantage to installing an application using Add/Remove Programs from the Control Panel is that it creates the "shadow key" properly in all cases. The Add/Remove Programs application monitors changes to the HKEY_CURRENT_USER key and saves them in the shadow key. This key is then propagated to each user, as shown in Figure 13-1, so that they may have unique settings for that application.

Figure 13-1: Shadow key propagation

Note

Do not allow the system to reboot until after you click Finish in the Add/Remove Programs application to ensure that the shadow key information is safely written.

Using Change User /Install

Using the change user/install command works well most of the time, but we have seen that in some cases shadow key information is missed. For example, there is a known problem installing Internet Explorer in this manner, but it works perfectly well using the Add/Remove Programs application. This method involves opening a command prompt, typing change user /install, installing the application, then typing change user /execute.

Note

If you use this method, make sure you do not allow the system to reboot without first issuing the change user /execute command. If you do not issue the command, the system may not properly record the changes to the registry.

The Application Installation Checklist

The basic procedure for installing applications on a Windows 2000 Server or Windows Server 2003 running MetaFrame XP is as follows:

1. Make sure you are logged onto the test server console as a member of the local Administrators group.

2. Reset any remote sessions with the Citrix Management Console.

3. Disable logons to the server using the Citrix Management Console (select Server | Properties | MetaFrame XP settings, then uncheck the Enable Logons to this Server check box) to prevent users from logging in during the application installation.

4. Run the Add/Remove Programs application and select the application's setup program to begin installation.

5. Click Finish after the application has completed installation and before the server reboots.

6. If an application compatibility script exists, run it. Review the notes in the script and any "read me" notes on application compatibility, then perform any other necessary steps.

7. At this point, the application is installed, and testing can begin.

Note

Though you can uninstall an application with Add/Remove Programs, we don't recommend it. We recommend using the imaging process outlined in Chapter 11 or Installation Manager (discussed later in this chapter) to create standard server images including packaged applications. If an application needs to be removed, simply restore the image that was current before the application package was installed or unpublish the application within Installation Manager. Other methods can leave remnants of the application in the form of leftover registry changes or library files that can cause problems with the system or with other applications.

Postinstallation Changes

Although a large majority of current applications run without a hitch in a Windows 2000 Server and Windows Server 2003 Terminal Services environment, there remain some older and more rogue applications that simply aren't designed appropriately. For the older applications, a bit of tweaking may be needed after installation on the MetaFrame XP server using the Add/Remove Programs application or the command-line method. Most postinstallation changes provide necessary changes to user-specific program settings, or library file locations.

As multiuser environments have grown increasingly popular, some application vendors have created fixes to make their applications work in a Terminal Services environment. An application compatibility script is a batch file that makes any changes to the operating system that are necessary for a specific application to function in a multiuser environment. There are two types of Application Compatibility Scripts: Install and Logon.

Install Scripts

The two main functions of the Install Script are to remove any inappropriate changes to the HKEY_LOCAL_MACHINE registry key, and to verify that the logon scripts are correct. An Install Script will first verify that the root drive has been properly specified. If it has not, the script will open the ROOTDRV2.CMD file so it can be specified. If the root drive has been specified, it proceeds to correct inappropriate writes to HKEY_LOCAL_MACHINE as well as perform any other necessary cleanup work to make the application run correctly. Finally, it adds a call to the USRLOGN2.CMD file that will call the appropriate Logon Script for the application.

Logon Scripts

As the name implies, these scripts are designed to correct problems with the user logon environment, either with the HKEY_CURRENT_USER key, the user's home directory, or user-specific application settings. The USRLOGN2.CMD batch file calls the application Logon Scripts. This script is called by the main logon file, USRLOGON.CMD. USRLOGON.CMD is responsible for creating the RootDrive variable used by all logon scripts to identify the user's home directory.

The RootDrive variable defines both the user's home drive and the home path and can be used instead of the UNC path defined in the user properties of the Computer Management utility. Use of the drive letter is preferable because the user will not have access to directories above the directory where the home drive is mapped.

Softricity SoftGrid for Terminal Servers

It is important to note that a useful third-party tool is available to resolve some of the typical application installation problems with application compatibility, DLL conflicts, and Windows registry conflicts. Softricity (www.softricity.com/products/) offers a product called SoftGrid for Terminal Servers that dramatically changes the application installation and deployment approach. With the SoftGrid solution, applications are never installed on the Terminal Servers. Instead, applications run inside Softricity's SystemGuard virtual environment, which protects the computer's operating system from any alterations and enables the application to run intact.

SystemGuard is a virtual run-time environment within which an application executes. It maintains the integrity and reliability of the operating system by shielding it from change that is normally created by the application as it is installed and run. However, since the applications execute locally, access is still available to all local services including cut and paste, OLE, printing and network drives.

We recommend that enterprise environments with 1000 or more users consider Softricity or other similar solutions to reduce the complexity and testing required on Terminal Servers providing large numbers of applications.

Installation Tips

Though it is impossible to provide installation tips for all common applications, we thought it would be appropriate to include a few to set expectations. There is a wealth of information about application configurations on the Citrix web site (http://support.citrix.com). We have found the online knowledge center (Citrix's knowledge base and user forums) to be particularly useful, as it contains many technical notes from other users on application difficulties and the methods used to fix or work around them.

The following examples show the format for application installation and configuration checklists. They are provided both as an example of the process of installing an application under MetaFrame XP and as a suggestion for recordkeeping purposes.

Example Installation Instructions—Installing Microsoft Office XP on Windows Server 2003 for Use in a Terminal Services/MetaFrame Environment

For the purposes of providing an example of a common application installation in a Terminal Services environment, we will utilize our fictional case study, CME Corp introduced in Chapter 10, as an example. CME Corp, a medical device manufacturer with 3000 employees worldwide, will be deploying Microsoft Office XP. In order to install Office XP in the Terminal Services environment, a Microsoft Transform file (MST) will be used for installation. The MST file allows for full customization of the install, including configuration of the Outlook profile with a user-specific profile.

Note

Unlike Office 2000, Office XP does not require a special transform to install Office on a Terminal Services-enabled computer. Office XP Setup detects that it is being run under Terminal Services and it preconfigures all the proper options. Because a transform file allows a custom configuration, including Outlook Profile configuration, we will cover the custom transform file setup in this section.

To install Office, do the following:

1. Create an administrative installation of Office XP.

2. Install the Microsoft Office XP Resource Kit. The ORK can be downloaded from www.microsoft.com/office/ork/xp/appndx/appa04.htm.

3. Create a custom Microsoft Transform file.

4. Execute the Microsoft Office XP installation program to install Microsoft Office XP. (CME Corp will use Installation Manager as described later in this chapter, and thus will need to add the package to the CMC.)

Note

Installation of Office XP on a Terminal Services-enabled system requires the use of the Application Server mode configuration. A computer configured for Remote Administration mode is not recognized by Office XP Setup and installs Office XP as if it were being installed to a generic workstation.

Creating an Administrative Installation of Office XP To create an administrative installation of Office XP, run the setup program with a /a switch and choose an installation directory on an easily accessible network share. For example, from the desktop of any Windows 2000 Server machine in the environment, click Start | Run, and then type setup.exe /a path\name SHORTFILENAMES=TRUE /qb /L* path\name of log file.

The following are various command-line options available:

• /a Enables Windows Installer to perform an administrative installation of a product on a network share.

• SHORTFILENAMES=TRUE Directs Windows Installer to create all filenames and folders with MS-DOS-compatible filenames. Required when you run Windows Installer from the command line.

• /qb Sets the user interface to the basic level (simple progress and error handling).

• /L* Turns on logging and sets a path for the log file. The * flag causes the switch to log all information.

• path\name of log file Path and filename of the Windows Installer log file.

Installing the Office XP Resource Kit The Office XP resource kit can be downloaded from www.microsoft.com/office/ork/xp/appndx/appa04.htm. Install it accepting all of the defaults.

Creating a Custom Office XP Terminal Services Transform File After installing the Office XP Resource Kit, we are ready to create a custom Microsoft Terminal Server Transform (MST) file with the Custom Installation Wizard for CME's environment. We will later use this file with Installation Manager to deploy Office XP to all current and future MetaFrame Servers.

To create and configure a custom Microsoft Office XP Terminal Services Transform file:

1. Click Start | Programs | Microsoft Office Tools | Microsoft Office XP Resource Kit Tools | Custom Installation Wizard. Click Next to go forward with the installation.

2. Click the Browse button.

3. Browse to the PROPLUS.MSI file (this filename will be different for the Premium or Standard versions of Office XP) located on the administrative installation share and click OK, then click Next.

4. Select Create a new MST file and click Next.

5. Select a location and name the file TERMSRVR.MST to save the new MST and click Next.

6. Specify the Default installation path and the Organization name and click Next.

7. Specify if you want to uninstall any previous Office versions as part of the Office XP install and click Next.

8. Select the features that you do not want to install and click Next. (Set the installation state of the selected feature to Not Available, Hidden, or Locked. Select the Do Not Migrate Previous Installation State check box.)

   Note

   The Do Not Migrate Previous Installation States check box must be selected for each feature that is set to Not Available, Hidden, or Locked. Carefully choose which features to install. Features like animation and the office assistant should notbe installed, since they can cause unnecessary strain on the server.

9. Click Next on the following screens, making any customizations appropriate.

10. On the Outlook Screen: customize the Default Profile page, choose New Profile, and name the profile %username%, then click Next.

11. Select Configure an Exchange Server connection and enter an Exchange Server name, then click Next.

12. Click Customize Additional Outlook Profile and Account Information.

13. Click Add and choose Outlook Address Book, then click Next and Finish on the Add Account Wizard.

14. Click Next.

15. Continue to click Next while making any appropriate changes until the wizard is complete.

Executing the Microsoft Office XP Installation Program For basic installation to one server, use the Add/Remove Programs or change user /install as described earlier in this chapter and click Start | Run, then type setup.exe TRANSFORMS=C:\TERMSRVR.MST /qb. Click OK.

To install this application to multiple servers, please see the "MetaFrame Installation Manager" section later in this chapter.

Managing the Application List

Before launching into the application test process, it is important to have a controllable list of applications targeted for production. The list should be as small as possible but still have representative applications in any category that your company needs to use. What must be avoided is a lack of standardization within a category. For example, a large organization may be using both Microsoft Office 2000 and Office XP. Make every effort to choose one application (or suite, in this case) for deployment in the SBC environment. It will reduce complexity, ease support, and cause less confusion to the user community.

Application Testing Procedure

Each application should go through two phases of testing—component testing and system testing—in order to assess how it functions running by itself and as part of a fully configured server. The strategy is to have as much breadth and depth of testing coverage as is practical, given the realities of most fast-paced corporate IT departments. The effort of creating and refining an application testing process is worthwhile. Over time, the IT staff will become fast, proficient, and confident at running the tests.

Component Testing

This phase of testing is designed to exercise an application running by itself in a multiuser environment. This can be especially important with applications that were not written specifically for this environment, do not have application-compatibility scripts, or are older DOS or 16-bit applications.

Generic Functions The generic functions of the component test phase are functions that are common to most applications. Examples of generic functions are Execute (run the program), Exit, File-Print, File-Open, and Cut and Paste. Coverage of generic functions is important to ensure the application works as expected in a multiuser environment. One test list can be created that will cover every application slated for deployment, or at least broad categories of applications. Not every test on the list will apply, but running the test list is important nonetheless.

Specific Functions As the name implies, these are functions that are specific to each application. At least one test list should be created for each application to cover specific functions. Examples are running a custom macro in Microsoft Excel, creating a new project in Visual J++, and changing the color saturation in Adobe Photoshop.

System Testing

The system-testing phase is designed to ensure that an application behaves predictably on a server loaded with other applications. This is also typically the phase that includes some load testing for performance. A system test involves running the following steps:

• Run the component tests again on a fully configured server. Such a server has all the applications slated for production deployment loaded, the network connected, and is participating in a domain, a server farm, and load balancing. The idea is to set up an environment that is as close to the production environment as possible.

• Test necessary application integration functions—for example, database access through Microsoft Excel, cutting and pasting between applications, running a mail-merge macro in Microsoft Word, or running a custom client application that provides a front-end user interface to a legacy system.

• Load test the application. Establish as many user sessions as are likely to be used in production. This can either be done literally, or through scripting or a commercial testing application covered in Chapter 11. Have several people run test lists on the application simultaneously.

• Test the application using all targeted client environments. This includes not only desktop PCs, laptops, and Windows terminals, but also different points in the enterprise network and other different types of network connections.

Anecdotal Testing

We have found that a period of "beating on the application" after all other formal testing has been done is often very useful. This type of undirected testing allows the testers to think "outside the box" and exercise functions that the test-list creators may not have thought of. Anecdotal testing is no substitute for formal testing and should never be used as the sole testing method.

Test Lists

There is no secret to creating good test lists, but there is an art to it that can only be mastered with practice. The most important thing to remember is not to let "best get in the way of better." In other words, it is better to start with a basic test list and make it better over time than to delay the test process until the perfect test list is completed. The perfect test list will never be realized without experience in the process.

We have provided an example test list as a starting point. Feel free to adapt it to other programs or even modify its structure to fit your needs. Table 13-1 shows a test list of generic functions that can be applied to most applications. In addition to this generic list, a more specific list should also be developed to ensure that a particular application's functionality has been fully tested.

Table 13-1: Generic Functions Test List 1

Step	Test (Generic)	Description	Expected Result	Result	Pass/Fail	Notes
1	Launch Method #1	Click the Application icon on the desktop.	The application executes.	Application is executed.	P
2	Launch Method #2	Click Start | Programs, the program group, and the application name.	The application executes.	Application is executed.	P
3	Open a document	Choose File | Open from the menu.	The default or last data directory is displayed.	The default directory was displayed.	P	Might want to run this test two more times to see which directory is displayed.
4	Print a document	Choose File | Print from the menu.	Current document prints in full.	Document printed.	P
…
24	Exit Method #1	Choose File | Exit from the menu.	The application exits.	Application is exited	P
25	Exit Method #2	Click the X in the upper-right corner of the main application window.	The application exits.	Application is exited	P	This method is faster.

Note

Substitute the generic information in the tables with information specific to the application being tested.

Pass or Fail Status

Once a test list has been run, a report of the application, test lists, tests run, and the status can be generated. It is not unreasonable to expect an application to pass all tests before being considered for production deployment.

Test Cycles

All test lists run on a particular application are considered one test cycle. Keep in mind, all tests may not pass. Following the test cycle, and after any fixes or corrections have been made, all test lists with failed tests should be run again. Once all the failed tests have passed, a final run of the entire suite of test lists is advisable to make sure nothing new was "broken" during this phase. This is often referred to as regression testing. The cycle repeats until all tests pass or until the pass percentage meets a predetermined acceptance level. Once all tests have passed or met the goal, the application can be considered a candidate for production deployment.