Situation 1
SP-AMS is not automating a connected system.
Explanations
Any of the following are possible explanations:
No SP-AMS database is active. This is the case if the Automation icon in the Status bar in Operations Sentinel Console shows Automation inactive.
Operations Sentinel server is not monitoring the system. This is the case if Operations Sentinel Console shows the value of the Automation State property for the system as Inactive.
[MCP]
A valid usercode and password were not submitted to the MCP system, or the Operations Sentinel Interface for MCP is not running on the MCP system.
Solutions
The following are possible solutions:
Activate an SP-AMS database by clicking Tools, AutomationControl, and then Activate in Operations Sentinel Console.
Begin monitoring the system by setting the Monitor value for that system to True in Operations Sentinel Console.
[MCP]
Activate a database containing a pattern that matches the SP-AMS internal automation initialization message with a valid usercode or password action. Force generation of the initialization message by disabling and re-enabling the connection to the system. The Administrator must set Monitor to False, save the changes, set Monitor to True, and then save the changes again.
[MCP]
Start the Operations Sentinel MCP agent on the MCP system. See the Operations Sentinel Interface for ClearPath MCP Installation and Configuration Guide.
Situation 2 [MCP]
The message
<<ASPO>> timeout waiting for SP-AMS usercode/password
appears in the console of an MCP system.
Explanations
The Operations Sentinel MCP agent is trying to connect to Operations Sentinel. The connection protocol requires that SP-AMS supply a usercode and password to the agent. The usercode and password come from the active SP-AMS database.
Solutions
Check the following to determine why the agent is not getting the usercode and password:
Verify if the Operations Sentinel server is monitoring the MCP (NX, LX, Libra, etc.) system.
If there is no SP-AMS database active, then activate a database that provides the usercode and password. The database MCPmon, included with Operations Sentinel, supplies a default usercode and password that you must update to the appropriate usercode and password for your MCP system.
Your site might also have developed your own SP-AMS database that supplies a usercode and password. The database responds to the message
SINGLE POINT AMS AUTOMATION STARTED USING DATABASE dbname FOR SYSTEM systemid
by supplying the usercode and password, they are automatically generated after the database is activated.
If the Operations Sentinel server already has the database active that you think is supplying the information, then there is probably an error in a database pattern. The following are the most likely causes of the error:
The system name has changed and no longer matches the pattern.
In this case, update the pattern with the new system name; then recompile and activate the database.
You modified pattern 2 in the C2 group in the MCPmon database to include the correct system ID but forgot to change OMIT to END before compiling the database.
In this case, change OMIT to END; then recompile and activate the database.
Some other pattern in the database is matching the message
SINGLE POINT AMS AUTOMATION STARTED …
and its actions are carried out instead of the ones that would supply the usercode and password. This would not happen with the MCPmon database, but could happen if you have added or modified patterns or combined databases.
In this case, use SP-AMS trace mode to determine the pattern that is matching this automation message; then update the pattern to include the ACTION PASSWORD command that supplies the usercode and password.
Situation 3 [UNIX]
The message
Host key does not match recorded value, possible security intrusion!
appears on the SSH-connected replicated console for a UNIX and Linux system or in the log for that system.
Explanation
When Operations Sentinel connects to a managed system using SSH protocol the first time, the managed system provides a key. Operations Sentinel stores this key in the registry on the Operations Sentinel server at the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Unisys\Single Point Operations\Security
On subsequent connections, Operations Sentinel compares this stored key with the key supplied by the managed system and continues if they match. They should match unless the keys on the managed system have been regenerated. This is typically a manual operation on the managed system. If the preceding message is received, Operations Sentinel cannot complete the connection.
Solution
In this situation you should confirm that the keys on the managed system have been regenerated, to verify that the managed system has not been compromised. If you are convinced your security has not been violated, edit the registry on your Operations Sentinel server to remove the key that Operations Sentinel stored. Start the registry editor and find the above key location. At this location you will see one key for each managed system and for each key type.
The keys are in the following form:
key-type@port-number system-name
where
key-type is
rsa for SSH version 1 connections
dss or rsa2 for SSH version 2 connections
port-number is typically 22
system-name is the network name of the system you configured in Operations Sentinel
Locate the item that corresponds to the system with the mismatched key and delete it. If there is more than one key for the system, delete all occurrences. The next time Operations Sentinel attempts to connect to that managed system, a new key is recorded in the registry for the system.