HP Server Automation 7.86 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.86

Publication date: March 2011

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

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.

Fixed and Known Issues

Critical fixes and known issues each have their own tables: see Fixed Issues For This Release or Fixed Issues for 7.85, 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.

What was New In Previous Releases?

This section describes what was new in previous 7.8x releases.

============================================================

Microsoft Hyper-V Virtual Machine Enhancements (7.81)

Please see the Support and Compatibility Matrix for the most updated information on this topic.

This version of HP Server Automation significantly improves and expands your ability to manage Hyper-V hypervisors and virtual machines (partitions). With this version of SA you can create and provision Hyper-V virtual machines with these operating systems:

Windows Server 2008 x64 and x86
Windows Server 2003 x86
Windows Server 2000
Windows XP Professional x86 SP 2 or SP 3
SUSE Linux Enterprise Server 10 with Service Pack 2 (x86 or x64 Edition)
SUSE Linux Enterprise Server 10 with Service Pack 1 (x86 or x64 Edition)

You can also modify and delete Hyper-V VMs. You can add, delete and modify the following on Hyper-V VMs:

Legacy Network Adapters
Network Adapters
SCSI Controllers
Virtual Hard Disks
DVDs

You can also modify the following on Hyper-V VMs:

Memory size
The number of virtual processors
BIOS order
VLAN and MAC address configuration of network adapters
Media specification for DVDs
Controller and location for virtual hard disks

For complete information, see "Microsoft Hyper-V Partition Management" in the SA User Guide: Server Automation.

Solaris Patching Enhancements (7.81)

This version of HP Server Automation significantly improves the process of keeping your Sun Solaris servers running with current patches.

With this version of SA you can:

• Determine which patches your managed servers need.
• Download Solaris patches and patch clusters and store them in the SA library.
• Create Solaris patch policies from downloaded Solaris patches and patch clusters.
• Resolve all the dependencies for a set of patches including required patches, obsolete patches, superseding patches, incompatible and withdrawn patches.
• Install patches and patch clusters by remediating patch policies on managed Solaris servers. Remediation automatically handles various patch reboot settings including single-user mode, reconfiguration reboot and reboot immediate.

For complete information, see "Patch Management for Solaris" in the SA User Guide: Application Automation.

Revised Sizing Guidelines (7.81, 7.82)

SA 7.80 and later have increased memory demands on the Slice Component bundle host(s). Table 3 and Table 4 provide the revised sizing guidelines:

Table 3: Small-to-Medium SA Deployment (SA 7.80 and later)

Table 4: Medium-to-Large SA Deployment (SA 7.80 and later)

Windows Agent Deployment Helper Obsolete (7.81)

In SA 7.81, the Windows Agent Deployment Helper (WADH) is no longer required to manage Windows servers with SA and has been removed from the SA distribution. The process of bringing Windows servers under SA management is now the same as for any other platform.

Note: After you install this patch on all your core and satellite servers and are certain that you will not need to roll back the 7.81 patch, you can redeploy the Windows server that hosted the WADH.

The removal of WADH obsoletes the following sections in the SA 7.80 documentation set:

• The WADH installation instructions described under "Enabling ODAD for Windows Servers" on pages 118-119 of the 7.80 SA Planning and Installation Guide are no longer required.
• The bullet on page 35 of the SA Policy Setter's Guide that reads the following is no longer valid, and also affects online help:
  

The folder contains the tools required to install the Windows Agent Deployment Helper and upload ISMs to SA.

See the SA Planning and Installation Guide for more information about Windows Agent Deployment Helper. See the SA Content Utilities Guide for more information about ISMs.

• Step 1 under "Discovery and Agent Deployment" on page 28 of the 7.80 SA Administration Guide is no longer required.
  
• Step 6a under the heading "For Windows:" on page 28 of the 7.80 SA Administration Guide is no longer required.
  
• On page 208 of the 7.80 SA Administration Guide the permissions requirements should be:

-> Read access to facilities where you will scan for servers and manage servers.
-> Features > Managed Servers and Groups must be enabled.
-> Client Features > Unmanaged Servers > Allow Manage Server set to Yes.
-> Client Features > Unmanaged Servers > Allow Scan Network set to Yes.
-> Read access must be set to customer Opsware.

