Environment
NetIQ AppManager Enterprise 8.2
NetIQ AppManager Enterprise 8.0.3
NetIQ AppManager Enterprise 7.0.1
NetIQ AppManager Agent
NetIQ AppManager Enterprise 8.0.3
NetIQ AppManager Enterprise 7.0.1
NetIQ AppManager Agent
Situation
When you check the mctrace.log from one or more AppManager Windows Agents in your AppManager environment, you find the following message repeated throughout the log at varying intervals:
"mcGetMaintStatusFromMS : failed to get adhoc maintenance status from ms <x.x.x.x>, rc=87"
"mcGetMaintStatusFromMS : failed to get adhoc maintenance status from ms <x.x.x.x>, rc=87"
Resolution
The easiest and quickest way to stop these error messages from occurring is to clean up the MSConfig.txt file on the affected Agent(s), leaving only the valid, current IP address(es) of any Management Server to which the Agent should still be attempting to communicate with (both the current Primary, and current Secondary MS).
All other IP addresses should be removed from the file. Once the file has been cleaned up, simply Warm-Start (Stop and then Start) the NetIQ AppManager Client Resource Monitor service on the Agent, and the errors should stop occurring in the mctrace.log file for that Agent.
All other IP addresses should be removed from the file. Once the file has been cleaned up, simply Warm-Start (Stop and then Start) the NetIQ AppManager Client Resource Monitor service on the Agent, and the errors should stop occurring in the mctrace.log file for that Agent.
Cause
When an AppManager Agent is told who its Primary (and optionally) Secondary Management Servers (MSs) are, the IP address of each MS is stored in the MSConfig.txt file on the Agent. This entry allows the Agent to find its MS(s) on the network quickly, after an Agent's services are re-started for any reason.
When an Agent is migrated to a new QDB, or is told to use a new MS as either Primary or Secondary, a new entry is made in the MSConfig.txt file for the new MS(s) that it will be speaking to going forward, but the original entries are not cleaned out in an automated fashion. The result is that you can have entries in the MSConfig.txt file that are no longer valid.
The Agent has several self-checks that it must perform regularly, and it will always attempt to use any IP Addresses that it finds in the MSConfig.txt file, in order to make contact with each assigned MS, in order to complete those self-checks. When it tries to use an IP address that it finds in the MSConfig.txt file, for an MS that is no longer assigned to that Agent, the Agent will generate the error message mentioned in the Situation portion of this article.
When an Agent is migrated to a new QDB, or is told to use a new MS as either Primary or Secondary, a new entry is made in the MSConfig.txt file for the new MS(s) that it will be speaking to going forward, but the original entries are not cleaned out in an automated fashion. The result is that you can have entries in the MSConfig.txt file that are no longer valid.
The Agent has several self-checks that it must perform regularly, and it will always attempt to use any IP Addresses that it finds in the MSConfig.txt file, in order to make contact with each assigned MS, in order to complete those self-checks. When it tries to use an IP address that it finds in the MSConfig.txt file, for an MS that is no longer assigned to that Agent, the Agent will generate the error message mentioned in the Situation portion of this article.