BMC Server Automation 8.8
Placing a watch on this page is a great way to stay informed of changes to this space.
|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.
Ready-made PDFs are available on the PDFs page. You can also create a custom PDF.
Concepts, architecture, deployment, planning, and system requirements.
Information about installing the product and migrating product data.
Required post-installation configuration.
Upgrade process, migration, and configuration.
Issues resolution, error messages, logs, and contacting Support.
Interface descriptions, using the product.
Security, system administration, maintenance.
Development interfaces and toolkits.
Integrations with other products.
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:
- Installation and upgrade enhancements
- Version management of product objects using Git
- Compliance Content and Compliance enhancements
- Patch management enhancements
- Virtualization enhancements
- User experience enhancements
- Job enhancements
- Administration enhancements
- Health and Value Dashboard enhancements
- New walkthrough topics added in this release
- BLCLI enhancements
- Changes in OS support in BMC Server Automation version 8.8
- Related topics
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_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):
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:
- Walkthrough: Managing versions of NSH scripts using Git
- Walkthrough: Managing versions of component templates using Git
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:
|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:
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.
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).
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.
- 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:
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.
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.
- Create the SuSE 11 SP1 repository using the offline downloader.
- Create the SuSE 11 SP2 repository using the offline downloader.
- Copy the RPM packages from the two repositories to a separate folder.
- Run the offline downloader script using the createrepo option, and use the location from step 3 as input.
- Create the offline patch catalog using the above payload source location.
- Run the patch analysis job using the patch catalog created above.
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.
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)
Earlier versions of the agent (for example, versions 8.6 and 8.7) are supported for patch management on the above OS versions.
The following enhancements have been introduced in BMC BladeLogic Server Automation 8.8.00 for virtualization support:
|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
ESX server 5.5
ESX server 5.1
ESX server 5.0
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).
Do not use the NSH proxy tunneling mechanism in the following cases:
- If you want to use automation principals for server management.
- If you want to use TLS communication with client-side certificates to secure access between Application Servers and agents or repeaters.
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
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.
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.
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.
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).
|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:
- Walkthrough: Managing versions of NSH scripts using Git
- Walkthrough: Managing versions of component templates using Git
For a full list of available walkthrough topics, see FAQs and additional resources.
The following table lists the new BLCLI commands that support developments and enhancements in BMC BladeLogic Server Automation 8.8.00:
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.
Frequently asked questions
This section provides answers to frequently asked questions (FAQs) about BMC Server Automation.
For supported version information, see the following BMC Support Support page:
Note that as of June 26, 2012, version 7.x releases are no longer supported.
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
See the ports and protocols list.
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.
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.
Installation and upgrade questions
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).
You can find deployment architecture recommendations in the following Planning section: Deployment use cases
General product usage
Use the following process:
- 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.
- Remove the "nouser" line from the users file.
- 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.
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.
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.
See the following Knowledge Article for information on this issue:
Knowledge Article ID: 000022404
You can find recommendations for sizing Application Servers in Sizing Application Servers.
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.
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.
You can specify a schedule for any Job to ensure that it is executed every x hours.
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.
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.
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.
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:
On Windows: INSTALL_DIR\RSCD\rscd.log
On UNIX: INSTALL_DIR/[NSH|RSCD]/log/rscd.log
The default deployment name is appserver, while other common deployments have names such as job-1.
For detailed instructions on analyzing the Trace.txt file, see How to analyze Trace.txt generated by a Windows Patch Analysis Job (user contribution).
Top Knowledge Articles from BMC Customer Support
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.
|Getting started with automation||
The following BMC sites provide information outside of the BMC Server Automation documentation that you might find helpful:
- BMC Communities, Server Automation community, where you can find a series of Best Practice webinars
- BMC Support Knowledge Base, search filtered by BMC Server Automation
- BMC Educational Services, BMC Server Automation learning path
- BMC Global Services, BMC Server Automation offerings
- www.bmc.com, information about BMC Server Automation