• The last five Read permissions listed on page 208 are no longer required.
• The WADH permissions listed in Table 31: "Default Top-Level Folder Permissions of the Predefined User Groups" on page 262 of the 7.80 SA Administration Guide are no longer required.
• The section "Prerequisite Setup for Discovery and Agent Deployment" on page 88 of the 7.80 SA User's Guide: Server Automation and in the SA online help is no longer required.
• In the 7.80 SA User's Guide: Server Automation section titled "Creating Reports on Agent Installation," the Example Report on page 95 is no longer valid.
• The requirement to install a WADH displayed in the section "Deploying Server Agents on Unmanaged Servers" in the SA online help is no longer valid.

Agent Deployment Tool (ADT) Behavior in a Mixed-SA Version Environment (7.81)

When you run the Agent Deployment Tool (ADT) from a 7.81 SA Client session (the SA version of the core the SA Client session is logged in to), Windows agent deployment from that session is supported only to realms also running SA 7.81; deployment to realms running earlier SA versions is not supported.
If SA Client session is logged into a pre-7.81 core (for example, 7.80, 7.50.03, etc.) as long as that SA core has a properly configured Windows Agent Deployment Helper server, you can deploy Windows agents from that session to realms running SA 7.81 as well as earlier versions.

Veritas File System Support - Red Hat Enterprise Linux SA Cores (7.81)

As of SA 7.81, the Veritas File System (VxFS) is supported for SA Cores on Red Hat Enterprise Linux. Veritas File System (VxFS) is not supported on Solaris systems. For more information, see the SA Supported Platforms in the documentation directory of your SA installation.

Storage Visibility and Automation Feature (7.81)

For Server Automation 7.81, the following changes were made to the Storage Visibility and Automation feature:

• Added new platforms that support the Storage Host Agent Extension component.
• Added new storage reports and moved these reports and the corresponding user documentation to the BSA Essentials Network (BSAEN) for delivery.
• Updated the storage compliance functionality and moved the corresponding user documentation for storage audits to the BSA Essentials Network (BSAEN) for delivery.
• Fixed and described product defects.
• Identified and described known product defects.

See the Storage Visibility and Automation 7.81 Release Notes for detailed information about these changes.

Oracle Real Application Clusters (RAC) Support (7.82)

Concurrent with the release of version 7.82, SA provides support for Oracle RAC. In order to configure SA for Oracle RAC support, you must perform a fresh installation of SA 7.80, configured for Oracle RAC, then upgrade to SA 7.82. For more information about configuring SA for Oracle RAC support, see Oracle RAC Support: Oracle Setup for the Model Repository/SA Planning and Installation Guide, Appendix A on page 89 of these release notes.

Solaris Patching Supports Patch Bundles (7.82)

Version 7.82 of HP Server Automation adds support for Solaris patch bundles.

• You can download Solaris patch bundles and import them into the SA library using the solpatch_import command. You can import each part of a bundle separately, but you cannot install the bundle until all the parts have been imported into the SA library. The Contents view in the SA Client displays the parts in the bundle. The bundle icon in the SA Client will be grayed out until all the parts have been imported. Note that you cannot import patch bundles using the Import Software menu item in the SA Client.
• You can install Solaris patch bundles directly on managed servers or on all servers in a device group or you can add Solaris patch bundles to a Solaris patch policy (or to a software policy), attach the policy to managed servers or device groups and then remediate the servers against those policies. When you remediate the servers or device groups, the Solaris patches specified in the attached policy are automatically installed on the managed servers.
• All solpatch_import actions, except the policy action, now can be performed with patch bundles.
• When you import a bundle, SA updates the metadata in the SA Library with all the patches contained in the bundle. Depending on the number of patches in your SA Library, the bundle import may take some time.
• Deleting a patch bundle from the SA Library or by using the solpatch_import command deletes all the parts of the bundle.
• The default reboot settings for patch bundles are listed below. You can change these settings by opening the patch bundle in the SA Client, selecting the Properties view and editing the Install Parameters.

