Operational Rules module parameters
The operational rules module defines how and which BMC Client Management function is to be run. These rules are made up of a series of commands called steps executed by the agent. A series of ready-to-use steps are loaded upon startup. Operational rules can run single or multiple actions according to their schedule on individual devices or on the device groups they are assigned to.
Parameter |
Default Value |
Description |
---|---|---|
Status-Check Interval (sec) |
120 |
The interval in seconds at which the status values of the operational rules are updated. Any file which has is not yet in transfer is requested again. |
Resume rule execution at startup |
Yes |
Defines if any not terminated operational rule is to be continued after a restart of the client. |
Delete package after successful distribution |
Yes |
Check this option to delete the package on the client (to free up disk space) once the software distribution has executed successfully. |
Enable Simultaneous Rule Execution |
Yes |
Defines if operational rules may be executed in parallel mode. |
Synchronize at Startup |
Yes |
Check this box if the operational rules are to be synchronized at every startup of the agent. Operational rule synchronization allows a device to send its current list of operational rules it is assigned to as well as their checksum. The master compares the checksum and, if it is different to its own, it sends the master list of operational rules to the device. In this case the local agent compares its list of operational rules assigned to the device with the master list and updates it accordingly by deleting the unassigned operational rules and adding the newly assigned ones. |
Additional Automatic Synchronization Hour |
23 |
Enter here the hour at which an additional synchronization is to be effected, that is, the comparison of locally available operational rules with the operational rules master list. The format is 24-hour format, for example, 23 for 11 pm . |
Minimum Gap between Two Automatic Synchronizations (sec) |
43200 |
Defines the minimum interval in seconds at which the rule synchronisations are to be done. This means that if a default synchronisation is executed at 23:00 at night and the client is started at 6 am with agent startup synchronisation defined, no synchronisation is executed until at least 11 am even if the agent is started/restarted before, as the interval is fixed for 12 hours minimum. |
Proceed with Added Rules |
Yes |
Check this box to check for new rules in the base. |
Proceed with Updated Rules |
Yes |
Check this box to check for updated rules in the base. |
Proceed with Deleted Rules |
Yes |
Check this box to check for deleted rules in the base. |
Proceed with Published Rules |
Yes |
Check this box to check for published rules in the database. |
Proceed with Operational Rules |
Yes |
Check this box to check only for operational rules in the database. |
Proceed with Software Distribution Rules |
Yes |
Check this box to check only for distribution rules in the database. |
Proceed with Quick Link Rules |
Yes |
Check this box to check only for Quick Link rules in the database. |
Only Proceed with Not Received Rules |
Yes |
Check this box, if only rules for which the assignment has been sent but after 12 hours still have not been received by the local agent. |
Output File |
../log/OperationalRules.log |
Defines the path to the log file relative to the installation directory:
|
Maximum Agent Log Size (Byte) |
5000000 |
The maximum size of the log file in bytes. When the output file size reaches this limit, it is deleted and a new file of the same name created to start again. If the output file is stdout this setting has no effect. If set to 0 or not specified at all, there is no limit check on the size of the file. |
Maximum Agent Log File Count |
5 |
Maximum number of log file backups to keep. As a log file hits its maximum size it is copied to a backup file with an incrementing integer index. When the number of backups hits this limit, backup number 1 is removed and all the others are renumbered down. |
Activate Operational Rule Publication for Users |
Yes |
Defines if rules may be published to users. If activated, the module checks on the master if rules are available to be published to a user, otherwise rules are not published. |
Automatic Status Upload |
Yes |
Defines if the current status of the operational rule is automatically updated. If the option is deactivated, no status value is updated, however status actualization can still be done via the Update Operational Rule step or via an operational rule synchronisation. |
Recreate Local Database If Integrity Check Fails |
No |
Defines the actions to be executed if the database check fails at agent startup due to its corruption. If this parameter is activated, the local database is recreated and the master reassigns all operational rules for the concerned devices, depending on the settings defined in the system variables (Automatic reassignment of all general operational rules if the local database is corrupted and Automatic reassignment of all software distribution rules if the local database is corrupted). If it is deactivated that no status values is updated any more and no synchronisations be performed. |
Failed to check the chronological dependencies if the rule execution is failed |
No |
Check this box if an operational rule that depends on another rule is not executed if the rule it depends on does not have the status Executed OK . If this option is not activated, the depending rule is executed even if the first rule's execution failed. |
Comments
Log in or register to comment.