Chapter 8: Applications

 < Free Open Study > 



Application management and configuration are crucial elements of Citrix MetaFrame administration. At the end of this chapter, you should have a firm understanding of how to install and configure applications, application publishing, and the Citrix Installation Manager.

Certification Objective 8.01: Installing Applications

Most application setup procedures provide no way to propagate private application settings (either INI files or profile settings) to users other than the installation user on MetaFrame. Citrix introduced different installation modes so that application installation and configuration could be tracked, if required, to enable propagation of private settings to any user running the application.

Managing Sessions During Application Installation

Applications should NEVER be installed while you have remote users logged on to the system. When users are logged on, it is possible for their session to have open file handles to files the application is attempting to overwrite.

Always disable logins either by disabling the Enable Logon To This Server check box in the MetaFrame Settings tab of the server in the Citrix Management Console (see Figure 8-1) or by using the command: change logon /disable. Also use the Citrix Management Console to verify that no users have existing sessions open on the MetaFrame server BEFORE installing applications. Once an application has been installed and configured, logins can be re-enabled.

click to expand
Figure 8-1: The MetaFrame Settings tab in the Citrix Management Console

Exam Watch 

Be sure to know that logons must be disabled and no users logged on prior to installing applications.

How Modes Affect the Installation

There are two different modes of application execution:

  1. Installation mode

  2. Execute mode

A server is normally always in execute mode, where %windir% points to an individual users' %homedrive%homepath%\windows (or %userprofile%\windows, if a home drive hasn't been defined). The install mode can be enabled either by using the Add/Remove Programs applet in the Control Panel, and choosing Install Application For Multiple Users, or by running the command, change user /install, at the DOS prompt (see Figure 8-2). The Install mode enables applications to be installed and configured so settings and INI files will be distributed on a per-user basis.

click to expand
Figure 8-2: Changing to installation mode via the command prompt

Before we define what each mode does, there are a number of system variables and abbreviations that have to be defined. These are listed in Table 8-1.

Table 8-1: Commonly Used Variables

Abbreviation or Variable

Description

%systemroot%

Operating system directory on system drive

%homedrive%

User's home drive

%homepath%

User's home folder off %homedrive%

%windir%

Pointer to functional Windows directory

%winsysdir%

%windir%\system32

%userprofile%

Location of user's profile while logged on, for example, c:\wtsrv\profiles\%username% (NT 4.0) or c:\documents and settings\%username% (Win2K)

%appinstalldisk%

Disk drive used for application installs by IM 2.0

%username%

User's login name

HKLM

HKEY_LOCAL_MACHINE

HKCU

HKEY_CURRENT_USER

Install mode does the following:

  1. Sets %windir% to %systemroot% instead of the execute mode default of %homedrive%%homepath\Windows.

  2. Registers any application INI files for later automatic distribution under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times.

  3. Links HKCU\Software with HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software.

  4. Tracks changes of HKLM in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Machine.

On The Job 

Even printer drivers and fonts should be installed in install mode, or they could be copied to the wrong location. Good evidence that install mode hasn't been used properly is the presence of DLLs and programs in the install user's home Windows directory or fonts installed to the home Windows\fonts directory.

Once users log on in execute mode, the application install tracking ensures that when a user now tries to run a correctly installed application the following actions occur:

  1. For install mode-installed applications that use INI files, if the INI file doesn't exist in the user's home Windows directory (%windir% in execute mode), it is copied there from %systemroot%. If the INI file in the home Windows directory exists but is older than the file in %systemroot%, it is renamed to inifilename.CTX and replaced with the newer file.

  2. For applications that store settings in the user's profile, when the application is run the first time, it creates application-specific registry entries under HKCU. If the newly-created registry key exists under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software, then the contents of the key are copied into the user's profile (HKCU\Software).

This way, any settings are automatically replicated to users when they first run a new application. When using Add/Remove Programs, never let an installation program reboot the system until Finish has been selected. This allows the system to finish its application tracking and safely record the changes. In Windows 2000 Server (Application Server), if you attempt to install an application any way except via the Add/Remove Programs applet in the Control Panel, the installation will fail unless you are in install mode.

Exam Watch 

The exam is sure to test your knowledge of install mode. Be sure you understand how to change modes.

Application Compatibility Scripts

Many applications require post-setup modifications to enable them to run properly for multiple users in a MetaFrame XP environment. These modifications can be made using application compatibility scripts, located under %systemroot%\Application Compatibility Scripts. There are three types of scripts, located in three directories (see Figure 8-3):