- Reboot Required: Yes – This setting indicates the managed server will be rebooted when the patch bundle is successfully installed.
- Install Mode: Single User Mode – This setting indicates that the patch bundle will be installed in single user mode. Note that the Solaris system is rebooted to single user mode, then the patch bundle is installed, then the system is rebooted to multiuser mode.
- Reboot Type: Reconfiguration – This setting indicates that a reconfiguration reboot will be performed after installing the patch bundle.
- Reboot Time: Immediate – This setting indicates that the server will be rebooted immediately after installing the patch bundle.

• A Solaris patch compliance scan will indicate that the server is out of compliance even though the patch bundle installed successfully if one or more patches in the bundle were not installed because a required prerequisite patch was not installed. For details on what patches in the patch bundle were not installed, see the log file for the patch bundle installation job.

A software compliance scan will similarly indicate the server is out of compliance if the patch bundle is included in the software policy and the same scenario occurs.

To bring the server into compliance, place the relevant patches into a patch policy, resolve the dependencies on the policy to place all required patches in the policy and remediate the policy on the server.

• You must set the "Manage Packages" permission to "Read and Write" to use the solpatch_import command. This is in addition to the permissions described in "Patch Management for Solaris" in the SA User's Guide: Application Automation. For details on permissions, see the SA Administration Guide.
• If you encounter errors when importing Solaris patch bundles, perform the following troubleshooting steps.
  1. Log in as root to an SA core where the SA 7.82 patch has been installed.
  2. Locate the log file from the 7.82 patch install which is typically under
     /var/log/opsware/install_opsware/patch_opsware.<time stamp>.log
     
  3. Search this log file for a message with "update_supplements." For example, you could use the following grep command:
     grep update_supp patch_opsware*
  4. The result should be a log message with "update_supplements successfully completed". However, if the message indicates the update_supplements failed, update the Solaris patch supplement file manually, as follows.
     1. Log in as root to an SA core system where the solpatch_import command is installed.
     2. Change to the directory where the solpatch_import command is,
        /opt/opsware/solpatch_import/bin.
     3. Run the following command:
        ./solpatch_import -a update_supplements
        
  5. Try importing Solaris patch bundles again.
     

  For more information, see "Patch Management for Solaris" in the SA User's Guide: Application Automation.

Solaris Patching and Benign Error Codes

Installing Solaris patches sometimes results in benign error codes. A benign error code is an error code that does not reflect a true error situation. For example, a patch installation may fail because the patch is already installed or because a superseding patch is installed, resulting in a benign error code. The exit code from the Solaris patchadd command would indicate an error, when in reality the patch was not installed for a valid reason.

When a patch does not install because of a true error situation such as the server being out of disk space, SA reports the error and the valid error code.
SA detects benign error codes and reports success in most cases. In the following two cases, however, Solaris cannot detect benign error codes:

• Solaris Deferred-Activation Patches
• Any patches installed on Solaris Global Zones where Local Zones are defined.

You can configure SA to detect benign error codes in these cases by performing the following steps:

1. Install the following patches on all your servers running Solaris 10:
   - 119254-36 (sparc)
   - 119255-36 (i386)
2. Run the SAS Web Client and log in as a user with "Configure Opsware" permission.
   The Configure Opsware permission is given by default to the "SA/Opsware System Administrators" group. You can locate and set it in the SAS Web Client by selecting Administration > Users & Groups, select the Groups tab, select the "SA/Opsware System Administrators" group and select the Features tab.
3. Under the Administration node, select System Configuration.
4. Select Command Engine.
5. In the configuration parameters table, locate the line "way.remediate.sol_parse_patchadd_output".
6. Select "Use value:".
7. Enter the number 1 in the edit field.
8. Select the Save button.

Behavior when a Pre-Install Script Fails (7.82)

You can specify pre-install scripts in patches, packages and software that run before the patch, package or software is installed on a server. For each pre-install script, you can specify the behavior if the pre-install script fails. The following shows a pre-install script and the error setting.

RMFOLDER=/opt/opsware/dbfile.cb
If [ -d $RMFOLDER ]; then rm -rf 4RMFOLDER
fi

When you initiate a remediate job or an install job that installs patches, packages or software, you can specify the behavior if any part of the job fails. The following shows an Install Patch job and the setting that controls the behavior when any part of the job fails.

In the Install Patch window:

All Steps > 3. Install Options

