This one fits under the categories of testing, troubleshooting, development and upgrades and if done properly it could save most admins or packagers time and effort at different points. Sometimes you could avoid that whole, make a copy of a bundle then test that and then either replace the original... (you get the idea). If you use ZCM to manage recurring tasks on your
Primaries and Satellites like we do then this is useful since you cannot use Sandboxes on ZCM Servers since they cannot be set as Test Devices.

Quite Often we have bundles that mostly run silent automated tasks. Sometimes these can be scripts and sometimes they are force installs of bundles. We often do not want them to just fire off if conditions are not right so we use system requirements. But sometimes we want them to be able to still be fired off manually. That is not feasible to do with bundle level system requirements.

I would like to propose that System requirements be extended to the relationship.

For our example we have a reg key that indicates a server is undergoing maintenance. We do not want the bundle to fire off automatically but we still want to be able to run it manually for testing or validation purposes, .i.e testing a new patch. We would have 2 relationships:

1. The launch schedule set to fire at recurring intervals. This relationship would have the check for the reg key indicating maintenance mode and would not fire if the server was undergoing maintenance.
2. A generic assignment just making the bundle available in the application window or wherever. This one would not have the check for the reg key and could still be fired off manually for testing and validation.

There are several other niche applications for this type of functionality but this is the most straightforward to document...

Thanks.

by: Chad G. | over a year ago | Application Mgmt