As discussed in Understanding the AppManager Agent, the Client Resource Monitor and the Client Communication Manager work together to start jobs automatically if a computer is shut down and to retain information about jobs, events, and data in the agent computer’s local repository if communication with the management server is interrupted. This default behavior is called Autonomous operation.
Autonomous operation requires the following:
The Client Communication Manager service must be running to log events and data points locally on the agent computer when the agent cannot communicate with the management server.
The Client Communication Manager service must be configured to periodically poll the management server and the Client Resource Monitor to determine the availability of the management server and whether events and data points should be stored locally or uploaded to the management server.
Although it ensures that data and events are not lost when communication with the management server is interrupted, autonomous operation requires the Client Resource Monitor and Client Communication Manager to be started together and to run continuously while a monitored computer is powered up.
NOTE:If the Client Communication Manager service is stopped, the Client Resource Monitor can send events and data directly to the management server. If the Client Communication Manager service is running, events and data are always passed by that service unless you explicitly disable Autonomy.
In some rare cases, you may need to temporarily disable Autonomous operation. If you disable Autonomous operation, be aware of the following:
The Client Resource Monitor agent service must be running for jobs to run and events and data to be collected.
The Client Resource Monitor agent service will bypass the Client Communication Manager and send events and data directly to the management server, if needed, as long as the management server is available. The Client Resource Monitor does not, however, write to the local repository. If the Client Communication Manager is stopped and the Client Resource Monitor cannot communicate with the management server, any event or data point generated while connectivity is down is lost.
Because of this potential loss of data, you should always run both agent services in Autonomous mode unless there is a specific need to temporarily stop the Client Communication Manager service and you can ensure connectivity between the Client Resource Monitor and the management server.
To turn off autonomy so that updates occur without being routed through the Client Communication Manager service:
On the agent computer, in the Services Control Panel or from the command-line prompt, stop the NetIQ AppManager Client Communication Manager and NetIQ AppManager Client Resource Monitor services.
Start the Registry Editor and change the value of the following registry key from 1 (Autonomous operation) to 0 (non-autonomous operation):
HKEY_LOCAL_MACHINE\Software\NetIQ\AppManager\4.0\Netiqmc\Config\Autonomy
In the Services Control Panel or from a command prompt, restart the AppManager services.
Periodically, the Client Communication Manager service checks the connectivity between the agent computer and the management server. Two registry keys control the interval for this checking under HKEY_LOCAL_MACHINE\Software\ NetIQ\AppManager\4.0\NetIQccm\Config:
|
Registry Key |
Interval Controlled |
|---|---|
|
PingMSInterval |
Checking connectivity to each management server. The default interval is 30 seconds. |
|
PollMCInterval |
Polling the Client Resource Monitor service (NetIQmc) to find if there’s been any data generated that needs to be sent to the management server. The default interval is 5 seconds. |
At each PollMCInterval, the Client Communication Manager (NetIQccm) service checks the Client Resource Monitor for new event messages and collected data. If there have been any events or data collected, the service processes the information and prepares to send it to the management server or the local repository.
At each PingMSInterval, the Client Communication Manager checks whether it can communicate with the management server. As it checks connectivity, the service sets a flag for each management server to indicate whether communication was successful. If the flag indicates the agent computer can successfully connect to a management server, all events and data points received are uploaded. If the flag indicates the communication with the management server was not successful, the Client Communication Manager sends events and data points to the local repository until the next PingMSInterval.
Although you can adjust both of these intervals for checking connectivity, you should be careful about doing so. For example, if you have a slow network connection between the agent computer and the management server, you may want to lengthen the time for the PingMSInterval key, but this may put a strain on the agent computer and its local repository or may prevent you from seeing problems promptly.
Before changing these intervals for any agent computer, consider the following:
The characteristics of the network connection between the managed computer and the management server computer. For example, if you have a high-speed, LAN connection, you should be able to maintain a shorter interval for checking the connection than if you have a WAN connection.
The characteristics of the managed computer in terms of available disk, memory, and CPU for checking connectivity and storing data locally between connections to the management server.
The type of monitoring you are doing and the intervals at which jobs run on the computer. For example, if jobs are scheduled to run at 15 minute or one hour intervals, you are less likely to generate a backlog of events and data points than when jobs run at two- or five-minute intervals.
The frequency at which you are seeing events on the agent computer. For example, if events are rare for a particular computer, you may feel more confident in increasing the PollMCInterval, PingMSInterval, or both intervals.