HP Server Automation 7.85 Release Notes

for the HP-UX, IBM AIX, Red Hat Enterprise Linux, Solaris, SUSE Linux Enterprise Server, VMware, and Windows® Operating Systems

Software version: 7.85

Original publication date: December 2010

This document is an overview of the changes made to Server Automation. It contains important information that is not included in books or Help.

Note: The only new or revised guide in this release is the APX for Configuring LVM and MPIO: User Guide.

Table of Contents

You can find information about the following in this document:

What's New In this Release?

Server Automation release notes contain information for Server Automation, Storage Visibility and Automation, SE Connector, and other changes.

For information on what was new in previous releases, please see the corresponding release.

Fujitsu Clusters

Support for Fujitsu Clusters

As of 7.85, SA supports Fujitsu clusters. A Fujitsu cluster is a cluster designed for a Solaris system that runs on Fujitsu hardware. This section contains information pertaining to these clusters. For more information on clusters, see the SA User Guide: Application Automation.

Issuing SA Commands

You can use the same cluster commands for Fujitsu clusters as you do for standard Solaris clusters.
Use the following command to display more information on cluster commands:
/opt/opsware/solpatch_import –manual
Fujitsu clusters can only be imported using the solpatch_import command.

Special Considerations for Downloading Fujitsu Clusters

If you use a single solpatch_import command to download both a Fujitsu cluster and a Solaris Recommended cluster file, both files will be downloaded to the same location but will not imported into the SA core. The first downloaded cluster will be overwritten by the second downloaded cluster, because both clusters have the same file names (such as: 10_Recommended.zip). To avoid overwriting one file with the other, do not use a single solpatch_import command to download the two clusters. Instead, download the first cluster, move it to a different location, then download the second one.

Note: You can still use a single solpatch_import command to import Fujitsu clusters and standard Solaris Recommended clusters for the same platform because when SA imports a file, it downloads and then immediately imports it to the core, no file overwriting can occur.

Special Considerations When Creating Patch Policies for Fujitsu With the -policy Option

You can create patch policies for any cluster from the command line or in the SA Client.
When you create a patch policy for a Fujitsu cluster using the –policy option from a command line, all applicable patches included in the cluster are applied  (regardless of whether Fujitsu intended them to be installed on your hardware model, using the cluster install). These extra patches do not cause harm. However, if you would rather apply only the patches that Fujitsu has designated for your hardware model, use the SA Client to create a new policy, and include the Fujitsu cluster. When you remediate the policy, SA will correctly apply the relevant patches only.

Sun Solaris Moves to Oracle

As of the 7.85 release, Oracle and Sun were in the process of retiring the SunSolve web site and establishing a new Oracle support web site for Solaris patches and patch information. Once this transition is complete, HP will provide information about how to modify your solpatch_import.conf file to ensure that Solaris patching with SA continues to work correctly.

This information will be posted on the standard HP support channels.
For more information on Solaris patching and the solpatch_import.conf file, see the SA User Guide: Application Automation.

