Deploying Applications - Citrix MetaFrame XP

One of the primary advantages of MetaFrame is the fact that you can significantly decrease your software deployment timeframe since you only need to install applications once on a server instead of dozens of times on client devices.

It's kind of ironic, really. One of the primary advantages of MetaFrame is the fact that you can significantly decrease your software deployment timeframe since you only need to install applications once on a server instead of dozens of times on client devices. However, as your MetaFrame environment grows, it quickly becomes apparent that you need a solution for your servers, because with a large environment you need to install applications onto dozens of servers. Even though installing applications on dozens of servers is less work then installing them on hundreds of workstations, it is still a significant task that can be automated.

Fortunately, MetaFrame XP servers are the perfect candidates for using automated software distribution tools to install and update your applications on multiple servers. Before examing the details and design components of these tools, let's look at how automated software distribution works in general.

An Overview of Automated Software Distribution

Automated software distribution is conceptually the same anywhere it is used, regardless of platform or tools. ZENWorks, SMS, Tivoli, Unicenter, IntelliMirror, and Citrix Installation Manager all work in exactly the same way.

Fundamentally, no software distribution tool has the ability to "push" software applications to target computers. These distribution tools simply evaluate a set of conditions on a target computer. If these conditions indicate that software should be deployed, the distribution tool causes the target computer to execute a command that launches the automatic software installation.

Software distribution environments are made up of three components. These components do not apply just to Citrix Installation Manager, but to all software distribution programs listed above.

  • Software Package. This is a collection of the files (the source installation files) that are to be installed on the target computer.
  • Installation Command. This is the command that is used to launch the installation of the software.
  • Software Distribution Agent. This term describes the program that decides whether the software should be deployed. If it should, it executes the installation command on the target computer.

For example, imagine that you wanted to install Notepad onto some computers. You would create a software package that contained your source files-notepad.exe in this case. Then, you would need to specify the command that should be used to install the software. In this case, that command would not be notepad.exe. To understand this, let's look at what happens on the target computer.

When the time came for the package to be installed, your software distribution agent would connect to the network location where your package was stored and run the installation command line. In this case, if you specified the installation executable as notepad.exe, when the software installation was scheduled to begin the Notepad application would be launched (because you specified notepad.exe). The user would be confused, wondering why Notepad opened all by itself. They would close it and continue working. In this case the software distribution program did exactly what you wanted it to-it connected to the network share and ran notepad.exe. In fact, the software distribution program would report that there was a successful installation, because notepad.exe ran and it exited successfully. In this scenario, the software distribution utility did its job. However, the administrator that configured it did not.

In order to successfully deploy Notepad with a software distribution utility, you need to create an installation procedure. In this simple case, that is probably most easily done with a batch file. Let's create a batch file called install.bat. The batch file can be made up of the following line:

copy \\networkserver\share\notepad.exe %systemroot%\system32\

As you can see, this "installation program" will copy notepad from the network share to the target computer's local hard drive. It's important to note here that the %systemroot% variable is used to specify the location on the target computer. That way, your program will work no matter how the target computer's drives are configured.

Once this installation program is complete, you need to update your software package. Your new package will contain two source files-notepad.exe and install.bat. You also need update your installation procedure. Instead of running notepad.exe, your package is now launched by running install.bat.

Now, when the software distribution agent needs to install your package, it will work whether or not a user is logged on, and it will not interrupt them while they're working. As you have seen, this improvement step had nothing to do with a bug in the software distribution utility. It had everything to do with the skill of the people creating the package.

Let's take a look at another example. Imagine that you want to deploy Microsoft Office XP to 100 computers. Ordinarily, you would go to each computer and execute setup.exe. That setup program would prompt you for several options, configurations, and information. When it had all the information it needed, the actual installation would begin.

When using automated software distribution utilities, this process is no different. If the software distribution utility decides that a computer needs to have an application installed, then the software distribution utility instructs the computer to run the application's installation program.

If you simply copied the contents of the Microsoft Office XP CD to a network share and then instructed the target computers to run the command setup.exe to install Office XP, each target computer would run the full GUI version of setup.exe. This GUI version requires user input along the way to enter the options, installation path, and CD key. Imagine what would happen in the real world if the executable for an Office XP distribution was setup.exe:

  • Some computers would have no one logged on, which would mean that the software distribution would fail, because Office XP's setup.exe requires a user to be logged onto the computer in interactive mode.
  • Other users would see the box pop up that said "Microsoft Office XP Setup." They would think to themselves, "Why is this happening? I didn't run this!" Then, they would immediately cancel the installation.
  • Still other users would continue through the installation. In these cases, each user would probably choose different options, meaning that the Office XP installation is different on each computer.