Install Options > Staged Install Options > Continuous: Run all phases as an uninterrupted operation.

Error Options > Attempt to continue running if an error occurs.

Before SA 7.82, if the error setting for the job specified "Attempt to continue running if an error occurs" and the error setting for the pre-install script specified "Stop Install" and an error occurred in the pre-install script, the job would ignore the script's error setting and continue running.

As of SA 7.82, if this situation occurs, the error setting for the pre-install script applies and the patch or package or software will not be installed. The job will continue running and attempt to install the remaining patches, packages or software.

To retain the pre-SA 7.82 behavior, simply change the error setting on the pre-install script to "Continue".

Approving Blocked Jobs that Run SA Extensions (7.82)

Job Approval Integration in SA allows you to block certain SA jobs from running until they are verified and unblocked. The typical method of unblocking these blocked jobs is by using HP Operations Orchestration (OO). SA 7.82 provides a way to unblock jobs that run program APXs (Automation Platform Extensions) without requiring HP Operations Orchestration. For more information on Job Approval Integration, see the SA Platform Developer's Guide.

In releases prior to SA 7.82, the only way to unblock blocked jobs was by calling an OO flow. The OO flow performed the appropriate checks and unblocked the job, allowing it to run.

SA 7.82 adds the ability to verify and unblock jobs that run program APXs without requiring HP Operations Orchestration.

Note: This applies only to "Run Program Extension" jobs, which are jobs that run a program APX. APXs are extensions to SA. For more information on APXs, see "Creating Automation Platform Extensions (APX)" in the SA Platform Developer's Guide.

Enabling Job Approval for APXs (7.82)

You must have the appropriate permissions to make changes to System Configuration parameters. For more information on permissions, see the SA Administration Guide.

To create this type of APX, perform the following steps:

1. Write a program APX that checks the blocked jobs and unblocks them using the SA API methods approveBlockedJob(), updateBlockedJob(), cancelScheduledJob() and findJobRefs(). These methods are the callbacks into SA that enable job approval integration. For details on writing APXs see "Creating Automation Platform Extensions (APX)" in the SA Platform Developer's Guide.
2. Log in to the SAS Web Client. For more information on the SAS Web Client, see the SA User's Guide: Server Automation.
3. In the navigation pane, select Administration System Configuration. This displays the subcomponents of the SA platform.
4. Under "Select a Product:", select Opsware. This displays the system configurations you can modify.
5. Locate the entry for approval_integration.apx.enabled.
6. Under the Value column, select the "Use value" button.
7. In the text box next to the "Use value" button, enter a 1.
   
8. Locate the entry for approval_integration.apx.uniquename.
   
9. Under the Value column, select the "Use value" button.
   
10. In the text box next to the "Use value" button, enter the unique name of your program APX that checks and unblocks blocked jobs.
    
11. Select the Save button at the bottom of the page.
    
12. Set up a mechanism to run this APX. For example, you could schedule this APX to run periodically to check for blocked APXs.

Disabling Job Approval for APXs (7.82)

You must have the appropriate permissions to make changes to System Configuration parameters. For more information on permissions, see the SA Administration Guide.

To disable the unblocking APX, set the value of approval_integration.apx.enabled to 0. For details on setting this system configuration value, see Enabling Job Approval for APXs on page 22.

Restricting Access to RPM Folders (7.82)

In SA 7.82, you can ensure that your Linux managed servers only have access to the set of RPMs in the SA Library that apply to each server. You simply specify in a custom attribute the folders in the SA Library that the server has access to. All other folders will be inaccessible to the server. This section describes how to set up these restrictions.

With this new mechanism, you can mimic the common Redhat systems administration paradigm of having multiple, distinct yum (Yellowdog Updater, Modified) repositories. This gives you folder-level control over which versions of RPMs can be applied to a given server, allowing you to precisely manage platform update versions, for example Redhat Advanced Server AS4 Update 5 versus Update 6.

This is not intended as a user-level access control mechanism, but rather to restrict the library and folder view of a managed server from access to the full set of RPMs in the SA Library. For information on user level folder access controls and folder permissions in the SA Library, see the SA Administration Guide.

How the RPM Folder Restrictions Work

During remediation, if a server has one or more of these custom attributes defined, SA reads the custom attribute values and only allows the managed server access to the RPMs in the SA Library folders specified in the custom attributes and their subfolders. Subfolders of all the specified folders are recursively searched for RPMs. All other folders are not accessible to the server.

Enabling RPM Folder Restrictions

To restrict a server or group of servers to a subset of RPMs in the SA Library, set a custom attribute in the format described below on your managed server or at a location that will be inherited by the server such as a device group, a software policy, a customer, a facility and so forth.

These custom attributes follow the custom attribute inheritance rules. For example, if you set a custom attribute at the facility level, the servers in that facility will inherit the custom attributes.

SA does not validate the SA Library folder paths you specify in these custom attributes so make sure the folder paths you specify are correct.

For more information about custom attributes, see the SA User's Guide: Application Automation.

Custom Attribute Format (7.82)

The custom attributes that restrict access to RPMs must be in the following format:

repo.restrict.<name>

Where <name> is any user-defined alphanumeric string. Specify a <name> that is descriptive and helps you remember the purpose of the custom attribute. You can define multiple custom attributes as long as each <name> is unique.

Examples

The following defines custom attributes that grant access only to the SA Library directories

/Redhat/AS4/en/x86_64/U5 and /Oracle/10/AS4/x86_64:
repo.restrict.as4u5=/Redhat/AS4/en/x86_64/U5
repo.restrict.oracle_updates=/Oracle/10/AS4/x86_64

The custom attribute value can be multiple lines. The following defines custom attributes that grant access only to the SA Library directories listed:

repo.restrict.as4u5=/Redhat/AS4/en/x86_64/U5
/Redhat/AS4/en/x86_64/U5-extras
repo.restrict.s5u3=/Redhat/5Server/en/x86_64/U3
/Redhat/5Server/en/x86_64/U3-extras
/Redhat/5Server/en/x86_64/U3-VT
/Redhat/5Server/en/x86_64/U3-Cluster

Troubleshooting Errors

If you attempt to remediate a software policy that contains RPMs that are not accessible to the server, the following error message will be given:

The metadata needed to install this package is missing.

This indicates that SA was unable to access the RPM because the server does not have access to the RPM in the SA Library. To resolve this error, check the folder locations you have set in your custom attributes to ensure they are correct.

New Memory Requirement for Solaris x86_64 VM PXE Booting (7.83)

In order to PXE boot Solaris x86_84 VM, you must assign the Solaris VM one gigabyte memory or more.

SA Cores on VMs Support (7.83)

SA 7.80 added support for running SA Core Components within VMWare ESX Virtual Machine (VM) environments.

In the release notes, HP recommended that the Model Repository not be deployed to a VM and that the only supported installations were those in which the VM which supports the SA Core infrastructure was the sole VM.

The intent was to ensure that in conditions where overall performance was potentially a factor, SA performance could be isolated from the environmental impact of resource contention caused by other VMs. However, it was not intended to require that all SA Core on VM installations would always have exclusive domain of the ESX container.

To clarify:

• SA Core components are supported when executed within VMs provided you follow VMWare's best practices for managing resource allocation and overall workload to ensure that other VMs sharing the same ESX container do not significantly impact the performance available to the VM hosting the SA Core Components.
  
• To facilitate support of Infrastructure and Slice Component bundles on VMs, HP reserves the right to ask you to replicate any potentially performance related issues in an environment where the VM supporting the SA Core Components is the sole VM active within the ESX container.
  
• To facilitate support of the Model Repository on a VM, HP reserves the right to ask you to replicate any issues in an environment where the Model Repository is installed on a supported physical platform. Any issues resulting from interactions between the Oracle Database and the VM platform requiring interaction with Oracle technical support are your responsibility.

Red Hat Enterprise Linux 4.x PPC64 and 5.x PPC64 OS Provisioning (7.83 and 7.84)

While most OS Provisioning procedures are the same for Red Hat Enterprise Linux 4.x PPC64 and 5.x PPC64 as documented in the SA Policy Setter's Guide and the SA User's Guide: Server Automation, there are certain differences.

Red Hat Enterprise Linux 4.x PPC64 and 5.x PPC64 Kickstart files should be specified similarly to that shown in the sample files below:

Red Hat Enterprise Linux 4.x PPC64 Sample Kickstart File

lang en_US.UTF-8
timezone --utc US/Pacific
reboot
text
install
bootloader --location=partition --driveorder=sda,sdb --append="console=hvsi0 rhgb quiet"
#zerombr yes

clearpart --drives=sda --initlabel
part prepboot --fstype "PPC PReP Boot" --size=4 --ondisk=sda
part /boot --fstype ext3 --size=100 --ondisk=sda
part pv.3 --size=0 --grow --ondisk=sda
volgroup VolGroup00 --pesize=32768 pv.3
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=1000 --grow --maxsize=5888

authconfig --enableshadow --enablemd5
rootpw opsware

firewall --disabled
selinux --disabled

skipx

%packages
@Base

Red Hat Enterprise Linux 5.x PPC64 Sample Kickstart File

lang en_US.UTF-8
timezone --utc US/Pacific
reboot
text
install
bootloader --location=partition --driveorder=sda,sdb --append="console=hvsi0 rhgb quiet"
#zerombr yes

clearpart --drives=sda --initlabel
part prepboot --fstype "PPC PReP Boot" --size=4 --ondisk=sda
part /boot --fstype ext3 --size=100 --ondisk=sda
part pv.3 --size=0 --grow --ondisk=sda
volgroup VolGroup00 --pesize=32768 pv.3
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=1000 --grow --maxsize=5888

authconfig --enableshadow --enablemd5
rootpw opsware

firewall --disabled
key --skip
selinux --disabled

skipx

%packages
@Base

DHCP Configuration For PowerPC

PowerPC machines must be booted using BOOTP which requires that the dhcpdtool dynamic-bootp flag is enabled in each range statement in the dhcpd_subnets.conf file.

The dynamic-bootp usage is:

range [ dynamic-bootp ] low-address [ high-address ];

For more information about dhcp.conf statement usage, see:

http://www.daemon-systems.org/man/dhcpd.conf.5.html

Network Booting Red Hat Enterprise Linux 4.x or 5.x PPC64 Servers

1. Mount the new PowerPC server in a rack and connect it to the network. The installation client on this network must be able to communicate with the SA DHCP server on the SA Core network. If the installation client is running on a different network than the SA Core network, your environment must have a DHCP proxy (IP helper).
2. Use the SMS menu to configure the server to boot from the hard disk on which the operating system will be installed because the OS Provisioning process requires several reboots that default to the local disk.
   
3. Start Open Firmware.
   
4. Use the boot command to boot the server over the network. This command requires the Open Firmware path to the device you are booting from. You can specify device aliases to a device's Open Firmware path. If you configured the boot order with the SMS menu you can use the printenv and devalias commands to create the alias.
   For example:
   
   printenv boot-device
boot-device /pci@800000020000002/pci@2,4/pci1069,b166@1/scsi@1/sd@5,0
/pci@800000020000002/pci@2/ethernet@1:speed=auto,duplex=auto,
192.168.157.2,,192.168.157.25,192.168.157.1
devalias net /pci@800000020000002/pci@2/ethernet@1
   
   
5. After you have set the net device alias, issue the following command:
   
   boot net:[SERVER_IP],[IMAGE_FILE],[CLIENT_IP],[GW_IP] [ARGUMENTS]
   
   You need only specify the IMAGE_FILE argument, for example:
   
   boot net:,yaboot,,
   
   Executing this command retrieves the bootloader (yaboot) and displays the server boot options. Press Enter to boot the default option (linux5) or wait for the boot to occur automatically.
   
   
6. The Red Hat Anaconda installer starts. If your server has multiple network interfaces, the installer may prompt you to specify the interface to use.
   
7. After the booting process finishes successfully, a message appears on the console indicating that the server is ready for OS provisioning. Since the OS Build Agent was installed, the server now appears in the SAS Web Client Server Pool list.
   
8. (Optional) Record the MAC address and/or the serial number of the server so that you can locate the server in the SAS Web Client Server Pool list or in the SA Client Unprovisioned Servers list.
   
9. Verify that the server appears in the SA Client Unprovisioned Server list and is ready for OS installation. For more information, see the SA User's Guide: Application Automation.

SuSE Linux Kernels and PPC Architecture (7.83 and 7.84)

