Agent Configuration Policies

The TrueSight Server Automation application performs the target server management tasks through RSCD Agents that are installed on target servers. You can manage access to these RSCD Agents using the following configuration files: exports, users, and users.local

These configuration files control which clients and users can access RSCD Agents. As a TrueSight Server Automation administrator, you need to manage these configurations and perform periodic checks to make sure that the configuration files are correctly configured before running jobs. Any accidental or manual configuration changes that are made in these files can break the TrueSight Server Automation access with the target servers. To effectively manage these configurations without manual intervention, you can use Agent Configuration Policies. An Agent Configuration Policy is a collection of the configurations that are defined for the exports, users, and users.local files. The policy also contains rules that specify the targets where you want to apply the policy.

When you configure and apply the policy, the Smart Agent applies the configuration files as defined in the policy. The Smart Agent periodically monitors the policy status and reports any deviations in the applied policy to the Application Server. If a deviation is detected, the Smart Agent retrieves the latest copy of the policy from the Application Server and reapplies the policy to the target. This reinforcement ensures that the consistent agent configurations are retained. All the Agent Configuration Polices are stored in the Application Server and are applied to the targets based on the defined rules. For information about when the policies are applied, see Policy apply mechanism.

The following sequence of events occur after you create and apply the Agent Configuration Policy:

1. When you create the policy, a new internal Agent Configuration Policy Apply job is created.
   

   This job is not visible in the Jobs workspace. You can view this job on the Results tab when you open the Agent Configuration Policy details. For more information, see Managing-Agent-Configuration-Policies.

2. When you apply the policy, the job is triggered and the policy is sent to the Smart Hub as a work request.
3. The Smart Agent, which periodically polls the Smart Hub for work requests, retrieves the work request from the Smart Hub.
4. The Smart Agent applies the policy to the target.
5. The Smart Agent performs the periodic validation of the policy after every five minutes (this period is not configurable). If a deviation is detected, the Smart Agent retrieves the latest copy of policy from the Application Server and reapplies the policy to the target.

For information about creating, updating, and deleting configuration policies, see Managing-Agent-Configuration-Policies.

Policy apply mechanism 

The Application Server applies the policies to the target servers through the Smart Hub and Smart Agent. To apply the policies, the following prerequisites must be met: 

• The version of the RSCD Agent is at least upgraded to 21.02.
• The Smart Agent is enabled on the target server.

Manually applying policies

You can manually apply the policies. The target servers are selected based on the rule definition, and the policies are applied as a work request to the eligible targets. When a policy is applied for the first time, it becomes active and a scheduler is created based on the value configured for the INTERVAL_HOUR property.

Policy apply action after auto enrollment

When a new server is auto enrolled via the Smart Agent, the Application Server validates all the active policies against the server: 

• If more than one matching policy is found, an error is logged in the Application Server log files. The server property that holds the policy details is updated to list all the mapped policies.
• If a single matching policy is found, the policy is pushed to the server using the Smart Hub push mechanism.
• If a matching policy is not found, no action is taken.

Policy apply action based on the configured periodic interval

For each policy, a default interval is set for applying the policy. The Application Server runs the Apply Job at this interval to push the policy to the target servers. 

The following validations are performed for applying policies:

• If a difference is found with the already applied policy, the policy is pushed.
• If no difference is found with the already applied policy, the policy is not pushed.

Policy conflict 

A target server can have only a single policy. A situation when the same target is qualified by multiple policies is considered as a conflict. A policy conflict can occur in the following scenarios:

• Scenario 1: A policy is already applied to the server and the same server is detected as eligible target by another policy. When the second policy is applied, a conflict is detected because another policy is already applied to the server. In such a case, the second policy is not applied to the server.
• Scenario 2: A new server enrollment request is received and the server is auto enrolled. If multiple policies qualify this server, a conflict is detected and none of the policies will be applied to the server.

When a conflict occurs, the log shows the additional details about the conflicting policies. To resolve the conflict, analyze the policy rules and server properties and update them as required. For more information about detecting and resolving conflicts, see Managing-Agent-Configuration-Policies.

ACL Push Job and Agent Configuration Policies 

The existing ACL Push job computes the server ACLs. These computed ACLs are stored in the users file on the target server. When you run the ACL Push job, these ACLs are applied to the target server. If a policy is already applied to the target, the users file computed by the policy is replaced with the users file computed by the ACL Push job.

During the next policy scan interval, the Smart Agent detects that the users file is not in sync with the policy. Therefore, the Agent reapplies the users file defined by the Configuration Policy to the target, and reports this difference as violation.

To avoid this type of conflict, we recommend updating the ACL Push Job to remove the target servers where a policy is already applied.