In the real world, if you want to deploy Microsoft Office XP to your MetaFrame XPe servers, you need to create a software installation package it.

In your package, you would specify the location of the source files and the command line needed to kickoff the installation. Instead of specifying "setup.exe" to launch the installation, it is possible to create a "silent" installation of Microsoft Office XP. This silent installation involves creating a configuration file that specifies all of the options that you want, and then running setup.exe with special command-line parameters that instruct it to read settings from the custom configuration file. This is done with the same methods used to specify "silent" installs of the ICA client software in Chapter 10.

To summarize, the important thing to remember when using any software distribution environment, including Citrix Installation Manager, is that you must first create the "silent" installation routine for your application before you can distribute it to any target computers (or target MetaFrame XPe servers in this case).

Automated Software Distribution Considerations

If you're thinking that using automated software distribution is too much work, consider this: Would you rather spend some upfront time building packages for and testing your applications, or would you rather install your application over and over and over until it was on all your servers.

The decision of whether to use automated software distribution can be a difficult one to make. Fundamentally, everyone wants to use automated software distribution because on the surface, it simplifies the management of software and software updates. However, in the real world, it's not always that easy. To help you decide whether or not you can use automated software distribution for your applications, ask yourself the following questions:

  • How difficult is it to package your applications?
  • How often are your applications updated?
  • How long do these updates take to deploy?

How difficult is it to package your applications?

For each application, consider whether it comes to you ready to go in Windows Installer package or whether you need to manually create the application package. If you have an MSI file, then your application package is ready to go without much effort on your part. However, if you must manually create an application package, you need to do some testing to figure out how long it will take you to create that package.

All too often in the real world people spend four days trying to create a software installation package that they could have manually deployed to all their servers in two days.

You can download a document called "Application Compatibility Guide: Citrix Installation Manager" from www.citrix.com/support. This document contains detailed instructions on how to package dozens of popular applications for deployment with Installation Manager to MetaFrame XP servers. It provides a great starting point when determining how difficult an application will be to deploy. If your application is not listed in that document, you can always post a question on the http://thethin.net forum.

How often are your applications updated?

If you have an application that will need to be updated frequently, then it may be worth your time to create an application package because once you figure out the tricks you should be able to package new versions of the application quickly. On the other hand, if your application is only updated every 18 months, then it might not be worth it.

How long do these updates take to deploy?

If the application updates only take ten minutes each and you have ten servers, then you can manually deploy all of your updates to all of the servers in less than two hours. Most likely, it will take you longer than that to create an application package. However, if you have 100 servers, it could take two full days to deploy all of the updates. If you can make an application package in one afternoon, then it's worth it.

Factors that May Lead to Automated Software Deployment

  • Many MetaFrame XP servers.
  • Frequent application updates.
  • Applications that are easy to package, such as MSI applications.
  • Good test lab environment.

Factors that May Prevent Automated Software Deployment

  • Small number of MetaFrame XP servers.
  • Infrequent application updates.
  • Complex applications that require significant effort to package.
  • No test lab environment.

What method of software deployment should you use?

If you decide that automated software deployment is right for your environment, there is no reason to use Citrix's Installation Manager. There are many other third-party software distribution tools to consider using instead of Citrix's tools, such as Microsoft Systems Management Server, Novell ZENworks, CA Unicenter, or Tivoli.

If you don't have these tools in your environment, then you should not introduce them for the sole purpose of deploying software applications to MetaFrame XP servers. However, if you have them already and they are being used on a daily basis, you can extend them to the MetaFrame XP environment without much additional effort and without the need to learn Citrix's Installation Manager or purchase MetaFrame XPe.

Advantages to Using Third Party Software Distribution Tools

  • They work with any version of MetaFrame XP, not just MetaFrame XPe.
  • You can use them for other, non-MetaFrame XP environments.
  • You don't have to learn any new packager tools or software distribution tools.
  • Their single purpose is to distribute software, so they are much more robust than Citrix Installation Manager.

Disadvantages to Using Third Party Software Distribution Tools

  • They do not integrate as tightly with MetaFrame XP.
  • They require that you have the expertise and support structures in place.
  • They cost more than Installation Manager, which is built into MetaFrame XPe.

Citrix Installation Manager Overview

One of the advanced components of MetaFrame XPe that's not available with XPs or XPa is the Citrix Installation Manager (IM). IM is Citrix's automated software distribution tool that is fully integrated into the CMC and the MetaFrame XP environment. Installation Manager fundamentally works in the same fashion as any software deployment application, such as Novell's ZENWorks or Microsoft's Systems Management Server.

