Tips on Using the ZENworks Application Management Tool Kit
Articles and Tips: article
Consulting Branch Manager
Novell Consulting
01 Sep 1999
Thanks to Matt Brooks, Troy Wilde, Randy Cook, and Erik Bock of Novell for their assistance in preparing this document.
Read about a whole slew of handy utilities that are available free of charge to help you better manage the application distribution aspects of ZENworks.
Introduction
The ZENworks Application Management Tool Kit contains a number of useful utilities to help administrators create, edit, and distribute Application objects for use with ZENworks' application management features. Created by Novell Consulting, the utilities in the ZENworks Tool Kit can be used to simplify tasks ranging from updating files in an AOT template to duplicating Application objects from one container into another.
This AppNote offers a quick reference for the utilities included in the ZENworks Tool Kit, along with several sample usage scenarios to help you see how these utilities can assist you in the Application object creation and distribution phases of using ZENworks.
The ZENworks Tool Kit is currently available for download from the ZENworks Cool Solutions Web site at:
http://www.novell.com/coolsolutions/zenworks/downloadables.html
These ZENworks tools have been created in response to customer feedback and provide solutions for real-world problems faced by ZENworks users. They are provided free of charge, but are not supported by Novell or Novell Consulting. Use these tools at your own risk.
Overview of the ZENworks Tool Kit
The creation, management, and enhancement of the enterprise computing environment remains a top priority and concern for today's managers. As more users are added and applications are updated, the management of these items becomes more time consuming and expensive. Given the dynamics and complexities of today's enterprise applications, workstations connected to the network must be stable and secure, while providing robust network applications and client functionality to users.
The solution to many desktop management headaches is Novell's ZENworks, an advanced, dynamic desktop management tool that builds on the industry- leading enterprise functionality of Novell Directory Services (NDS). As the development of ZENworks has progressed, customers have asked for various enhancements to make the product even more useful. In response, Novell Consulting has created the ZENworks Tool Kit to maximize performance, enhance security, and extend integration with needed enterprise components.
Currently, the utilities in the Tool Kit work with ZENworks 1.1 and earlier. It is particularly important to verify the version of NWAPP32.DLL you are using. If you use NWAPP32.DLL version 2.7, you can create Application objects from AOTs in a ZENworks 1.1 environment only, not1.01 or 1.0. If you have NWAPP32.DLL version 2.5, you can create Application objects from AOTs in a ZENworks 1.0, 1.01, and 1.11 environment. If you have a mixed environment, you should use NWAPP32.DLL version 2.5.
Note: A ZENworks 2 version of the Tool Kit is currently under development. Stay tuned to Novell's Web site for news of the update.
The Tool Kit Tools
Like a mechanic's tool kit, the ZENworks Tool Kit contains a variety of tools to help maintain resources or resolve problems when they arise. Following are descriptions of each of the tools, their usage, and examples of their capabilities.
AOTFDEF
AOTFDEF is an Application object template (AOT) filename processor utility. It is used to validate and convert filenames within an AOT template file. The best time to use it is after you have run snAppShot, which renames the files installed by an application by giving them a numerical filename with a .FIL extension (for example, NETSCAPE.EXE becomes 36.FIL). With AOTFDEF, you can revert these .FIL files back to their original (or "true") filenames. Conversely, you can rename "true" filenames to the numerical .FIL convention. AOTFDEF also lets you set the starting number for a .FIL series, remove duplicate files from an AOT file, and regenerate the FILEDEF.TXT file that lists the .FIL files for a given application.
You can also use AOTFDEF to update files in an existing Application object. For example, say you want to update Visio version 5 to the new version 5.0c. After you install Visio 5, run the first snAppShot. Install the update and reboot. Run snAppShot the second time to capture the changes. Now you have a new AOT file with only the updates for version 5.0c, which you can name VISIO5UPD and place in a common directory for distribution.
Usage. The usage syntax for this utility is as follows:
AOTFDEF AOTfilename[options...]
The options are listed in the table below:
|
/FIL2TRUE |
Renames all .FIL files to their true filenames. Updates the AOT as well as the files listed in the source location. If there are duplicate files in the AOT, they must first be removed using the /RD option before the renaming can be done. |
|
/TRUE2FIL |
Renames all files to a ###.FIL name. Updates the AOT as well as the files listed in the source location. |
|
/V |
Verifies the file's existence. |
|
/RD |
Removes duplicate files. The AOT files created using older versions of snAppShot could have the same file name. A duplicate file is a situation where two or more FILs are being copied to the same location. This option removes the entries from the AOT file and the duplicate files from the source location. |
|
/REGEN |
Regenerates the FILEDEF.TXT. Given an AOT file, this option re-creates the FILEDEF.TXT file. |
|
/N### |
Sets starting number when naming files with the ###.FIL convention (by default, the starting number is 1). Used only in conjunction with the /TRUE2FIL option. |
Examples. The following examples will help illustrate the use of this utility.
AOTFDEF W:\ZENAPPS\COMMON\NETSCAPE\NETSCAPE.AOT /REGEN
Regenerates the FILEDEF.TXT file for the NETSCAPE.AOT file.
AOTFDEF OFFICE97.AOT /V /FIL2TRUE /REGEN
Verifies the existence of all files in the OFFICE97.AOT file, renames .FIL files to their true filenames, and regenerates the FILEDEF.TXT file.
AOTFDEF SUITE99.AOT /RD /V /REGEN
Removes duplicate files, verifies the existence of the files, and regenerates the FILEDEF.TXT file.
AOTFDEF \\ZENSRVR\SYS\ZENAPPS\COMMON\NETSCAPE405.AOT /V
AOTFDEF \\ZENSRVR\SYS\ZENAPPS\COMMON\NETSCAPE405.AOT /V /RD
After these two commands are executed, a backup of the original AOT file is generated with a BAK extension.
AOTFDEF \\ZENSRVR\SYS\ZENAPPS\COMMON\NETSCAPE405.AOT /V /TRUE2FIL /REGEN
After this command, a backup of the original FILEDEF.TXT is generated with a BAK extension.
AOTREV
AOTREV is similar to an "uninstall" utility, because it reverses the settings in an existing AOT or AXT (Application object text template) file. AOTREV creates a new AOT or AXT file with the letters "REV" appended to the filename before the AOT extension. This utility essentially reverses the file distribution attribute to a delete so that all of the file distributed and registry entries created by an application can be removed.
Be careful with this utility. If you distribute a "reverse" Application object that replaces or updates any files that the operating system depends on, your workstation could become disabled. Testing has shown that most major Windows 95 and NT applications replace critical system DLLs when they are installed. Reversing such an installation can remove these critical DLLs and thereby disable your operating system. The most notable examples are Microsoft Internet Explorer 4.0 and Office 97.
The following items are reversed by the AOTREV utility:
All "delete" AOT entries are removed from the new AOT file. Because the purpose of this tool is to create Application objects that remove applications, there is no reason to change "delete" AOT entries to "create" entries.
All "create" AOT entries are changed to "delete" entries for the following settings:
File Copies
Directory Creates
Add INI Entry
Add Shortcuts
Add Groups
Add PM Icons
Add PM Groups
Add Text File lines
All file copies entries flagged as "shared files". These entries are reversed just like the other file entries. Note that when Application Launcher handles shared file deletions, it reads the shared Registry count for the shared file and decrements the count. If the count reaches zero, the Registry key is removed and the file is deleted. If the count is more than 1, the count decrements and the file is not deleted from the system.
All "replace" entries. Replace values in text files and INI files are reversed. If the original entry says search for intraNetWare and replace it with NetWare, the new entry will search for NetWare and replace it with intraNetWare.
All other AOT entries are not processed and added to the new file.
Usage. The usage syntax for this utility is as follows:
AOTREV AOTfilename[/CREATEAXT]
The /CREATEAXToption converts the output AOT file to an AXT file.
Example. An example will illustrate the use of the AOTREV utility.
AOTREV G:\ZENAPPS\COMMON\NETSCAPE\NETSCAPE405.AOT /CREATEAXT
This command reverses all files and registry entries in the NETSCAPE405.AOT file and converts the resulting file to an AXT file.
AOTSPLIT
The AOTSPLIT utility is used to split an AOT file into user-specific and workstation-specific portions. This is useful when you are distributing an application in two stages. For example, suppose you want to distribute Office 97 after hours when users aren't logged in. What you need is an Application object that distributes the files and HKEY_LOCAL_MACHINE registry settings. AOTSPLIT saves you time by providing two separate AOTs from which to build Application objects: one with "_u" (user) and the other with "_w" (workstation) appended to the end of the filename.
Usage. The usage syntax for this command is as follows:
AOTSPLIT AOTfilename
Example. An example will illustrate how this utility is used.
AOTSPLIT \\ZENSRVR\SYS\ZENAPPS\COMMON\NETSCAPE\NETSCAPE405.AOT
This command creates two new AOT files, NETSCAPE405_U.AOT and NETSCAPE405_W.AOT in the \\ZENSRVR\SYS\ZENAPPS\COMMON\ NETSCAPE directory.
AOTXPORT
AOTXPORT is a bidirectional AOT-to-AXT conversion utility. It converts an AOT file (binary format) to an AXT file (text format) and back.
Usage. The usage syntax for this command is as follows:
AOTXPORT [ ImportFilename] [ExportFilename]
where ImportFilename is the name of the file to convert from and ExportFilename is the name of the output file. If neither name is specified, a prompt to select a file will be displayed. If only the ImportFilename is specified, the ExportFilename will automatically be generated with the opposite extension.
Example. A few examples will illustrate how this utility is used.
AOTXPORT NETSCAPE405.AOT
Creates a NETSCAPE405.AXT file based on NETSCAPE405.AOT.
AOTXPORT NETSCAPE405.AXT NEWNETSCP.AOT
Creates a NEWNETSCP.AOT file based on NETSCAPE405.AXT.
APPASSOC
APPASSOC is an application association utility. It associates an Application object with a User, Group, or Container. It also sets the association flags as requested.
Usage. The usage syntax for this command is as follows:
APPASSOC TreeName AppObject AssociationObject [Flags...]
where TreeName is the name of the NDS tree, AppObject is the DS name of the Application object, and AssociationObject is the DS name of the object with which to associate the Application object (a User, Group, Organization, Organizational Unit, or Country object). Unless you include the full name with a leading period for the Application and Association objects, the names must be relative to the default context.
The flags are used to set which options you want enabled on the association. There must be at least one flag specified. The valid values are:
ForceRun
Launcher
StartMenu
Desktop
SystemTray
Examples. Here are some examples of how to use APPASSOC.
APPASSOC ZEN_TREE .APP1.Novell .Novell ForceRun Launcher StartMenu Desktop SystemTray
APPASSOC ZEN_TREE .APP2.Novell .Novell Launcher StartMenu SystemTray
APPASSOC ZEN_TREE .APP3.Dal.Novell .Dal.Novell ForceRun Launcher StartMenu
APPASSOC ZEN_TREE .APP4.Novell .Novell Launcher StartMenu SystemTray
APPASSOC ZEN_TREE .APP5.Novell .User1.Novell StartMenu SystemTray
APPASSOC ZEN_TREE .APP6.Det.Novell .Det.Novell Launcher StartMenu
APPASSOC ZEN_TREE .APP7.Novell .Novell Launcher Desktop
APPASSOC ZEN_TREE .APP8.Bos.Novell .Bos.Novell Launcher StartMenu
APPASSOC ZEN_TREE .APP9.NOVELL .Novell Launcher
APPASSOC ZEN_TREE .APP10.IS.Prv.NOVELL .Novell Launcher StartMenu Desktop
APPCREAT
APPCREAT is an Application object creation utility. Use this utility to create an Application object from an AOT file. If you have an AXT file, use AOTXPORT to convert it to an AOT file first, and then use APPCREAT.
Usage. The usage syntax for this utility is as follows:
APPCREAT TreeName AppObject AOTpath [sourcepath] [targetpath]
where TreeName is the name of the NDS tree, AppObject is the DS name of the Application object to create, and AOTpath is the full path and name of the AOT file. Unless you include the full name with a leading period, the name must be relative to the default context.
The optional sourcepath is the value to be used for the SOURCE_PATH macro. If none is specified, the value already in the AOT file will be used. Likewise, targetpath is the value to be used for the TARGET_PATH macro. If none is specified, the value already in the AOT file will be used. A sourcepath must be specified in order to specify a targetpath.
Examples. A few examples will illustrate the usage of this utility.
APPCREAT ZEN_TREE .APP1.Novell H:\ZENAPPS\COMMON\AOTS\ TEMPLATE1.AOT
Creates an Application object named APP1 based on the TEMPLATE1.AOT file located in the ZENAPPS/COMMON/AOTS directory.
The following commands show how to pass a new SOURCE_PATH and TARGET_PATH when creating the Application object:
APPCREAT TEST_TREE .APP2.Novell H:\ZENAPPS\COMMON\AOTS\ TEMPLATE2.AOT \\FS5\ZENVOL\ZENAPPS\COMMON\APPS
APPCREAT NEW_TREE .APP3.Dal.Novell H:\ZENAPPS\COMMON\AOTS\ TEMPLATE3.AOT \\FS5\ZENVOL\ZENAPPS\COMMON\APPS D:\DISTAPPS
APPCREAT ZEN_TREE .APP1.Novell H:\ZENAPPS\COMMON\AOTS\ TEMPLATE1.AOT \\Server\Volume\AppsDir\AppsDir \C:\Program Files\AppDir\
APPERASE
APPERASE is an Application object deletion utility. It erases the DS object specified. The result is similar to selecting the Application object in NWADMN32.EXE and deleting it.
Usage. The usage syntax for this utility is as follows:
APPERASE TreeName AppObject
where TreeName is the name of the NDS tree and AppObject is the name of the Application object to delete.
Example. An example will illustrate how this utility is used.
APPERASE .APP1.Novell
This command deletes the APP1 object located in the Novell container.
GUIDSYNC
GUIDSYNC is a utility for synchronizing GUIDs (the Globally Unique IDentification numbers that play a central role in the software distribution process). Use GUIDSYNC to synchronize the Application object GUID and version stamp across multiple Application objects.
Usage. The usage syntax for this utility is as follows:
GUIDSYNC TreeName AppObject SyncObject1 [SyncObject2...]
where TreeName is the name of the NDS tree and AppObject is the NDS name of the Application object to be synchronized against. (Unless you include the full name with a leading period, the name must be relative to the default context.) The GUID and version stamp are read from this object and set on the specified SyncObjects. SyncObject1 is the NDS name of the first Application object whose GUID and version stamp are to be overwritten with the GUID and version stamp read from the Application object. You can specify as many additional NDS object names as necessary.
Examples. A few examples will illustrate how this utility is used.
GUIDSYNC ZEN_TREE .OVERVIEW_PPT.Novell .CLIENT32_PPT.Novell .SNAPSHOT_PPT.Novell .NAL25_PPT .Novell.NDS_PPT.Novell .USERPOL_PPT.Novell .WORKSTATPOL_PPT.Novell .ADVANCED_PPT.Novell
Synchronizes the GUIDs so each presentation has the same GUID.
GUIDSYNC ZEN_TREE .Word.Dallas.Novell .Excel.Dallas.Novell .PwperPnt.Dallas.Novell ..Access.Dallas.Novell.
Synchronizes the GUIDs of the Microsoft Office applications Word, PowerPoint, and Access.
APPGUID
APPGUID is a snap-in component for the NetWare Administrator 32 utility. Use APPGUID to add a GUID Sync Manager option to the Tools menu of NWAdmin32. This snap-in provides a visual view of the GUIDs, and makes it easier to synchronize GUIDs between Application objects. For example, you can select the Application object from a list that carries the GUID you want to propagate to all others in the list.
APPGUID requires the version of NetWare Administrator 32 that ships with ZENworks. It is dependent on the NWAPP32.DLL that comes with ZENworks 1.0 or above. To install APPGUID, copy APPGUID.DLL into the Snapins directory below NWAdmin32 (typically this is SYS:PUBLIC\WIN32\Snapins).
To run the utility, follow these steps:
Run NWAdmin32.
Optionally select one or more Application objects that you want to synchronize GUIDs.
Select the Tools | Application Add-on Tools | Application GUID Manager menu items.
Add Application objects to the list.
Select the Application object whose GUID you want to use to set on all others in the list.
Click on Sync. All other application objects in the list will have their GUID and version stamp set to the one you selected (see Figure 1).
Figure 1: Synchronizing Application objects with the GUID Manager in NWAdmin 32.
APPXPORT
APPXPORT is an application export utility. Use it to export an Application object to an AOT file.
Usage. The usage syntax for this utility is as follows:
APPXPORT TreeName AppObject filepath
where TreeName is the NDS tree in which the Application object is located, AppObject is the name of the Application object, and filepath is the path and filename of the AOT file to create.
Example. An example will illustrate how this utility is used.
APPXPORT .APP2.Novell H:\NEWAOTS\APP2.AOT
Creates an AOT file named APP2 in the specified directory. The target directory must be created before exporting the Application object.
NALRUN
NALRUN32 is a Windows 32-bit application launching utility. NALRUNW is a Windows 16-bit application launching utility. This application is useful for pre-launch scripts where you want several applications to be launched or distributed in a specific order. If the application fails to launch, NALRUN32 will return an errorlevel.
Usage. The usage syntax for this utility is as follows:
NALRUN32TreeName AppObject [/F] [/V] [/W] [/P=params]
NALRUNW TreeName AppObject [/F] [/V] [/W] [/P=params]
where TreeName is the NDS tree in which the Application object is located and AppObject is the NDS name of the Application object (specify the full NDS name with a leading period).
The optional parameters are described in the table below.
|
/F |
Filter application that checks system requirements before launching. |
|
/V |
Verify the distribution and run the application. |
|
/W |
Wait for the application to terminate before continuing. |
|
/P=params |
Pass parameters to the application (params is the command-line parameters to pass - enclose in quotes if it includes spaces). |
NALSTAMP
NALSTAMP is a utility that assists in migrating from NAL 2.01 to NAL 2.5 (ZENworks 1.0). It prevents the re-processing of the distribution for an application previously distributed through NAL 2.01. NALSTAMP copies NAL GUID stamps from the HKEY_LOCAL_MACHINE\Software\NetWare\ NAL\1.0\Distribute\\TreeName\ key to the HKEY_LOCAL_MACHINE\ Software\NetWare\NAL\1.0\Distribute\\TreeName\\\UserDN\ key.
NAL 2.5 introduces a new GUID stamp in the registry. This stamp controls the per-user/per-machine distribution of files and settings. If this GUID stamp is missing (which it would be when upgrading from NAL 2.01 to 2.5), NAL would read through every distribution file and setting looking for items marked as "distribute per user". While reading through every setting, NAL displays a distribution processing window. It appears as though NAL is re-distributing or verifying the install of the application. In reality, the settings are only being displayed. No changes are being made, making the processing very fast.
Usage. Usage of NALSTAMP is two-fold: as a force-run application through NAL, or as a scheduled action through Workstation Manager.
Running as a Scheduled Action. Run NALSTAMP as a scheduled action only if the workstation is a secured Windows NT workstation. In order to modify registry settings in HKEY_LOCAL_MACHINE, you would set up the scheduled action to be run as the system. When doing that, you would need to specify both the tree name and NDS user name on the command-line, as in this example:
NALSTAMP ACME_TREE.jdoe.users.dept.corp
Because NALSTAMP is running as a system process, you need to specify the user name.
Running as a Force-Run Application. If running NALSTAMP as a force-run application, you only need to specify the tree name. The NDS user name is automatically read and used. For example:
NALSTAMP ACME_TREE
It is advisable to set an icon order of 1 so NALSTAMP will be run ahead of all other force-run items.
TXT2AOT
The TXT2AOT utility is offered because many customers want to migrate existing software distribution schemes to ZENworks Application objects. This utility converts a Seagate Corporation WinInstall version 5.1 DAT file to a ZENworks AOT or AXT file. You can then import these files into NetWare Administrator to create Application objects in your NDS tree. You can leave the existing files from the WinInstall package as is and not have to use snAppShot to repackage the application.
Limitations. Currently, the utility handles all DAT file settings that have Novell Application object equivalents. However, there are a few limitations that you should be aware of. Originally, this utility was written as a tool to validate the algorithm design, so it has limited functionality. No attempt has been made to integrate the conversion utility into other ZENworks Tool Kit tools. No other formats other than the DAT format are supported in this prototype (including other versions from Seagate). This utility is a standalone application and does not "snap-in" to NetWare Administrator. Therefore, it does not integrate with the NDS Application Object Creation Wizard. The utility also does not copy any files (including application files). You will need to copy them manually into the appropriate source directory. Finally, TXT2AOT does not unpack or uncompress application files compressed with the WinInstall administration utility.
TXT2AOT Requirements. TXT2AOT depends on the NWAPP32.DLL library file, which is installed by ZENworks into the SYS:\PUBLIC directory on your NetWare server. Therefore, the machine you are using to run TXT2AOT.EXE must have access to this DLL. If you want to run this program in a standalone mode (not connected to the network environment), you will need to copy the NWAPP32.DLL into the directory where you are running TXT2AOT. This utility is a native Win32 console application and will run anywhere Win32 applications are supported. Very little RAM and disk space is required to run this tool.
Installation and Removal. To use the conversion utility, copy TXT2AOT.EXE to a convenient place on your hard drive (a directory in the machine's DOS path is recommended). You should be able to use the executable from within a DOS or Windows NT command box. No other support files are needed or created. No Registry settings, INI file settings, autoexec.BAT, config.SYS, or other system changes are required.
To remove the utility when finished evaluating the prototype, simply delete the executable. No cleanup of Registry or other system files is required.
Usage. To view the various command-line options of the utility, type the executable name without any parameters and press <Enter<. The following instructions appear:
txt2aot sourcepath [/x]
|
sourcepath |
The filename or filenames to convert (standard wildcards may be uses). |
|
/x |
(Optional) Creates an AXT file in addition to an AOT file. |
You will need to edit a few items in the generated AXT file. This can be done before or after running TXT2AOT.EXE. The server name is converted as """@servername"". You will want to change this to a "SOURCE_PATH" Macro like ""servername" or G:"ZENAPPS"APP1. If you import the AOT or AXT file that is generated, you can also make these changes in the MACRO's property.
Examples. A few examples will illustrate how this utility is used.
TXT2AOT office.dat
Creates an AOT file based on the OFFICE.DAT file.
TXT2AOT *.DAT /X
Creates an AOT and AXT file for all DAT files in the current directory.
Sample Usage Scenarios
The following are six possible scenarios where the utilities included in the ZENworks Toolkit present various solutions.
Scenario 1: From Testing to Production, No Problem
Say you have ten remote sites that all need the same applications. You have spent some time creating and testing AOTs and they are just the way that you want them in the lab. Here's an easy way to get all of these applications created and configured at each site.
Export the Application Object to an AOT or AXT format from your testing environment. This can be done with NWADMN32.EXE or with the APPXPORT utility. These AOT or AXT files should be kept with the application FIL files (primarily for ease of administration). By using the APPXPORT utility, you can quickly create a simple batch file to export the Application objects to the AOT or AXT format. An example directory structure could be:
\\Server\Volume\ZENAPPS\COMMON\APP1
Copy the file structure from your test server to each server where the applications will be deployed. You might use Novell Replication Services to replicate the FS\VOLUME:ZENAPPS\APPNAME directory structure. This provides a consistent directory structure to all servers.
Since all servers have a different name, the SOURCE_PATH macro may need to be changed for each Application object. Each application needs to be created under each site's Organization Unit and then associated to the Organization Unit, Group, or Users. You could also the APPCREATE utility to create the Application object in any Organizational Unit (that the user has rights to) and modify the SOURCE_PATH or TARGET_PATH macros.
Associate the Application object in an Organizational Unit, Group, or User (that the user has rights to), by using the APPASSOC utility. You can also specify where the Application object appears for the user. For example, this may be the Start Menu, NAL Window, or Desktop.
At this point, you have several options:
Export the testing environment that was tested and rollout to the production environment.
Copy the directory structure and all packaged applications to all servers that will distribute them.
Create the applications, update the SOURCE_PATH macros, and associate them to whoever needs them, as well as their location.
Scenario 2: One Application Requires Another to Install
Some applications require other entities to already be installed before they will function properly (also referred to as dependencies). For example, suppose that before the DATABASE Application can be run, the Oracle32 client must be installed.
For this scenario, we can use ZENworks to do some preliminary checks for us:
Select the "Scripts" property from the DATABASE Application object.
Call the required Application object before this application is launched in the pre-launch script for some dependency checking using the NALRUN32.EXE utility. This requires that NALRUN32.EXE and/or NALRUNW.EXE be copied to the SYS:PUBLIC directory.
NALRUN32.EXE ZEN_TREE.ORACLE32.NOVELL /F /W NALRUNW.EXE ZEN_TREE.ORACLE.NOVELL /F /W
When a user tries to execute the DATABASE Application from ZENworks and that user does not have Oracle 32 installed, it will not install until the DATABASE Application is launched. In the situation where the Oracle client is already installed, the Registry is already stamped with the GUID for Oracle so it continues to launch the DATABASE Application.
For more information on GUIDs, refer to the Help files or visit the ZENworks Cool Solutions Web site at http://www.novell.com/coolsolutions/zenworks/.
Scenario 3: Applying an Update to an Application
This scenario is very common, but there are few ways of addressing it. Say you have Visio 5 Professional version 5.0a and you want to update to Visio 5.0c. You want to apply this to your already-created Application object named Visio55Pro. Here's what to do:
From a clean workstation, deploy the VISIO5PRO Application from ZENworks. Upon completion, start the snAppShot utility and take the first scan.
Install the Visio 5.0c update. Upon completion, continue with snAppShot and take the second scan.
Now that you have a new set of FIL files and new AOT and AXT files for this update, create a new Application object and name it "VISIO50C_Update" or use the Tool Kit to place all new updates in the existing VISIO5PRO Application object.
Note: Before continuing, you should have a backup copy of the files in case you encounter problems. I would also suggest trying this in a test environment first so mistakes will not impact users. You may also want to copy the Source Directory and its contents to a backup directory. For example, rename the SYS:\ZENAPPS\COMMON\VISIO5PRO directory to \VISIO5PRO.BAK\. Then create a new directory called \VISIO5PRO\ and copy the contents from VISIO5PRO.BAK to VISIO5PRO.
Write down what the SOURCE_PATH macro is from the Application object. In this example, it is ZENSRVR\SYS:\ZENAPPS\COMMON\VISIO5PRO.
Now run the AOTFDEF utility to rename all files to their true names in the VISIO5PRO directory:
AOTFDEF\\ZENSRVR\SYS\ZENAPPS\COMMON\VISIO5PRO\VISIO5PRO.AOT /V /FIL2TRUE /REGEN
This renames all of the FIL files to their true filenames, verifies that all files are present, and regenerates a new AOT and FILEDEF.TXT file.
Now run the AOTFDEF utility to rename all files to their true names in the VISIO50C directory:
AOTFDEF \\ZENSRVR\SYS\ZENAPPS\COMMON\VISIO50C\ VISIO50C.AOT /V /FIL2TRUE /REGEN
This renames all of the FIL files to there true filenames, verifies that all files are present, and regenerates a new AOT and FILEDEF.TXT file.
All of the files for the original Visio 5 Pro and the Visio 5 Update should be present. Copy all files from the VISIO50C directory to the VISIO5PRO directory. You will be prompted that certain files already exist and asked whether or not you want to copy over them. Select "Yes" as these are the updated files and you want them included in the Visio5Pro Application Object directory.
Run the AOTFDEF utility to rename all files to their true names in the VISIO5PRO directory:
AOTFDEF \\ZENSRVR\SYS\ZENAPPS\COMMON\VISIO5PRO\ VISIO5PRO.AOT/ V /TRUE2FIL /REGEN
This renames all of the FIL files to their true filenames, verifies that all files are present, and regenerates a new AOT and FILEDEF.TXT file.
Run the AOTFDEF utility to rename all files to there true names in the VISIO50C directory:
AOTFDEF \\ZENSRVR\SYS\ZENAPPS\COMMON\ VISIO50C \ VISIO50C.AOT /V /TRUE2FIL /REGEN
This renames all of the FIL files to their true filenames, verifies that all files are present, and regenerates a new AOT and FILEDEF.TXT file. After testing the VISIO5PRO Application object, you may want to delete this directory unless you create a VISIO50C Application Object to distribute separately.
Now that the Application Files are updated, what about the registry and INI files? For example, what if there were new files added to the Application Directory which are not part of the Application Object Application Files property? Continue with Step 10 to resolve this.
From the Visio5PRO Application object, select "Application Files". You may want to delete all files here and then import the newly-generated VISIO5PRO.AOT file. This adds back all of the application files.
From the Visio5PRO Application object, select "Registry Settings". You may want to only import the newly-generated VISIO5PRO.AOT file. This adds any new registry settings.
From the Visio5PRO Application object, select INI Settings. You may want to only import the newly-generated VISIO5PRO.AOT file. This adds any new INI settings.
The GUID stays the same so users only get the new updates if the Application files are flagged "Copy if newer" or "Copy if newer version" (provided there is a Windows version number in the files). Another option is to increment the version number in the "Environment" property for the Application object. The next time a user selects the VISIO5PRO Application object, he or she will get the updates and be updated to version 5.0c.
Scenario 4: Forcing a Reboot after Application Installation
Some applications require a reboot before they will function properly. ZENworks is capable of forcing this action.
From the Application object, select the "Scripts" Property.
In the Post Launch script, you can force an action after the application has been distributed or is exited. Use the NCSHTDWN.EXE utility (available from the ZENworks Cool Solutions Web site) to force the workstation to reboot. Be sure that NCSHTDWN.EXE is in the user's path or search drive mappings. You may want to copy this to the SYS:PUBLIC directory. For example:
#NCSHTDWN.EXE /5
Refer to the help that comes with the NCSHTDWN utility for use of switches. (For example, the /5 switch will force a reboot for Windows NT.)
Set the Application object to "Run Once" so the user does not consistently run the application and reboot each time. If you are distributing a suite designated as "Run Once" to a user that has App2, App3, App4, and App5, they could never run the subsequent applications. Resolve this by referring back to Scenario 2 and using the pre-launch script in App2-5 to call App1, which initiates the distribution and reboots the workstation.
Scenario 5: Application Suites with Multiple Applications
To have a successful deployment of a suite, you must be familiar with the applications and then decide how to distribute them. If you are using Microsoft Office 97, for example, you have a decision to make prior to packaging the applications: do you want to distribute each application in the suite separately, or create one Application object to distribute the entire suite of files? If you will do each application separately, you do not need to continue reading, as each Application object will have a separate GUID and will contain the specific applications files and settings. For those of you distributing the entire suite, this will be very easy. Once you have your package completely tested and ready to distribute, create the following Application objects:
One for Installation only (App1). This reboots the workstation once installation is complete.
One for each Application (App2, App3, App4, App5). These will not reboot the workstation.
Set App1 as a "Run Once" Application object and add the NCSHTDWN.EXE to the post-launch script.
For App2-App5, point each Application object to launch the appropriate executable (App2: Winword.exe, App3: Excel.exe, App4: Powerpnt.exe App5: MSAccess.exe). In the pre-launch script, use the NALRUN32 utility to call the App1 Application Object. Associate to the users and your distribution setup is complete.
Scenario 6: Synchronizing the GUIDs
To provide a simple distribution of application files, you must understand the GUID. In Scenario 5 you would want to synchronize the GUIDs of App2, 3, 4, and 5 so that if App2 is launched and App1 (which has a different GUID than App2-App5) has not been run (registry is not stamped), then App1 is distributed to the workstation. If App3 is launched and has a different GUID than App2 and App1, App3 will call App1 (the registry is stamped so App1 does not distribute) but App3 is not stamped in the registry. Now App3 will re-distribute all of the files (based on the file properties) to the workstation. This is a delay that can be avoided by using APPGUID.DLL from the Took Kit.
Summary
This AppNote has provided brief descriptions of the individual tools and utilities that comprise the ZENworks Tool Kit. It has also presented various scenarios where these utilities may be used to help manage applications.
Admittedly, the proper use of these tools requires a considerable amount of expertise with ZENworks and other Novell solutions. When ZENworks is deployed under the direction of Novell Consulting, customers can expect unsurpassed service quality, reduced cost of ownership, and excellent return on investment. To engage the services of Novell Consulting, visit:
http://consulting.novell.com/onsite/engage.html
For more information about ZENworks, visit:
http://www.novell.com/products/nds/zenworks/
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.