Known issues, limitations, and workarounds

Word reports missing packages when working in a multislice environment deployed on top of a Logical Volume Manager (LVM) custom partitioning.

Workaround: Do not mount Word on the core servers where you are planning to install SA slices. Mount /var/opt/opsware/word on a local partition only for the core server where infrastructure/wordstore will be installed.

Packages are stored in the /var/opt/opsware/word on the infrastructure/wordstore server. Slices only mount the NFS export, therefore no actual space is required on the slice server for this folder.

Therefore, before installing the core make sure that /var/opt/opsware/word is not mounted and does not exist under /etc/fstab. After installation, only the wordstore NFS mount should be available.

Installing additional slices fails if recurring jobs are scheduled to run.

Workaround: Cancel any pending recurring scheduled jobs, and restart the slice installation.

CORD  installation on a secondary core fails if the installer runs word_uploads before patch_opsware.

When importing RedHat 6 rpms using redhat_import, any ++ characters available in the package title are converted to spaces.

This leads to the following error when trying to apply patches: An error occurred while installing or removing this package. The package may not be applicable to the selected server. Parameters: results: {0} package: {1} command: {2} Action: Ensure that the package is correctly defined and applicable to the selected server. If the problem persists, please contact technical support.

The tokens used by recurring app config compliance jobs have a limited lifetime of one year. This causes the recurring jobs to stop working without a warning.

Exporting a full CBT with all.rdf and cbt.numthreads=10 hangs.

Workaround: Run the export with a single CBT thread by setting cbt.numthreads=1 in the CBT configuration file.

By default, the configuration file is available on the HPE Server Automation core at /opt/opsware/cbt/cfg/default.properties

Users and Groups SMO do not report all the groups created on Windows 2012 Essentials. The SMO does not record any changes made to the user properties.

This means that audits with U&G rules are not accurate for Windows 2012 Essentials.

You cannot upgrade to version 10.60 if the SA Core’s existing certificate is MD5 base.

Workaround: Recertify the SA Core to use a different signature algorithm.

After upgrading SA 10.50 to SA 10.51, the certificates from keystore are deleted, which results in the failure of SA-OO Integration.

Workaround: Perform the following steps to reimport the certificates:

1. Stop the Web Services Data Access Engine (Twist):

   /etc/init.d/opsware-sas stop twist

2. Transfer the OO Central Certificate to SA:

   Note When you are prompted for a password, provide the password as changeit.

   1. Export the OO Central Certificate.

      The procedure to export the certificate may differ depending on the OS version you have on your OO server. For more details, see the OO documentation.

      Note The client certificate is not bundled with SA, therefore, you must run the certificate export command on the OO server.

      For example; run the following command to certificate from an OO 10.x instance installed on a Windows server:

      <OO_INSTALL_DIR>\java\bin\keytool.exe -exportcert -alias tomcat -file

      C:\oocentral.crt -keystore <OO_INSTALL_DIR>\central\var\security\key.store

   2. Import the OO Central Certificate to the SA Java Runtime Environment (JRE) Keystore:

      /opt/opsware/openjdk/jre/bin/keytool -importcert -alias oocert -file

      /tmp/oocentral.crt -keystore /opt/opsware/openjdk/jre/lib/security/cacerts

      Note The example above uses the alias, oocert. However, you can use any alias when importing the certificate, provided the alias is not already used in that keystore.

3. Verify whether OO Central Certificate was imported successfully:

   /opt/opsware/openjdk/jre/bin/keytool –list –alias oocert –keystore

   /opt/opsware/openjdk/jre/lib/security/cacerts

4. Restart the Web Services Data Access Engine (Twist):

   /etc/init.d/opsware-sas restart twist

If a custom certificate is added to the cert.pem file, this certificate is not available when rolling back the SA 10.51 cert pem patch.

Workaround: Back up /opt/opsware/openssl/cert.pem to a secure location and restore it after upgrading.

Some failed patch installations may show up as successful although they have been rolled back during server reboot.

Workaround: Always check the Patch Compliance page of the Job Status window to make sure you are getting the correct result for your remediation job.

When scanning hosts with ipv4 and ipv6 enabled, results show both ipv6 and ipv4 IPs. However, the SSH port is not available for IPv6.

Workaround: Modify the ADT scanning parameters based on the network topology, proxy and firewall rules.

If you cannot scan unmanaged servers via ADT on IPv6, go to the SA Client > Tools > Options > SA Agent Installation > Advanced and remove -S %GATEWAY_IP% --exclude %GATEWAY_IP% from the scan parameters.

Users and Group remediation jobs with multiple uses and user groups fail with the following error message: No Group found.

Workaround: Run a Users and Group remediation job with user groups followed by a remediation job. This remediates users that belong to the remediated user group.

Content import from HPE Live Network for SAVA fails in a air-gapped environments.

Workaround: Make sure you have network connectivity before you import content from HPELN.

When upgrading a core, SA may show UNITS and REALM_UNITS tables conflicts.

Workaround: Resolve conflicts manually or use the Force Resolver script then continue with the upgrade. To minimize the number of model repository conflicts, run all operations on units through the master spin.

Cannot delete VMs from the SA Client after a Create VM, Clone VM or Deploy VM from VM Template job fails running the OSBP, and the VM ends up in Build Server Failed state.

Workaround: Delete the VM from the native vendor tool and reload it into SA.

When installing a satellite, using a realm_name different than the facility name, breaks SA functionality.

The SA web interface is not accessible from Windows browsers if your SA certificates are using an SHA-224 signature algorithm.

This is not an SA issue, but a limitation of browsers when running on Windows.

Workaround: Access the SA web interface via a Linux browser.

The SA Java RMI Client, opswclient.jar, might not work on Windows platforms if your SA certificates are using an SHA-224 signature algorithm.

This is caused by the following JDK change: Remove SHA224 from the default support list if SunMSCAPI enabled.

Workaround: Disable the SunMSCAPI security provider. This restores support for SHA-224 in the JDK. To disable the SunMSCAPI provider either:

• edit <JRE_HOME>/lib/security/java.security and comment out the line that defines the SunMSCAPI provider OR
• disable the SunMSCAPI provider programatically by using the java.security.Security.removeProvider() method.