Before we take an in-depth look at how you can begin using Installation Manager, let's provide a real-world overview. We'll cover the components that comprise an Installation Manager environment and some of the actions that must be taken to use it.

Installation Manager Components

Installation Manager for MetaFrame XPe is made up of several core components:

  • Application Packages.
  • The Citrix Packager.
  • Packager Machine.
  • Network Share.
  • Citrix Installer Service.
  • Installation Manager plug-in for the Citrix Management Console.

Component 1. Application Package

An Installation Manager application package is a collection of source files and the scripted installation procedure needed to install a software application onto a MetaFrame XPe server. Every application or software update needs to be "packaged" in order to be installed to a MetaFrame XPe server with Installation Manager. In the real world, you will end up having dozens of application packages in your MetaFrame XPe environment.

Component 2. The Citrix Packager

The Citrix Packager is the stand-alone utility that you use to create certain types of application packages for applications that are to be deployed to MetaFrame XPe servers. As you will see later in this chapter, the Citrix Packager is only one of the many options you have for creating application packages.

Component 3. Packager Test Server

In order to create your application packages, you need a test server. This server is usually a non-production server that is dedicated to the use of the Citrix Packager. Ideally, the format and layout of this server will mimic your production servers.

Component 4. Network Share

Once a package is created, it is stored on one or more network shares. From here, target MetaFrame XPe servers can download and install the package.

Component 5. Citrix Installer Service

The Citrix Installer Service is installed on the target MetaFrame XPe servers that receive packages deployed with Installation Manager. This service is comprised of two parts: the installer subsystem and installer service. The installer subsystem manages packages and schedules installations, while the installer service runs on each server and physically installs the packages. The Citrix Installer Service must be installed on every machine that will have software applications installed via Installation Manager packages.

Component 6. Installation Manager Snap-in for the CMC

In order to manage and configure Citrix Installation Manager, components are added to the Citrix Management Console. These components extend the functionality of the CMC by allowing you to view the status of packages and installation jobs.

How Citrix Installation Manager Works

The six components of Citrix Installation Manager work together to allow applications to be deployed to MetaFrame XPe servers. That deployment process can be summarized in four steps:

  1. Packages are obtained or created.
  2. Packages are added to the Installation Manager database.
  3. Jobs are scheduled.
  4. Applications are published.

Step 1. Packages are obtained or created.

The first step to deploying software to MetaFrame XPe servers is obtaining or creating application packages. Applications that use the Windows Installer installation method (that have .msi files) are ready for Installation Manager without any other administrative work. In these cases, the software vendor has already created the application package for you. (See Chapter 10 for more information about the Windows Installer.)

For applications whose installation routines were not built with the Windows Installer, you will need to create a package using the Citrix Packager and the Packager test server.

Step 2. Packages are added to the Installation Manager database.

After application packages are created, they must be added to the Installation Manager database, which is part of the IMA data store. By adding packages to the database, the packages are made available to MetaFrame XPe servers. Adding packages to the database is usually as simple as copying the contents of the package to a network share or shares that are available to all the MetaFrame XPe servers, and then using the CMC to add information about the package, such as its name, network location, and intended platform.

Step 3. Jobs are scheduled.

After the package is added to the Installation Manager database, it needs to be installed onto the target MetaFrame XPe servers. Each software installation is known to Installation Manager as a "job." Installation jobs can be designed to run immediately or they can be scheduled to happen during off-peak hours. For each job that is executed on a target MetaFrame XP server, the package's installation script is "played back" and the needed package files are copied from the network share.

Step 4. Applications are published.

After the application is installed on a target MetaFrame XPe server, the application must be published. This process is identical to traditional methods of deploying applications, in which after they are installed they must be published to be load-balanced across multiple servers. In most cases, publishing applications simply involves adding the new target MetaFrame XPe server to the published application's list of configured servers.

Understanding Installation Manager Components

Now that we've reviewed the high-level Installation Manager components and the software installation process, let's take an in-depth look at each of the components.

Component 1. Application Packages

An Installation Manager Application Package consists of the complete scripted installation procedure and the source files needed to perform a software installation. An application package can be created for anything, from a service pack update to a full installation of an application to a hotfix. Basically, if you can script it, it can become an application package.

Application packages exist because the MetaFrame XPe servers to which you want to deploy software must have the instructions for procedure to follow to install the new software.

MetaFrame XPe's Installation Manager recognizes two different types of packages:

  • Windows Installer Packages (.msi)
  • Application Deployment Files (.adf)

Windows Installer Packages

