Hardware

An introduction to the ZENworks Application Launcher

The ZENworks Application Launcher is a mechanism for the automatic delivery, repair, and management of applications. Gerald Foster shows how it can help you install applications consistently and minimize the headache of application delivery.


In previous ZENworks Daily Drill Downs, we’ve introduced you to ZENworks and shown you how you can use it to distribute policies to your workstations. This Daily Drill Down is about managing applications with the ZENworks Application Launcher. This component of ZENworks allows you to put your effort into installing, configuring, and repackaging your applications and then automatically delivering them to your users rather than performing lots of tedious manual installations.

What is the ZENworks Application Launcher?
The delivery of applications to the Windows Desktop is one of the greatest headaches for IT managers. The users’ insatiable appetite for more and more applications and the struggle to deal with upgrades is an endless treadmill. Delivering, repairing, and upgrading applications by installing from a CD-ROM is not a scalable response to these demands.

What you need is a strategic response—a mechanism for the automatic delivery, repair, and management of these applications. This strategy, however, must fulfill the requirements of the user, maintain or improve system stability, and keep the need to visit workstations to a minimum.

When you install an application, you must be consistent. If you install applications manually on a number of different machines, chances are you won’t be consistent with every machine.

This is the road to chaos. Over time, every workstation in your organization winds up being different and behaving differently as a result. And when you chase down problems on individual workstations, you must take extra time to figure out each machine’s quirks before you can get to the problem.

When you install the application using Application Launcher, it will be installed consistently. That doesn’t imply that it will be installed correctly. You could still make a mistake somewhere along the way and configure a setting incorrectly. What it does mean is that the application is installed consistently across all workstations—right or wrong. And, if it is installed incorrectly, you may simply have to make one global correction to fix it.

The ZENworks Application Launcher is one of the most powerful features of ZENworks. It allows you to be strategic about delivering applications in a consistent way. There’s a lot to learn about Application Launcher, but it’s well worth your while to spend the time and effort to understand how it works.

How it works
Application Launcher has three main components:
  1. The Snapshot tool helps you understand what has occurred during the installation.
  2. The Application object in the NDS holds all the details about the application.
  3. The Workstation Agent runs on the client PC and displays the Application object to the user.

Application objects are displayed on the client Desktop as if they were normal shortcuts. The object has all the information about how to run the application, and about how to install and configure it. The obvious advantage is that when the "shortcut" is displayed to the user, the application can install itself before executing.

The Application object doesn’t install the application by running the install or setup program, but by copying files into the correct location, installing registry keys, and configuring INI files. The Snapshot tool captures these settings and then generates a file with the list of changes. Using these captured settings, the Snapshot tool then creates the Application object.

The Snapshot tool
When you install an application on a workstation, what happens? You don’t know? That’s not surprising. What an application installation program does to your workstation usually isn’t available in the documentation.

The Snapshot tool is your best friend for this purpose. It can capture which files have been added to the file system, which files have changed, and what changes have occurred in the registry. The snapshot process takes a “picture” of the system before and after the application's installation. It then compares the two pictures to find the differences. The differences are stored in a file, which can then be used to create an Application object.

Before using the Snapshot tool for the first time, you’ll have to decide where your install base is to be located. Your Application objects will contain installation information as well as execution information. If a user clicks an Application Launcher shortcut for the first time, where are the files to be copied from?

You may wish to make these files available from each server or from a designated server at each geographical location, but the files should be in a consistent location. Don’t copy the files across a slow network link, or your application launch times will be unacceptable. The install base location is referred to as the source path.

When you run the Snapshot tool, you are given several options about how you would like to run it:
  • Standard: Default settings are used.
  • Custom: Gives you the most flexibility when performing a snapshot and is the option I always use. The options can be saved and used in future snapshots with the Express option.
  • Express: Loads the default settings that you saved earlier from a custom session.

The Snapshot tool will prompt you for the application title and the install base, which are easy enough. It will also ask for the areas to search on the system, which will usually be the main hard disk. The areas in which to detect changes are files, INI files, text files, and the registry.

