Home - BMC Server Automation 8.8

BMC Server Automation, one of BMC's digital enterprise automation solutions, allows you to quickly and securely provision, configure, patch, and maintain physical, virtual, and cloud servers.
Release notes and notices
updated 01 Mar
This section provides information about what is new or changed in this space, including urgent issues, documentation updates, service packs, and patches.

Placing a watch on this page is a great way to stay informed of changes to this space.

Date

Title

Summary

March 1, 2017 Version 8.8.00.001: Patch 1 for version 8.8 Lists the updates introduced in BMC Server Automation version 8.8 Patch 1.
June 14, 2016 8.8.00 enhancements and updates

Lists the enhancements introduced in BMC Server Automation version 8.8.

Tip

Ready-made PDFs are available on the PDFs page. You can also create a custom PDF.

  Click here to see the steps.

From the Tools menu in the upper-right, select:

  • Export to Word to export the current page to Word format
  • Export to PDF to export the current page to PDF format
  • Export branch to PDF to export the current page and its child pages to PDF format

    PDF export


Getting started

 

Video > Overview of BMC Server Automation




 

Planning

 

Concepts, architecture, deployment, planning, and system requirements.

Installing

 

Information about installing the product and migrating product data.

Configuring after installation

 

Required post-installation configuration.

Upgrading

 

Upgrade process, migration, and configuration.

Troubleshooting

 

Issues resolution, error messages, logs, and contacting Support.

Using

 

Interface descriptions, using the product.

Administering

 

Security, system administration, maintenance.

Developing

 

Development interfaces and toolkits.

Integrating

 

Integrations with other products.
What's new?

Tip

For information about the updates included in the most recent patch for this release, see the following page:

The following sections describe enhancements for BMC BladeLogic Server Automation version 8.8.00:

Tip

For information about issues corrected in this release, see Known and corrected issues.

Installation and upgrade enhancements

The following enhancements have been introduced in BMC BladeLogic Server Automation 8.8.00 for Installation features:

Change in installation directory structure

A new Disk1 folder is now created when you extract installation files for Windows platforms, to match the directory structure since version 8.6.01 for the corresponding Linux installation files. The new folder structure upon extraction is: <temporary location>\Disk1\files.

Support added for SELinux

BMC BladeLogic Server Automation now supports SELinux in version 8.8.00. You do not need to enable the allow_execmod and allow_execstack commands during agent installation. If it is already enabled on the target the agent installer will not disable it. Note that support for SELinux is limited to the following configured state (as defined through /etc/sysconfig/selinux):

SELINUX=enforcing
SELINUXTYPE=targeted

Multi Level Security is not supported.

Version management of product objects using Git

BMC BladeLogic Server Automation now supports version management of two types of product objects — component templates and Network Shell scripts. Version management of these objects is based on an integration of BMC Server Automation with Git, using any of the following supported Git repository tools: GitHub, Gitblit, and GitLab. Git version management is supported even in an environment with multiple Application Servers (MAS).

Version management of product objects has the following benefits:

  • Storage of content for IP protection and disaster recovery
  • Tracking of changes — what changes were made in the product object, who made them, and when
  • Reuse — the ability to choose a version of the product object to work with, rather than having to create additional objects
  • Collaboration — multiple users can edit and modify the same object, and an audit history of all changes is retained

To prepare for the storage of versions of component templates and NSH scripts, you must configure the following repositories and define them through the new Git Repository node in the Infrastructure Management dialog box:

  • A local repository on a computer that hosts an RSCD agent, preferably on the file server.
    The local repository must not be located behind a SOCKS proxy server.
    The following minimum specifications are recommended for the local repository:
    • 2 GB disk space

    • 1 GB RAM

    • Bash version 1.8 or above installed

  • A remote Git repository

After setting up the repositories, you can migrate existing NSH scripts, committing them into the local repository. The new Move to Git option is available for any individual NSH script in the depot, or for multiple NSH scripts in the Group Explorer view. Results of a migration of multiple NSH scripts are displayed through the new Git Migration Result dialog box.

After making changes to a component template or NSH script, you have the following options:

  • Commit your changes to the local repository. NSH scripts versions are saved as plain text, while component template versions are saved as json files, with the option of also storing template dependencies.
  • Push changes to the remote Git repository using a new Push button in the toolbar and the Git Push dialog box.
  • Open the component template or NSH script and view a summary of all object versions on the new Git Repository History tab for the component template or the new Git Repository History tab for the NSH script.
  • Compare any two object versions on the Git Repository History tab.
  • Revert to any previous version of the object.

For more information about the version management tasks that you can perform in product objects, see the following pages:

Several new commands have been added to the BLCLI to support the execution of these actions through command line. See BLCLI enhancements.

Compliance Content and Compliance enhancements

The following enhancements have been introduced in BMC BladeLogic Server Automation 8.8.00 for Compliance features:

New templates in Compliance Content for supporting additional policies and platforms

BMC BladeLogic Server Automation now supports the following additional Compliance Content component templates:

PCIv3 templates

Operating system OS Version Benchmark version Benchmark update BMC version
Microsoft Windows Server 2012 R2 3.0 November, 2013 8.8
Red Hat Enterprise Linux ES/AS 7 3.0 November, 2013 8.8

Existing templates that are updated in version 8.8 are as follows:

Policy Operating system OS version Benchmark version Benchmark update
DISA Microsoft Windows Server 2008 R2 Domain Controller Version 1/Release 17 October, 2015
2008 R2 Member Server Version 1/Release 17 October, 2015
Red Hat Enterprise Linux ES/AS 6.x Version 1/Release 9 October, 2015
5.x Version 1/Release 12 October, 2015

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

Patch management enhancements

The following enhancements have been introduced in BMC BladeLogic Server Automation 8.8.00 for patch management features:

Live reporting

The Live reporting dashboard displays complete information about patch management in one consolidated view. This view displays current and historical patch-related data, which allows the patch administrator to make informed decisions about patch management in the environment.

For example, the patch administrator may use Live reporting to answer the following questions:

  • What type of operating systems are running on the enrolled servers?
  • When was the last time a particular catalog updated successfully?
  • How many individual servers have been patched?
  • How many individual servers have been analyzed?
  • What are the common reasons for failure in patch analysis?
  • What are the errors for remediation jobs not executed successfully?

The Live reporting dashboard can be accessed from the Configuration menu in the console. However, before you use Live reporting, you must install and configure the Yellowfin business intelligence tool. For more information about setting up and using Live reporting, see Installing and configuring Yellowfin to enable Live reporting and Using the Live Reporting patch management dashboard.

Note

The Live Patching Dashboard capability delivered in version 8.8 is a new product feature that is supported via integration with Yellowfin. BMC Server Automation (BladeLogic) does not require a license key; however, use of Yellowfin does. A limited-use license key has been enabled as part of the Yellowfin installation process.

Use of Yellowfin technology is provided in conjunction with the Live Patching Dashboard capability of BMC Server Automation. Use of Yellowfin for capabilities other than the Live Patching Dashboard or independently of the integrated BMC Product is prohibited.

Selective remediation of successfully analyzed targets

You can now filter target servers that you want to remediate, from a list of successfully analyzed target servers within an analysis job. This filter enables you to run or schedule remediation jobs for target servers based on the priority of remediation. A remediation job for lower priority targets can then be run or scheduled at a later date and time.

You can choose to include or exclude the list of target servers for the remediation job, as follows:

SuSE 12 patching support

You can now patch SuSE 12 target servers using BMC Server Automation, if the SuSE patch repository server is configured with the Subscription Management Tool (SMT).

See the following table for information about which versions are installed with SMT out-of-the-box, and on which versions SMT must be manually installed.

Repository server version SMT installation

SuSE 11 SP3
SuSE 11 SP4

SuSE 12

Note: SuSE recommends upgrading SuSE 12 to SuSE 12 SP1 to avoid dependency issues.

Not configured with SMT out of the box. You must manually install and configure SMT (version 11 SP3) on the repository server before you create a SuSE patch catalog.
SuSE 12 SP1 or later (recommended) SMT is shipped out-of-the-box with the operating system.

Warning: BMC strongly recommends using Zypper when creating a patching job for a patch catalog that was created using the Subscription Management Tool (SMT). For more information, see Zypper patching tool.

Zypper patching support for SuSE Linux

An improved packaging framework called Zypper has been introduced in SUSE Linux 10.3 and later versions. BMC Server Automation 8.8 now supports patching using the Zypper packaging framework. Because Zypper is an improved packaging framework, BMC strongly recommends using the Zypper tool for patching instead of the existing YUM patching tool. For information about creating a patching job, see Patching Job - Analysis Options for Red Hat Enterprise Linux, Oracle Enterprise Linux, and SUSE Linux Enterprise.

Warning

  • Ensure that you have Zypper 1.3.7 or later is installed on your SuSE repository server, before you use Zypper for patching.
  • BMC strongly recommends using Zypper when creating a patching job for a patch catalog that was created using the Subscription Management Tool (SMT).

You can select the Zypper patching tool option while creating a SUSE patching job, as shown in the screenshot below:

Note

When upgrading at the SP level, select Dist-Upgrade Mode instead of the Update mode.

Zypper also supports updates for distributions and service packs, which is not supported by the YUM patching tool. The Zypper method of analysis automatically skips distribution and service pack upgrade-related rpms during normal package updates (Install mode and Update mode). In yum method of analysis, however, the distribution and service pack upgrade-related rpms are manually excluded during the normal package updates. As a result, you may find a difference in the analysis results of Zypper and yum.

  Click here to see steps to for upgrading SuSE 11 SP1 to SuSE 11 SP2 using zypper

As noted in this KB article from SuSE, SuSE 11 SP2 systems need both the SuSE 11 SP1 and the SuSE 11 SP2 repositories. Therefore, if you attempt to run patch analysis using a SuSE 11 SP2 catalog on a SuSE 11 SP1 target, dependency issues can occur, as the required RPM packages are not part of the SuSE 11 SP2 repositories.

  1. Create the SuSE 11 SP1 repository using the offline downloader.
  2. Create the SuSE 11 SP2 repository using the offline downloader.
  3. Copy the RPM packages from the two repositories to a separate folder.
  4. Run the offline downloader script using the createrepo option, and use the location from step 3 as input.
  5. Create the offline patch catalog using the above payload source location.
  6. Run the patch analysis job using the patch catalog created above.
  7. Run the update server properties job after the SuSE Upgrade. Note that the server properties are not automatically displayed after an upgrade, unless you run the update server properties job.

Refer to the following SuSE article for additional upgrade information: How to upgrade to SLES/SLED 11 SP3.

Improvements in the script-based patching solution for Solaris 11

The script-based solution for patching on Solaris 11 was enhanced with the following improvements:

  • The zip package for the Solaris 11 patching solution has been incorporated into the package of optional product components (BBSA88-Optional.zip) and is readily available through the EPD site.
  • During installation of the Solaris 11 patching solution, the the Solaris 11 Analysis Results extended object for display of patch analysis results is now imported automatically into the Configuration Object Dictionary; you no longer need to manually import it. The layout of information presented by this extended object through Live Browse was enhanced and simplified and is now easier to read.
  • The names of folders and scripts provided in the patching solution were adjusted with minor changes, for clarity.
  • The patching solution for Solaris 11 now supports alternate boot environment patching, as described in Solaris Live Upgrade (LU) patching. Alternate boot environment patching was previously supported only for the earlier versions of Solaris (9 and 10).
  • The patching solution now supports multiple IPS repositories. During the configuration of the parameters within the patching script, you can now specify multiple publishers as the value of the Publisher Name parameter (the -p flag). The two parameters that were used in the past to map the publisher name to a single repository server and repository location (the -s and -r flags, respectively) were removed, and mapping of multiple publishers is now done through the solaris11.cfg file.
  • A new parameter in the Repository Update script, Number of Retries (the -r flag) enables you to control the number times to try to update the repository before marking the update as failed. The default is 3 tries.

Deployment of Solaris IPS packages

BMC Server Automation now supports the packaging and deployment of Solaris IPS packages, archive files with the .p5p extension that have been prepared using Solaris tools. Deployment of .p5p archive files can serve as an alternative to using the script-based patching solution for Solaris 11.

To add an IPS package (.p5p file) to the depot, use the following new option for adding software to the depot: New > Software > Solaris IPS Package.

Support for reboot flag in Windows hotfixes

BMC Server Automation now uses the reboot property from the Windows metadata. This means that you can choose whether a BLPackage deploy job should reboot a target after a single hotfix is applied (based on the IS_REBOOT_REQUIRED* property) or after all hotfixes are applied on the target.

By default, the BLPackage deploy job reboots a target only after all hotfixes are applied. You can enable reboot for individual hotfixes, in the BLpackage deploy job, by selecting Use item defined reboot setting from the Reboot Options drop-down list, as shown in the following screenshot.

BMC Server Automation will now reboot the Windows target after deploying and applying each hotfix that has the IS_REBOOT_REQUIRED* property set from the Windows metadata. For example, the following screenshot highlights a hotfix that will reboot after it is applied on the target.

Note

You can also use the IS_REBOOT_REQUIRED* property to perform the following operations:

  • Create smart groups for hotfixes based on whether reboot is required or not.
  • View or sort analysis results based on the reboot flag

Customizing the products in the Windows filter selection list

The Windows product category XML file (product_categories.xml) contains Information that is used to populate the filter selection lists found in the patch catalog wizard. You can now customize the products in Windows product category XML file from the Global Configuration parameter list. For more information, see the Windows Filter Configuration File field in Global Configuration parameter list.

Support for creating an online Red Hat patch catalog using child channels

You can now create errata type filters for child channels, while creating an online Red Hat patch catalog. To customize the list of child channel filters displayed while creating the online catalog, edit the Red Hat Channel Filters List XML file, as described in Global Configuration parameter list.

Patch management issue for version 8.8 agents

The following OS versions are not supported as patching targets if the target system has version 8.8 of the BMC Server Automation agent installed. 

  • RedHat Enterprise Linux version 5 (and earlier)
  • Oracle Enterprise Linux version 5 (and earlier)
  • SuSE version 10 (and earlier)

For targets on any of these platforms, do one of the following:

  • Update the version 8.8 agents with the component template fix available from Knowledge Article 000120867.
  • Use an earlier version of the agent (for example, version 8.6 or 8.7).

Virtualization enhancements

The following enhancements have been introduced in BMC BladeLogic Server Automation 8.8.00 for virtualization support:

Item Description
Increase in maximum number of virtual disks deployed for a VMware VM

BMC Server automation can now successfully deploy a VMware VM with the maximum number of virtual disks (60) supported by VMware. In previous versions, you could deploy only 15 virtual disks.

Extended support for vCPUs and memory

BMC Server automation has increased the maximum limits for both vCPU and memory. The following list shows the limits by version:

ESX server 6.0

  • Virtual CPUs per VM: 128
  • RAM per VM: 4 TB

ESX server 5.5

  • Virtual CPUs per VM: 64
  • RAM per VM: 1 TB

ESX server 5.1

  • Virtual CPUs per VM: 64
  • RAM per VM: 1 TB

ESX server 5.0

  • Virtual CPUs per VM: 32
  • RAM per VM: 1 TB
Platform support

Beginning in BMC Server automation 8.8, versions of VMware ESX server prior to version 5.0 are no longer supported.

User experience enhancements

The following enhancements have been introduced in BMC BladeLogic Server Automation 8.8.00 to improve the general user experience:

Enhanced handling of OS-level exceptions by the Application Server

Various OS-level exceptions from the Windows Structured Exception Handling (SEH) mechanism or from Linux signals are now recognized and properly handled by the BMC Server Automation Application Server. New error messages are written to the Application Server log (appserver.log), and Application Server crashes are avoided. A new blasadmin parameter, EnableSignalHandling, enables you to turn on enhanced signal handling. By default, this parameter is set to false (that is, enhanced signal handling is turned off, and you turn it on only if you know that specific exceptions can be ignored).

NSH proxy tunneling

A new mechanism is introduced for communication between clients and Application Servers of type NSH_Proxy. This mechanism is based on tunneling, and it enhances the efficiency and throughput of communications. A new blasadmin parameter, EnableProxyTunneling, enables you to turn off the tunneling mechanism. By default, this parameter is set to a value of true (that is, tunneling is turned on).

Note

Do not use the NSH proxy tunneling mechanism in the following cases:

Job enhancements

The following enhancements have been introduced in job management in BMC BladeLogic Server Automation 8.8.00:

Limiting the number of targets that can be assigned to a job

You can now limit the number of targets that can be assigned to a job during job creation, job modification, or job execution against specific targets. To limit the number of targets allowed in jobs, you use a pair of blasadmin parameters in the JobFactory namespace, LIMITMAXTARGETSINJOB and MAXTARGETSINJOB. This maximum number of targets is applied to jobs of the following types: Audit Job, Compliance Job, Component Discovery Job, SCAP Compliance Job, Snapshot Job, Deploy Job, NSH Script Job, ACL Push Job, Update Server Properties Job, and Patch Job.

Administration enhancements

The following enhancements to BladeLogic administration have been introduced in BMC BladeLogic Server Automation 8.8.00:

Maintenance window for target servers

In a production environment, it is best practice to patch a server or update its software when it is in an idle state, to ensure that its resources are not over-utilized.

BMC Server Automation now allows the user to define a time interval, or maintenance window, within which all commit operations must be executed. This focus on commit operations is because all software packages and patches are applied to a target server only during the commit phase of a Deploy Job or Patching Job. If the commit phase of a Deploy Job is run outside of this time interval, the Deploy Job fails with a warning.

A maintenance window can be created and enabled for an individual server, a server group, or a server smart group. For more information, see Walkthrough: Defining a fixed time period for running deploy jobs or patching a server.

Item-wise status for a Windows BLPackage deploy job

In a BLPackage deploy job results view, you can now see the status of individual items deployed on Windows target servers. In the example below, a BLPackage is deployed on four Windows servers. You can see the individual items deployed on a server by right-clicking  or  in the Commit or Rollback column of that server.

You can see a detailed display of the status of each item deployed on the server. If the item is not deployed successfully, Windows sends an error code and description of the failure, and these are also displayed to the user.

You can also export the details for all items deployed by the BLPackage Deploy Job to a CSV file by right-clicking the deploy job and selecting Export Item Details.

New Shared Data module for online database cleanup

The online database cleanup mechanism, which enables you to delete unused data that is no longer needed for BMC Server Automation operations while the Application Server is running and the database is online, was enhanced with a new module to support the cleanup of historical database rows for generic assets and configuration objects created during the execution of Snapshot Jobs and Audit Jobs. Generic assets typically include configuration files, hardware information, processes, and daemons. The BLCLI command Delete cleanupHistoricalData now includes a new object type, SharedData, to enable this functionality.

Note

The shared data deleted by Delete cleanupHistoricalData SharedData does not usually overlap any of the data deleted by the existing commands Delete hardDeleteAllSharedObjects and Delete hardDeleteSharedObjectsByClass.

Health and Value Dashboard enhancements

In version 8.8, the Health and Value dashboard has been enhanced with the following new features:

  • Ability to configure Email notifications whenever there is a threshold violation. The notifications include recommended solutions, where possible.
  • Validation of Application Server database connection pool parameters, to ensure that they are properly set, based on work item threads (WITs).
  • Analysis of DBM offline clean-up parameters, to:
    • Show when the last time Offline Cleanup was run
    • Offer recommendations to run Offline Cleanup for a particular module

These new features are described in the following sections.

Email notification

Ability to configure Email notifications whenever there is a threshold violation. You can now use the following blasadmin utility commands to specify an email address that will receive threshold violation notifications:

set emailconfig smtpserver <smtp server name>

set emailconfig fromaddress <email address>

Once set, the email notification contains information for all Application Servers in your environment. You can specify one email address per Application Server.

The email report is generated whenever you run the dashboard update job, and a threshold has been crossed. The email has a subject line of Health Dashboard Violation Report With Recommendation.

The notifications include recommended solutions, where possible, as shown in the following graphic under Threshold Tips:

DB connection pool parameters

Validation of Application Server database connection pool parameters, to ensure that they are properly set, based on work item threads (WITs), worker threads, and so on.

In previous versions, the Maximum Job Execution Connections field on the Application Server tab displayed the value with which it had been configured. In version 8.8, a recommended value for the parameter is also displayed. The recommendation is dynamicaly calculated, based on the number of WITs.

For example, if the Number of work item threads value increases to a point where more connections are required, the dashboard shows a threashold violation (the row is highlighted in red) and provides a recommended value, as shown below:

The second column shows the current setting, while the third column displays the recommended value.

DBM offline clean-up

The following table lists the enhancements to the Database tab related to offline database cleanup. The new fields focus on analysis of DBM offline clean-up parameters, to:

  • Show when the last time Offline Cleanup was run
  • Show if it needs to be run
  • Show the domain names on which DB cleanup should be run
  • Provide recommendations to run Offline Cleanup for a particular module (including recommendations for Retention period).
Item Description
Run DBM Offline?

If the field displays Yes, then the recommendation is that you run the DBM Offline Cleanup.

This field has a value of Yes if more than 30% of the data can be cleaned up. The row is shaded yellow if 30-49% of the data can be cleaned up. If more than 50% can be cleaned up, the row is shaded red and will generate an alert.

Recommended Domain list for DBM offline cleanup

If the Run DBM Offline field displays a value of Yes, this field is also displayed. Click the Domain List link to see a list of the domains on which you should run the DBM offline cleanup. The list also displays the current Retention Time setting for the domain, based on your retention policy, and how much data will be cleaned up (in the Deletable Data in Percentage column).

Note: If the value for the Run DBM Offline field is No, then the Recommended Domain list field is not displayed.

DBM Offline Retention Scenarios

If available, click View to display the DBM Offline Retention Scenarios report.

This report lists the domains that are availlable for DBM offline cleanup, and also shows you the amount of data data (in %) will be cleaned up for specific retention settings (15, 30, 60, 90, 180, 365, and 730 days). A negative value indicates that you do not need to run DBM offline cleanup for that domain. In the example below, running the offline cleanup for the Deploy domain with a data retention policy of 90 days will clean up 99% of the data. The example also shows that running the offline cleanup is not necessary for the Audit Trail and Audit Result domains, as they are displaying a negative value.

The report can be exported in CSV format.

Database Active Resource Plan (if available)

This field is displayed only for Oracle databases. If the database is running maintenance windows, then this field will be highlighted in red, indicating that the performance of the offline cleanup was degraded due to the maintenance window. During the maintenance window, the system gets a higher priority of resources, while database users (including the offline cleanup) get a lower priority.

For SQL server databases, or if the cleanup is not affected by a maintenance window, the field displays Not applicable.

For more information about using the dashboard, see Using the Health and Value Dashboards.

New walkthrough topics added in this release

Walkthrough topics introduce you to a key BMC Server Automation use case (for example, compliance), and provide step by step, cookbook-style examples that demonstrate a specific aspect of that use case. The following walkthrough topics were added in 8.8:

For a full list of available walkthrough topics, see FAQs and additional resources.

BLCLI enhancements

The following table lists the new BLCLI commands that support developments and enhancements in BMC BladeLogic Server Automation 8.8.00:

New BLCLI commands in 8.8.00

Namespace Command Description
ContentImportExport commitTemplate Commits a specified component template into the local Git repository
NSHScript addNSHScriptToExternalRepo Adds an NSH script to the local Git repository.
NSHScript commitNSHScript Commits the specified NSH script to the local Git repository.
NSHScript moveToGit Moves the specified NSH script to the local Git repository.
Git pushToRemote Pushes all the git commits to the remote public Git repository.
Git saveGitConfig Obtains Git configurations from an input properties file and saves them in BladeLogic for Git-related operations.
DepotSoftware addSolarisIpsPackageToDepotByGroupName Adds a Solaris IPS package archive in the Depot.
DepotSoftware addSolarisIpsPackageToDepotByGroupName_1 Adds a Solaris IPS package archive in the Depot with URL mounting options.
PatchingJob createSusePatchingJobWithTargetServer Creates a Patching Job that is run against an individual server, using an existing SuSE catalog.
PatchingJob createSusePatchingJobWithTargetGroup Creates a Patching Job that is run against a server group, using an existing SuSE catalog.
Utility populateServerGrpforLiveReporting Populates data about servers included in server groups (whether static groups or smart groups) into a database table so that  reports on the Patch Live Dashboard will include information for the appropriate groups of servers.

Changes in OS support in BMC Server Automation version 8.8

This section lists the changes in OS support in BMC Server Automation version 8.8. For a complete list of supported platforms for the various components, see the Supported platforms for version 8.8.

New platform support for product components

The following table lists new combinations of operating systems and components that are supported in BMC Server Automation 8.8. (A plus sign (plus) indicates support.)

Platform / Version

RSCD
Agent

Network
Shell
(NSH)

Application
Server

PXE and 
TFTP

Provisioning

Patch

Virtualization Console
CentOS Linux 7.x (error) (plus) (error) (error) (error) (error) (error) (error)
Citrix XenServer 6.5 (error) (error) (error) (error) (error) (error) (plus) (error)
Debian 7.x (plus) (plus) (error) (error) (error) (error) (error) (error)
Debian 8.x (plus) (plus) (error) (error) (error) (plus) (error) (error)
Microsoft Windows version 10 (plus) (plus) (error) (error) (error) (plus) (error) (plus)
Oracle Enterprise Linux 7.x (plus) (plus) (plus) (error) (error) (error) (error) (error)

Ubuntu Linux Server 15.1 and 16.04

(plus) (plus) (error) (error) (error) (error) (error) (error)
VMware ESX Server 5.0 (error) (error) (error) (error) (plus) (error) (error) (error)

Deprecated platform support in version 8.8

BMC Server Automation 8.8 no longer supports Red Hat Enterprise Linux 5.x for the Application Server.

BMC Server Automation 8.8 no longer supports IBM AIX 5.1 for patch management.

BMC Server Automation 8.8 no longer supports the following platforms on all components:

  • Cent OS 4.x and 5.x
  • Debian 5.x and 6.x (OS end of life)
  • Windows Server 2003 and Windows Server 2003 with Virtual Center
  • Oracle Enterprise Linux 4.x
  • Red Hat Enterprise Linux 4.0 (and zSeries)
  • Solaris 9
  • SUSE Linux Enterprise Server 9.x
  • SUSE zSeries 9.x
  • Ubuntu 10.x and 11.x (OS end of life)
  • VMware ESX 3.x and 4.x (OS end of life)

BMC Server Automation 8.8 no longer supports the following platforms for virtualization:

  • VMware ESXi Server (via vCenter Server) 3.x and 4.x
  • VMware vCenter Server 4.0

Related topics

Downloading the installation files
Known and corrected issues

Frequently asked questions and other information

 This topic provides information that supplements the BMC Server Automation documentation. It contains the following sections:

Frequently asked questions

This section provides answers to frequently asked questions (FAQs) about BMC Server Automation.

General questions

  When is the end of support for my version of BMC Server Automation? Is my version supported? (Should I be thinking about upgrading?)

For supported version information, see the following BMC Support Support page:
http://webapps.bmc.com/support/faces/az/prodallversions.jsp?seqid=164625
Note that as of June 26, 2012, version 7.x releases are no longer supported.

  Where can I find information about the platforms currently supported for BMC Server Automation product versions?

You can find information about the supported platform for BMC Server Automation on BMC Support Central, under Product Availability and Compatibility.

  Where is the Knowledge Base?

The BMC Knowledge Base (which includes answers for common problems with BMC Server Automation) is located at https://bmcsites.force.com/casemgmt/sc_CoveoSearch#q=BMC%20Server%20Automation&t=KB&sort=relevancy

  What ports and protocols does BMC Server Automation require?

See the ports and protocols list.

  Where can I find the build number for a release?

You can find the build number for the various releases (base version, SPs, and patches) in Preparing for a Windows upgrade using the unified product installer or Preparing for a Linux or UNIX upgrade using the unified product installer.

  Where can I find information about the integration of BMC Server Automation with BMC ProactiveNet?

See the following documentation resources:

  • For information about enabling the retrieval of change information from BMC BladeLogic Server Automation for Probable Cause Analysis (PCA), see the chapter about integrating with BMC Server Automation in the BMC ProactiveNet User Guide.
  • For information about transferring data to BMC PATROL and BMC ProactiveNet regarding the status, availability, and performance of hosts and servers managed by BMC Server Automation, see the online documentation for BMC PATROL for BMC Server Automation and BMC ProactiveNet Automation Server Monitoring.

  Where can I find information about the third party software versions included with BMC Server Automation?

You can find information about the included software versions in the Third-party software section of the Minimum software requirements topic and in the Browsing discovered software applications topic.

Installation and upgrade questions

  What are the Supported upgrade paths for BMC Server Automation?

You can find information about the supported upgrade paths for BMC Server Automation in the Upgrading using individual component installers section of the online technical documentation (in the Preparing for a Windows upgrade using the unified product installer or Preparing for a Linux or UNIX upgrade using the unified product installer topics).

  Where can I find deployment architecture recommendations for implementing BMC Server Automation?

You can find deployment architecture recommendations in the following Planning section: Deployment use cases

  What do I do if I just upgraded and am getting errors in Jobs that reference Custom/Server Objects?

General product usage

  I'm having trouble with an RSCD agent. How do I open up the permissions temporarily?

Use the following process:

  1. Start by looking at the rscd.log. Who are your requests currently mapping to? If it is someone who does not exist in your users or users.local file, consider adding a temporary definition for them.
  2. Remove the "nouser" line from the users file.
  3. Change the contents of the exports file so that it contains a single line: "* rw,user=root" or "* rw,user=Administrator" (or the name of your local admin account).

Once you have finished troubleshooting, make sure to restore the original configuration.

  What do I do if my Application Server will not start up?

The following list shows some common causes for this issue:

  • Review the Application Server log and look for a Java stack trace; this usually indicates the issue.
  • A few common things can cause problems with the Application Server start up:
    • The File Server RSCD Agent is not licensed (for pre-8.2 versions).
    • ACLs were pushed to the File Server agent.
      • Add a 'System:System  rw,map=<root|Administrator>' to the users.local on the File Server agent.
  I have multiple Application Servers but I cannot see all Application Server status in the Infrastructure Manager window.

In this case, you need to synchronize the bladelogic.keystore across all Application Servers.

See To synchronize keystore files of multiple Application Servers for more information.

  How do I configure NSH/ZSH command history to persist across sessions?

See the following Knowledge Article for information on this issue:
Knowledge Article ID: 000022404

  Where can I find sizing recommendations for Application Servers?

You can find recommendations for sizing Application Servers in Sizing Application Servers.

  Where can I find "how to" information for specific user scenarios?

You can find a list of user contributed tutorial information in the BMC Contributor topics topic.

In addition, the taking the reins article on Communities includes additional videos and "how to" information.

  Are videos available that help to explain how to accomplish specific user tasks?
See the PDFs and videos topic for a list of all videos.

In addition, the taking the reins article on Communities includes additional videos and "how to" information.

Patch management

  How do I make sure my catalog does not get any new patches?

If the catalog is in Online mode, updating the catalog obtains any new patches or modifies existing patches that have changed. To prevent new patches from being downloaded, do not run the Catalog Update Job until you need new patches in the catalog.
If the catalog is in Offline mode, then to prevent new patches from being downloaded, you must ensure:

  • The source location has not been updated by re-running the downloader
  • The metadata file(s), if applicable, in the depot have not been changed since the last run

If you ensure the preceding items, running a Catalog Update Job does not add any new patch metadata or modify existing patch metadata.

  How do I make sure that my patching job remediates servers on execution?

While creating the Patching Job, from the Deploy Job options menu within the Remediation Options panel, select the Execute job now option. The same options are available while creating a remediation job from the Analysis results.

  How do I make sure that I run analysis every x hours?

You can specify a schedule for any Job to ensure that it is executed every x hours.

  How do I ensure that my catalog contains only attributes that meet "my" criteria?

You must create a custom property on an appropriate depot object. For example, to set certain criteria on a Windows Hotfix object, by selecting Property Dictionary View > Built-in Property Classes > Hotfix, you can add a new property. You can then create a new smart group using an appropriate condition to include this new property.

  How do I know which filters are missing from my Windows catalog to cover all products installed on all my targets that have been added to my patching job?

The job log of the Patching Job displays a warning message that indicates the filters that must be added so that all products on all targets that are part of the Patching Job are analyzed in the next run of the Patching Job. A sample warning message is shown below.

  How do I get more details about the Deploy Job that was executed when I installed patches on my targets?

You can use the drop-down list in the Deploy Job options settings to get the desired information about the execution of that Deploy Job. For example, if you select the All Information option within Logging level, subsequent execution of the Deploy Job provides you with all information about the Deploy Job execution.

Troubleshooting

  How can I determine where BMC Server Automation is installed?

On UNIX, look in /etc/lib/rsc/HOME or /usr/lib/rsc/HOME. If that file does not exist, you are running a local or self-contained installation, and will need to derive the installation location from running processes. For example:

  Where are the RSCD Agent logs located?

On Windows: INSTALL_DIR\RSCD\rscd.log

On UNIX: INSTALL_DIR/[NSH|RSCD]/log/rscd.log

  Where is the transaction or bldeploy log?

<INSTALLDIR>\Transactions\log\bldeploy-xxxx.log

  Where is the BMC Server Automation Application Server log that contains deployment messages?

<INSTALLDIR>\br\<deployment name>.log
 
The default deployment name is appserver, while other common deployments have names such as job-1.

  How do I analyze the *Trace.txt* file that is generated by a Windows Patch Analysis Job?

For detailed instructions on analyzing the Trace.txt file, see How to analyze Trace.txt generated by a Windows Patch Analysis Job (user contribution).

For a list of frequently asked questions for Agent troubleshooting, see  Frequently asked questions for agent troubleshooting .

Top Knowledge Articles from BMC Customer Support

BMC Communites maintains a list of the top 10 Knowledge Articles (KAs) as recommended by the Customer Support team for BMC BladeLogic Server Automation.

The KAs are selected by a combination of both the collective experience of the team and other quantitative factors, with the goal of sharing the most relevant and useful information in a easy to consume format.

See Top 10 Knowledge Articles for BladeLogic Server Automation on BMC Communities for the list.

Available walkthroughs

Walkthrough topics introduce you to a key BMC BladeLogic Server Automation use case (for example, compliance), and provide step by step, cookbook-style examples that demonstrate a specific aspect of that use case. 

  Click here to see a list of the topics in this space that are walkthroughs.
Category Walkthrough topics
Getting started with automation

Provisioning

Configuration management

Patch management

Job management

Compliance

Installing
Integrating
Database


Additional resources

The following BMC sites provide information outside of the BMC Server Automation documentation that you might find helpful:


PDFs

 

Videos

The following table lists topics that contain videos that supplement or replace the text-based documentation. To see additional videos about BMC BladeLogic Server Automation and other BMC solutions, visit BMCtv.

Category Topics with videos
Administering
Getting started

Installing
Upgrading
Console management

Auditing
Compliance
Patch management
Deploy Jobs
Live Reporting Dashboard
Security
Integrating
Developing
BLCLI
Troubleshooting
Support information
Licensing
 

Was this page helpful? Yes No Submitting... Thank you

Comments