Windows Installer packagers are regular application packages that have been created with the Windows Installer utility. The scripted installation procedures for these packages are located in files with the .msi extension. These .MSI files contain the information and instructions needed to install applications.

If the software application that you want to install with Installation Manager has an .MSI file, then the application package is already created. Every new piece of Microsoft Software and many other vendors' software products use the Windows Installer. You can import the .MSI package directly into Installation Manager. In fact, if you're using Feature Release 2, Installation Manager will even detect new .MSI files placed in designated network shares and add the packages to the installation environment automatically.

Windows Installer packages are still launched via some type of command such as setup.exe. However, that setup executable is a small stub program that launches the Windows Installer. Take a look at a Windows Installer application (such as Office 2000). You will see that there is an .MSI file in the root directory representing the instructions for the package.

Ordinarily, you wouldn't create a Windows Installer package yourself. You usually take the .MSI packages created by the software vendor and bring them directly into your Installation Manager environment so that you can begin deploying the software to your MetaFrame XP servers.

ADF Packages

Not all software vendors choose to use the Windows Installer for their applications. (Okay, most software vendors choose not to use the Windows Installer.) As outlined previously, in order to deploy any applications to MetaFrame XPe servers with Installation Manager, they must be packaged. To package non-MSI applications, Citrix includes a utility with Installation Manager called "The Citrix Packager."

The Citrix Packager creates ADF packages. Each ADF package is composed of two components:

  • The collection of files that are to be copied and installed to the target MetaFrame XP servers. This is known as the ADF package itself. Like any software package, the ADF package is the collection of the application's source files. These can be on a CD or a network share.
  • The ADF software installation script. The ADF script is a file with the extension .wfs. This file is a text file created by the Citrix Packager. It is the actual script played back on the target machine that copies files and modifies registry keys.

The ADF script file is named with the application to be installed, based on the project in the Citrix Packager.

Component 2. The Citrix Packager

The Citrix Packager is a stand-alone utility that watches how applications are installed on test servers and then creates ADF packages that can be used to deploy the applications to target MetaFrame XPe servers. It monitors applications as they are installed and records any registry keys or .INI files that are added, modified, or deleted. It also creates a list of any files that were added.

From this information, the Citrix Packager gathers all of the new files together into a package. It then creates an ADF installation script that can be used to play back the installation on future servers.

Using the Citrix Packager, you can create projects for each software application that you want to deploy. A Citrix Packager project stores all sorts of information about the environment, changes, setups, and additions, as well as your settings for how the scripts play back on target MetaFrame XPe servers.

By creating a different project for each software application, you can easily modify pieces of the installation without having to build a new package from scratch. Even after a project's ADF has been entered into the CMC and deployed, you can still work with the packager and modify the project. For example, you can add outside files to the package. Many people use this when a new version of a file is available, when a new hotfix is released.

When your project is configured as you want it, the Citrix Packager allows you to "build" the project. This build process creates the actual ADF script file.

Everything that a software application does as it's being installed on your test MetaFrame XPe server while the Citrix Packager is running is logged. This allows you to use the packager's "rollback" feature, which essentially removes everything that your application installation did on the test server. You can use this to quickly test new changes without having to rebuild a new MetaFrame XPe test server after each installation.

Component 3. Packager Test Server

The Citrix Packager software should be installed on a dedicated MetaFrame XPe test server, informally known as the "Packager Test Server." This is the server that you will use to create ADF packages for non-MSI applications that you would like to deploy to MetaFrame XPe servers. This server should be identical to your production servers, both in terms of software and hardware.

In the real world, some people laugh when they hear that they should have a test server that is the same as their production servers. "You don't know what it's like around here!" they say. However, getting a new dedicated test server from your boss might be easier than you think. Remember that if the test server is identical to your production servers, its hardware components can be instantly swapped with a failed component in a production server. Also, because Installation Manager is only used in larger environments, you might be able to get several departments to chip in together to pay for a test server.

At a minimum, the packager test server must have the same software configuration as your production MetaFrame XPe servers. For example, if you have applications installed on your packager test server that are not installed on your MetaFrame XPe target servers, you could have problems when the packaged applications are run on the target servers. TMost software applications' installation programs will not install required shared files, like DLLs, if a current version already exists on the computer where the installation is taking place.

If you have applications already installed on your packager test server, the script for the application installation routine that you are recording may not contain information on some of the DLLs that are required since they already exist on the packager test server (causing the installation routine not to install them). If this occurs, the installation script doesn't realize that a required DLL was skipped and the required DLL is not written into the script.

