Tech Tip : Server Command and Agent Command Explained

TechTip

Server Command

Policy Server can be deployed in a Server Farm configuration, where multiple Policy Server share the same Policy Store. In order to maintain policy data synchronization, Policy Server utilizes objects called Server Commands. Server Commands are temporary objects used to broadcast commands to all the Policy Servers that use the same policy store.

Generated by the server that initiated the change, a Server Command can ask all of the Policy Servers to reload certain objects to cache, to hold or resume synchronizations, and more.

Server commands are processed by the management thread and are read and processed by every server every 60 sec. (configurable by JournalRefresh (in sec) ).

Since server commands may force a reload of certain objects, which were persisted in the store merely milliseconds before that, and since changes to related objects may generate duplicate server commands, server commands are not being persisted immediately to the policy store, and are buffered and (after purging duplicate commands off of the list) persisted every 10sec (configured by ServerCmdDelay).

Agent Command

Some Server commands convey information that has to be carried over to the various agents. In order to achieve that, when persisting the Server Command object, an Agent Command is generated, buffered and scheduled to be saved within 15sec, configurable by JournalRefresh in sec.

The purpose of Agent Commands is that information will be delivered to the agent instances, regardless of which server they are connected to.

Every 10sec (configured by ServerCmdDelay), the Management Thread goes through the list of Agent Commands scheduled to be saved, and if their scheduled time was reached, saves them.

Policy Server maintains a cache of AgentCommands read from the store. Policy Server will search the store every 60 sec (configurable by JournalRefresh, in sec) searching for new Agent Commands. Every Agent Command object has a timestamp. The timestamp’s granularity is seconds. Agents use the DoManagement API call to poll the server for the list of new agent commands. The Agent keeps an indicator of which commands where processed and which ones are new and yet to be seen by it, by keeping the timestamp of the last agent command it received (called Management Timestamp). When starting up, the Agent will send a timestamp of 0, indicating to the Policy Server that it has just started up. Policy Server replies by sending the list of current agent keys along with the time of the latest agent command it has in its cache.

The agent then poll the Policy Server every 30 sec (Configured by the ACO parameter PollInterval, in sec) using the DoManagement call. PS will respond to the DoManagement call (in particular the GetAgentCmd request) by sending the list of Agent Command objects newer than the agent’s ManagementTime.

 

Server Command Agent Command

 

RELATED SETTING :

  • Flush Journal entries older than = JournalDelete registry entry.
  • Apply administrative changes every =  JournalRefresh registry entry.
RELATED REGISTRY :

[HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore]
“JournalRefresh”=dword:0000003c
“JournalDelete”=dword:0000003c
“ServerCmdDelay”=dword:0000000a
“MaxTimeDeltaBetweenServers”=dword:0000001e
“AgentCmdStabilizationDuration”=dword:0000000a

JournalDelete 

Delete journal commands older than N minutes. For e.g. if the JournalDelete = 60 minutes. Policy server will delete all journal (server command and agent command ) older than current time – 60 minutes.  Lower this value , if the policy store size grows rapidly due to large number of journal entries.

MaxTimeDeltaBetweenServers 

The MaxTimeDeltaBetweenServers setting reflects the time differences between all Policy Servers that are connected to the same policy store. These servers generate server and agent commands. The default is 30 seconds.

 Policy store data synchronization can be inconsistent. Synchronization issues can occur under the following conditions:

  • The system times on the Policy Servers differ.
  • Network latency.

For example, Policy Server A has a system time of 10:00 and Policy Server B has a system time of 10:05. Policy Server A sends its data to the policy store at 10:00, but Policy Server B does not record any changes. The data is time-stamped before 10:05 so according to Policy Server B, the updated events have occurred earlier.

Set the value to the number of seconds that corresponds to the time difference. For example, for a five-minute time difference, set the value of the key to 300.

If you specify a longer period than the default, the Policy Server reads older server commands from the policy store when synchronizing its cache. However, the Policy Server re-reads the same updates from the policy store that it already received. Re-reading the same updates does not affect data integrity because duplicate notifications are ignored.

AgentCmdStabilizationDuration 

The Policy Server maintains agent commands in cache. Every 15 seconds by default, the Policy Server searches for new agent commands from the policy store. When the agent polls the Policy Server for these commands, the Policy Server sends a list of agent commands newer than the time-stamp of the last agent command the agent received.

The AgentCmdStabilizationDuration specifies the amount of time the Policy Servers holds on to new agent commands. These newly loaded commands are considered unstable until the AgentCmdStabilizationDuration time period expires. After the specified time elapses, the agent commands are considered stable and the Policy Server sends them to the agent. The default stabilization period is 10 seconds.

The stabilization mechanism addresses situations where the Policy Server loads server commands in a given amount of time, but only a partial list of commands are read within that time. The stabilization period ensures that the Policy Server uses the same amount of time when querying for new agent commands.

If the agent is not getting updates properly, adjust this setting. The higher the value for this setting, the longer the Policy Server waits until it considers the agent commands stable before sending the commands to the polling agents. Also increase the value if the policy store is replicated and some commands have earlier time-stamps than other commands in the replicated store. The Policy Server could ignore commands with a time-stamp earlier than when it reads data from the policy store. The increased AgentCmdStabilizationDuration value ensures that the Policy Server keeps searching for objects that were created during the stabilization period.

 

Leave a Reply