Getting Bundle Chaining to work the way it did in ZENworks 7

over 8 years ago
This last week I’ve been in Europe attending GWAVACon Dusseldorf, training our SEs and partners on ZENworks 11 SP3, and visiting with customers and partners. During one of my visits this week I got asked a question that comes up frequently. The question was…”In ZENworks 7 when you chain applications together, if App1 (Word) depends on App2 (Office) then every time I launch Word it checks the version of Office and if it is newer then it updates the dependent application. How do I get the same behavior in ZENworks Configuration Management?”

A bit of background on how ZCM Bundles Work

Before answering this question, I want to provide a quick review of how a bundle is structured and how versions are used in ZENworks Configuration Management. When you make a change to a bundle object in ZENworks Configuration Management it is necessary for the version number of the bundle to be incremented before agents will request that application from the server, as a locally cached version is present otherwise. This means that any change that impacts the appearance or behavior of the bundle on the workstation requires the bundle version to be incremented.

In ZENworks Configuration Management 10.x when you made changes, the changes were made to the bundle immediately. This meant that even before you incremented the version they could be picked up by devices that had not previously cached the bundle. This would result in two devices saying they had the same version of an application when in reality it was different. This was addressed in ZENworks Configuration Management 11 with the introduction of the Bundle and Policy change management process (also known as sandboxing). In ZENworks Configuration Management 11 and higher when you make a change to the bundle, the changes are saved to a Sandbox which is only read by devices that are flagged as test in the ZENworks Control Center. This means that all production clients will always receive the same version of the bundle.

In order to properly understand why the solutions I will suggest work, you also need to understand Action Sets and how they are internally versioned. An Action Set is an ordered list of actions that are executed sometime during a bundle’s lifecycle. For Windows bundles, six Bundle Actions exist: Distribution, Install, Launch, Uninstall, Verify, and Terminate. Because changes made to any of these action sets require that you increment the version, it is important that the agent only execute the Action Sets that have changed or those configured to run always. If this were not the case, then anytime you changed the Launch action set it would re-run the Distribution and Installation actions.

To prevent this each Action Sets has a version number that is maintained internally by the ZENworks server. If you make a change to either the Action Set Options or the Action Set action list then the version stored on the Action Set is automatically incremented. This means that in a Sandboxed bundle changes to the action set can be tested by test workstation -- they will see a sandbox exists that has an updated Action Set version and will then update the cache and execute the new actions. All other workstations wait until they get a newly published version, then check the Action Set versions, and execute them based on the configuration and changes.
Finally, you need to understand the way the agent handles running Action Sets is determined by Action Set Options. When a bundle is double clicked in the ZENworks window the default behavior is as follows:

  1. Check to see if the content associated with this bundle version is present in the device’s cache and if the current version of the distribution action set has already been executed on the device. If not then the distribution action set actions will occur. If so, then the distribution Action Set actions are skipped.

  • Check to see if the bundle is installed and the Install action set version is the same as the current bundle. If not then transact the Install Action set. If the bundle is installed and the action set has been run, then the Install action set is skipped by default.

  • Run the launch action set. By default this is run each time the bundle is launched.
    If you wish to change this default behavior, click on the Options link on the appropriate Action Set in the bundle.

Answer #1 to the Question : Use the Install Always option in Action Set Properties

Now that you have an understanding of how ZENworks deals with Bundle versioning and Action Set versioning, we can answer the original question : ”In ZENworks 7 when you chain applications together, if App1 (Word) depends on App2 (Office) then every time I launch Word it checks the version of Office and if it is newer then it updates. How do I get the same behavior in ZENworks Configuration Management?”

The first way to achieve this, if you have a launcher bundle that chains to one or more installer bundles, is to configure Install Bundle actions on the Install Action Set of the launcher application, as shown in the picture below.


If the only actions in the Action Set are Install Bundle actions, then you can configure the Install Action Set options, shown below, so that the Bundle is configured to “Install Always” and you are done.


This configuration means that when the application is launched, it will always process the Install Bundle actions; however, unless the Install Action Set version on the dependent application is newer AND the Install action set version is newer on the dependent application is newer, then the dependent bundle will not reinstall the application.

If you have additional actions in the Installation action set that you do not want to process after the initial launch, you can use Action requirements and ensure that you check some condition that is only met when a particular action has not already been performed once. This will result in the Install process skipping the actions you don’t want to occur every time you launch the application.

When you use this solution to solve the problem, the user double clicks the application the first time, and all of the Install action set actions are processed and then the Launch action set is processed. The next time the user double clicks the application, the application once again processes the Install action set. This time when it tries to trigger the Install action set of the dependent bundle it will find the versions are the same and skip the install of the dependent bundles unless that dependent bundles is also configured to install always. Additionally, any actions with requirements specified are only reprocessed in the requirement indicates that they need to be.

One key advantage to this method is that the application progress bar is displayed each time the application is launched if the Show Activity option is set in the bundle.

Answer #2 to the Question: Use the Launch Action Set

The second way to solve this problem is to use Install Bundle actions in the Launch action set for those applications you want to check on launch, as shown in the screenshot below:


In this case when the user launches the bundle it will process its own Install action set one time. This allows you to do any one time installation work you wish to perform as part of the bundle. After the Install action set is completed, then the launch action set will be processed. The first time it is processed the dependent bundles will not be present and ZENworks will initiate the install. On subsequent launches the bundle will be present and unless the Install action set version of the bundle has changed the application will not be re-installed.

The drawback to this approach is that the activity progress bar is not displayed while the dependent applications are being deployed. This is because the agent only displays a progress bar when processing the Distribution, Install, Verify or Uninstall action sets as those are generally the long running action sets.

In both of these solutions you also have the ability to launch the dependent bundle by using the Launch Bundle action in the appropriate action set so that if the dependent applications needs to be up and running before the main application it can do so.


ZENworks Configuration Management provides solutions for ensuring that capability similar to the ZENworks Desktop Management 7 chaining functionality can be implemented. Additionally, with the flexibility of being able to use the Install Bundle, Launch Bundle or Uninstall Bundle actions in the various action sets of a bundle you have much more fine-grained control over this behavior.


How To-Best Practice
Comment List
Related Discussions