AXT stands for Application Object Text Template, meaning that the .AXT file is written in human-readable, text format. Therefore, you can open it in a text editor and edit the contents.

An .AXT file contains information about what happened on a workstation when an application was installed to it. You can also think of it as a “change log” that contains the differences between the pre- and post-application installation states of a workstation. snAppShot discovers these differences and records them in the .AXT file, as shown in Figure 5.1.

Figure 5.1. Sample excerpt from a snAppShot .AXT file.

You use the .AXT file when creating and setting up Application objects using Application Launcher for large-scale distribution. The .AXT file delivers the information about the application to the new Application object.

AOT stands for Application Object Template. The .AOT file is written in binary format and cannot be edited in a text editor.

You use the .AOT file when creating and setting up Application objects using Application Launcher for large-scale distribution. The .AOT file delivers the information about the application to the new Application object.

One .FIL file represents one application file that was installed to a workstation. Because there can be hundreds of files installed to a workstation during an application's installation or upgrade, there can also be hundreds of .FIL files representing that application.

Think of .FIL files as the Application object's copy of the originally installed application files.

A list of the .FIL files that need to be copied to run an application appears in the .AOT file. This list can be viewed from the Application Files property page in the Application object in ConsoleOne.

The FILEDEF.TXT file is a “legend” that compares originally named installed files with the newly named .FIL files. snAppShot copies the FILEDEF.TXT file to the same directory where the .FIL files are created. You then use it to compare .FIL files to the originally installed files. A sampling from the FILEDEF.TXT file is shown in Figure 5.2.

Figure 5.2. Sample excerpt from a snAppShot FILEDEF.TXT file.

First and foremost, snAppShot saves a list of all files that were added or modified during the installation or upgrade. It also saves a copy of the file as a .FIL file to be used in later installations or upgrades.

snAppShot saves any changes to application or system .INI files, so that those files can be modified when the Application object is used later. The following are some of the files snAppShot monitors for changes:

snAppShot records any changes to system configuration text files. That way any changes to drivers being loaded, paths being set, or environment variables being added or changed are recorded. You can then apply such changes to other systems when you use the Application object to install or upgrade the workstation.

The following are the two files snAppShot monitors for system configuration changes:

Any changes to Windows shortcuts are also recorded by snAppShot. Therefore, if an application installation or upgrade adds a new shortcut to the desktop or Start menu, or modifies the path in an existing shortcut, those changes are applied to other systems as well along with the Application object.

snAppShot can record any changes made to a Windows workstation's Registry by an installation or upgrade. This is extremely important later, because even if you copy all files installed by an installation or upgrade and make the appropriate changes to configuration files, the application often fails to run, because Registry settings have not been made.

Using snAppShot to save the Registry settings fixes that problem by saving the changes to the Registry and then applying them when the Application object is used to install or upgrade the application on a new workstation.

Using snAppShot preferences, you can include or exclude the recording of certain changes to particular folders and files. This enables you to protect certain directories that you do not want to alter on other workstations when the Application object is used on them to install or upgrade an application.

Using snAppShot preferences, you can exclude particular Windows shortcut files from being recorded. This allows you to protect certain application shortcuts from being created or altered on other workstations during the installing or upgrading of an application.

Using snAppShot preferences, you can exclude particular application .INI files from being recorded. This enables you to protect certain application .INI files from being created or altered on other workstations when the Application object is used on them to install or upgrade an application.

Using snAppShot preferences, you can define which system configuration file changes are recorded. This enables you to set which system configuration changes should be recorded and created or altered on other workstations when the Application object is used on them to install or upgrade an application.

Using snAppShot preferences, you can also include or exclude changes from particular portions of the Windows Registry from being recorded. This enables you to protect certain areas of the Windows Registry that you do not want to be altered on other workstations when the Application object is used on them to install or upgrade an application.

Some applications query the computer system to determine what hardware is installed and only install necessary drivers for the hardware that actually exists. This often results in problems if you distribute the application to clients that do not have the same hardware as the computer in which the application package was created. You can use the hardware inventory feature of ZENworks for Desktops, discussed later in this book, to quickly determine what specific hardware is installed on clients.

Occasionally, an application install prompts the user to input additional paths of locations to store files. When you use snAppShot to create an application package, make certain that any additional paths you specify, both local and network, exist on all clients you want to distribute the application to. For example, if you specify a path on the D: drive, all clients must have a D: drive on their computer. If necessary, you can use macros and user prompts when distributing the application to handle this; however, that must be defined in the Application object.

Another thing you should watch for when creating application packages using snAppShot is prerequisites for application installs. For example, if the application needs to determine which version of DirectX is installed on the computer, it might determine that the current version is correct and then not install needed DirectX drivers. This results in the drivers not being included in the Application object. If a client that is receiving the application from ZENworks for Desktops does not have the correct version of DirectX drivers, the application might not function properly.

It is possible that an application distributed with ZENworks for Desktops could conflict with a local application that was installed by the user of that workstation. For example, you distribute a corporate virus scanner to all workstations. An existing application then cannot open files correctly because the virus scanner believes it is a virus that is trying to modify the files.

Most companies have some sort of standard for applications that can be installed on clients. This standard usually ensures that applications being distributed with ZENworks for Desktops do not conflict with any other applications on the users' systems.

When an Application object is delivered to a workstation, it can be configured to copy files only if they are newer. This usually protects shared DLLs because the older functionality is usually available in newer versions.

However, some applications have DLLs that have functionality written specifically for them. This functionality does not exist in newer versions, and, if they are overwritten with a newer file, the application they supported might no longer function.

Many applications are written for computer systems that have a high level of CPU speed, RAM, video memory, disk speed, and so on. If this type of application is distributed down to a client workstation that does not have the hardware capability to support them, they will not function properly.

This potential problem can be controlled somewhat by configuring the Application object to check for hardware levels before installing (discussed in the next chapter). You can use the hardware inventory feature of ZENworks for Desktops, discussed later in this book, to quickly determine what hardware is installed on clients.

Once you select the standard mode installation from the main screen in snAppShot, a window similar to the one shown in Figure 5.4 is displayed. From this screen, you need to input the name that the Application object has in the eDirectory tree and include a title for the icon that represents the Application object.

Figure 5.4. snAppShot window for naming the Application object and the application's icon.

Next, a screen similar to the one in Figure 5.5 enables you to set the network location to store the application source files (.FIL).

Figure 5.5. This snAppShot window allows users to specify the location to store the application source files.

When setting this location, remember the following two issues:

Once you have specified a network location for the .FIL files, snAppShot enables you to set a network location for the application template (the .AOT and .AXT files). Set the network location by either entering it into the text window or by clicking on the folder button and navigating to the appropriate directory.

Once you have selected the network location to store the Application object support files, you need to select which disk drive to scan on the workstation to determine changes, as shown in Figure 5.6.

Figure 5.6. snAppShot window for specifying which disk drives, network and local, are scanned during discovery.

You can add drives to the list by clicking on the Add button and selecting the drives you want to scan. Conversely, you can remove drives from the list by selecting the drive and then clicking on the remove button. You can select network drives as well, but only if they are mapped. This allows you to install applications to a larger network drive if needed and still discover the changes.

Once you have all the drives you want to select added to the list of drives to be scanned, click Next and a summary of the preferences is displayed in the next window, as shown in Figure 5.7. The information displayed includes:

Figure 5.7. This snAppShot window allows you to review the current preference settings before starting the first discovery.

The first snAppShot discovery runs when you click Next from the Preference Summary window. A screen shows the status of the discovery and a count of the following items that have been discovered:

Once the first snAppShot discovery is complete, a Run Application Install button is available. When you select the Run Application Install button, a pop-up menu appears. You can navigate to the application install executable and execute it.

Once the application install is complete, you can continue with the discovery process of the snAppShot application.

Once you have completed the application install, snAppShot gives you the option to specify a path to the application's executable on this workstation. You can enter the location of the installed application files on this workstation in the text field.

Of course, if you do not want snAppShot to set a target distribution location, leave this field blank and continue.

Once you are finished setting the path to the application's executable and you click the Next button, snAppShot runs the second discovery. Once again, you can monitor the status of the discovery by noting the count of the following items:

Once the discovery is finished, snAppShot begins generating an object template. This is where the differences between the two discoveries are discerned and the template files are created.

Once the second snAppShot discovery is complete and the template files are generated, a completion summary of what took place is displayed in the window shown in Figure 5.8. The completion summary contains information about the application template creation, including:

Figure 5.8. This snAppShot window allows users to review the summary of the Application object template generation.

The first window that comes up after you select the custom mode in snAppShot is the Choose snAppShot Preferences window. From this window, you have the option of either using a previously saved preference file, or using the snAppShot default settings.

If you have previously created and saved a preferences file in a previous custom mode, you can navigate to that file or enter the path to it into the text field as shown in Figure 5.9.

Figure 5.9. The snAppShot window for specifying a pre-created preference file or for using the default settings.

Once you select the preference file option in custom mode in snAppShot, a window is displayed. From this screen, you need to input the name that the application object will have in the eDirectory tree and a title for the icon that represents the application object.

Once you have set the name for the application object and title for its icon in the custom mode install, a screen enables you to set the network location to store the application source files (.FIL).

When setting this location, you should remember the following two points:

Once you have specified a network location for the .FIL files, snAppShot enables you to set a network location for the application template (.AOT and .AXT files). Set the network location by either entering it into the text window, or by clicking on the folder button and navigating to the appropriate directory.

Once you have selected the network location to store the Application object support files, you can select which of the following parts of the workstation you want to include or exclude, as shown in Figure 5.10:

Figure 5.10. The snAppShot window for specifying which parts of the workstation to include or exclude.

• Files and folders—From the Workstation Scan Customization menu in snAppShot, you can modify which files and folders you want to include or exclude. Simply select the files and folders option and click the Customize button. A window similar to the one in Figure 5.11 pops up, and you must select which files and folders to ignore.

Figure 5.11. The snAppShot window for specifying how and which files and folders are created in the Application object template.

Tip

Wildcards are valid here. For example, if you want to exclude all .DAT files, you could specify *.DAT in the list of files to ignore.

• .INI files—From the Workstation Scan Customization menu in snAppShot, you can modify which .INI files to exclude. Simply select the .INI files option and click the Customize button. A window pops up from which you select which .INI files to ignore.

• System configuration text files—From the Workstation Scan Customization menu in snAppShot, you can modify which system configuration text files you want to include in the scan. Simply select the system configuration text files option and click the Customize button. A window similar to the one in Figure 5.12 pops up, from which you select which system configuration text files you want to include.

Figure 5.12. This snAppShot window allows you to specify which system configuration files are created in the Application object template.

• Windows shortcuts—From the Workstation Scan Customization menu in snAppShot, you can modify which Windows shortcuts to exclude. Simply select the Windows shortcuts option and click the Customize button. A window pops up, and you select which Windows shortcuts to ignore.

• Registry—From the Workstation Scan Customization menu in snAppShot, you can modify which Registry hives you want to include or exclude. Simply select the Registry option and click on the Customize button. A window similar to the one in Figure 5.13 pops up, and you select and deselect from a list of hives to include.

Figure 5.13. This snAppShot window indicates which Windows Registry hives are created in the Application object template.

Once you have specified which parts of the workstation to include or exclude, you must select which disk drive to scan on the workstation to determine changes.

You can add drives to the list by clicking on the Add button and selecting the drives you want to scan. Conversely, you can remove drives from the list by selecting the drive, and then clicking on the Remove button.

Once you have all the drives you want to select added to the list of drives to be scanned, click Next and a summary of the preferences are displayed. The information displayed includes:

The first snAppShot discovery runs when you click Next from the preference summary window. A screen shows the status of the discovery, and a count of the following items that have been discovered:

Once the first snAppShot discovery is completed, a Run Application Install button is available. When you select the Run Application Install button, a file pop-up menu appears, from which you navigate to the application install executable and execute it.

Once the application install is complete, you can continue with the discovery process of the snAppShot application.

Once the application's installation or upgrade is complete, snAppShot enables you to specify how to handle the creation of entries for the Application object. From the screen shown in Figure 5.14, you can set the additional criteria for the entries described in the following sections.

• Folder and file entries—From the Application Object Entry Addition window in snAppShot, you can choose whether files and folders are added to the Application object. Click the down arrow under the folders and files option and select one of the following additional criteria, as shown in Figure 5.15:

• Copy always

• Copy if exists

• Copy if does not exist

• Copy if newer

• Copy if newer and exists

• Request confirmation

• Copy if newer version

• Copy if different

Figure 5.15. The snAppShot window that allows the users to specify how snAppShot handles the creation of file and folder entries in the Application object template.

• .INI files—From the Application Object Entry Addition window in snAppShot, you can configure whether .INI files are added to the Application object by clicking the down arrow under the .INI files option and selecting one of the following additional criteria, as shown in Figure 5.16:

• Create always

• Create if does not exist

• Create if exists

• Create or add to existing section

Figure 5.16. The snAppShot window for indicating how snAppShot handles the creation of .INI file entries in the Application object template.

• Registry entries—From the Application Object Entry Addition window in snAppShot, you can configure whether Registry entries are added to the Application object. Click the down arrow under the Registry entries option and select one of the following additional criteria, as shown in Figure 5.17:

• Create always

• Create if does not exist

• Create if exists

Figure 5.17. The snAppShot window that allows the users to specify how snAppShot handles the creation of Registry entries in the Application object template.

Figure 5.14. The snAppShot window for specifying how snAppShot handles the creation of file, folder, .INI file, and Registry entries in the Application object template.

Once you have defined the additional criteria for entries into the Application object, snAppShot gives you the option to specify a path to the application's executable on this workstation. You can enter the location of the installed application files on this workstation in the text field.

Of course, if you do not want snAppShot to set a target distribution location, leave this field blank and continue.

Once you are finished setting the path to the application's executable and have clicked the Next button, you can define macros to control the distribution of Application objects. A screen similar to the one shown in Figure 5.18 enables you to add, edit, or remove macros to control automation of application distribution.

Figure 5.18. This snAppShot window allows the users to add, edit, or remove macros to be used in the Application object template.

When you click the Add button in the Macro Definition window, you can specify a variable name and a string that is replaced within the template data, as shown in Figure 5.19.

Figure 5.19. The snAppShot window for specifying a variable name and string in macros.

Once you are finished with defining macros to automate Application object distribution, click Next, and snAppShot runs the second discovery. Once again, you can monitor the status of the discovery by noting the count of the following items:

Once the discovery is finished, snAppShot begins generating an object template. This is when the actual differences between the two discoveries are discerned and the template files are created.

Once the second snAppShot discovery is complete and the template files have been generated, a completion summary of what took place appears. The completion summary contains information about the application template creation, including:

The first window that appears after you select the express mode in snAppShot is the Choose snAppShot Preferences window. From this window, you can choose to use a previously saved preference file.

If you have previously created and saved a preferences file in a previous custom mode, you can navigate to that file or enter the path to it into the text. If you have not previously created and saved a preference file, you must do so before selecting the express mode.

Once you have selected a preference file from a previous application package, click Next and a summary of the preferences are displayed in the next window. The information displayed includes:

The first snAppShot discovery runs when you click Next from the Preference Summary window. A screen shows the status of the discovery and a count of the items that have been discovered, including:

Once the first snAppShot discovery is complete, the Run Application Install button is available. When you select the Run Application Install button, a file pop-up menu appears, and you can navigate to the application install executable and execute it.

Once the application install or upgrade is finished, click Next, and snAppShot runs the second discovery. Once again, you can monitor the status of the discovery by noting the count statistics of the following:

Once the discovery is finished, snAppShot begins generating an object. This is when the actual differences between the two discoveries are discerned and the template files are created.

Once the second snAppShot discovery is completed and the template files generated, a completion summary of what took place is displayed. The completion summary contains information about the application template creation, including:

The first step to use the super express (command-line) mode in snAppShot is to enter DOS and change to the directory where the snAppShot utility is located.

Once you are in the directory of the snapshot utility, enter the following command from the DOS prompt.

<filename> is the name of a snAppShot preferences file you defined and saved earlier when running snAppShot in custom or express modes.

Once you have executed the snAppShot command from the DOS session, a window appears that gives you the option to overwrite the existing Application object template, as shown in Figure 5.20. You must select Yes to continue.

Figure 5.20. The snAppShot window that allows you to overwrite the previous snAppShot discovery when using the super express mode.

Once you select Yes, the Application object template creation continues the same as in the regular express mode, by displaying the pre-discovery summary screen, followed by the first discovery.

The most complete way of creating .MSI files is by using development tools to create .MSM and .MSI files, and then configuring them with the files, Registry changes, resources, and logic to perform a complete install of the application.

This method is preferred by most application developers, because it gives them the greatest control over how and what information and logic actually goes into the .MSI file.

The discovery method of creating .MSI files is very similar to the way snAppShot creates its Application object templates. The discovery method works by using a double discovery process to accumulate changes made by an install. Most third-party application installs are created by this method. The following steps describe how this method is accomplished: