Service Pack 1: version 8.9.01

8.9.01.68

The Live Reporting installer simplifies and improves the installation experience by providing a centralized UI for installing and configuring the Live Reporting dashboard. You are no longer required to manually install and configure the Yellowfin database to support the Live Reporting dashboard. This operation is automatically performed by the Live Reporting installer.

For more information about the running the Live Reporting installer, see Installing and configuring Yellowfin to enable Live reporting (for versions 8.9.01 and later).

A new blasadmin parameter named IsUsedInReports controls the default value of the IS_USED_IN_REPORTS* property in any newly created server group. You can use this blasadmin parameter to exclude newly created server groups from the list of server groups when filtering the Live Reporting Dashboard.

To shorten the list of server groups when filtering, use the following command:
set SmartGroupConfig IsUsedInReports false

In this command, you change the default value of true (that is, include all new server groups in the list) to false (that is, do not include new server groups in the list). For more information, see Troubleshooting the Live Reporting dashboard.

Note the following points:

• Setting the IsUsedInReports blasadmin parameter does not affect existing server groups. To remove existing server groups from the list, you must manually set the IS_USED_IN_REPORTS* property in each individual server group to False.
• After you set the IsUsedInReports blasadmin parameter to false, remember that for any newly created server group that you do want to appear in the list you must manually set its IS_USED_IN_REPORTS* property to True.

BMC Server Automation now supports version 1.2 of the Transport Layer Security (TLS) protocol for session layer security across the various communications legs between BMC Server Automation components.

After installing or upgrading to BMC Server Automation 8.9.01, TLS version 1.2 is the default protocol for communication between the Application Servers and the RSCD Agents. Earlier versions of TLS are supported, for backward compatibility, in the following scenarios:

• Existing communication sessions with agents that were upgraded to 8.9.01 continue with the current TLS version until the session expires, at which time communication is updated to TLS version 1.2.

• Communication with agents of earlier versions (<8.9.01) continues with the existing default TLS version.

In the case of an upgrade to 8.9.01, ensure that the Network Shell component is upgraded to version 8.9.01 on the computer that hosts the BMC Server Automation Console, to support the new default protocol used by the RSCD Agent. The Network Shell is normally upgraded together with the BMC Server Automation Console.

If you want to override the default behavior (outlined above) for communication between Application Servers and agents of version 8.9.01 — for example, if you want to limit all communication to TLS 1.2 with no option for use of earlier versions of the TLS protocol — you must configure various properties on your agents and also on your Application Servers, as described in Configuring use of TLS version 1.2.

Support for Microsoft Windows Server 2016 was added in the following components and functionalities in BMC Server Automation:

• Unified Product Installer (UPI)
• Application Server
• Patch management
• Bare-metal provisioning
• Virtualization for the following types of virtual servers:
  • VMware vSphere, vCenter Server 5.5, 6.0, and 6.5
  • Microsoft Hyper-V 3.0. SCVMM 2012 R2

For the complete list of supported platforms, see Supported platforms for version 8.9.

The following component templates for the CIS policy have been updated to more recent benchmarks:

• CIS on Red Hat Enterprise Linux 6 was updated to benchmark version 2.0.1 of June 2, 2016
• CIS on Red Hat Enterprise Linux 7 was updated to benchmark version 2.1.0 of June 2, 2016
• CIS on Windows Server 2008 R2 was updated to benchmark version 3.0.0 of April 28, 2016

For the complete list of available templates, see Compliance policy standards supported by BMC Server Automation templates.

Several intrinsic properties have been added to the following system objects:

In these system objects, the following properties were added:

• CVE_IDS*
• OS*
• OS_VENDOR*
• OS_PLATFORM*
• OS_RELEASE*
• OS_VERSION*

These properties already existed in other object types — the CVE_IDS* existed in the Windows Bulletin object, and the other properties existed in the Server object. They have been added to the BLPackage, NSH Script, and Component Template objects for the purpose of enabling integration with the auto-mapping feature for vulnerability management in the SecOps Dashboard of BMC BladeLogic Portal.

For more details about these properties, see Intrinsic properties.

A new intrinsic property was introduced in the Patch Analysis Job for Linux platforms. This property, OTHER_LINUX_ANALYSIS_PATCHING_TOOL* in the OtherLinuxPatchingJob property class, reflects your choice of patching tool for the job — either Zypper or Yum.

The OTHER_LINUX_ANALYSIS_PATCHING_TOOL* property accepts the following Values:

• 0 — Zypper
• 1 — Yum (default value)

BMC Server Automation now supports the use of native YUM as the patching tool for deploying patches to target Linux servers. Prior to this release of BMC Server Automation, native YUM was supported only on Red Hat Enterprise Linux version 7, and it is now supported on the following types and versions of Linux servers:

• RHEL 5 and 6
• OEL 5, 6, and 7

Support for native yum is available for yum versions 3.2.22 and later.

The blyum utility, a custom binary that was used until now in BMC Server Automation for patch deployment to many types of target Linux servers, is now used only if no supported native YUM is detected on the target Linux server.

If you want to override this default behavior and use blyum as the patching tool even when a native YUM exists on the target server, you can set the intrinsic server property PATCHING_TOOL_INSTALL_LOCATION* with the path to blyum (<installpath>/bin/blyum, typically /opt/bmc/bladelogic/RSCD/bin/blyum). Alternatively, you can use this server property to specify the path to a different yum.

During patch analysis on Linux (on all types of Linux except for Ubuntu and Debian) or Windows target servers, a set of temporary analysis files are created on each target server. Prior to version 8.9.01 of BMC Server Automation, this set of analysis files was deleted at the end of the Patch Analysis Job run, unless the job was set to run in DEBUG mode. As of version 8.9.01, these patch analysis files are archived, and the files from the 3 most recent job runs are stored in the target agent's Transactions directory, in a subdirectory named analysis_archive. A pair of blasadmin parameters enable you to control the archiving mechanism.

For more information, see Archiving mechanism for patch analysis files and Controlling patch analysis file archiving.

Patch
management

RHEL patch analysis optimizations for include and exclude

BMC Server Automation can automatically select the appropriate rpm version or versions while including or excluding an rpm package in an RHEL patch analysis job. To enable this version optimization, select the By Package Name Only option while including or excluding patches. Whenever any rpm package is selected with the By Package Name Only option, BMC Server Automation automatically performs the following:

• In case of an include patch operation—includes the latest rpm version of the package from the catalog, even if that version is not manually selected
• In case of an exclude patch operation—excludes all rpm versions of the package from the catalog, even if all versions are not manually selected

You can still individually specify rpm versions for include or exclude by selecting the By Complete Package Name option. When this option is selected, BMC Server Automation does not automatically include or exclude any rpm version that is not manually selected by the user from the catalog. Whenever any rpm package is selected with the By Complete Package Name option, BMC Server Automation automatically performs the following:

• In case of an include patch operation—includes the latest rpm version of the package, from the selected rpm packages
• In case of an exclude patch operation—excludes all rpm versions of the package, from the selected rpm packages

To see some examples with screenshots, see Patching Job - Analysis Options for Red Hat Enterprise Linux, Oracle Enterprise Linux, and SUSE Linux Enterprise.

The following updates have been introduced in job logging:

• A group of new information messages are written to the job log during job execution. These messages enhance the tracking of job execution. The messages provide the following information:
  • Information about an execution override
  • The full folder path to the job
  • Whether the job was manually executed, executed through an Execution Task, or scheduled through a job schedule
  • Whether Debug mode was enabled
  • For a scheduled job: schedule type, time, and time zone
• New information in the appserver.log:
  • Job routing rule used (usually only in the initial job run)
  • Several details about the Application Server in the memory monitor line: host name, deployment name, and version
• Generation of log packages for job runs now has the following enhancements:
  • In addition to the BLPackage Deploy Job and Patch Analysis Job (which were already supported), this feature now supports the following job types: NSH Script Job, ACL Push Job, Update Server Properties Job , Compliance Job, Snapshot Job, Audit Job, Component Discovery Job, File Deploy Job, and Agent Installer Job
  • Patch Archive archive files are included in the package, within a .zip file whose name ends with _patchsupport.zip.
  • All the new information described above, introduced in the job log and in the appserver.log, is included in the package.

During online database cleanup, various cleanup-related log messages are saved in the DBM_RUN_LOG table. This table is now cleaned up as well during subsequent cleanups of historical data (any cleanup mode that runs the Delete cleanupHistoricalData command) or cleanups of the database (any cleanup mode that runs the Delete cleanupDatabase command). Log messages from the last 4 cleanup runs of each object type are retained.

For more information, see Types of data commonly included in cleanups.

The following third-party software that are shipped with BMC Server Automation have been updated:

• OpenSSL was updated to version 1.0.2j on most platforms.
  On Windows 32-bit systems, the version remains 1.0.2f.
• Java Runtime Environment (JRE) was updated to 1.8.0_121 (JRE 1.8 Update 121)

The following changes have been applied to BLCLI commands:

• BlAclTemplate listAllAclTemplates now provides a list of ACL templates without further details, and the new command BlAclTemplate listAllAclTemplatesWithDetails provides a list of ACL templates that includes details of template properties.
• The new command ComponentException createComponentExceptionWithOneRuleWithExpirationDate creates a compliance exception with one rule, reference number, and expiration date and sets it on a component.
• The new command Delete cleanupFileServerWithEmptyDirectoryScan cleans all the unused files from the file server and runs the empty directory scan.