click to expand
Figure 8-3: The Application Compatibility Scripts directory located in %systemroot%

  • Install Makes any registry or other configuration changes necessary for the application to be multiuser after installation.

  • Logon Copies nonshareable files; also makes profiles or other user-specific changes needed for an application on login.

  • Uninstall Removes references to a script added using an install script.

In normal usage, install scripts are run once after the installation of an application, while logon scripts are run each time a user logs on by being called via the system login script: %systemroot%\system32\usrlogon.cmd.

Not all applications have compatibility scripts, although more are being made available either by Citrix (http://www.citrix.com/support) or Microsoft (see http://www.microsoft.com/windows2000/docs/W2kTSApCmpt.doc).

On The Job 

Application compatibility install scripts can be run automatically after an application is installed by using Citrix Installation Manager.

Now that you have a better understanding of how to install applications, here are some possible real-world issues and their solutions.

Scenario & Solutions

You have just installed an application and its icons and INI files only appear for the user that installed it.

It is possible that the application was not installed in install mode. Uninstall the app as that user, then reinstall it in install mode.

You are about to install an application that requires you do so from the command line. What is the easiest way to change into install mode?

Execute the command: change user /install

You are now finished installing the example application. How do you change back into execute mode?

Execute the command: change user /execute

Exercise 8-1: Installing Microsoft Word 2000

start example

In order to complete this lab, you must have a copy of Microsoft Office 2000 and the Microsoft MST for installing Office in a Terminal Services Environment. This MST file (a Windows Installed Template) is named TERMSRVR.MST and can be downloaded from Microsoft's Web site or is included with the Office resource kit.

  1. Log on to your MetaFrame XP server as Administrator.

  2. Access the Add/Remove Programs applet in the Control Panel.

  3. Choose the appropriate option to install a new application.

  4. Browse to the setup.exe on the root of the Office 2000 CD.

  5. Assuming your E:\ is the CD-ROM drive, the setup command line should look like this: E:\setup.exe

  6. Modify the preceding command line so it includes the path to the TERMSRVR.MST, making the command line look like this: E:\SETUP.EXE /Transforms=C:\temp\termsrvr.mst (This assumes you have downloaded the MST file to your C:\temp directory. If not, specify the correct path.)

  7. Install the components of MS Office you wish to use.

  8. Once the install is complete, do not reboot. Make sure to return to the Add/Remove Programs window and click Next, then Finish.

end example

Uninstalling Applications

Applications have to be uninstalled the same way they were installed. Logins should be disabled, and logged in users should be logged out BEFORE uninstalling an application. If any users are logged on and using the application, the executables and DLLs will be in use and will not be removed.

A manual uninstallation can then be completed either by using the Add/Remove Programs applet in the Control Panel or by implementing the Change User /Install command before running the application's uninstaller. Logins can then be re-enabled.

Exam Watch 

Applications installed using Installation Manager should never be uninstalled using either Add/Remove Programs or the application's uninstaller.

Citrix Installation Manager 2.0 Overview

Citrix Installation Manager 2.0 is an integral part of the MetaFrame XPe Enterprise solution. It is a sophisticated software deployment tool that can be used to automate the installation of applications, files, registry changes, hotfixes and service packs across a server farm or an enterprise (WAN-connected farms). The features of the Installation Manager include these:

  • An improved Packager that has a rollback capability

  • Deployment of multiple application packages

  • Comprehensive logging of the application deployment process

  • Scheduling of application deployment, including intelligent (no users logged on) and postponed timing

  • Installation of MSI packages, as well as ADF (application deployment files) packages

  • Installation of ADF packages from MetaFrame 1.8 Installation Management Services 1.0

  • Centralized management of deployment to individual servers and groups of servers (generally in zones) across an enterprise

Installation Manager 2.0 consists of three components: the Packager, an Installation Manager 2.0 plug-in for the Citrix Management Console, and the Installer. Implementation of Installation Manager 2.0 requires the following:

  • A workstation or server to host the Citrix Management Console

  • A valid MetaFrame XPe license for the farm (or an eval XPe license for each of the servers if in a pilot)

  • A network share point to accommodate the ADF and MSI deployment packages

  • MetaFrame Xpe servers participating in an Independent Management Architecture (IMA) farm

  • An application packager system

Exam Watch 

Be sure to know the three components of Citrix Installation Management Services.

The Packager

The Citrix Installation Manager 2.0 packager can be used to package one or more applications, application compatibility scripts, MSI packages, and files into a single project or package to be deployed to servers in the farm. Important packager usage considerations are

  • The installer system configuration has to be similar to the MetaFrame XPe systems that will get the deployment packages. This includes operating system, service packs, hotfixes, MetaFrame hotfixes, but not necessarily the same hardware.

  • Separate packages must be made for each version of the operating system on servers in the farm. Use separate partitions (or machines) for different operating system versions.

  • Many Microsoft applications require that Internet Explorer (at least version 4 SP2) is present, or the installation will fail.

  • The package requires a network mount point to store the packages. Create a directory for a new package before running the packager.

On The Job 

If you intend to use Installation Manager 2.0 to distribute Windows NT (4.0 or Windows 2000) service packs or hotfixes, the installer system hardware MUST be identical to the target systems.

Packager output is controlled by parameters in the packager initialization file: \Program Files\Citrix\IM\Packager\packager.ini. You can edit packager.ini to modify which objects and actions are included in the finished package or project.

One very important function of packager.ini is that it defines exclusions, files, directories, and registry changes that will NOT be recorded. These include *.tmp files, the TEMP directory and HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install. The latter exclusion means that default packager-deployed applications will not support propagation of user registry settings to other users unless you include appropriate application compatibility scripts in the package.

The packaging process starts with a new project that can consist of one or more recordings of application installations, upgrades, service packs, MSI packages, or hotfixes. An example in which multiple recordings would be of use is a database client application project, which could include the database client and the application that uses it. You can either start a new project, open an existing project, or launch the Project Wizard. (See Figure 8-4). A project can consist of seven sections:

click to expand
Figure 8-4: Citrix Packager Project Wizard

  • Project Entries Lists project inputs including installation recordings, compatibility scripts, file collections, and so on (modifiable)

  • Applications Applications installed as a result of the project entries (read-only)

  • Symbols Lists symbols used by the package installer (modifiable)

  • File System Changes File system changes resulting from the project entries (read-only)

  • Registry Changes Registry changes resulting from the project entries(read-only)

  • History Log Lists the actions taken on this project

  • Installation Sequence Optional section; only invoked when installation includes disabling and enabling services

If an application doesn't use the Windows installer (MSI package), then the usual way to build the package is to add a recording and specify the full path to the installation program. The normal setup or installation program is then executed. The recording logs all aspects of an application's installation. These include

  • Any changes made to the registry

  • Any changes made to INI files

  • The copying of any files like executables and dynamic link libraries (DLL)

While you have to let the installation complete before ending the recording, don't let the application reboot the packager system. Cancel the reboot and then end the recording by selecting Done. Stopping the reboot from occurring allows the Citrix Packager to complete its recording process. A reboot during the recording process will cause packaging to fail.

The recording allows the package deployment to behave almost exactly like the applications setup program. Any additional components and application compatibility scripts will need to be added to the package before it is built.

To add registry changes to a project, create a .reg file that makes appropriate registry changes and then execute the regfile while recording. This is extremely useful for setting application preferences stored in the registry but not available as options during the install. You can also use this feature to deploy standard registry changes, such as increasing the number of idle sessions, configuring the Second Level Data Cache, and tuning the user's desktop environment to reduce the amount of screen updates during a session.

Once the project is completed, the bottom window in the Citrix Packager utility allows you to view logs created during the packaging/project building operation. Three tabs in the window allow you to select what you would like to view. History, Build, and Post are your available logs.

When you build the package, the packager will copy any included files to the application's package share point directory-for example, \\FP01\ctxpkg$\project98-and then compile an installation script or ADF file (with WFS extension). The ADF file is a text file in the INI file format that can be edited if necessary to modify the installation conditions, such as the installation target directory. (See Figure 8-5.)

click to expand
Figure 8-5: Typical directory containing the Application Deployment File (ADF) Package

An example in which this could be necessary is when installing Office 97-based applications (such as Project 98 or Publisher 98) on to systems that were already running Office XP. Normal behavior of the Office XP setup looks like this: if an Office 97 product exists in \Microsoft Office\Office\, Office XP will install into \Microsoft Office\Office10\ to avoid overwriting essential Office 97 components. However, if we are doing the opposite, then a global search and replace of \Microsoft Office\Office\ for \Microsoft Office\Office8\ in the ADF file would be needed to keep the Office DLL versions separate.

If you edit the ADF file, it's a good idea to check the file syntax by running the ADFverfw utility against the ADF file.

The Rollback function in the packager lets you remove any application install changes and get the system back into a 'clean' condition for the next project.

On The Job 

If a project consists of several different recordings, you have to remove them, using rollback, in the reverse order they were recorded.

Exam Watch 

Make sure you know the Packager is NOT installed on a production system. Instead, it is installed on a system dedicated to packaging with an OS that matches the target servers.

The Installer

Software deployment on servers in a MetaFrame XPe farm is carried out by the Installation Manager Installer. The Installer needs to be loaded on every server in the farm and consists of three components:

  • The ADF Installer service Installs ADF packages and invokes the MSI installer as required

  • The MSI installer Installs MSI packages

  • Independent Management Architecture Sends and receives scheduling and configuration information to the ADF installer

The Installer service requires a user account to function. This account must have read access to the share point that the packages are stored in. It also must have rights to install applications on the MetaFrame servers in the farm. You can configure this account by right-clicking the Installation manager icon in the Citrix Management Console and selecting Properties. Once in the Configuration tab, select the Edit button to browse for the network account and supply the account's password (see Figure 8-6).

click to expand
Figure 8-6: Configuring the Network Account for Installation Manager

Deploying Applications to a Server Farm

Building the package creates the files necessary for the application to be installed on the MetaFrame servers. Using the Citrix Management Console's Installation Manager (IM) plug-in, you can add the package to the MetaFrame XP farm by right-clicking the Packages icon in the Installation Manager node and selecting Add Package. You will then browse to find the Package's script file (WFS extension) or a Microsoft Installer File (MSI extension). (See Figure 8-7.)

click to expand
Figure 8-7: Using the Citrix Management Console to browse for an MSI or ADF package

Once the package is added to the data store, you have the ability to install the package by right-clicking the package's icon in the Citrix Management Console and selecting Install Package. You will be prompted with two options. The first concerns which servers to install the package on. The list of available servers will only show MetaFrame servers with the IM Installer service installed. The second, and perhaps most important, is scheduling. The scheduler allows administrators to schedule package installation during off-peak hours, reducing downtime. (See Figure 8-8.)

click to expand
Figure 8-8: Scheduling an application package

Once the installation has been scheduled, you can monitor the status of that installation by selecting the application package in the Citrix Management Console and then viewing the jobs tab for that package. (See Figure 8-9.) The Jobs tab will show you all pending and completed installations, along with their status. Once the installation has completed successfully the application looks and functions like any application installed manually.

click to expand
Figure 8-9: The Jobs tab for the Installation Manager MSI Package

Removing Applications

When deciding how to remove an application from a MetaFrame server, you must consider how the application was installed. An application installed using the Citrix Installation Manager should not be removed using Add/Remove Programs. These applications should be uninstalled using the Installation Manager utilities. An application installed manually using Add/Remove Programs should be removed the way it was installed, using Add/Remove Programs.

Uninstalling an application that was installed using IM should be done through the Citrix Management Console. In the Installation Manager node, you should select the package's Installations tab. Here you will be presented with a list of every MetaFrame server that has installed the package. By right-clicking the proper server and selecting Uninstall Package, you will remove that program and all its associated files.

On The Job 

Just like with the application installations, you should ensure this is done during off hours, or during a period when no users have active sessions to the server.

To uninstall an application that was manually installed, you should remove it using the Add/Remove Programs applet in the Control Panel. If the application you are removing has an application compatibility script, you should determine if an uninstall compatibility script exists. If so, this script should be executed as well. If no uninstall script exists, then you must verify that all calls for logon compatibility scripts are removed from Usrlogn2.cmd in %systemroot%\system32 directory.

Now that you have a better understanding of Installation Manager, here are a few real-world issues and their solutions.

Scenario & Solutions

After installing several packages to your farm using the Citrix Installer, you find that you want to remove two of them from one of the servers. What is the easiest and most proper way to accomplish this?

Use the Citrix Installation Manager Plug-in in the Citrix Management Console to remove the packages from the target server.

You have a mix of different hardware on your network, but the same operating systems. Is it possible to deploy Windows Service Packs using Installation Management Services?

No. Your hardware should be exactly the same if you are deploying service packs.



 < Free Open Study > 



CCA Citrix MetaFrame XP for Windows Administrator Study Guide Exam 70-220
CCA Citrix MetaFrame XP for Windows Administrator Study Guide (Exam 70-220)
ISBN: 0072193190
EAN: 2147483647
Year: 2001
Pages: 169

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net