For more information, see the Knowledge Base Article KM1032711 at: (http://support.openview.hp.com/selfsolve).

New Command Engine System Configuration Parameter

A new system configuration parameter, way.remediate.yum, was added under Command Engine to solve the issue where the RedHat server 5 x64 OS update software policy was not honoring kernel RPM dependencies. 

This parameter enables you to use YUM (Yellowdog Updater Modified) for install/remove transactions, which greatly simplifies the installation process when a package has a lot of dependencies. YUM is a frontend that can be used with RPM (Red Hat Package Manager) to perform install and remove transactions. Unlike RPM, YUM is capable of tracking the dependencies of a package and installing them prior to installing the package that the user wants to install.

You can use the way.remediate.yum parameter to specify which tool will be used to install RPM packages. Possible values:
  0 = only use RPM.
  1 = use YUM when available else use RPM. (default)
  2 = only use YUM.

YUM version 2.4.3 and greater is supported.

Faster Application Configuration Pushes

You can speed up your application configuration pushes by disabling the restore capability. This section describes how to disable the restore capability.

For complete details on application configurations, see the SA Application Configuration User Guide .

Whenever you push an application configuration to a server, SA creates a snapshot of the server's configuration files. If you later restore the configuration file on the server, SA uses the snapshot to restore the configurations. One way to speed up application configuration pushes is to disable the snapshot creation. However, when you disable the snapshot creation, you also disable the ability to restore previous application configurations. Only disable snapshot creation if you are sure you will not need to restore your application configurations to a previous state.

You can disable snapshot creation in one of two ways:

1. Disable snapshot creation for all servers: Set the global configuration parameter appconfig.disable_snapshots to 2, as described below.
2. Disable snapshot creation for some servers:

• Set the global configuration parameter appconfig.disable_snapshots to 1, as described below.
• On the servers where you want a snapshot, set a custom attribute named appconfig.enable_snapshots to 1, as described below.
• Optionally, for completeness, you can also set a custom attribute named appconfig.enable_snapshots to 0 (or any value other than 1), on all servers where you do not want snapshots created.

  For more information about custom attributes, see the SA User Guide: Server Automation .

Disabling Snapshots for Application Configuration Pushes

To disable snapshot creation and the ability to restore previous application configurations, perform the following steps.

1. Log in to the SAS Web Client as a user that is a member of the Opsware System Administrator user group.
2. In the SAS Web Client, select System Configuration, under the Administration section in the navigation pane. This displays the System Configuration screen.
3. In the System Configuration screen, select Web Services Data Access Engine. This displays configuration settings for the Web Services Data Access Engine.
4. Locate the configuration parameter named "appconfig.disable_snapshots".
5. Set the value of appconfig.disable_snapshots to one of the following values:
   • 0 - Take a snapshot and enable application configuration restores on all managed servers. This is the default value.
   • 1 - Only take a snapshot if the server that the application configuration is being pushed to has defined or inherited a custom attribute named appconfig.enable_snapshots and the custom attribute has a value of 1. If the custom attribute is not defined on a server or if the value is anything other than 1, a snapshot will not be taken on that server.
   • 2 - Do not take a snapshot on any servers. This disables application configuration restores on all managed servers.
6. Scroll down to the bottom of the screen and select the Save button.
7. Run the command below on each server hosting a Slice Component bundle in your SA Core to restart the Web Services Data Access Engine. For detailed instructions, see the SA Administration Guide.
   
   /etc/init.d/opsware-sas restart twist
8. If you set the value of the appconfig.disable_snapshots to 0 or 2, skip the remaining steps.
9. If you set the value of the appconfig.disable_snapshots to 1, create a custom attribute named appconfig.enable_snapshots where you want the snapshot to be taken and set its value to 0. Custom attributes can be created on device groups, customers and facilities and they apply to all servers in the device group, customer and facility, respectively. You can also create custom attributes on software policies and all servers with the software policy attached inherit the custom attribute.
   
   For more information about custom attributes, see the SA User Guide: Server Automation.
10. Optionally, on the servers where you do not want snapshots created, create a custom attribute named appconfig.enable_snapshots and set its value to 0. This step is optional because the snapshot will not be taken on any servers that do not define the custom attribute.

The following table shows when a snapshot will be created when you push application configurations depending on the value of the global configuration parameter appconfig.disable_snapshots and the value of the appconfig.enable_snapshots custom attribute on individual servers:

When Snapshots are Created

Enabling Snapshots for All Application Configuration Pushes on All Servers

To enable snapshot creation and enable the ability to restore previous application configurations on all your managed servers, perform the following steps.

1. Log in to the SAS Web Client with a user that is a member of the Opsware System Administrator user group.
2. In the SAS Web Client, select System Configuration, under the Administration section in the navigation pane. This displays the System Configuration screen.
3. In the System Configuration screen, select Web Services Data Access Engine. This displays configuration settings for the Web Services Data Access Engine.
4. Locate the global configuration parameter named "appconfig.disable_snapshots".
5. Set the value of appconfig.disable_snapshots to 0.
6. Scroll down to the bottom of the screen and select the Save button.
7. Run the command below on each server hosting a Slice Component bundle in your SA Core to restart the Web Services Data Access Engine. For detailed instructions, see the SA Administration Guide.
   
   /etc/init.d/opsware-sas restart twist

This creates snapshots for all application configuration pushes on all managed servers.

New In Storage Visibility and Automation

APX Created to Configure Volume Manager

A WAPX (Web Application Programming eXtension) solution to automate the configuration of Linux Native Volume Management (LVM) is new for this release. This new feature helps streamline the configuration of volume managers on SA managed servers.

MPIO configuration is NOT supported in 7.85.

See the APX for Configuring LVM and MPIO: User Guide for more information.

New in the SE Connector

Attaching and Remediating the SE Storage Scanner and SE Connector Update Policies

This section describes the steps to follow when you attach and remediate the SE Storage Scanner and SE Connector Update policies.

To attach and remediate:

1. Attach the software policy SE Storage Scanner to the managed server
2. Remediate the server.
3. If your HP Storage Essentials management server is version 6.1.1, you do not need to follow any more steps.
4. If the HP Storage Essentials management server is version 6.2 or later, attach the software policy SE Connector Update for your version to the managed server.

Note: The version of the SE Connector Update must be compatible with the version of the Storage Essentials server, which means that the version numbers of the SE Connector Update libraries must be the same as the version of the Storage Essentials. For example, if you have SE 6.2, installed, you will have to install the SE Storage Scanner first, then install the SE Connector Update for 6.2.

Fixed and Known Issues

Critical fixes and known issues each have their own tables: see Fixed Issues and Known Issues. Within those tables, defects are conveniently listed alphabetically by subsystem, and then numerically under each subsystem.

Supported Operating Systems and Platforms

For a list of supported operating systems and platforms for Server Automation Cores, Agents, clients, and Satellites, see the Server Automation Support and Compatibility Matrix .

For a list of supported operating systems and platforms for Storage Visibility and Automation Managed Servers, SE Connector, SAN Arrays, Fibre Channel Adapters,
SAN Switches, File System Software, Database Support, and Storage Essentials Compatibility, see the Storage Visibility and Automation Support and Compatibility Matrix .

To check for updates to these documents, go to:
http://support.openview.hp.com/selfsolve/manuals

The HP Software Product Manuals site requires that you register for an HP Passport and sign in. To register for an HP Passport, select the New users - please register link on the HP Passport login page.

Back to the Table of Contents

Installation

This section describes the SA 7.85 installation procedure.

General Information

• SA can be rolled back, but only to the previous full release (SA 7.80).
• The patch_opsware.sh script is used both for installing and uninstalling.
• There's no need to supply a response file with patch_opsware.sh .
• The patch_database.sh script is used both for installing and rolling back database schema changes required for this release.
• You must run the patch_database.sh script on all Model Repository hosts in the First Core and all Secondary Cores. Note that the Oracle database can exist on a different host than the Model Repository host.
• The response file used to last install/upgrade of the SA Core must be supplied when invoking patch_database.sh.
• This patch includes updated Server Agents that will be uploaded to the Software Repository. However, no agents will be upgraded on core machines (that is, in the Model Repository) or on Managed Servers without manual intervention
• SA can only be installed on systems running SA versions with a Build ID of opsware_37.0.3006.

If any installed SA components (other than a previously installed patch) have a different build ID, you won't be allowed to install this patch.

To determine the build ID for a core machine, open the file:

/var/opt/opsware/install_opsware/inv/install.inv

and find the section beginning with %basics_ . Under this line, find the build_id .

For example:

%basics_linux

build_id: opsware_37.0.3006.*

When you install an SA patch, the patch installation updates the install.inv file to record the patch installation and the patch build ID. For example:

%opsware_patch

build_id: opsware_37.0.3826.0

• Before a patch operation (such as install/upgrade/uninstall), all core/satellite services must be up and running. If any services are stopped or dysfunctional (as reported by the /etc/init.d/opsware-sas status command), the patch operation will terminate.
• Upon completion of a patch operation, all services on the core/satellite machine should be up and running.
• If you are patching a multi-host core/satellite, you must patch each core and satellite host separately, one at a time.
• If you are patching a Multi-master mesh, HP recommends that you patch the primary core first, followed by secondary cores and satellites, thus ensuring that the primary core is at a higher version (such as SA 7.85 or higher) than the secondary cores.

If you must roll back this patch in a Multi-master Mesh, HP recommends that you roll back the secondary cores and satellites first, then the primary core.

• Mixed version core environments are not supported. However, during the patch upgrade, a transitory mixed core version environment is supported. For example, while the patch upgrade is in progress, cores at different patch levels can temporarily coexist in a Multimaster Mesh.
• In order to patch and/or roll back Wayscripts, the spog.pkcs8 certificate must exist under/var/opt/opsware/crypto (typically the certificate is installed with the Shell, SAS Web Client, or Build Manager). If the certificate does not exist, the patch operation will fail with the following error:

Could not find spog.pkcs8 /var/opt/opsware/crypto

Copy the certificate from another core machine (for example, occ ) to

/var/opt/opsware/crypto/oi

and retry this operation.

If this error is encountered, simply copy the certificate from another core machine to your core server and retry the operation.

• In order to patch and/or roll back Software Repository ( word ) updates, the spin.srv certificate must exist under /var/opt/opsware/crypto (typically the certificate is installed with the Web Services Data Access Engine ( spin )). If the certificate does not exist, the patch operation will fail with the following error:

  Could not find spin.srv under /var/opt/opsware/crypto.

  Copy the certificate from another core machine (such as occ) to

  /var/opt/opsware/crypto/oi

  and retry this operation.

• The following error may occur during upgrade on cores on which Solaris patching has not yet been set up:

  You don't have permission to update the patch meta database in HP SA.
Please re-run this command with a proper hpsa_user and hpsa_pass.
T he hpsa_user needs permission to write the folder
"/Opsware/Tools/Solaris Patching" and the Package Management
Client Feature, "Manage Package" permission set "Read & Write".
There was a problem with running update_supplements.
Please refer to section Patch Management for Solaris of the Users Guide:
Application Automation manual for details on how to set up Solaris
patching on your core.

  You can safely disregard this error.

MBSA 2.1.1 Supported for SA 7.84 and Later

Obtain the required Windows patch management files by performing the following tasks:

1. Obtain the following files from Microsoft:
   • mbsacli.exe (version 2.1.1)

   This file is packaged with the MBSA 2.1.1 setup file, MBSASetup-x86-EN.msi, that you must download from:

   http://www.microsoft.com/downloads/en/details.aspx?FamilyID=B1E76BBE-71DF-41E8-8B52-C871D012BA78

   After the download, on a Windows machine run MBSASetup-x86-EN.msi to install MBSA 2.1.1. In the directory where you installed MBSA 2.1.1, locate the mbsacli.exe file. By default, the file is installed here:
   %program files%\Microsoft Baseline Security
Analyzer 2\mbsacli.ex

   • wusscan.dll

     The wusscan.dll file is in the directory where you installed MBSA 2.1.1. By default, the file is here:
     %program files%\Microsoft Baseline Security
Analyzer 2\wusscan.dll

2. Import the files you just downloaded into SA:
   1. Log in to the SA Client.
   2. Navigate to Administration > Patch Settings > Windows Patch Utilities.
   3. Select the Windows Patch Utility.
   4. Select the Utility name in the table.
   5. Select the Import Utility Update button to open the Import Patch Utility file picker.
   6. Select one of the files (mbsacli.exe or wusscan.dll) that you downloaded from Microsoft.
   7. Click the Import button.
   8. Repeat steps d through g for the second file.
      

   These patch management files will be copied to all managed Windows servers during software registration.
   For more information on Windows Patch Management, see the SA User's Guide: Application Automation.

Script Running Order

The pre-patch, database update and patch install scripts must be run in the following order:

Table 2 - SA Script Running Order - Upgrade

Table 3 - SA Script Running Order - Rollback

Note: When you upgrade from 7.8x to 7.85, you do not need to run the prepatch.sh script, since it should already have been applied during the upgrade to 7.8x.

Pre-Patch Procedure

You must complete the following pre-patch procedure before applying the SA 7.85 patch.

Managed Platform Update

You must install an SA update on 7.80 cores before installing the SA 7.85 patch. If you are upgrading from SA 7.81 or 7.82, this update will have already been installed. This update enables the SA Core to handle new supported managed platforms introduced in CORD patch releases by ensuring mesh compatibility between a First Core patched with SA 7.84 and unpatched Secondary Cores.
The update should be applied to each Slice Component bundle host in all secondary cores and only needs to be applied once during the lifetime of the SA 7.80 server. If for some reason you have not applied the update, the CORD installation will automatically install the update before installing the CORD release.

Note: This update cannot be rolled-back.

To install the pre-patch update, run the following script: <distro>/opsware_installer/tools/prepatch.sh

If the patch has not been previously been applied, the following is displayed:

Patching /opt/opsware/occclient/ngui.jar

If the patch has been previously applied, the following will be displayed:

/opt/opsware/occclient/ngui.jar checksum = <current MD5 checksum>

Patch not applicable

Database Schema Update Procedure

The script run during this procedure makes required changes to the Model Repository including adding required tables and objects. Perform the following tasks to install SA 7.85 database updates:

1. Mount the SA 7.85 distribution. Invoke patch_database.sh on the Model Repository host:
   
   

   <distro>/opsware_installer/patch_database.sh --verbose -r <response file>

   Where <response file> is the response file last used to install/upgrade the system.

   Usage: patch_database.sh [--verbose] -r <response file>

   patch_database.sh automatically detects if a database update is already
   installed and presents a corresponding menu:

   1. If the database update has not been previously applied, you see the following:
      Welcome to the Opsware Installer.
It appears that you do not have a database update
installed on this system.
Press 'i' to proceed with patch installation.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: i

      Enter i at the prompt to begin the database update.

   2. If the database update has previously been applied, you see the following:
      

      Welcome to the Opsware Installer.
It appears that you have installed or attempted
to install a previous version of the database
update on this system.
Press 'u' to upgrade the patch to the current version.
Press 'r' to remove this patch.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: u
You chose to upgrade the patch. Continue? [y/n]: y

      Enter u at the prompt then Y to begin the database update.

2. After you make your selection, the installer completes the new (or interrupted) installation.
   On completion, you see a screen similar to the following:

   [timestamp] Done with component Opsware SQL patches.

   [timestamp] ########################################################

   [timestamp] Opsware Installer ran successfully.

   [timestamp] ########################################################

Note: After running the patch_database.sh script, you may see the following error when running the System Diagnostic test on your core:

Test Name: Model Repository Schema
Description: Verifies that the Data Access Engine's version of the schema matches
the Model Repository's version.
Component device: Data Access Engine (spin)
Test Results: The following tables differ between the Data Access Engine and the
Model Repository: local_data_centers, role_class_bridge.

This error is invalid and you can disregard it.

Patch Installation Procedure

Note: Before performing the tasks in this section ensure that you have completed the tasks listed in the following sections: MBSA 2.1.1 Supported for SA 7.85 and Later, Managed Platform Update, and Database Schema Update Procedure.

Perform the following tasks to install SA 7.85:

1. Mount the SA 7.85 distribution. Invoke patch_opsware.sh on every host in the
   core/satellite facility:
   
   

   <distro>/opsware_installer/patch_opsware.sh --verbose

   Usage : patch_opsware.sh [--verbose]

   patch_opsware.sh automatically detects whether or not there is a patch
   already installed and presents a corresponding menu:

   1. Non-upgraded System : If your system has not been upgraded, you see the following menu:
      Welcome to the Opsware Installer. It appears that
you do not have any patches installed on this system.
Press 'i' to proceed with patch installation.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: i

      Enter i at the prompt to begin the installation.

   2. Previously Upgraded System : If an SA patch has already been installed successfully, when patch_opsware.sh is invoked from a newer patch release, you see the following menu:
      Welcome to the Opsware Installer. It appears that you have
installed or attempted to install a previous version of
the patch on this system.
Press 'u' to upgrade the patch to the current version.
Press 'r' to remove this patch.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: u

      Enter u at the prompt to begin the upgrade.

2. After you make your selection, the installer completes the new (or interrupted) installation.

   The installer displays the following upon completion:

   [<timestamp>] Done with component Opsware Patch.

   [<timestamp>]

   ########################################################

   [<timestamp>] Opsware Installer ran successfully.

   [<timestamp>]

   ########################################################

Software Repository Content Upgrade

This section details upgrades to the software repository content on the upload distribution (such as agent packages to be reconciled to managed servers).

General Information

If you are upgrading a core hosted on multiple servers, the Software Repository content patch must be applied to the server hosting the Software Repository Store ( word store ).

If you are upgrading a Multimaster Mesh, the Software Repository content upgrade should only be applied to the First Core (the upgraded content will automatically be propagated to other cores in the mesh).

 Note: Unlike core patches, Software Repository content upgrades cannot be rolled back.

Upgrading the First Core Content

1. On the First Core Software Repository store ( word store ) host, invoke the upgrade script:
   
   

   <distro>/opsware_installer/patch_contents.sh --verbose -r <response file>

   where <response file> is the response file last used to install/upgrade the SA Core.

   The following menu is displayed:

   Welcome to the Opsware Installer. Please select the components
to install.
1 ( ) Software Repository - Content (install once per mesh)
Enter a component number to toggle ('a' for all, 'n' for none).
When ready, press 'c' to continue, or 'q' to quit.
   
   Enter either 1 or a and press c to begin the installation.
   

2. If the Software Repository content image is not installed on the server, the following message will be displayed:

   [<timestamp>] There are no components to upgrade.
[<timestamp>] Exiting Opsware Installer.

Rolling Back the Patch

To rollback SA 7.85 to SA 7.80, invoke the script:

<distro>/opsware_installer/patch_opsware.sh --verbose

If this is a patched system, the following will be displayed:

Welcome to the Opsware Installer. It appears that you have previously
completed installation of this patch on this system.
Press 'r' to remove this patch.
Press 's' to show patch contents.
Press 'q' to quit.
Selection:

Enter r at the prompt to remove the patch.

Note: Rolling back SA 7.85 does not:

• Remove the Windows Server 2008 data that was created when the core was upgraded.
  For example, any Windows Server 2008 patches or policies created will remain. If you try to install these patches or attach the policies, an error will occur.
• Delete any patches and policies that you have imported or created after the upgrade and these may fail with an error if you attempt to run them.

Rolling Back the Database Schema Update

To roll back the database schema update, enter this command:

<distro>/opsware_installer/patch_database.sh --verbose -r <response file>

Where <response file> is the response file last used to install/upgrade the system.

If the database has been updated, you see the following:

Welcome to the Opsware Installer. It appears that you have previously
completed the installation of this database update on this system.
Press 'r' to remove this patch.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: r

Enter r at the prompt to begin the database schema update rollback.

Post-Patch Installation Tasks

Completing the Update to the Waypurge Garbage Collection Procedure

When you ran the SA 7.85 patch_database.sh script, Garbage Collection was modified so that during the next run, the old child records are completely deleted from the SESSION_SERVICE_INSTANCES table to improve performance.

After you have upgraded to SA 7.85, you should perform the following tasks to delete any existing old child records in your SESSION_SERVICE_INSTANCES table which reduces the size of the table.

Note: The following steps are optional but HP highly recommends that you perform this step, especially for large databases. If this step is not performed then nightly Waypurge Garbage Collection job will run automatically and delete the old unwanted records.

Changes Made by patch_database.sh

When you ran the pre-patch script, patch_database.sh, it updated the Waypurge garbage collection PL/SQL and added a new WAY_GC_SESSIONTREES_DELETE_MAX to the lcrep.audit_params table.

To view the new row you can use the following SQL*Plus command:
SQLPLUS> col NAME format a30
SQLPLUS> col AUDIT_PARAM_ID format a15
SQLPLUS> col VALUE format a30
SQLPLUS> set line 100
SQLPLUS> select AUDIT_PARAM_ID, NAME, VALUE from audit_params;

Sample output:

AUDIT_PARAM_ID NAME VALUE
--------------- ------------------------------ --------------------
68 DAYS_WAY 30
69 DAYS_CHANGE_LOG 180
70 LAST_DATE_WAY 20-FEB-10
71 LAST_DATE_CHANGE_LOG 23-SEP-09
72 DAYS_AUDIT_LOG 180
73 LAST_DATE_AUDIT_LOG 23-SEP-09
74 WAY_GC_SESSIONTREES_DELETE_MAX 100 ------> new row

Steps to Complete the Waypurge Garbage Collection Update

The following steps must be performed on all Model Repository hosts after the pre-patch script is run and the 7.85 patch is installed.

1. Verify how many records are expected to be deleted.

   SQLPLUS> SELECT count(session_id) FROM sessions
WHERE (parent_session_id IS NULL OR
parent_session_id IN (SELECT session_id FROM sessions WHERE
parent_session_id IS NULL AND status = 'RECURRING')) AND
status <> 'PENDING' AND status <> 'RECURRING' AND
trunc(nvl(signoff_dt, nvl(end_dt,start_dt))) <
(trunc(sysdate) - (SELECT value FROM audit_params WHERE name = 'DAYS_WAY'))
AND NOT EXISTS (SELECT reconcile_session_id FROM device_role_classes
WHERE reconcile_session_id IS NOT NULL AND
reconcile_session_id = sessions.session_id);

2. Run the WAYPURGE.GC_SESSIONS dba_job manually.

   sqlplus "/ as sysdba"
SQLPLUS> grant create session to gcadmin;
SQLPLUS> connect gcadmin/<password_for_gcadmin>
SQLPLUS> col schema_user format a10
SQLPLUS> col what format a50
SQLPLUS> set line 200
SQLPLUS> select job, schema_user, last_date, this_date, next_date, broken, what from user_jobs where what LIKE '%WAYPURGE%';

   Sample output:
   
   JOB SCHEMA_USE LAST_DATE THIS_DATE NEXT_DATE BRO WHAT
---------- ---------- --------------- --------------- --------------- -
189 GCADMIN 14-APR-10 15-APR-10 N WAYPURGE.GC_SESSIONS;----> note job number

   SQLPLUS> exec dbms_job.run(189);

   Note the time taken by the manual job run and increase the value of WAY_GC_SESSIONTREES_DELETE_MAX accordingly. WAY_GC_SESSIONTREES_DELETE_MAX value should be gradually increased and the time taken to run the job should be monitored. WAY_GC_SESSIONTREES_DELETE_MAX can be increased to say 300, 500, 1000, 3000 and so on.
   

   sqlplus "/ as sysdba"
SQLPLUS> grant create session to lcrep;
SQLPLUS> connect lcrep/<password for lcrep>
SQLPLUS> UPDATE audit_params SET value = 1000 WHERE name = 'WAY_GC_SESSIONTREES_DELETE_MAX';
SQLPLUS> commit;
   

   Step 2 can be run to monitor the number of records that need to be cleaned up.

3. The Waypurge job can be run manually or the nightly dba_job can delete the child records. Note that the GC nightly DBA job is run only once a day, so it may take several days for it to delete all the child records. A combination of manual and nightly job run is recommended.
   
   
   
4. After all child records are removed, delete the WAY_GC_SESSIONTREES_DELETE_MAX value from the AUDIT_PARAMS table.

   sqlplus "/ as sysdba"
SQLPLUS> grant create session to lcrep;
SQLPLUS> connect lcrep/<password for lcrep>
SQLPLUS> DELETE FROM audit_params WHERE name = 'WAY_GC_SESSIONTREES_DELETE_MAX';
SQLPLUS> Commit;
SQLPLUS> select AUDIT_PARAM_ID, NAME, VALUE from audit_params; ->check that the value was removed.

Windows Server 2008 R2 x64

SA 7.85 and later provides improved support for Windows Server 2008 R2 x64. Windows Server 2008 R2 x64 now appears with its own entries in the SA Client rather than as a subset of Windows Server 2008.

However, there are some tasks you must perform in order to migrate any Software Policies,
Application Configurations, packages (units), Patch Policies and/or OS Provisioning objects
you may already have set up for your server(s).

This section describes how to set up SA support for Windows Server 2008 R2 x64.

Migrating Software Policies, Application Configurations and/or Patch Policies is handled by
running a script, windows_2008_R2_fix_script.pyc , provided with SA 7.85 and later
in the directory:

<distro>/opsware_installer/tools

The script is called windows_2008_R2_fix_script.pyc and is invoked as follows:

/opt/opsware/bin/python2 windows_2008_R2_fix_script.pyc [--mrl=<MRL_ID>|--listmrls|--help

The script has the following options:

Table 4: Windows Server 2008 R2 Migration Script Options

Note: Migrated objects other than Patch Policies are not copied, they are attached to the new Windows Server 2008 R2 x64 configuration.

For Patch Policies, Windows Server 2008 R2 x64 copies are created of Windows Server 2008 x64 Patch Policies containing R2 patches (x64 patch library).

The Windows Server 2008 x64 Patch Policies are then detached from the Windows Server 2008 R2 x64 servers and the equivalent Windows Server 2008 R2 x64 Patch Policy copies are attached to the Windows Server 2008 R2 x64 servers.

Note: You can run windows_2008_R2_fix_script.pyc multiple times without issue. The changes made by the script cannot be rolled back.

Requirements

• Run the script:
  • On the Core's Software Repository ( word ) host.
  • On a machine that has OPSWpytwist installed.
  • On an active core, all SA Core Components must be running.
  • As root.
  • After the Windows Server 2008 R24 x64 server(s) has performed hardware registration and is recognized by SA as a new platform.
• Provide SA credentials for a user that has all privileges (for example, detuser).
• Log in to the SA Client and navigate to Administration -> Patch Settings-> Windows Patch Downloads -> Patch Products. Use the Edit button and add the Windows Server 2008 R2 x64 option.
• Re-import the latest MBSA patch database by selecting Patch Database, then the Import from Vendor button.
• If your Hyper-V servers are installed with Windows Server 2008 R2 x64, either run hardware registration manually or wait for the scheduled hardware registration to complete before you run:
  • Data Reload on the Hyper-V server
  • Create VM, Modify VM, Delete VM, or any control operation on a
    Hyper-V VM

Software Policies

After migration completes, the Software Policy appears in the SA Client Navigation pane under Library/By Type/Software Policies/Windows/Windows Server 2008 R2 x64 and Windows Server 2008 x64.

During migration, Software Policies are modified only if:

• The software policy is attached to a Windows Server 2008 R2 x64 server and the software policy platform list contains Windows Server 2008 x64, or
• The Software Policy is attached to a device group, the device group contains a Windows Server 2008 R2 x64 server and the software policy platform list contains Windows Server 2008 x64.

When processing policy items the script looks for the following types of objects:

• Nested Software Policies
• Units (Packages)
• Application Configurations

If the script finds a policy item that has Windows Server 2008 x64 in the platform list it will migrate that policy item to Windows Server 2008 R2 x64. However, the type must be included in the list of types that the script processes. For example, if the script is run with --swPolicy and --units, it will process Software Policies and packages included as policy items. The script will not process any application configurations (even if they are included in the policy items of a Software Policy that will be migrated).

Similarly, if the script is run only with the --swPolicy option, it will only process Software Policies and any policy items that are Software Policies, but policy items that are packages or application configurations will not be processed.

The order of items in the Software Policy is retained and remediation status remains unchanged.

If the script identifies an existing Software Policy as a Windows Server 2008 R2 x64 policy, it does not modify it during processing.

Packages

To migrate packages, the script must be run with --swPolicy and --units or --all option. The script migrates only the packages that have Windows Server 2008 x64 in the platform list and are included as policy item inside a Software Policy that is migrated by the script.

After migration, the package will appear in the SA Client under both the Windows Server 2008 x64 and Windows Server 2008 R2 x64 folders in
Library/By Type/Packages/Windows.

The script does not take into account the package type. It looks for packages included in migrated Software Policies that are attached to Windows Server 2008 x64. Server Module Result objects, Windows Registry objects and Windows Services objects cannot be migrated by the script because their platform associations cannot be changed.

Properties settings (including general, archived scripts, install parameters, install scripts, uninstall parameters, uninstall scripts) are preserved.

Application Configurations

To migrate application configurations, the script must be run with the --appConfig or --all option.

The migration script migrates an application configuration if:

• It is attached to a Windows Server 2008 R2 x64 server and has Windows Server 2008 x64 in the platform list, or
• It is attached to a device group that contains a Windows Server 2008 R2 x64 server and has Windows Server 2008 x64 in the platform list, or
• It has Windows Server 2008 x64 in the platform list and is a policy item of a Software Policy that is migrated.

During migration the script adds Windows Server 2008 R2 x64 to the application configuration's platform list. The script also inspects all application configurations' associated templates (CML templates) and if a template has Windows Server 2008 x64 in the platform list it is also migrated.

The Compliant/Non Compliant/Scan Failed compliance status is changed to Scan Needed after running the script.

There is no undo option.

Patch Policies

To migrate SA Patch Policies, patch metadata and patch exceptions, the script must be run with the --patchPolicy or the --all option. During migration, the script appends R2 to the Patch Policy name. For example, for a patch policy named 2008 XYZ Policy, the migration script creates a new Windows Server 2008 R2 x64 policy named 2008 XYZ Policy R2 if:

During migration, the script appends R2 to the Patch Policy name. For example, for a patch policy named 2008 XYZ Policy, the migration script creates a new Windows Server 2008 R2 x64 policy named 2008 XYZ Policy R2 if:

• There are Windows Server 2008 R2 x64 patches in 2008 XYZ Policy .
• There does not exist any patch policy named 2 008 XYZ Policy R2 that contains
  patches applicable to platforms other than Windows Server 2008 R2 x64.

Note: If a Windows Server 2008 R2 x64 policy named 2008 XYZ Policy R2 already exists, the applicable patches will be added to it.

If Windows Server 2008 R2 x64 servers, or device groups containing Windows Server 2008 R2 x64 servers, are attached to Windows Server 2008 x64 patch policies, the migration script will detach these policies and attach the newly created or updated equivalent Windows Server 2008 R2 x64 policies. Applicable Patch Policy exceptions are also migrated.

If metadata associated with Windows Server 2008 R2 x64 patches has been modified (for example: install/uninstall flags, pre/post install/uninstall scripts), that metadata will be migrated.

OS Provisioning

To migrate OS Provisioning MRLs, OS Sequences and Installation Profiles, the script must be run with the --osProv or the --all option. During migration, the script runs import_media for all detected Windows Server 2008 x64 MRLs. When it detects Windows Server 2008 R2 x64, it deletes the old MRL and creates a new one with the same configuration (same MRL ID) but with the Windows Server 2008 R2 x64 platform associated.

Since import_media cannot detect a WIM image's platform, it cannot automatically migrate MRLs that point to this type of media. However, you can force the migration of a specific MRL that contains a WIM image by providing its MRL ID using the --wim=<MRL ID> option. This option can be used multiple times so multiple WIM MRLs can be migrated. If the script finds an MRL that points to a WIM image and its MRL ID was not specified using the --wim=<MRL ID> option, it will display a warning message and skip processing of that MRL.

If a MRL that points to a WIM image was previously used to provision a Windows Server 2008 R2 x64 machine, then the script must be run with --wim=<MRL ID> to avoid data integrity errors. The IDs of all WIM MRLs that were already used for provisioning should be added by running the script with the --wim option multiple times.

If a you use dynamic MRLs (the MRL path has script weaver tokens like @mediaserver@), the script cannot migrate such MRLs because they can't be mounted. You can temporarily specify a full URL in the MRL using the SA Client interface before running the migration script. You can then restore the dynamic MRL specification after migration if needed.

Existing Installation Profiles attached to the old (migrated) MRL are linked with the newly created MRL and the platform is changed to Windows Server 2008 R2 x64.

Any OS Sequences linked to a migrated Installation Profiles will also be updated to show the Windows Server 2008 R2 x64 platform.

Software Policies attached to a migrated OS Sequence are not modified. However, if a migrated OS Sequence is used to provision a server, that server becomes identified as a Windows Server 2008 R2 x64 server and the Software Policies attached to the migrated OS Sequence are attached to the newly created Windows Server 2008 R2 x64 server. When you run the migration script again, these software policies are then migrated.

The populate-opsware-update-library Script

A new option, --no_w2k8r2, is provided for the populate-opsware-update-library script and is used to specify that Windows Server 2008 R2 x64 patch binaries should not be uploaded. For more information about the populate-opsware-update-library script, see the SA User's Guide: Application Automation .

Windows Server CLI Installation

If you plan to install the SA Command-line Interface (OCLI) on a Windows Server after upgrade to SA 7.85, you must update the Agent on that server to the latest version. Errors occur during OCLI installation on Windows servers with earlier Agent versions.

Back to the Table of Contents

Known Issues

This section describes known issues for SA, Storage and Visibility (Storage), and SE Connector (SE) 7.85. The table lists issues first by subsystem, then numerically within each subsystem. All issues are for SA unless otherwise designated as Storage or SE Connector.

Table 5: Known Issues

Back to the Table of Contents

Fixed Issues

This section describes fixed issues for 7.85.
The table lists issues first by subsystem, then numerically within each subsystem.

Table 5: Fixed Issues

Back to the Table of Contents

Documentation Errata

This section describes documentation errata for release notes and product manuals.

Back to the Table of Contents

HP Software Support

This web site provides contact information and details about the products, services, and support that HP Software offers. For more information, visit the HP Support web site at: HP Software Support Online.

HP Software support provides customer self-solve capabilities. It provides a fast and efficient way to access interactive technical support tools needed to manage your business. As a valued support customer, you can benefit by being able to:

• Search for knowledge documents of interest
• Submit and track progress on support cases
• Submit enhancement requests online
• Download software patches
• Manage a support contract
• Look up HP support contacts
• Review information about available services
• Enter discussions with other software customers
• Research and register for software training

To access the Self-Solve knowledge base, visit the Self-Solve knowledge search home page.

Note: Most of the support areas require that you register as an HP Passport user and sign in. Many also require an active support contract. To find more information about support access levels, go to: Access levels.

To register for an HP Passport ID, go to: HP Passport Registration.

Legal Notices

Warranty

The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein
should be construed as constituting an additional warranty. HP shall not be
liable for technical or editorial errors or omissions contained herein.

The information contained herein is subject to change without notice.

Restricted Rights Legend

Confidential computer software. Valid license from HP required for possession, use or copying.
Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government
under vendor's standard commercial license.

Copyright Notices

© Copyright 2000-2010 Hewlett-Packard Development Company, L.P.

Trademark Notices

Adobe® is a trademark of Adobe Systems Incorporated.
Intel® and Itanium® are trademarks of Intel Corporation in the U.S. and other countries.
Microsoft®, Windows®‚ Windows® XP are U.S. registered trademarks of Microsoft Corporation.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.

Documentation Updates

To check for recent updates or to verify that you are using the most recent edition of a document, go to:
http://support.openview.hp.com/selfsolve/manuals
This site requires that you register for an HP Passport and sign in.
Or click the New users - please register link on the HP Passport login page.
You will also receive updated or new editions if you subscribe to the appropriate product support service.
Contact your HP sales representative for details.

Republishing date(s):

February 2011 -Reformatted; added Fujitsu cluster information.

Back to the Table of Contents