Known issues with IBM Spectrum Protect Operations Center Version 8.1.6

Answer

The following issues have been identified in version 8.1.6 of the Operations Center:

Log-in and general issues

• You cannot configure the Operations Center for first-time use
• Message: "ANR3218E UPDATE ADMIN: Administrator IBM-OC-server_name is a managed object and cannot be updated
• After deleting the Operations Center truststore file on AIX, you cannot open the Operations Center
• After upgrading the Operations Center, you cannot log in and you are redirected repeatedly to configure the hub server

Security Notifications

• A new client already has a security notification history

Replication

• You cannot configure replication by using the Add Server Pair wizard

Symptom

You are connecting to the Operations Center for the first time. You enter the connection and configuration information for the hub server in the appropriate fields, but the Configure Operations Center wizard does not complete. The wizard fails with the status message "Not ready to show server information".

Cause

If the Operations Center is not installed on the same computer as the IBM Spectrum Protect server, the "Connect to" field must identify the hub server by its IP address or full domain name. The wizard is unable to complete the configuration because only the hostname was provided.

Solution

When you are connecting to the Operations Center for the first time, enter the connection information for the hub server by using the following syntax: host:port_number.

host

If the Operations Center is installed on the same computer as the IBM Spectrum Protect server, enter localhost . If the server is installed on a different computer, enter the IP address or full domain name of that computer.

port_number

If the ADMINONCLIENTPORT server option is enabled for the IBM Spectrum Protect server, enter the port number that is specified by the TCPADMINPORT server option. If the ADMINONCLIENTPORT server option is not enabled, enter the port number that is specified by the TCPPORT server option.

You can view server option settings by using the QUERY OPTION command.

Return to list

Symptom

The error message ANR3218E is displayed. This error might be displayed when you try to connect a spoke server to the hub server, or when you try to update passwords on spoke servers.

Cause

The Operations Center runs independently of enterprise configuration, and is unable to update user IDs that are managed by the configuration manager. An administrator ID that the Operations Center creates and maintains on spoke servers was unintentionally placed under the control of the configuration manager.

When you try to connect a spoke server to the hub, the Operations Center attempts to register the monitoring administrator ID, IBM-OC-server_name, on the new spoke server. This same monitoring administrator ID with the same password is registered on the hub server and on all spoke servers. Periodically, the Operations Center automatically updates the monitoring administrator ID password on the hub and spoke servers. You typically do not need to use or manage this password. If the password update was not successful, and the Operation Center detects that the passwords on one or more spokes are not current, it prompts you to have it attempt the password update again.

If the error message ANR321E is displayed when you try to connect a spoke server or update a spoke server's monitoring administrator ID password, it might be because the monitoring administrator ID was inadvertently placed under the configuration manager's control. You might unintentionally place the monitoring administrator ID under the control of the configuration manager when you issue the DEFINE PROFASSOCIATION command. If you use a wildcard character in the DEFINE PROFASSOCIATION command to identify which administrators are associated with the configuration profile, you might unintentionally match the monitoring administrator ID. For example, you might associate all administrator IDs with the configuration profile by specifying admins=* in the DEFINE PROFASSOCIATION command.

Solution

Do not specify admins=* in the DEFINE PROFASSOCIATION command when you associate administrator IDs with the configuration profile. Instead, list all administrator IDs, excluding the monitoring administrator ID, in the command. For example, admins=admin1,admin2,admin3,admin4. Make sure to update the list when administrator IDs are added to or removed from the hub server.

Tip: You can use an enterprise configuration to maintain the monitoring administrator ID on spoke servers, but only if you designate the configuration manager server as the Operations Center hub server. For more information about grouping hub and spoke servers in an enterprise configuration, see
https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.6/srv.install/c_oc_inst_reqs_tips_for_hub_spoke.html

Return to list

Symptom

You are running the Operations Center on an AIX system. Because you forgot the password for the Operations Center truststore file, you needed to reset the password. To reset the password, you completed the steps outlined in the following topic in the IBM Knowledge Center:

https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.6/srv.install/t_oc_inst_ts_truststore_password_reset.html

Although you completed these steps, you cannot open the Operations Center to log in. Entering the URL for the Operations Center in a web browser does not display the log in page.

Cause

On Windows and Linux machines, starting the Operations Center web server as described in the documented procedure automatically creates a new truststore file and the TLS certificate for the Operations Center is automatically included in the truststore file. On AIX machines, you might need to stop and restart the Operations Center as described in the following steps.

Solution

Complete the following steps to stop and restart the Operations Center web server:

1. Issue the following command to start the Operations Center web server:
   /opt/tivoli/tsm/ui/Liberty/bin/server start guiServer

   A new truststore file is automatically created for the Operations Center, and the TLS certificate of the Operations Center is automatically included in the truststore file. However, the Operations Center will likely not be available.

