Browse Prior Art Database

Cooperative constraints on the agent behaviour in a policy driven system management tool Disclosure Number: IPCOM000202029D
Publication Date: 2010-Dec-01
Document File: 3 page(s) / 26K

Publishing Venue

The Prior Art Database


Usually the agents of a policy driven system management tool apply policies to target system simply considering the status of the system and not the status of the other systems in the environment. This behavior is not always desiderable, because if all the agents decide to apply a new policy at the same time on a large set of target systems, the performances of the IT environment would be largely affected. There is accordingly a need for a synchronization method that allows multiple independent agents to coordinate the policy evaluation and remediation actions to distribute them in a suitable time frame.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 31% of the total text.

Page 01 of 3

Cooperative constraints on the agent behaviour in a policy driven system management tool

In a policy driven configuration management system, each target computer (or set of target computers) gets associated with a set of policies. A policy is basically composed of a condition to check and a remediation action that gets executed if the condition evaluation returned that the condition is false. To better understand the policy concept let's consider an example policy that installs software: the check condition verifies if the software is installed (for example querying the installation registry of the Microsoft Software Installation engine) and the remediation action installs the software. So if the software is not installed, the check condition evaluation returns false and thus the software installation command gets executed. Once a policy gets associated with a target system, the target system periodically (or based on an external event) evaluates the check condition and in case of failure performs the remediation: considering the example above, it means that the first time the policy gets executed, it basically install the software if it was not installed.

    A target computer periodically evaluates a policy to verify its compliance and if necessary executes a remediation action. Obviously it is not always desirable that the management agent executes actions on a target computer. Consider as an example the reboot of the target computer after the installation of a set of security patches: if the user is using the computer very likely he will not want the reboot to happen immediately.

The usual solution to this problem is to restrict the complete set of operations that are

part of the execution of a policy in well defined time windows.

    Restricting some operations to some time windows is still not the best solution in the cases where we do not want some operations to happen at the same time on a set of computers. As an example consider the requirement of installing software and performing the reboot of the machine; consider a set of computers that work as a cluster to improve reliability and scalability. The desired behavior is to avoid that all the members of the cluster to reboot at the same time, because this will adversely affect the service offered by the cluster.

    We suppose the policy model has been extended to include the concepts of Behavior and Obligations. A


                  is a characterization of an action that a policy must perform on the computer. Examples of behaviors are: install software; download file; upload file; uninstall software; execute task; reboot the computer.

    A remediation action or compliance check must externalize its behaviors to let the management system to apply obligations when asked to perform certain kinds of operations. An obligation can specify that a reboot of a computer can only be performed after user confirmation; an obligation can specify that a download of a big software package cannot be