ZENworks uses Tiered Electronic Distribution to distribute Application objects to other locations in the same tree or other trees. Using a Desktop Application Distribution, the original files associated with the applications are copied to the appropriate server locations where they can be used to locally service user groups and workstation groups associated with the distributed Application objects.
To distribute applications, you use the Server Management Desktop Application Distribution Wizard to configure the Distribution. This includes:
Determining the destination’s tree context
Determining whether to maintain the associations between user/workstation groups or containers and the applications
Determining whether to have automated load balancing or fault tolerance
Determining how to trigger rebuilds of the Distribution
Selecting the applications
Determining the file copying paths
To create a Desktop Application Distribution using the wizard, continue with Section 6.3.2, Creating the Distribution.
IMPORTANT:You can also perform these step in iManager instead of running this wizard in ConsoleOne. Instructions are contained in the context-sensitive help in iManager.
Fulfill all of the requirements listed under Section 6.2, Requirements, including creation of a code page variable if necessary.
In ConsoleOne, right-click the container where you want the Distribution object located, click , click , select , then click .
Provide a name for the Distribution.
IMPORTANT:Periods (.) are not allowed in Distribution names. Instead, use dashes (-) or underscores (_) as word separators. If you use a period in the Distribution name, the Distribution is not sent, and the Distributor is not reloaded after it has been exited.
To give a Distributor ownership of the Distribution, browse and select the Distributor object, click , then click .
The Distribution object’s properties are displayed.
Select the tab and fill in the fields:
Active: Required. In order to make a Distribution available to Subscribers, it needs to be active.
Use digests: Digests are used by Distributors and Subscribers to verify that Distributions have not been tampered with while in transit. The digest provides an MD5 checksum for the Subscriber to compare.
Digests also detect corruption in a Distribution’s package. If corruption is present, the Subscriber renames the distfile.ted Distribution file to distfile.corrupt and the Distribution is rebuilt and sent the next time the Channel’s schedule fires.
Encrypt: You can have the Distribution encrypted if you are sending it across non-secured connections. Encryption provides security for the Distribution during transit between the Distributor and Subscriber when they are not within the same firewall. Select either Strong or Weak encryption.
You must also have NICI 2.6.4 or later installed to each of these servers for encryption to work (see Installing NICI 2.6.4). Older versions of NICI are not compatible with version 2.6.4 or later.
Maximum revisions: This number helps you to control disk space usage by determining how many versions of a particular Distribution are kept in the Distributors’ and Subscribers’ working directories. The default is 10. Select and enter a number.
Increase the number if data is changing often and the changes are minimal (smaller delta files). Decrease the number if data is not changing very often, or if a significant amount of data is changing (larger delta files).
The following e‑mail options are available if you set a maximum number. If you select , these options are dimmed.
Approaching maximum revision email notification list: Contains the e‑mail addresses of anyone who is to be notified when a Distribution is approaching the maximum revisions set in the field. Here, you can either remove a single or all displayed addresses.
Email address (maximum revision notification): You can add e‑mail addresses to the list in . Just enter an e‑mail address and click and it is displayed in the listing.
Send notifications when Distribution revision is ___ or less of reaching maximum revisions: Enter a number to indicate how close “approaching” is. When the current revision number of Distribution plus this number equal the maximum revisions, an SMTP notification is sent to the listed addressees.
SMTP must be configured and its e‑mail server address listed in the next field.
Email server address: The SMTP server used to send the e‑mail notifications. For example, mail.novell.com.
For information on configuring SMTP e‑mail notifications, see SMTP Host.
Priority: You can give the Distribution a priority that determines how it is sent in relation to other Distributions. A High priority means it is sent before Medium or Low priority Distributions.
Distributor: Displays the DN of the Distributor object that builds and sends this Distribution. You selected the Distributor when you created the Distribution object.
Description: Provide useful details about the Distribution, such as the name of the desktop application, the files and directories it contains, intended user groups, and so on.
Click > .
You can select whether to have platform restrictions for the Distribution itself. This is not a restriction for the distributed Application object.
No restrictions: This option is selected by default. To determine platform restrictions, select this option to disable it, then select the check boxes corresponding to the platforms you want to receive this Distribution.
Platforms with check boxes not selected cannot receive the Distribution. In other words, you restrict sending to a platform by deselecting the No Restrictions option and not selecting the platform.
The available options are:
No Restrictions NetWare All NetWare 4.x (earlier versions of ZfS supported these platforms) NetWare 5.0 (earlier versions of ZfS supported this platform) NetWare 5.1 NetWare 5.x (earlier versions of ZfS supported these platforms) NetWare 6.x Windows Server
No Restrictions means that the Distribution can be sent to any of these platforms.
If you select NetWare All, you do not need to select any of the individual NetWare platforms.
Select the tab, select Desktop Application in the Select Type drop-down box, then click .
The Desktop Application Distribution Wizard is started. iManager provides its own interface in place of this wizard.
You can also start this wizard from the Desktop Application Agent properties page by clicking .
Click after reading the introductory information.
Fill in the fields, then click .
Maintain source tree structure: Duplicates the source tree’s structure at the destination’s location (the target Subscriber’s working context) for placing the distributed Application objects. If you are selecting chained applications, you must select this option.
For more information, see Maintaining Source Paths.
Source root context: Select a container to be used as the root container for the golden Application objects to be distributed. You should select golden Application objects only from this root container and its subordinate containers.
Maintain associations: Distributes the associated groups or containers at the target location if they do not exist. However, users or workstations contained in the groups or containers in the source location are not distributed.
For more information, see Maintaining Associations When Distributing Objects.
You must enable this option if you have chained applications in the Distribution. For more information, see Chained Applications in Distributions.
IMPORTANT:Rights previously set in the associated user/workstation groups or containers that are maintained are not distributed, but set to the minimum necessary in the distributed groups or containers so that users can use the applications.
Overwrite Existing Target Folder Object Attributes: When selected, this check box causes existing target folder objects to be overwritten with the relevant content of the source folder objects, meaning all previous folder associations for the application are replaced by the new folder associations.
To retain previous folder associations while adding new folder associations, deselect this option. (This is the default function previous to ZENworks 7 for how folder objects are handled. The option to overwrite is added in ZENworks 7.)
Always replicate association flags: Causes the launch configuration flags for each group or container associated with the golden Application object to be replicated with each distributed application.
Load balance and fault tolerance support: Choose whether to use automated load balancing, fault tolerance, or neither:
Load balance: Automates spreading server workloads over the servers being used for the Desktop Application Distributions. The functionality of fault tolerance (redundancy) is automatically accomplished through load balancing.
Fault tolerance: Allows a server being used for Desktop Application Distributions to assume the distribution duties of another server that goes down. Fault Tolerance does not provide load balancing.
None: Neither option is applied. You must individually configure each distributed Application object for load balancing or fault tolerance, if you want that support on an individual basis.
For these two features to work:
Multiple Subscribers receiving the Distribution must be using the same working context
The User Source List button must be selected on the Fault Tolerance > Fault Tolerance or the Fault Tolerance > Load Balancing properties pages of the Application object
Depending on the selected options, the Load Balancing or Fault Tolerance pages are populated with the file locations on all servers that share this working context.
For more information, see Distributed Applications in Server Management.
Rebuild only if any application version number changes: Allows you to control Distribution rebuilding based on the Build schedule. Select this check box to withhold modifications to a golden Application object until you are ready to release them.
Regardless of the status of this check box, if applications are added to or removed from the Distribution, it is rebuilt according to its Build schedule.
For more information, see Section 6.4.2, Triggering a Rebuild.
Click to browse for and select golden Application objects.
Do not browse above the root directory that you established in the previous wizard page, especially if you have selected the Maintain Source Tree Structure option.
IMPORTANT:The Desktop Application source files must reside in the Distributor server’s file system. The Distribution cannot be gathered from another server’s file system.
Select the option if you want to retain the golden Application object’s source path when the mapped drive feature is used in the distributed application.
For more information, see Maintaining Source Paths.
Provide the destination volume or shared folder.
The application files distributed are those that are associated with the golden Application objects you selected in the previous wizard page.
You can provide a variable instead. If you use a variable, it must be defined in the destination Subscriber server’s properties to point to the target server’s volume or shared folder.
This volume (NetWare) or shared folder (Windows and Linux) becomes the root location for placing subordinate directories where the application files are copied.
To use only an application’s default path, click , which is placed beginning with the root location you specified in Step 7.e.
or
To provide a user-defined directory path to the application’s files, click User-Defined Directory Path, then provide your path information.
The path you specify is used in the following manner:
The volume or shared folder name remains unchanged (as specified in Step 7.e).
Your path information is inserted after the volume or shared folder name.
Part of the application’s default path is appended to your path information, beginning with the default path’s immediate parent directory to the application’s files. Any default path information that was above the immediate parent directory is replaced by your path entry.
The result is a customized directory path that begins with the volume or shared folder, has your user-defined path information next, and ends with the application’s immediate directory. For example, suppose the default path to the application’s executable file (application.exe) might be:
\application_root_directory\application_subdirectory
and you enter \mypath for your user-defined path; the new full path to the executable is now:
c:\mypath\application_subdirectory\application.exe
If you entered C: as the shared folder and \mypath as your user-defined path, \application_root_directory is replaced by \mypath, and \application_subdirectory is the immediate parent directory to application.exe.
Click to continue.
The Summary page is displayed.
To make changes, click .
When you have finished configuring the Distribution object, click to exit the wizard.
You can edit the Distribution at any time on the tab of the Distribution object by clicking .
Select the tab, click , then browse for and select the Channel for this Distribution.
Each Distribution must be associated with at least one Channel if it is going to be used to push data to a Subscriber. A Distribution is sent to all Subscribers that are subscribed to the selected Channel.
Select the tab, then select a Build schedule:
Click to create the Distribution.
You are prompted to copy additional security certificates.
Select to resolve the certificates.
This copies the security certificates from the Distributor to Subscriber subscribed to the Channel.
For information, see Section 7.1.6, Resolving Certificates.
Click to close the Distribution object.
The next time the Distributor reads eDirectory (this schedule is set in the Distributor object’s properties), it retrieves all of the information about the new Desktop Application Distribution, such as Distribution details, the Build schedule, and so on.
The Distribution is built according to the Build schedule, sent according to the schedule set in the Channel object, and extracted according to schedule set in the Subscriber object.
If the Distributor throws an exception during the file gathering process, the Distribution is not built. The Distributor logs the failure in the reporting database.
If the Subscriber throws an exception during extraction, the process is not completed. The Distributor receives this information from the Subscriber and logs the failure in the reporting database.
After extraction, Desktop Management users whose objects are located in the associated containers, or are members of a distributed group, will have access to the desktop applications that were distributed.
IMPORTANT:For Desktop Application Distributions, a built-in delay exists to accommodate directory synchronization when you have multiple applications being distributed at the same time (whether by one or multiple Distributions).
Subscribers can receive Desktop Application Distributions all at the same time, but extract them one at a time. And, when there are multiple applications contained in one Distribution, the Subscriber creates the distributed Application object and copies the files one application at a time. The built-in delay helps directory synchronization for the newly-created Application objects to occur smoothly.
To determine how much additional time this built-in delay might add to the distribution process, multiply each application contained in a Desktop Application Distribution by 30 seconds.
As a rule of thumb, if an application being distributed includes multiple versions, such as one baseline and two deltas, each of these three versions receives the same 30-second delay. For example, if you are sending 10 desktop applications, and each has three versions, the completion of the Distribution extractions could take at least 15 minutes.
For Desktop Management users and workstations to have automatic access to their applications from any geographic location, you must link up the site lists:
Wait for the Desktop Application Distribution to be distributed and extracted by each Subscriber server that received it, because the distributed Application objects must be created and the application’s files installed before you can link up the site lists.
In ConsoleOne, right-click the golden Application object that was used to build the Distribution, then click .
Click the tab, then click the button.
All distributed Application objects that were created from the golden Application object are displayed in the list box, and all Distributions containing the distributed Application objects are listed in the list box.
The button does the following:
For the golden Application object, it searches for each distributed Application object that was created from the Distribution and lists the full DN of those objects in the golden Application object’s properties (in the Replicated Applications list box).
For each distributed Application object, it searches for the other distributed Application objects that were created from the Distribution; for the golden Application object, it lists the full DN of all of these objects in the distributed Application object’s properties (in the Replicated Applications list box).
Step 13.c.a and Step 13.c.b are repeated for each distributed Application object.
For each Application object listed in the Replicated Applications list box, any Distributions associated with those objects are listed in the Distributions Currently In list box in each of these Application objects.
Thus, the golden Application object and all distributed Application objects have each other listed in their Replicated Applications list box, which allows users to have local access to the same application no matter where they connect to their network.
Click to close the golden Application object’s properties.
Repeat Step 13.b through Step 13.d for each golden Application object that was used to build the Desktop Application Distribution.
You need to perform the site list link-up only on the golden Application objects.