NetIQ AppManager 7.0.x
NetIQ AppManager Management Server
AMAdmin_SiteSchedUpload Knowledge Script
AMAdmin_EnableSiteComm Knowledge Script
AMAdmin_SetLocalRPSize Knowledge Scripts
AMAdmin_ConfigSiteNetFlowCtrl Knowledge Script
To increase the scalability of AppManager, performance and event data can be stored in the local repository until you're ready to upload it to the Management Server, even when the Client Communication Manager and Management Server are communicating. Scheduled autonomy improves network bandwidth usage and allows the Management Server and repository to handle data from more servers.
For example, if collecting significant amounts of data on a Managed Client, the data can be stored locally while the network is busy - reducing the chance of hitting a network bandwidth wall - and then transferred to the Management Server according to a schedule (for example, between 3:00 AM and 5:00 AM when network traffic is light). Also, data from different Managed Clients can be scheduled at staggered times, reducing the load on the Management Server and repository. Scheduled autonomy is implemented using the AMAdmin_SiteSchedUpload Knowledge Script. Through parameters on the Values tab in the Knowledge Script Properties dialog box, you specify whether performance data and/or events are to be stored in the local repository. On the Schedule tab, you specify the upload schedule for the stored information.
The Knowledge Script immediately signals the Client Communication Manager service to begin storing in the local repository the specified information from all jobs running on the managed client.
At the scheduled upload time, the information is transferred to the Management Server.
To further configure the scheduled autonomy feature, you can run these Knowledge Scripts:
AMAdmin_ConfigSiteNetFlowCtrl specifies how much information can be sent to the management server at set intervals, allowing you to control how much network bandwidth AppManager uses.
AMAdmin_SetLocalRPSize Knowledge Scripts specifies the maximum number of events or data points that can be stored in the local repository. If all the information in the local repository can't be transferred to the Management Server because the upload time was too short or because of the network traffic flow configuration (or a combination of both), then the remaining information stays in the local repository.
Another way to have information stored in the local repository is by running the AMAdmin_DisableSiteComm Knowledge Script, which disables network communication from a Managed Client to the Management Server. Then, when you run the AMAdmin_EnableSiteComm Knowledge Script, which restores network connectivity, the information is transferred to the Management Server.
Enabling and disabling autonomy
To turn off autonomy so that updates occur without being routed through the Client Communication Manager service:
- 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.
- Change the value of the following registry key from 1 to 0:
- In the Services Control Panel or from the command line prompt, restart the AppManager services.
The Client Communication Manager service has the following configurable parameters in the Registry under this key: HKEY_LOCAL_MACHINE/Software/NetIQ/AppManager/4.0/NetIQccm/Config:
|This key||Controls the interval in seconds for|
Checking connectivity to each management server.
The default interval is 30 seconds.
Polling the managed client to find if there's been any data generated that needs to be sent to the management server.
At each PollMCInterval, the Client Communication Manager service checks for event messages and collected data. If there have been any events or data collected, the service reads and processes the information.
The Client Communication Manager also checks whether the managed client can communicate with each management server at each PingMSInterval. As it checks connectivity, the service sets a flag for each management server to indicate whether communication was successful. If the flag indicates the managed client can successfully connect to a management server, all events and data points are uploaded.
If the Client Communication Manager service is not running, the managed client sends job output directly to the management server. Once the service is up, all output goes through the service unless you explicitly turn off autonomy.
If an autonomous AppManager agent uses a local data repository and you suspect the local repository is in an inconsistent state, do a cold startup of the managed computer as described in Restarting the Client Resource Monitor.