2. Issue the following command to stop the Operations Center web server:
   /opt/tivoli/tsm/ui/Liberty/server stop guiServer
3. Issue the following command to restart the Operations Center web server:
   /opt/tivoli/tsm/ui/utils/startServer.sh

Return to list

Symptom

You were running an earlier version of the Operations Center. Communication between the Operations Center and web browsers was secured by using a certificate that was signed by a third-party certificate authority (CA). You upgraded the Operations Center to the new version, and now the browser does not display the login page. When you enter the address for the login page, you are redirected to a page to configure the hub server. Even if you enter the connection information for the hub server, you are redirected back to the configuration page.

Cause

The label on CA-signed certificate has a value other than "default". In previous versions of the Operations Center, the certificate label could be any name. However, in V8.1.6 and later, the certificate label must be the name "default".

Solution

Change the CA-signed certificate label to "default". For example, to change the label by using the ikeycmd command, complete the following steps:

1. From the command line, change the directory to the keystore location.

   AIX and Linux

   installation_dir/ui/Liberty/usr/servers/guiServer

   Windows

   installation_dir\ui\Liberty\usr\servers\guiServer

2. Issue the following command:

   ikeycmd -cert -db gui-truststore.jks -pw password -label certificate_label -new_label default

   Where:

   -pw password

   Specifies the password of the gui-truststore.jks truststore.

   -label certificate_label

   Identifies the CA-signed certificate by its current label.

   -new_label default

   Specifies the name for the certificate, which is default.

    

Return to list

Symptom

You register a client to an IBM Spectrum Protect server that is managed by the Operations Center. Although the client was recently added, it has a security notification history that predates its definition on the server. For example, you might observe the following symptoms:

• On the Security Notifications page, the Occurrences column for a client might show a count that is greater than the number of client backup operations.
• When you select a security notification on the Security Notifications page, the detailed information shows a history from before the client was defined.

Cause

The new client has the same name as a client that was previously defined on the server. When a client is removed from a server, its security notification history is not removed from the database. If a new client is defined with the same name, the Operations Center incorrectly assigns the earlier client's security notification history to the new client. This history includes any security notifications that were reported for the earlier client and the earlier client's baseline historical data. The earlier client's security notifications might be shown on the Security Notifications page. Backup characteristics for the new client might not resemble the earlier client's historical data, so backup operations from the new client might generate security notifications that are false positives.

Solution

Understand that registering a new client with the same name as a client that was removed from the server might result in security notifications that are false positives. If you observe any of the symptoms of false positives that are ceased by an inaccurate security notification history, you can reset security notifications for new client. When you reset security notifications for a client, historical data that was used for baseline comparison with current backup sessions is deleted, and a new historical baseline data is calculated going forward. To reset security notifications for a client, complete the following steps:

1. To open the Security Notifications page, click Overview>Security. The Security Notifications table contains one entry for each client for which at least one security incident was detected.
2. On the Security Notifications page, select the client's security notifications entry in the table.
3. Click Reset.

Return to list

Symptom

You are using the Add Server Pair wizard to define a source and target server relationship for replicating client data. You cannot advance past the Passwords page of the wizard, which displays the error "Unable to connect".

Cause

IBM Spectrum Protect V8.1.2 and later enforces stricter security requirements for network communication. All servers, for example, are expected to secure communication by using TLS 1.2 certificates. Although a transition period exists during which existing security settings are used for communication with servers and clients that are running earlier versions, the stricter security settings are required after they are first used.

All actions that are taken by the wizard are performed on behalf of the administrator who is logged in to the Operations Center. Because the administrator account has authenticated by using the stricter security settings, all communication that is initiated by the administrator must also use the stricter security settings. This restriction might cause the Add Server Pair wizard to fail because it cannot establish a session with the source or target replication server.

Solution

Use the Command Builder to configure replication. To use the Command Builder to configure replication between the servers, complete the following steps:

1. Configure server-to-server communication between the source and target servers by using the DEFINE SERVER command. Issue the command on the source server to define the target server, and on the target server to define the source server.
2. On the source server, issue the SET REPLSERVER command to set the target server.
3. To define a client replication schedule, use the DEFINE SCHEDULE command to create a new administrative schedule on the source server to run the REPLICATE NODE command.
4. To improve the performance of client replication, use the DEFINE SCHEDULE command to create a new administrative schedule on the source server to run the PROTECT STGPOOL command. By regularly running the PROTECT STGPOOL command to copy data in a directory-container storage pool to the target server, you can improve replication performance. Replication performance is typically improved because the data extents that are already copied to the target replication server by storage pool protection operations are skipped when node replication is started. Schedule enough time for the PROTECT STGPOOL schedule to complete before the REPLICATE NODE schedule starts.

Return to list