Then, when the application package's script is played back on target machines, the DLL would not be copied given that it was not in the script. Even though your script was successful, the application would fail due to the missing DLL.

Because of this, your package test server should have the same software configuration as your production servers. This includes the MetaFrame XP installation and configuration as well as any published applications or other utilities.

If you have MetaFrame XPe installed on multiple platforms in your environment, you should have two test servers or (worst case) one test server with two hard drives that you can swap-one for each operating system.

An Overview of DLL Versioning

Something that you need to be aware of when using the Citrix Packager on a test server is that the Citrix Packager is not aware of "DLL Versioning," unlike some other software packaging utilities (such as the Windows Installer).

DLL versioning is what allows an installation routine to be created on one computer for a program to be installed on another computer where the numbers and versions of DLLs could be different.

A DLL file is just a chunk of programming code. The reason developers put some code in a separate DLL file instead of the main EXE is because the code in a DLL file can be easily shared by several programs. For example, in Windows, all of the code that provides shared functionality is maintained in DLL files. This includes instructions for how to draw the menus, scroll bars and buttons, as well as code for interacting with the desktop and other programs.

All DLLs have version numbers, just like any program. Higher version numbers are used for newer versions of a DLL. Newer DLLs usually have new features while also including all of the functionality of previous versions.

The version numbers of DLLs play a big role in the software installation process. For example, if a software installation program knows that its application needs a file called resources.dll version 3.0, and it finds resources.dll version 1.0 on the computer already, it will update that DLL to version 3.0. Whichever program originally needed version 1.0 should still be able to use version 3.0. That program will just access the 1.0-level features of the DLL. If the new software application that needed resources.dll version 3.0 is uninstalled, its uninstallation program will leave version 3.0 of the DLL on the computer, because version 1.0 was there before it was installed.

However, this situation can become more complicated. If the new software application that needs the resources.dll version 3.0 sees that there is already a version 3.0 of that DLL installed on the computer, it will not copy over it. This can cause a problem if the original program that needed version 3.0 of the DLL were ever removed, because its uninstallation program would remove the DLL. Then, the new program that was installed wouldn't work, because resources.dll version 3.0 would not be available.

To combat this, the Windows operating system tracks the number of times a DLL file is installed. For example, if a software application needs resources.dll version 3.0 and it is not available on the computer, the installation program will install it. That DLL will have its installation counter set to 1. If another software application also needs resources.dll version 3.0, it will not be installed because it's already there. However, the DLL's installation counter will be incremented because the new program wanted to install that DLL. This would mean the resources.dll's installation counter would be set to 2, indicating that 2 programs use that DLL.

If the first program is removed, when it tries to uninstall the DLL it will notice that the DLL's installation counter is greater than 1 so it will not remove the DLL. However, it will decrement the installation counter. If any program's uninstallation routine ever tries to remove a DLL whose installation counter is already set to 1, then the DLL will be deleted because no other programs need to use it.

It is important to understand DLL versioning and installation counters because the Citrix Packager is not aware of any of them. This is why it is crucial that your packager test server has the same software configuration as your production servers.

Component 4. Network Share

To be able to use MetaFrame XPe's Installation Manager, you will need to identify at least one network share that can be used to hold all of your packages before they are deployed to the MetaFrame XPe target servers. This network share must be a Microsoft share that supports UNC naming conventions. All target servers receiving packages must be able to access a network share that you identify. This means that the account you configure for installation must have at least "Read" permissions to the shares.

Each network share must have enough free space to hold the applications package that you store on it. Each package will be the size of the installed application plus a bit of overhead for the installation script. It's important to note that the application size will be the size of the installed application, not the source files. Installation Manager does not compress application packages.

Component 5. Citrix Installer Service

The Citrix Installer Service runs in the background on MetaFrame XPe servers that are to receive applications deployed with Installation Manager.

When application installations are scheduled, this service plays back the installation scripts for the ADF or MSI packages. When this playback occurs, no user intervention is required.

The Citrix Installer Service is always running on MetaFrame XPe servers with Installation Manager enabled. However, it requires very little memory when not in use.

Component 6. Installation Manager Plug-in for the CMC

When Installation Manager is installed on a MetaFrame XPe server, the Citrix Management Console is extended to provide the administrative functionality of Installation Manager.

The setup routine is able to extend the functionality of the CMC by installing a Java plug-in contained in the imsmgr.jar Java package. This plug-in is copied to the \Program Files\Citrix\Administration\Plugins\ folder. If you see a generic folder called IM_FOLDER in your CMC, that means that your IMA data store contains Installation Manager information, but that the CMC console you are using has not had the Installation Manager plug-in installed. The simplest way to install this plug-in is to use the Installation Manager setup program from the CD.

This plug-in needs to be installed on each computer that runs the CMC where you want to manage Installation Manager. Obviously, the plug-in is automatically installed on the MetaFrame XPe servers where you install Installation Manager. But, if you have the CMC installed elsewhere, such as on your workstation, you will need to manually install the plug-in.

The Installation Manager CMC plug-in allows you obtain an ADF or MSI package from the network, add it to the Installation Manager database and schedule it for installation to servers. It also allows you to view the status of pending and previous Installation Manager jobs.

Using Installation Manager in the Real World

Remember the four steps to deploying applications with Installation Manager that we addressed previously?

  1. Packages are obtained or created.
  2. Packages are added to the Installation Manager database.
  3. Jobs are scheduled.
  4. Applications are published.

Now that we've taken a detailed look at all of the components that make up an Installation Manager environment, the four steps can be used as a high-level framework to build a detailed flowchart covering all of the steps, sub-steps, and decisions that need to be made when installing an application with Installation Manager to MetaFrame XPe servers. As you read through the steps, you can refer to the process outlined in Figure 12.1 (facing page).

Figure 12.1: The Installation Manager application distribution process

Step 1. Creating Packages

The first step is to create the application package. Remember, Installation Manager for MetaFrame XPe supports two types of application packages: Windows Installer packages and Citrix ADF packages. Let's take a look at the details of each type.

Option 1. Microsoft Installer Packages

Before an application built with the Windows Installer can be used by MetaFrame XPe's Installation Manager, the package must be prepared. Microsoft calls the preparation of an MSI package an "administrative" installation. To perform an administrative installation, execute the following command:

msiexec /a e:\path\packagename.msi

In this example, e:\path\ is the full drive letter and path to the existing installation package and packagename.msi is the name of the Windows installer file. This file will always have the extension .msi. Its name will usually be somewhat related to the package, such as visio.msi, but sometimes it is not, such as install.msi. Also, the MSI packages are not very large. For example, Office XP's MSI file is only about 3.4MB. That is because the MSI files must only contain the instructions (or the installation playback scripts) for installing applications. Often times they do not contain the actual files themselves. MSI installation files are very similar to the Citrix ADF files generated by the Citrix Installer, which have the file extension .wfs.

When the msiexec command is executed, the Microsoft Installer will perform an administrative install of the application. (Hence the "/a" command line option.) This administrative install does not actually install the application locally. Instead, it prepares the application to be installed from a network location by decompressing any CAB files and making sure that everything is in order.

When you execute the msiexec command, the standard graphical application installation dialog will begin. Your only option will be to enter a location for the installation. This should be the network location where your package will sit before it is pushed out to MetaFrame XPe servers. Remember, this graphical setup program does not install the application locally.

Advantages of Using Microsoft Installer Packages

  • No additional configuration is needed to use them with Installation Manager.
  • High success rates because the application's native installation routine is used.

Disadvantages of Using Microsoft Installer Packages

  • Not all applications are built with the Microsoft Installer.
  • Okay, most applications are not built with the Microsoft Installer.

Option 2. Citrix Packager

If the application that you want to deploy does not have an MSI file, you will have to package it with the Citrix Packager.

  • Packaging applications for automated deployment is more of an art than a science. In fact, there are entire books dedicated to this single topic. (Check out The SMS Installer by Rod Trent.) While it's not practical to discuss every possible scenario that you might run into when packaging an application, there are several tips and techniques that real world administrators use:
  • The package server where the Citrix Packager is loaded should be identical to the target MetaFrame XPe servers, in terms of software configuration and applications that are installed.
  • Application Packages should not be packaged through ICA sessions.
  • You should incorporate some sort of structured naming convention for your packages. This will help you identify packages that need to be updated months after they were created.
  • When you record your installation, it is important that there are no unnecessary programs running in the background. If there are, anything that they do will become part of the recording and will be played back on all of your target servers.
  • If you are using Feature Release 1 or 2, you will have a "Project Wizard" option that will walk you through creating an application package with the Citrix Installer.
  • If the software application that you want to package has a silent install option, you should use the "add unattended install" option of the Citrix Packager instead of recording it yourself. After all, you never can tell exactly what the programmer intended to do with the installation routine. By using the silent install, you are effectively using their installation routine instead of creating your own.
  • Become familiar with InstallShield. As discussed in Chapter 10, InstallShield is a program that application developers use to create the installation routines for their software applications. InstallShield is similar to the Windows Installer. While Installation Manager cannot support InstallShield applications directly, the Citrix Packager can support their silent installs. Even if it's not mentioned in the software application's product documentation, every single application whose installation routine is built with InstallShield can be installed in a silent mode. You can learn more about InstallShield, and how to use it from www.installshield.com. One of the great things about this is that you can purchase the InstallShield product manual for about US$60. That manual gives you all the information that you need to create silent installs for any commercial applications that use InstallShield. This will put you in a very good position, because about 95% of all commercial applications have installation routines that are built with either the Windows Installer or InstallShield.
  • Get to know the application packaging resources that are available. One of the best websites for information about application packaging is www.myITforum.com run by Rob Trent.

Advantages of Citrix Installer ADF Packages

  • Allows non-MSI applications to be deployed via Installation Manager.

Disadvantages of Citrix Installer ADF Packages

  • Creating the packages requires skill.
  • Packages that are not created properly can break target servers.
  • The Citrix Packager requires a dedicated test server.

Step 2. Adding Packages to Installation Manager

Once you've identified, created and/or prepared your application package, you need to let Installation Manager know that it exists. In order to do this, you tell Installation Manager which user account it should use to find and install the package and where on the network the package is located.

In order for Installation Manager to be able to access your package on the network, you need to specify which user account you would like Installation Manager to use when working with the package (CMC | Citrix Installation Manager | Properties | Network Account). This user account needs to have "Read" access rights to the package source files on the network and administrative rights on each MetaFrame XPe target server where the package will be installed. In the real world, most people create a dedicated service account in the domain, called something like "IMS_Service" that they use exclusively use for Installation Manager. By creating a dedicated account, you can give it only the security rights that it needs to perform Installation Manager functions, without giving it full Domain Admin rights.

Once you specify which account is to be used, you need to add the package to the IMA data store by telling Installation Manager where your package is located on the network (CMC | Installation Manager | Add Package, or with FR-2, CMC | Installation Manager | Packages | Add Package). If this network location is not the original location of the application package that you have created, then you should copy the package to its permanent location before adding it to the IMA data store. As soon as this step is complete, the application package will be primed and ready to be installed to target MetaFrame XPe servers.

If you're using Feature Release 2, you can create "Package Groups." By using package groups, you can create a folder structure in the CMC that helps your organize your packages. Also, each package group can contain its own network account and file share location, allowing you to segment packages in large environments.

Do not confuse FR-2's Package Groups with FR-1's Package Groups. While FR-1 does allow you to create Package Groups, they are nothing more than folders for sorting your packages. For "true" package groups, including the ability to store a package on multiple network share points, you need FR-2.

Creating Packages in WAN Environments

You should not use Installation Manager to deploy packages to MetaFrame XPe servers across slow WAN links. If you do this, you not only risk saturating the WAN, but you could also render your target server unavailable as the package is accessed across the WAN.

Figure 12.2: Installation Manager in a WAN environment

If you choose to use Installation Manager with multiple instances of one application, then you should develop a naming convention or implement package groups for your packages that indicate not only the application, but also the location where it is to be deployed. Sample package names include the following:

  • IE Security Update - All
  • MS Office SP-2 - North
  • MS Office SP-2 - Corporate
  • Sales Tracker - North
  • Sales Tracker - Corporate

  

Figure 12.3: Proper use of Installation Manager in a WAN environment

Advantages of Creating Multiple Instances of One Package

  • In large environments, the package can be deployed faster.
  • Efficient use of WAN bandwidth.
  • With FR-2, you can create multiple package groups. Each group can contain the same packages with different package source network shares.

Disadvantages of Creating Multiple Instances of One Package

  • More network storage space required.
  • Each instance of the package must be manually added to the IMA data store.
  • Prior to FR-2, each instance of the package must have its own unique name.

Step 3. Job Scheduling and Package Installation

Once an application has been copied to the network share locations and added to the IMA data store, the package must be installed to the target MetaFrame XPe servers. This is done by creating a package installation job. There are two different ways a job can be created:

  • Use the CMC to create an installation job.
  • Use the CMC to publish a package to a server where it is not installed.

Creating Installation Jobs for Servers

If you use the CMC to create an installation job (CMC | Installation Manager | Right Click on Package | Install Package), you can create a job that will install an application package to a server or a server group. This job can be set to run immediately or it can be scheduled so that the package is installed at some point in the future.

When a package installation job begins, all existing ICA connections are terminated. If necessary, you can configure the job not to begin until all of the ICA connections are closed. If you are using Feature Release 1 or 2, you can create a customized message that is sent to current users when a job is scheduled to run, notifying them of their impending session termination.

Whenever a job is finished, you should delete it to save space in the data store and keep your job list from becoming cluttered. If you create the job manually, you can specify the number of days before the job expires and is automatically removed from the job list, anywhere from "never" to 90 days.

If you are using Feature Release 2, you can filter your MetaFrame XPe servers by platform or by Installation Manager server group when you are creating a job. Without Feature Release 2, you will have to do this manually. Also, with Feature Release 2, you can specify in the job options that the target MetaFrame XPe servers should automatically reboot after the package has been installed. Without Feature Release 2, you will have to add the server reboot into your installation script.

Advantages of Creating Installation Jobs for Servers

  • Application installations can be scheduled for off-peak hours.
  • You can specify granular job options.

Disadvantages of Creating Installation Jobs for Servers

  • Applications must be manually published after they are installed.

Publishing Uninstalled Packages

Alternately, you can use the CMC to publish an uninstalled Installation Manager package to a target MetaFrame XPe server (CMC | Applications | Publish Application | Choose Installation Manager Package). When publishing an Installation Manager package with the CMC, all packages will be in the drop down list, regardless of whether or not a package has been deployed to any servers. This allows you to configure an application package for any MetaFrame XPe server, and if the application is published to a server where it has not been installed, the installation will start immediately after the application is published.

For farms containing more than 20 servers, you should not use this "single step" publish and install option to publish uninstalled application packages. This method will cause the application installation to start as soon as the application is published, and with more than 20 servers, your systems and networks will become overwhelmed.

If you need to deploy an application to more than 20 servers, then you should first deploy the application to the MetaFrame XPe servers by creating several smaller installation jobs, and then publish the application with the Citrix Management Console.

Advantages of Publishing Uninstalled Packages

  • Application installation, publication, and load management are combined into one step.

Disadvantages of Publishing Uninstalled Packages

  • The application installation job is launched immediately.

Regardless of the package installation method used, the following process shows how the various Installation Management components work together to install an application package to a target MetaFrame XP server:

Figure 12.4: Installation Manager's Package Installation Process

  1. The installation job is initiated, either because the scheduled date and time has arrived or because the administrator has manually started it.
  2. The installer service on the target MetaFrame XP server connects to the package source file share.
  3. The installation package and script are copied to the MetaFrame XP server, then executed.
  4. The status of the package is changed to "installed."

Segmenting Target Servers into Server Groups

When using Installation Manager, you can choose to use MetaFrame XP server groups to deploy packages to more than one server at a time. To do this, combine multiple servers into logical groups, giving each group a name. Then, create application installation jobs that deploy packages to the entire group instead of to just one server.

The server groups that you create for Installation Manager are logical groups used only for Installation Manager application deployments. Group membership has no bearing on anything outside of Installation Manager. A MetaFrame XPe server can belong to more than one server group.

Because server groups only affect deployment, changing a server's group membership after an application has been installed will not cause application packages to be installed or removed.

Use common sense when creating your server groups. It is probably not a good idea to create a group of 50 MetaFrame XPe servers. When a package is deployed to a single server group, a network connection is still opened between the package share and each MetaFrame XPe server. A package deployed to a group of 50 servers will cause 50 servers to try to download the package from the same share at the same time. Also, because all 50 servers would probably finish the application installation at about the same time, they would all reboot at about the same time, which means that they would all be downloading their IMA data at the same time.

Most people create server groups based on WAN locations, business units, or the application sets that different servers need. A server can belong to multiple groups, but it doesn't have to belong to any group.

Advantages of Using Server Groups

  • Packages can easily be deployed to multiple servers.
  • Multiple servers can maintain identical application sets.

Disadvantages of Using Server Groups

  • Server groups do not affect security.
  • Each group member server must obtain its own copy of the package from the package share.
  • Groups affect package deployment only.
  • Moving a server to a new group does not cause that server to receive new applications.

Viewing Package Installation Status

You can use the CMC (CMC | Installation Manager | Summary with FR-2, or CMC | Installation Manager without FR-2) to view the status of packages and installation jobs.

The applications tab shows you details about each package that has been added to the IMA data store, including its name and the executable used to launch it.

The "jobs" tab shows you details about each scheduled job, including the job name, the package it installs, its scheduled installation time, and the current status. Be careful when reading the status of a job, because it changes to "success" as soon as the job is successfully started. Installation Manager does not verify whether a job actually finishes.

Step 4. Application Publishing

If you manually created an installation job, the last thing to do is publish the application. Once the application has been deployed to all of your target MetaFrame XP servers, you can publish it just like any other application. If you chose to create the installation job by publishing the application directly, then the application will be ready to go and you can skip this step.

 

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close