Deployments of configuration objects to agentless managed objects

TrueSight Server Automation can support objects that do not have an RSCD agent installed, such as an IBM frame. TrueSight Server Automation calls these objects agentless managed objects (AMOs).

The system manages AMOs through other servers that are equipped with a custom configuration object that can communicate with the agentless device. This documentation refers to those other servers as AMO proxies.

You can deploy BLPackages to agentless devices, and you can roll back those deployments. The AMO proxy stores rollback information. If you change the AMO proxy for an agentless device, when you perform an undo, the system attempts to use the original AMO proxy for the rollback.

To run Deploy Jobs on agentless devices, the AMO proxy must be equipped with an RSCD agent running version 8.1 or later. Also, the custom configuration object used for communicating with the agentless device must be consistent with version 8.1 or later.

When running Deploy Jobs on agentless devices, be aware of the following:

• Deploy Jobs ignore reboots on agentless devices.
• Deploy Jobs ignore pre- and post commands on agentless devices.
• Deploy Jobs support single-job mode for agentless devices. However, the single-job mode setting affects all agentless devices managed from an AMO proxy. If an AMO proxy is set up to manage multiple agentless devices and the Deploy Job is running on more than one of those devices, the job would be processed on one agentless device before it can run on the next agentless device.
• Only a custom configuration object that is used to communicate with agentless devices should be used in packages deployed to agentless devices. Including more than one such custom configuration object in a job causes the job to fail.
• While a Deploy Job targets an AMO, it can only operate on custom configuration object-based assets. The job fails if it tries to operate against any other type of object. When a job is not targeting an AMO, it can operate on other server objects. However, not all server objects have an ActionOnFailure defined for them. When a job fails to deploy an object that does not have an ActionOnFailure defined, the entire job fails. This behavior differs from assets based on custom configuration objects. For those, the definition of ActionOnFailure dictates how the job behaves if a deployment fails.
• To prevent an AMO proxy from being overloaded with too many targets, the Deploy Job includes properties that allow you to set the maximum number of parallel targets during different phases of the Deploy Job. For more information, see Controls-for-the-number-of-simultaneous-processes.