I always search all of these areas. Although this is the default option, you can eliminate certain areas, such as the system swap files. I store user-specific data in a specific directory in the user’s home file space. This file space can also be a useful area to snapshot so that changes are detected there also. After you’ve told it where to search, the Snapshot tool will proceed to scan.

When this scan is complete, you can run the application and configure it the way you wish it to appear for the user. When that is done, the snapshot is complete.

The main issue to understand here is how you want the components to be handled where the options are set to Copy Always and Create Always. If you wish the files or registry keys to be overwritten each time, then select Copy Always and Create Always. If you find this a bit confusing the first time, selecting the default will work fine. Accept the defaults for all the other prompts. The Snapshot tool will perform the after scan, then subtract the before scan from the after scan, leaving you with a series of files that represent the differences.

If you examine the source path directory, you will see a number of files with the following extensions:
  • .fil: These are duplicates of the files that were copied on to the workstation during the application installation. They are renamed to be 1.fil, 2.fil, etc., so that you can use a NetWare volume without the long namespace loaded.
  • .txt: There should be just one of these called filedef.txt. This is a list of all the files that were installed on to the workstation and what their corresponding .fil names are.
  • .aot: This is the Application object template file. This file contains a list of all the changes and can be used to create an Application object.
  • .axt: This is a text version of the .aot file.

The client agent
Application Launcher has two client options:
  • Application Launcher Window: This is a Program Manager-style window, which shows the Application object icons directly or within folders.
  • Application Explorer: This option integrates more seamlessly into the Windows 95/NT/2000-style Desktop.

Which option you use depends on your requirements and personal choice. Table A lists the available platforms and functionality of the clients.

Table A:
Option
Application Explorer
Application Launcher Window
Windows 3.x No Yes
Windows 95/98 Yes Yes
Windows NT/2000 Yes Yes
Standalone shell No Yes
Integrate into shell Yes No
Include local apps No Yes
Personal folders Yes Yes
Force run Yes Yes
Icons in a window Yes Yes
Icons in Start menu Yes No
Icons on Desktop Yes No
Icons in system tray Yes No
Available platforms and functionality

One of the crucial parts of both clients under Windows NT/2000 is the Application Launcher Service. This service performs system work on behalf of the users who may not (and should not) have the rights to perform the work themselves. The service runs as system, and when Application Launcher needs to write to certain parts of the file system or registry, the service performs this work. This means that you do not have to give away excessive rights to the file system so that the installation can actually occur.

The Application object
The Application object is the key to the whole launcher service. The object contains the details about how to install the application and how to execute it. For some applications, such as Microsoft Office, that’s a lot of information. The Application object is a big object containing numerous pages. I’ll cover the basics of each page here so that you’ll have some idea of what they’re for.

Identification page
This page exists to allow you to name the application and define what (if anything) is to be executed by it. The Application name is the name the user will see next to the icon. This can be quite distinct from the actual object name in the NDS. If you have an object called Netscape Communicator 4.75, the user can be shown the title Netscape Communicator.

The executable image to be run can also be specified here, although you can decide to set the program to install to the local workstation rather than executing. You can also decide to have the application run just once. This is useful if you have a patch or upgrade to apply to the workstation.

System Requirements page
The System Requirements page is designed to disallow the availability of software to inappropriate workstations. If you install a piece of software on Windows NT, it would be inappropriate to make it available on Windows 3.1. This variable is one area where many system administrators get stuck. You must have an operating system variable defined on this page, or the application will never be visible to anyone.

There are several areas where you can restrict the application. One useful area is disk space. If the application requires 100 MB of disk space to install, there’s little point in proceeding with the installation if there’s insufficient disk space available.

Environment page
This page is designed to allow you to define how the application is to run. You can define its command-line parameters and the location of the working directory. You can also run the application minimized or even hidden.

There’s also a very useful utility to allow the application to run as system under Windows NT. This function is essential if you wish to use the object to run the cacls command to grant NTFS permissions to the users.

Distribution page
This page allows you to define several functions, including a reboot of the workstation after the install. One of the most useful features of this page is that it shows you the object’s Global Unique Identifier (GUID). It’s very important to understand what this is for because it affects the way applications are distributed to the workstation.

