Policies and Check Instances are not propagated to agents after modifcations or during agent connection to the MID server when previously in a down state. - Known Error

Policies and Check Instances are not propagated to agents after modifcations or during agent connection to the MID server when previously in a down state. Description During policy publish via an ECC queue message, check sum calculations are not performed on the MID server for policies that have previously been registered. These calculations are responsible for notifying agents tied with the policies and their check instances that changes have been made and a synchronization of the data must be pushed to agents via the WebSocket connection to reflect the changes.

The conditions for which this occurs are the following:

An agent registers for communication after the associated config_publish message containing the policies and their check instances for the agent have been processed by the MID server. This scenario requires a MID server restart while all agents are actively attempting to reconnect in order to resolve the issue. Disassociation will not clear up even with policy activation / deactivation activities or restarting the agent. Changes to existing policy configuration item parameters are made. This scenario will not trigger a check sum calculation when policy changes are made after a policy has previously been registered with the MID server via a config_publish message. Solvable by activation / deactivation of the policy or restarting the agent client collector to pull the updated policy information. The issue arises from the MID server caching the previous policy during a config_publish message. For agents that register after this message, the schedule message is never sent due to an error associating the cache entry in the MID server with the new agent connection. For updates to existing policies and/or check definitions, the cache is not updated with them check sum changes indicating the state has changed.

Steps to Reproduce

Configured Checks Show Zero:

Connect an agent to a MID server and verify host data collection has been accomplished and policies with check instances have been associated and synchronized to the agent. Verify on the agent client collector record that the configured checks are not zero and the related lists show the number of checks matches the value. Stop the MID server Disconnect the agent Start the MID server Verify the config_publish record has been sent containing the policy and check instances containing the down agent information Start the agent Verify within the MID server logs that the agent does not get a scheduled message sent during keep alive processing Resubmit the last config_publish output record from the ECC queue. Verify the input record has " {" ":0} ", indicating the agent has zero configure checks. This can be also verified from the instance, the agent client collector form, the configured checks = "0". On "check" related list, there will be non-zero configured checks. The agent ID will match the ID of the agent record in question. Policy Changes are not propagated:

Create a policy with a check instance that contains configuration item parameters Associated the policy with an agent Publish the policy Verify the policy is synchronized with the agent and is running. Modify the policy Publish the policy Verify the policy changes are not propagated to the agent. Workaround Configured Checks Showing Zero:

Ensure ALL agents are connected to the MID server. Stop the MID server Start the MID server NOTE: Any agents that are currently not connected will still exhibit this issue, required the previous steps to be re-performed. Policy Changes are Not Synchronized With Agents:

Deactivate and then Reactive the Policy, OR Restart the agent Related Problem: PRB1898155