When installing SUSE Enterprise Linux on PPC architectures, consoles may not work after the operating system loads during the boot process. Therefore, when provisioning or reprovisioning a server with SUSE Enterprise Linux on PPC architectures, you could lose console access to the server being provisioned.

New JDK Version Required for the DCML Exchange Tool (DET) (7.83)

As of SA 7.80, the DCML Exchange Tool (DET) requires jdk 1.6.

Support for Multiple Database Instances on the Model Repository Host (7.84)

SA now supports multiple database instances on the database server where one of the instances is the SA Model Repository instance. The requirements, configuration and procedures for adding instances is the same as shown in the SA Simple/Advanced Installation Guide, Appendix A: Oracle Setup for the Model Repository.

HP-UX Patch Management and OS Provisioning Support (7.84)

This release provides support for HP-UX Patch Management and for OS Provisioning. The documentation for these features is contained in separate white papers that you can download from the HP Self Solve web site:

http://support.openview.hp.com/selfsolve/manuals

This site requires that you register for an HP Passport and sign in. To register for an HP Passport ID, go to:

http://h20229.www2.hp.com/passport-registration.html

Or click the New users - please register link on the HP Passport login page.

The documents are titled:

• HP-UX Software and Patch Management
• HP-UX Provisioning for HP Server Automation

Windows Server 2008 R2 Support (7.84)

This release adds support for Windows Server 2008 R2. If you plan to provision or manage Windows Server 2008 R2 hosts, there are certain additional steps you must take during the patch installation process to ensure full compatibility and support for existing configurations (application configuration, software policies, and so on). See Chapter 2, Installing SA 7.84, on page 43 of this guide.

Model Repository Database on HP-UX and IBM AIX Supported (7.84)

As of this release, SA supports installation of the Oracle database for the Model Repository on the HP-UX and IBM AIX platforms supported by Oracle. The installation procedure is the same as that described for remote databases in the SA Simple/Advanced Installation Guide, Appendix A: Oracle Setup for the Model Repository.

Veritas File System Support (7.84)

As of SA 7.84, the Veritas File System (VxFS) is supported for SA Cores on Red Hat Enterprise Linux and Solaris 10 U6. For more information, see the SA Supported Platforms in the documentation directory of your SA installation.

Simplified Database Schema Update Script (7.84)

SA 7.84 provides a new, simplified database schema update script, patch_database.sh, that combines the multiple scripts that were previously required to be run before patch installation.

Sunsolve Website Rebranding and the solpatch_import Script (7.84)

Oracle Corp. has rebranded the Sunsolve website therefore, before running solpatch_import -action=create_db as described in the SA User's Guide: Server Automation, you must log in to your Sunsolve account and subscribe to patch download automation. For more information, see:

http://support.openview.hp.com/selfsolve/document/KM961930

New Guide (7.85)

APX for Configuring LVM and MPIO : User Guide.

Fujitsu Clusters (7.85)

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 (7.85)

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 (7.85)

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 (7.85)

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.

Storage Visibility and Automation (7.85)

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.

SE Connector (7.85)

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.

Back to the Table of Contents

Installation

This section describes the SA 7.86 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.
• Patches are "mesh compatible" with unpatched cores (i.e. patched and unpatched cores can interoperate). As a result, patches can be installed and rolled-back on one core at a time, and mesh-wide downtime is not required when applying patches.

  NOTE: Mesh-wide data changes (such as the uploading of updated Wayscripts) will only be made from the primary core, so it is recommend that this core is patched first.

• 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 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.86, 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.86 patch.

Managed Platform Update

You must install an SA update on 7.80 cores before installing the SA 7.86 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 database updates:

1. Mount the 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.84 and Later, Managed Platform Update, and Database Schema Update Procedure.

Perform the following tasks to install SA:

1. Mount the SA 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.86 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.86 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.86 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 upgrade to SA 7.86, 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 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-11 15-APR-11 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.86 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.86 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 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.86, 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) for this release. 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 for This Release

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

Table 5: Fixed Issues for This Release

Back to the Table of Contents

Fixed Issues for 7.85

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

Table 5: Fixed Issues

For information on fixed issues from earlier releases, see the individual release notes for that release.

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-2011 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.

Back to the Table of Contents