Each Application object is given a unique GUID when it’s created. When the user runs the application for the first time, the GUID is stored on the workstation so that Application Launcher will know that it’s already installed and will not reinstall every time it’s run. There are times when you will require several Application objects to have the same GUID.

An example of this is Microsoft Office, which has a single install but more than one program to run. If you have two Application objects, one called Word and the other Excel, they should be exactly the same installation with only the Identification page differing. They should also have the same GUID so after a user runs Excel the first time, the install will not be performed again when the user runs Word. To make the GUIDs the same, select all the objects, then choose Tools | Application Launcher Tools | Sync Distribution GUIDs.

Folders page
Folders are great for organizing program icons into sensible groups. Under the Windows Start menu you can arrange folders, which are literally directories in the file system. With Application Launcher, it’s a bit different because you need to create a Folder object.

From NWAdmin, select Create Object | Folder Object. Name it whatever you wish (the users will not see this name), and the object is created. Create a folder off the root with a name that will be understandable to the users, and then create a folder structure underneath it. This is the structure that the users will see and is dynamically changeable through the object. You can insert Application objects into this structure via this object or via the Folders page in the Application object (where you would select Linked Folder).

Description page
The users can obtain a description of the application via the Application Launcher interface. You insert the descriptive text that will be visible to the user in this page. You could potentially put any information in here, such as hints and tips for the users.

Drives/Ports page
When you need to map drives or printers prior to the application execution, this is the place to do it. If you have an application on the network that’s used infrequently, it may be a good idea to place it on a single volume on one server rather than replicate it to multiple servers. You could employ a CD-ROM server to implement certain software on your workstations. If you need to do this, map the drive here and select the Clean Up Network Resources check box from the Environment page to disconnect the drive after the program has terminated.

Launch and Distribution Scripts pages
The distribution scripts run before or after Application Launcher distributes the application. The launch scripts run before and after the program runs. If you need some task to be performed before and/or after the program is launched, indicate this in the Launch Scripts page. If you need work to be done prior to the installation of the application, use the Distribution Scripts page.

Fault Tolerance page
Single points of failure are always an area of concern for network and system administrators. This is one problem that would be difficult to handle without the functionality contained in this page.

Here you can indicate which applications are to be shadowed for fault tolerance. The Application objects will require UNC paths to the correct server. In the event that one server fails, the Fault Tolerance page will fail the Application object to the backup server.

The page also allows you to use the server for load balancing. If you plan to use a backup server (which may never get used), you may as well put it to use by load balancing across both servers. If one server fails, the other will take the full load.

Contacts page
If you wish a certain person to be contacted for support of a particular piece of software, enter the contact details in this page, and the user will be able to look up the details from the client interface.

Associations page
This page is used to define which users or workstations are able to see and execute the application. You can add individual users or workstations as well as groups and containers. The page allows you to make the application available via the following:
  • Force run: When the user logs in, the application will automatically run. You can combine this with the Run Once option on the Identification page to force a program that must be run but only needs to run once (such as a patch).
  • App Launcher: Makes the program available in the Application Launcher window.
  • Start menu: Makes the application visible in the Start menu. If you use folders as well, the application will appear in the appropriate folder.
  • Desktop: Makes the application visible on the Desktop. This is probably useful for certain important programs, but using this option too often will give the Desktop a very cluttered appearance.
  • System tray: Makes the application visible in the system tray. Again, the system tray is a small area that will appear very messy if overused.

Administrator Notes page
This is a great place to make notes for yourself about how you installed the application and what changes you have made. When there are several administrators installing and supporting these applications, it’s particularly important to make notes so that the others will know what you have done.

Macros page
Macros, in the Application Launcher sense, are really variable substitutions. If you want to insert a string into a configuration file, the registry, or the command line, you can use a macro to insert the text during the application distribution or execution. A good example is the use of %LOGIN_NAME% to insert the user’s name into an e-mail configuration file.

Environment Variables page
If you need to set environment variables for the program to work correctly, do it here. You can insert delimiters into the variable as well, such as a semicolon for adding to the %PATH% environment variable.

Registry Settings page
This page allows you to make changes to the registry on the user’s workstation. For most purposes, the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER components are used for most settings. You can track the settings on a per-user basis, so that if a user opens an application on a workstation after another user, the HKEY_CURRENT_USER component will be distributed to the new user.

INI Settings page
If your application has INI files, they can be managed through this page. I generally use this page only when there are macros to be inserted into the file, as the distribution can be quite slow if you have very many macros. If you’re simply copying the file to all users and workstations, it may be better to just copy the file as is from the Application Files page.

Applications Files page
Clearly, there will be a need to distribute files during the application installation. This will always be a slow process, especially if there are many files. You can set the files to track per-user here as well. This option is useful if you have users sharing workstations and certain files are needed on the user’s home directory.

Text Files page
If you have text files that are not structured as INI files, you can manage these files from this page. This feature is really useful for managing BAT files and application configuration files, which are text files.

Schedule page
When you want the application visible only during certain hours, you can define these hours through this page. You should consider the Termination page as well if you plan to make use of this feature.

Icons/Shortcuts page
If you need icons or shortcuts created during distribution, you can do so through this page. I rarely create icons because I rely on Application Launcher itself to provide a link to the executable via the Application object. There are times when a simple shortcut is what is needed, and a good deal of flexibility is available here for providing standard or customized shortcuts.

File Rights page
If the application needs certain file rights on a NetWare volume, you can grant these rights dynamically via this page. This page is not intended to grant NTFS rights on a Windows NT or 2000 volume. Please note that the rights are not automatically revoked when the application terminates.

Termination page
If you plan to restrict the application to be visible only at certain times, then you should consider using this page to enforce that policy. The termination can be performed nicely (by asking the user to save, etc.), or it can be performed without any user interaction. The way this action is performed will clearly depend on the application and the reason for termination.

Application Site List page
You can easily handle the issue of slow network links in organizations and performance with NDS partition replication and the provision of local caches of files to be downloaded to the client. Problems can sometimes occur with users who travel between sites. When they log on to the network, they can inadvertently look up the wrong replica because of the placement of their User object in the tree. This can lead to exceedingly long validation times or validation errors.

You can resolve this problem by duplicating the Application objects and placing them in each of the local replicas. They are then tied together in a ring on this page so that when the user logs in at a different location, the Application object from the nearest replica is used.

Reporting page
Use this page to define reports on application usage and errors.

Pre-install page
This very useful page allows you to install all the workstation-oriented components of an application when the user is not present. The user can log out as usual, but the workstation needs to be left on. The application must be workstation-associated for this to work so that it will install itself at a convenient (after-hours) time.

Software Metering page
If you’ve installed the software-metering component of ZENworks, then this page will be visible to you. Here you can associate license certificates with the application so that the license terms can be met.

Caring for your NDS
Like all ZENworks objects, Application objects can affect NDS performance if their placement is not considered. Application objects can be associated with users and workstations. The best plan is to associate the applications with users and workstations in the same geographical location. If your NDS spans a network with slow links, it’s best to duplicate the Application objects at the end of the link. Place the applications as near as possible to the associated objects, and set the application inheritance level correctly.

Configuring Application Launcher
Before Application Launcher can work correctly, you must configure it. This task is performed at the container level, where you will find a page called Launcher Configuration. There are a host of settings here that are mostly cosmetic.

The one setting that must be set correctly is the Application Inheritance Level. To set this, you must make a change to the setting at the container that you use to associate the Application objects. If you have a container called Users that contains numerous users, you need to set the Application Inheritance Level to 1 in the Users container. If there are containers below Users, you should set it to the number of levels down from the Users container to the farthest leaf object.

Another area to look at is the Automatic Refresh. If your users never log out, then you should set the refresh to some value or they will never see the new application you’ve installed. If it is set to refresh too frequently, there may be performance problems on the workstation. If your users log in and out regularly, then it might be best to switch off the auto refresh.

Conclusion
As I’ve demonstrated in this Daily Drill Down, Application Launcher is one of the best and most powerful components of ZENworks. It will take a while to get to know it, but it’s definitely worth your time. This tool could save you many hours of boring manual installations and frustration. So set aside a week, close your door, and immerse yourself in it.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks