Novell Doc: Novell ZENworks 7 Desktop Management Administration Guide - Configuring the Application in eDirectory

29.3 Configuring the Application in eDirectory

After you have prepared the application for distribution (see Section 29.1, Understanding Software Packages), you are ready to create the application as an Application object in eDirectory, define its distribution rules, and associate it with users and workstations.

You can create the Application object in any container you want. Because Application Launcher accesses the object on behalf on the logged-in user or workstation, you should place it in a container whose partition (or a replica of the partition) is available to the user or workstation over a local area connection rather than a wide area connection. For more information, see Section 51.0, Reference: Application Object Location.

To create the Application object in eDirectory and configure it:

In ConsoleOne®, right-click the container where you want to create the Application object, click New, then click Application to display the New Application Object dialog box.
Select from the following options to create the appropriate type of object for the application:

An application that has an .aot/.axt file: Lets you specify a .aot or .axt file you've created with snAppShot or exported from another Application object. The .aot or .axt file is used to populate the Application object's property fields. Skip to Section 29.3.1, Creating an Application Object from a ZENworks snAppshot File.

An application that has a .msi file: Lets you specify a Microsoft Windows Installer (.msi) file. The .msi file is used to populate the Application object's property fields. Skip to Section 29.3.2, Creating the Application Object from a Windows Installer (.MSI) File.

29.3.1 Creating an Application Object from a ZENworks snAppshot File

(Conditional) If the New Application Object dialog box is not open, see Section 29.3, Configuring the Application in eDirectory.
In the New Application Object dialog box, select the Application that has an .aot/.axt file option, then click Next.
Specify the path to the .aot or .axt file.

or

Click the browse button to browse for and select the file.

The file should be in the network location where you saved it when creating it with snAppShot. If you browse for the file, the Open dialog box defaults to *.axt for its file type display. If you created an .aot file, you must change the file type display to *.aot or All Files in order to select the .aot file.
Click Next, then modify the following fields to customize the Application object.

Object name: This field defaults to the Application object name that was specified when running snAppShot. You can change the name if you want. The name must conform to the following rules:
- The name must be unique in the container.
- Special characters are allowed. However, plus (+), equals (=), and period (.) must be preceded by a backslash (\) if used.
- The following characters are valid in Application object names but are invalid when used in Windows folder and file names:
```
\ / : * ? " < > |
```
  If you use these characters in the Application object name, they are replaced by an underscore (_) when displayed in locations controlled by Windows and not Novell Application Launcher™ (for example, on the Windows desktop).
- Uppercase and lowercase letters, as well as underscores and spaces, are displayed as you first entered them, but they aren’t distinguished. For example, ZENworks_Desktop_Management and ZENWORKS DESKTOP MANAGEMENT are considered identical.
The Application object's name is visible in eDirectory. By default, the name is also used as the Application object’s icon title when displayed by Application Launcher on a user’s workstation. You can, if necessary, change the icon title after the Application object has been created (Application object > Identification tab > Icon page).

SOURCE_PATH (location of installation files (.fil)): This field defaults to the location where the application's files (.fil) files were stored when running snAppShot. You should verify that the path is correct. If the path uses a drive mapping, you can either 1) ensure that all workstations have the same drive mapped to the source location or 2) change the drive mapping to another format such as UNC. For information about valid formats, see Filepath Syntax in File System Access Overview.

The path you enter here is added as the SOURCE_PATH macro in the Macros list for the Application object (Common tab > Macros page) and used in any fields that require a path to the source location.

TARGET_PATH (client workstation directory path): This path specifies the workstation location where the application files should be installed. It defaults to the path defined in the .aot or .axt, which is the location where the application was installed when running snAppShot. You should verify that this is the workstation directory where you want the application installed.

The path you enter here is added as the TARGET_PATH macro in the Macros list for the Application object (Common tab > Macros page) and used in any fields that require a path to the target location.
Click Next, then define the rules used by Application Launcher to determine if a workstation meets the requirements for the application.

The distribution rules ensure that Application Launcher does not distribute the application to workstations that cannot support the application. For example, if the application runs on Windows 2000/XP only, you can create an operating system rule that prohibits distribution to Windows 98 workstations.

NOTE:The requirement for an operating system to be defined before an application is available has been removed.

In previous ZENworks versions, an OS platform had to be defined in the System Requirements before an application would be available for distribution and launching. This requirement has been removed.

The new behavior uses the following logic: If an application runs only on a specific operating system, define an operating system distribution rule. If an application does not require a specific operating system, there is no need to define a distribution rule. By default, applications without a defined operating system distribution rule are available on all supported platforms (Windows 98, Windows 2000, and Windows XP).

To add a distribution rule:
1. Click Add, then select the type of rule you want to define.
2. Fill in the information for the requirement (click Help for information about the requirement or refer to Distribution Rules Page), then click OK to add the requirement to the list.
  
  If you want to create additional distribution rules for the application at a later time, you can use the Distribution Rules page on the Application object. For information, see Distribution Rules Page.
Click Next, then associate the Application object with the users or workstations that you want to distribute the application to. To do so:
1. Click Add, then browse for and select User or Workstation objects. You can also select Group objects, Workstation Group objects, and container objects (Organizational Unit, Organization, or Country). If you select a container object, you are given the choice of associating all the container's User and/or Workstation objects with the application.
  
  Each workstation that you want to associate with applications must first be imported into eDirectory as a Workstation object. If a workstation with which you want to associate the application has not been imported as a Workstation object, see Section III, Automatic Workstation Import and Removal.
  
  Associating an Application object with a Group, Workstation Group, or other container object is the preferred method of associating the Application object in eDirectory. Associating the application to a large number of User or Workstation objects (for example, more than 250) might cause increased server utilization.
  
  IMPORTANT:Do not associate the Application object with Alias objects. Alias objects are not supported.
2. After you add the user or workstation to the list, select the appropriate check boxes for the user or workstation to set the characteristics (Force run, App Launcher, Start menu, Desktop, System tray, Quick launch, and Force cache) you want applied to the application. Click Help for a description of each of these characteristics, or refer to Associations Page.
  
  If you want to associate the application with additional users or workstations at a later time, you can use the Associations page on the Application object. For information, see Associations Page.
Click Next, review the Application object settings, then click Finish to create the Application object.
Continue with Section 28.3, Establishing File System Access.

29.3.2 Creating the Application Object from a Windows Installer (.MSI) File

(Conditional) If the New Application Object dialog box is not open, see Section 29.3, Configuring the Application in eDirectory.
In the New Application Object dialog box, select the Application that has an .msi file option, then click Next.
In the Path to .msi file field, specify the complete path to the .msi file to use as the source file during distribution to workstation.

You can use a mapped drive or UNC path. If you use a drive mapping, you must ensure that all workstations have the same drive mapped to the source location. The path you enter here is added to the Package source list for the Application object (Common tab > Sources).

NOTE:After you create the Application object, you cannot change the .msi filename; however, you can change the path to the .msi file. If you change the .msi filename, the installation fails.
Click Next, then modify the following fields to customize the Application object.

Object name: This field defaults to the Application object name defined in the .msi file. You can change the name if you want. The name must conform to the following rules:
- The name must be unique in the container.
- Special characters are allowed. However, plus (+), equals (=), and period (.) must be preceded by a backslash (\) if used.
- The following characters are valid in Application object names but are invalid when used in Windows folder and file names:
```
\ / : * ? " < > |
```
  If you use these characters in the Application object name, they are replaced by an underscore (_) when displayed in locations controlled by Windows and not Novell Application Launcher (for example, on the Windows desktop).
- Uppercase and lowercase letters, as well as underscores and spaces, are displayed as you first entered them, but they aren’t distinguished. For example, ZENworks_Desktop_Management and ZENWORKS DESKTOP MANAGEMENT are considered identical.
The Application object's name is visible in eDirectory. By default, the name is also used as the Application object’s icon title when displayed by Application Launcher on a user’s workstation. You can, if necessary, change the icon title after the Application object has been created (Application object > Identification tab > Icon page).

Administration package path: This path specifies the location of the MSI package you want to use for administrative purposes. ConsoleOne uses the .msi file at this location to populate information in the Application object. This field is used only by ConsoleOne for reading of the .msi package. It is not used by Novell Application Launcher for distribution of the application. For distribution, Application Launcher uses the path defined in the Path to .msi file field located on the previous page.

The path defaults to the path defined in Path to .msi file field on the previous page. Change it if necessary. You can use a mapped drive or UNC path. If you use a drive mapping, you must ensure that all ConsoleOne workstations have the same drive mapped to the location. You cannot use macros in this field.

The path you enter here is added to the Administration package path field for the Application object (Identification tab > Package Information page).

NOTE:Do not use macros in this field or creation of the Application object will fail. After ConsoleOne has created the Application object, you can define a macro for the source location (Common tab > Macros) and use it in other Application object fields (such as the Package source list) if desired.
Click Next, then define the rules used by Application Launcher to determine if a workstation meets the requirements for the application.

The distribution rules ensure that Application Launcher does not distribute the application to workstations that cannot support the application. For example, if the application runs on Windows 2000/XP only, you can create an operating system rule that prohibits distribution to Windows 98 workstations.

To add a distribution rule:
1. Click Add, then select the type of rule you want to define.
2. Fill in the information for the requirement (click Help for information about the requirement or refer to Distribution Rules Page), then click OK to add the requirement to the list.
  
  If you want to create additional distribution rules for the application at a later time, you can use the Distribution Rules page on the Application object. For information, see Distribution Rules Page.
Click Next, then associate the Application object with the users or workstations that you want to distribute the application to. To do so:
1. Click Add, then browse for and select User or Workstation objects.
  
  Each workstation that you want to associate with applications must first be imported into eDirectory as a Workstation object. If a workstation with which you want to associate the application has not been imported as a Workstation object, see Section III, Automatic Workstation Import and Removal.
  
  You can also select Group objects, Workstation Group objects, and container objects (Organizational Unit, Organization, or Country). If you select a container object, you are given the choice of associating all the container's User and/or Workstation objects with the application.
  
  Associating an Application object with a Group, Workstation Group, or other container object is the preferred method of associating the Application object in eDirectory. Associating the application to a large number of User or Workstation objects (for example, more than 250) might cause increased server utilization.
  
  IMPORTANT:Do not associate the Application object with Alias objects. Alias objects are not supported.
2. After you add the user or workstation to the list, select the appropriate check boxes for the user or workstation to set the characteristics (Force run, App Launcher, Start menu, Desktop, System tray, Quick launch, and Force cache) you want applied to the application. Click Help for a description of each of these characteristics, or refer to Associations Page.
  
  With MSI applications, you must use the Force cache option if users or workstations do not have network client access to the source .msi files. The Microsoft Windows Installer requires file access that is provided by a network client but not by the ZENworks Desktop Management Agent. Consider the following examples:
  - Users outside your firewall need an MSI application but have no network client access to the source .msi files on a server inside your firewall. They log in to the ZENworks Middle Tier Server and Application Launcher displays the MSI application. For successful distribution to occur, the MSI application must be marked as Force cache so that the source .msi files are copied to the user’s cache directory (through the Middle Tier Server) and then distributed from the cache directory.
  - Users inside your firewall need an MSI application. They don’t have the Novell Client™ installed, so they log in to the ZENworks Middle Tier Server to authenticate to eDirectory. The users are part of an Active Directory domain, and the source .msi files are located on a Windows share that they have rights to. The distribution succeeds without force caching the application because the Microsoft network client provides file access to the source .msi files.
  If you want to associate the application with additional users or workstations at a later time, you can use the Associations page on the Application object. For information, see Associations Page.
Click Next, review the Application object settings, then click Finish to create the Application object.

If, after you create an Application object for an MSI application, you receive a new MSI package (.msi file) for the application, you must create a new Application object using the new .msi file. You cannot simply replace the old .msi file with the new one.

For example, the Desktop Management Agent is packaged as an .msi file (zfdagent.msi) that can be distributed through an Application object. Each time you receive a new zfdagent.msi file (through an upgrade or support pack), you must create a new Application object for it. This ensures that the GUID (global unique identifier) contained in the .msi file is synchronized with the one in the Application object and on the workstation, thus enabling the application to be installed and uninstalled correctly.
Continue with Section 28.3, Establishing File System Access.