BMC Server Automation User Guide
BMC Server Automation User Guide
Guide
Supporting
Version 8.2.01 of BMC Server Automation
April 2012
www.bmc.com
Contacting BMC Software
You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain
information about the company, its products, corporate offices, special events, and career opportunities.
BladeLogic and the BladeLogic logo are the exclusive properties of BladeLogic, Inc. The BladeLogic
trademark is registered with the U.S. Patent and Trademark Office, and may be registered or pending
registration in other countries. All other BladeLogic trademarks, service marks, and logos may be
registered or pending registration in the U.S. or in other countries. All other trademarks or registered
trademarks are the property of their respective owners.
AIX, Active Memory, Common Platform, Current, Express, IBM, Notes, and PowerVM are trademarks or
registered trademarks of International Business Machines Corporation in the United States, other
countries, or both.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks
of their respective owners.
UNIX is the registered trademark of The Open Group in the US and other countries.
The information included in this documentation is the proprietary and confidential information of BMC
Software, Inc., its affiliates, or licensors. Your use of this information is subject to the terms and conditions
of the applicable End User License agreement for the product and to the proprietary and restricted rights
notices included in the product documentation.
Support website
You can obtain technical support from BMC 24 hours a day, 7 days a week at http://www.bmc.com/support. From this
website, you can
read overviews about support services and programs that BMC offers
find the most current information about BMC products
search a database for problems similar to yours and possible solutions
order or download product documentation
download products and maintenance
report a problem or ask a question
subscribe to receive proactive e-mail alerts
find worldwide BMC support center locations and contact information, including e-mail addresses, fax numbers, and
telephone numbers
product information
product name
product version (release number)
license number and password (trial or permanent)
operating system and environment information
machine type
operating system type, version, and service pack or other maintenance level such as PUT or PTF
system hardware configuration
serial numbers
related software (database, application, and communication) including type, version, and service pack or
maintenance level
sequence of events leading to the problem
commands and options that you used
messages received (and the time and date that you received them)
3
License key and password information
If you have questions about your license key or password, contact BMC as appropriate for your location:
(USA or Canada) Contact the Order Services Password Team at 1 800 841 2031, or send an e-mail message to
[email protected].
(Europe, the Middle East, and Africa) Fax your questions to EMEA Contracts Administration at +31 20 354 8702, or send
an e-mail message to [email protected].
(Asia-Pacific) Contact your BMC sales representative or your local BMC office.
Contents 5
Viewing files using a tail -f editor .....................................................................81
Setting preferences for text editors ....................................................................82
Selecting editors ...................................................................................................83
Console management .....................................................................................................83
Customizing preferences ...................................................................................84
Viewing keyboard shortcuts ..............................................................................94
Customizing keystroke combinations ..............................................................94
Customizations for tables and columns ...........................................................95
Refreshing data ....................................................................................................99
Dragging and dropping jobs and targets .......................................................100
Folders view and resource management ..................................................................101
Components folder ............................................................................................101
Component Templates folder ..........................................................................101
Depot folder ........................................................................................................102
Devices folder .....................................................................................................102
Jobs folder ...........................................................................................................102
RBAC Manager folder .......................................................................................103
Search ...................................................................................................................103
Servers folder ......................................................................................................103
Creating new objects .........................................................................................103
Using the Active Node view ............................................................................104
Folder content organization ........................................................................................104
Searching for objects ..........................................................................................106
Creating a folder or group ................................................................................107
Defining a smart group ....................................................................................108
Copying, cutting, and pasting groups, folders, and system objects ..........112
Deleting a folder, group, smart group, or system object .............................113
Properties, Permissions, and Audit Trail tab group ................................................115
Properties view ...................................................................................................116
Permissions view ...............................................................................................117
Audit Trail view .................................................................................................117
Viewing dependencies .................................................................................................117
Import and export concepts ........................................................................................118
Exporting BMC Server Automation objects ...................................................120
Importing BMC Server Automation objects ..................................................123
Exporting templates using a version-neutral mechanism ...........................136
Importing templates using a version-neutral mechanism ...........................138
Contents 7
Creating an ACL policy ...............................................................................................189
ACL policy General ........................................................................................190
ACL policy Policy Access Control List ........................................................190
ACL policy Permissions .................................................................................194
Modifying ACL policies ....................................................................................195
Creating automation principals ..................................................................................195
Automation principal General ......................................................................197
Automation principal Role Associations .....................................................198
Automation principal Properties ..................................................................198
Automation principal Permissions ..............................................................199
Modifying automation principals ...................................................................200
Using server properties to map automation principals for Windows user
mapping ..............................................................................................................200
Creating an LDAP connection ....................................................................................201
LDAP Connection General ............................................................................202
LDAP Connection Properties ........................................................................204
LDAP Connection Permissions .....................................................................204
Modifying LDAP connections .........................................................................205
Creating an LDAP query .............................................................................................206
LDAP Query General .....................................................................................207
LDAP Query Properties .................................................................................208
LDAP Query Permissions ..............................................................................209
Modifying LDAP queries ..................................................................................210
Creating roles ................................................................................................................210
Role General ....................................................................................................212
Role Agent ACL ..............................................................................................213
Role Users ........................................................................................................216
Role Summary .................................................................................................216
Role Properties ................................................................................................216
Role Permissions .............................................................................................217
Modifying Roles .................................................................................................218
Creating users ................................................................................................................220
User General Information ..............................................................................221
User Role Selection .........................................................................................224
User Properties ................................................................................................225
User Permissions .............................................................................................225
Modifying users .................................................................................................226
Synchronizing users with LDAP servers ..................................................................227
Minimum authorizations for synchronizing users .......................................229
Object-based permissions ............................................................................................230
Defining permissions for a system object .......................................................231
Contents 9
Unified Agent Installer Remote Host Authentication Rule .....................282
Unified Agent Installer Agent Installer Job Options .............................283
Unified Agent Installer Agent Installer Job Targets ...............................284
Unified Agent Installer Required Properties ..............................................286
Unified Agent Installer Summary ................................................................286
Creating objects for agent installation .......................................................................287
Specifying or modifying information for remote host authentication .......288
Creating or modifying rules for remote host authentication ......................293
Creating an agent bundle .................................................................................296
Modifying agent bundles ..................................................................................303
Creating an Agent Installer Job ........................................................................303
Modifying Agent Installer Jobs ........................................................................315
Scenarios for installing agents ....................................................................................315
Troubleshooting agent installation ............................................................................316
Contents 11
Modifying components ................................................................................................432
Validating a component ...............................................................................................433
Setting multiple components as exceptions to compliance rules ..........................434
Set Component Exceptions General ............................................................435
Set Component Exceptions Associated Compliance Rules .....................436
Set Component Exceptions Components ...................................................437
Adding components to a component group .............................................................437
Installing or uninstalling a component ......................................................................438
Creating Compliance Jobs ...........................................................................................439
Compliance Job General ................................................................................440
Compliance Job Component templates for filtering ..................................441
Compliance Job Components ........................................................................441
Compliance Job Autoremediation ................................................................442
Compliance Job Default Notifications .........................................................452
Compliance Job Schedules .............................................................................454
Compliance Job Properties ............................................................................456
Compliance Job Permissions .........................................................................457
Modifying Compliance Jobs .............................................................................458
Compliance results .......................................................................................................458
Compliance statuses of compliance rules .......................................................460
Viewing compliance results by rule ................................................................461
Viewing compliance results by server ............................................................461
Viewing the results of a compliance rule .......................................................462
Defining exceptions for components ..............................................................464
Viewing and using autoremediation results ..................................................466
Undoing autoremediation ................................................................................466
Manually remediating compliance results .....................................................467
Creating a remediation package ......................................................................469
Packaging and deploying a component ....................................................................470
Exporting compliance results ......................................................................................471
Using component templates to ensure compliance for multiple instances of an
application .....................................................................................................................472
Contents 13
Adding files to the Depot ............................................................................................556
Add File General .............................................................................................556
Add File Properties .........................................................................................557
Add File Permissions ......................................................................................557
Contents 15
Chapter 14 Audit Jobs 677
Audit Job overview .......................................................................................................677
Creating Audit Jobs ......................................................................................................677
Audit Job General ...........................................................................................679
Audit Job Component Templates for Filtering ...........................................680
Audit Job Masters ...........................................................................................681
Audit Job Server Objects ................................................................................681
Audit Job Targets ............................................................................................687
Audit Job Default Notifications ....................................................................688
Audit Job Schedules .......................................................................................689
Audit Job Properties .......................................................................................692
Audit Job Permissions ....................................................................................693
Modifying Audit Jobs ...................................................................................................694
Audit Job results ...........................................................................................................694
Viewing audit results by object .......................................................................697
Viewing audit results by server .......................................................................698
Viewing differences between text files ...........................................................701
Audit results for configuration files ................................................................702
Using audit results to synchronize servers ...............................................................702
Sync Sync Details ............................................................................................704
Sync Package Item Options ...........................................................................705
Packaging audit results ................................................................................................706
Package Delta Package Type .........................................................................707
Package Delta Package Item Options ..........................................................708
Grouping noncompliant servers .................................................................................709
Exporting results of an audit or snapshot .................................................................710
Contents 17
Network Shell Script Job Properties .............................................................799
Network Shell Script Job Permissions .........................................................800
Modifying Network Shell Script Jobs ........................................................................801
Contents 19
Virtual Guest Job - ACL Wizard ......................................................................964
Virtual Guest Job - Server ACL ........................................................................964
Virtual Guest Job - Instance Properties ...........................................................965
Virtual Guest Job - Class Properties ................................................................965
Virtual Guest Job - Server Properties ..............................................................965
Virtual Infrastructure Discovery Job Wizard Panels ...............................................965
Virtual Infrastructure Discovery Job - General .............................................966
Virtual Infrastructure Discovery Job - Targets ..............................................968
Virtual Infrastructure Discovery Job - Destination Selection ......................969
Virtual Infrastructure Discovery Job - Select Lifecycle Properties
Mapping ..............................................................................................................969
Virtual Infrastructure Discovery Job - Notifications ....................................970
Virtual Infrastructure Discovery Job - Schedules ..........................................970
Virtual Infrastructure Discovery Job - Properties .........................................971
Virtual Infrastructure Discovery Job - Permission ........................................971
Virtual Guest Template Enrollment Job Wizard Panels .........................................972
New Virtual Guest Template Enrollment Job - General ..............................972
New Virtual Guest Template Enrollment Job - Targets ...............................973
New Virtual Guest Template Enrollment Job - Notifications panel ..........974
New Virtual Guest Template Enrollment Job - Schedule ............................975
New Virtual Guest Template Enrollment Job Properties .........................975
New Virtual Guest Template Enrollment Job - Permissions .......................976
Contents 21
New Patch Download Job Download Options .........................................1105
New Patch Download Job Default Notifications .....................................1106
New Patch Download Job Schedules .........................................................1107
New Patch Download Job Properties ........................................................1107
New Patch Download Job Permissions .....................................................1108
Removing irrelevant patches from an existing catalog .........................................1109
Deploying directly from the patch catalog (AIX only) ..........................................1109
Creating a Patching Job ..............................................................................................1110
Patching Job General ....................................................................................1112
Patching Job Analysis Options for Microsoft Windows .........................1113
Patching Job Analysis Options for Solaris .................................................1114
Patching Job Analysis Options for AIX .....................................................1119
Patching Job Analysis Options for Red Hat Enterprise Linux, Oracle
Enterprise Linux, and SUSE Linux Enterprise ...........................................1120
Patching Job Remediation Options ............................................................1121
Patching Job Targets .....................................................................................1121
Patching Job Output .....................................................................................1122
Patching Job Default Notifications .............................................................1123
Patching Job Schedules ................................................................................1124
Patching Job Properties ................................................................................1127
Patching Job Permissions .............................................................................1127
Modifying Patching Jobs ...........................................................................................1128
Viewing Patching Job results ....................................................................................1129
Managing patches through the analysis results view ................................1132
Viewing Batch Job results for remediation ..................................................1133
Manually remediating servers ..................................................................................1134
Patch Remediation Job General ..................................................................1134
Patch Remediation Job Packaging Options ...............................................1135
Remediation Jobs Deploy Job Options ......................................................1135
Patch Remediation Job Default Notifications ...........................................1136
Patch Remediation Job Schedules ..............................................................1137
Viewing manual remediation job results ................................................................1139
Patch Deployment ......................................................................................................1140
Enhanced view of Patching Job status ..........................................................1141
Additional Information on installed patches, configuration data, and more ....1142
Contents 23
Network Windows .......................................................................................1235
Unattend entries Windows 2008 .................................................................1236
Unattend entries all Windows operating systems except Windows 2008
1238
Post-install configuration Windows and Windows R2 ...........................1239
Local properties Windows ...........................................................................1243
Defining settings for Red Hat Linux servers ..........................................................1243
Pre-install scripts Red Hat Linux ................................................................1244
Disk partition Red Hat Linux ......................................................................1245
Basic configuration Red Hat Linux ............................................................1247
Computer settings Red Hat Linux .............................................................1248
OS components Red Hat Linux ..................................................................1249
Network Red Hat Linux .............................................................................1250
Kickstart entries Red Hat Linux .................................................................1251
Post-install configuration Red Hat Linux ..................................................1252
Local properties Red Hat Linux ..................................................................1254
Defining settings for SUSE Linux servers ...............................................................1254
Pre-install scripts SUSE Linux .....................................................................1255
Disk partition SUSE Linux ...........................................................................1256
Basic configuration SUSE Linux .................................................................1257
Computer settings SUSE Linux ..................................................................1258
OS components SUSE Linux .......................................................................1259
Network SUSE Linux ...................................................................................1260
AutoYaST entries SUSE Linux ....................................................................1261
Post-install configuration SUSE Linux ......................................................1264
Local properties SUSE Linux ......................................................................1265
Defining settings for ESXi 4.1 and 5.0 servers ........................................................1266
Pre-install script ESXi 4.1 and 5.0 ...............................................................1267
Disk partition ESXi 4.1 and 5.0 ....................................................................1267
Basic configuration ESXi 4.1 and 5.0 ..........................................................1268
Computer settings ESXi 4.1 and 5.0 ..........................................................1270
Network ESXi 4.1 and 5.0 ............................................................................1270
Kickstart entries ESXi 4.1 and 5.0 ...............................................................1271
Post-install configuration ESXi 4.1 and 5.0 ...............................................1274
Local properties ESXi 4.1 and 5.0 ................................................................1275
Defining settings for ESX servers .............................................................................1276
Pre-install script ESX ....................................................................................1276
Disk partition ESX .........................................................................................1277
Basic configuration ESX ...............................................................................1280
Computer settings ESX ................................................................................1281
Network ESX .................................................................................................1282
Contents 25
Local properties AIX .....................................................................................1322
Defining settings for HP-UX servers ........................................................................1322
Basic configuration HP-UX .........................................................................1323
Disk partition HP-UX ...................................................................................1324
Computer settings HP-UX ...........................................................................1324
Network settings HP-UX .............................................................................1326
Ignite commands/scripts HP-UX ...............................................................1327
Optional Ignite parameters HP-UX ............................................................1328
Software selection HP-UX ...........................................................................1328
Boot script HP-UX ........................................................................................1328
Post-install configuration HP-UX ...............................................................1329
Preview HP-UX .............................................................................................1330
Local properties HP-UX ...............................................................................1331
Folders, access control, and system package sharing: an example .....................1331
Importing and managing devices ............................................................................1332
Manually adding one device ..........................................................................1333
Preparing to import a list of devices .............................................................1338
Importing a list of devices .............................................................................1344
Device smart groups ........................................................................................1347
Deleting devices ...............................................................................................1348
Monitoring the provisioning status of devices .......................................................1349
Viewing imported devices ..............................................................................1349
Viewing provisioned devices .........................................................................1350
Viewing device information ...........................................................................1350
Viewing and changing device properties .....................................................1351
Viewing device provisioning history ............................................................1352
Viewing a system packages provisioning history .....................................1352
Manually classifying devices as provisioned .............................................1353
Deleting devices ...............................................................................................1353
Creating a Provision Job ............................................................................................1354
Provision Job General ...................................................................................1356
Provision Job System Package Properties .................................................1356
Provision Job Devices ...................................................................................1357
Provision Job Job Settings (PXE only) ........................................................1359
Provision Job Server Settings ......................................................................1360
Provision Job Default Notifications ............................................................1361
Provision Job Schedules ...............................................................................1362
Provision Job Properties ...............................................................................1364
Provision Job Permissions ...........................................................................1364
Selecting devices and executing a Provision Job ....................................................1365
Changing or adding devices in a Provision Job ..........................................1366
Contents 27
Inserting a parameter in a system package field .........................................1413
Using properties to reference scripts ............................................................1414
Data store instance properties ........................................................................1415
Data store instances and provisioning strategies ........................................1415
Glossary 1495
Contents 29
30 BMC Server Automation User Guide
1
Introduction
This section introduces BMC Server Automation.
Deploy software, patches, and complex packages of files and other assets
Store configurations
Chapter 1 Introduction 31
Documentation conventions
All BMC Server Automation capabilities are available on multiple operating systems.
Documentation conventions
This document uses some special conventions.
If a procedure requires you to select a suboption from a menu option, the description
includes a > to indicate you are choosing a sub-option. For example, a description
might read select Main Option > Suboption rather than saying select Main
Option and then select Suboption.
Chapter 1 Introduction 33
References to online documentation
RSCD agent (Remote System Call Daemon)Software that must be installed and
running on each remote server that BMC Server Automation accesses.
Command Line Interface (CLI or BLCLI)A set of utilities that let you perform
most BMC Server Automation tasks from a command line.
System architecture
A BMC Server Automation system has a three-tier architecture that consists of client,
server, and middle tiers.
The following graphic illustrates the relationship between the major components of
the three-tiered BMC Server Automation system.
Client tier
The BMC Server Automation client tier includes:
A web interface to the BMC BladeLogic Decision Support for Server Automation
server
The BMC Server Automation Console is a graphical user interface that gives system
administrators sophisticated tools for managing and automating data center
procedures. It also lets administrators provision operating systems onto servers.
All BMC Server Automation client-tier applications let you manage multiple servers
running many operating systems, including Oracle Solaris, Red Hat Enterprise
Linux, Novell SUSE Linux Enterprise, Oracle Enterprise Linux, IBM AIX, HP-UX,
and Microsoft Windows 2000, 2003, and 2008 servers.
Middle tier
The main component of the middle tier is the Application Server, which controls:
Communication between the BMC Server Automation Console and remote servers
The middle tier includes components for provisioning servers using the Preboot
Execution Environment (PXE) technology. The principal components are the PXE
server and TFTP server (typically installed on the same host) and the Application
Server. The PXE server delivers instructions to servers being provisioned so they can
download a bootstrap program from the TFTP server. The TFTP server transfers
preboot images to the servers on request from the PXE server. The Application
Server provides servers being provisioned with the instructions to provision the
machine.
If a site is running BMC BladeLogic Decision Support for Server Automation, the
middle tier includes an Apache Tomcat server. BMC BladeLogic Decision Support
for Server Automation uses the Application Server to authenticate users, and it reads
data from the core BMC Server Automation database as well as a reporting data
warehouse. The reporting data warehouse is populated with information from the
core BMC Server Automation database.
Server tier
The BMC Server Automation server tier consists of RSCD agents on remote servers.
The Application Server communicates with RSCD agents and initiates all
communication to perform ad hoc and scheduled tasks. RSCD agents never initiate
communication with an Application Server or any other BMC Server Automation
component.
Access control
BMC Server Automation uses a system of role-based access control (RBAC). You can
grant permissions to perform actions at both the role and object level.
The BMC Server Automation Application Server enforces access to system objects
throughout the BMC Server Automation Console. After role-level authorizations and
server permissions are defined, you can push information to an agent on a remote
server. The information is converted into entries in a configuration file that restricts
user access to the agent. In this way, you can control all incoming connections to
RSCD agents, including connections from Network Shell and the BLCLI.
For more information about BMC Server Automation security, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Administering
+security.
Folder overview
The main functional areas in the BMC Server Automation Console are called folders.
The following sections describe the folders that the console provides:
These folders provide the tools to define access to objects in the BMC Server
Automation system and then manage and automate activities throughout the data
center.
All folders except RBAC Manager let you organize system objects into folders,
groups, or smart groups. A folder or group consists of the system objects you assign
to it. A smart group is dynamically populated with system objects that meet a set of
conditions you define, such as all servers running Windows 2003 or all Compliance
Jobs.
such as junior administrators or system architects. Using the RBAC Manager folder,
you can take many actions, including:
Creating access control list (ACL) templates, which are sets of role-based
permissions that you can apply to system objects
Defining ACL policies, which let you manage a group of authorizations in one
location that automatically applies to multiple system objects
Servers folder
Use the Servers folder to browse all of the server objects on a serverthat is, the
files, applications, packages, registry values, and other assets that a server holds.
You can also view all job activity that has occurred on a server, including the history
of each job. From the Servers folder, you can initiate many actions based on servers
or server objects.
Components folder
Use the Components folder as a central location for managing components. With the
Components folder, you can organize components, run various jobs on components,
and change the properties and permissions of a component.
Depot folder
Use the Depot folder to store objects you may need, such as files, Network Shell
scripts, hotfixes, software packages, system packages, and patch catalogs. You can
also store a BLPackage, which is an aggregation of many types of server objects that
you can deploy simultaneously to multiple remote servers without user interaction.
From the Depot, you can initiate jobs and other actions based on the system objects
stored there. The Depot folder is also known as the Depot.
Devices folder
Use the Devices folder when provisioning servers. The Devices folder lets you view
discovered servers (servers that have booted up but have not yet been provisioned),
prediscovered servers (servers that have not yet booted up but have already been
added to the system), and provisioned servers. Using the Devices folder, you can
also create and run Provision jobs on servers.
Jobs folder
Use the Jobs folder to create and store all the jobs you use to perform tasks in BMC
Server Automation.
When you use the BMC Server Automation Console to log on, the logon process first
connects to the BMC Server Automation Authentication Service, which is a service
dedicated to validating user identities. The Authentication Service is implemented as
a service within the BMC Server Automation Application Server. Processing logon
requests for all authentication protocols, the Authentication Service examines user
credentials, such as IDs and passwords, to determine if a user is valid.
BMC Server Automation uses transport layer security (TLS) and X.509 certificates to
secure communication between all of its components. BMC Server Automation
Application Servers generate their own self-signed X.509 certificates. The first time
you use the BMC Server Automation console to contact an Application Server, the
Application Server presents a self-signed certificate and asks you to trust it. If you
choose to trust the certificate, secure communication is established with the
Application Server. The certificate you trust is added to a keystore, which holds all
of the certificates that the BMC Server Automation console has chosen to trust.
When you communicate with the same Application Server in the future, the
Application Server again presents its certificate. This time, however, the system can
determine that the certificate is already included in the keystore and a secure
connection is established immediately. You do not have to explicitly trust the
certificate again.
Before a user tries to log on to BMC Server Automation, some preliminary steps are
necessary (see Preparation for user logons on page 44).
Before you attempt to log on, you should confirm that your user name is included in
the BMC Server Automation system of role-based access control (RBAC). If a user is
not granted the appropriate rights in RBAC, the user may not be able to authenticate,
or, if authentication succeeds, the user may not be able access the correct system
objects throughout BMC Server Automation. For more information about RBAC, see
Access control on page 38.
After you satisfy the prerequisites, you can log on to the BMC Server Automation
Console (see Starting the BMC Server Automation Console on page 46).
When you set up an authentication profile, you can choose the type of authentication
you want to perform. By default, BMC Server Automation provides secure remote
password (SRP) authentication. For more information about configuring all types of
authentication, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Administering+security.
During a logon session, the Authentication Service authenticates users and issues
session credentials. The Authentication Service is a service implemented within the
BMC Server Automation Application Server. The Authentication Service is
responsible for authenticating users and issuing session credentials.
Note
Authentication profiles are stored in a file called authenticationProfiles.xml. If
multiple users share the same machine and decide to define their own authentication
profiles, they could access the same file simultaneously. To avoid this situation, BMC
recommends that administrators set up standard authentication profiles for all users
sharing the same machine. The administrator should also limit write access to the
authenticationProfiles.xml file. For information about storing authentication
profiles, see BMC technical documentation at https://docs.bmc.com/docs/display/
bsa82/Authentication+profiles.
1 To open the logon window for the BMC Server Automation Console, do one of
the following:
From the Start menu, select Programs > BMC Software > BladeLogic Server
Automation Suite > Server Automation Console releaseNumber.
From the directory where BMC Server Automation is installed (for example,
C:\Program Files\BMC Software\BladeLogic\CM), enter:
.\rcp\BSAClient.exe
If more than one version of the client is installed, the different versions
reside in directories called BladeLogicN, such as BladeLogic2.
(UNIX) From the directory where BMC Server Automation is installed (for
example, /opt/bmc/BladeLogic/CM), enter:
./rcp/launcher.sh
2 In the logon window, click Options. The window expands to show additional
options in a tabbed format.
To create a new profile, click Add. The New Authentication Profile dialog box
opens. It provides the same fields as the Edit Authentication Profile dialog box.
5 In the Authentication Profile dialog box, enter values for the following:
Profile Name
Name you assign to this authentication profile. For example, you could
assign a name such as QATeam or DevTeam.
Application Server
Authentication Port
Port to which the client should connect to the Authentication Service. The
same port is used for all BMC Server Automation authentication mechanisms.
Authentication Method
Select LDAP. Optionally, for Distinguished Name Template, enter the name
of a distinguished name template used to identify LDAP users.
For more information about distinguished name templates, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Configuring
+LDAP+authentication.
6 Click OK.
If the information you provide when you log on is valid, you are granted a session
credential. BMC Server Automation client applications use a session credential to
establish a secure connection with the BMC Server Automation Application Server.
If you already have a valid session credential, this procedure explains how to use the
credential to start the BMC Server Automation Console and establish a connection
with the Application Server.
You can choose to cache your session credential. By default, session credentials are
not cached. If a valid session credential is cached, when you use a BMC Server
Automation client application again, you do not have to authenticate again. Session
credentials remain valid for a configurable amount of time. For more details about
configuring this aspect of the authentication service, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Configuring+the
+Authentication+Service. By default, session credentials expire after 10 hours.
When you attempt to log on, a security message may warn you that the Application
Server has presented BMC Server Automation with an untrusted certificate. When
an Application Server uses self-signed certificates, the message always appears the
first time you try to connect to a particular Application Server. If you encounter the
warning, you should ideally examine the certificate before choosing to trust it. After
you trust it, the certificate is added to your keystore of trusted certificates and this
warning does not appear when you connect to the same Application Server again.
Tip
Some IT departments post lists of SHA1 or MD5 fingerprints of trusted certificates. If
your IT department follows this practice, compare the SHA1 and MD5 fingerprints
of the certificate you are asked to trust to items in the trusted list.
Only users who are granted access to BMC Server Automation can log on. For more
information about how users are granted access, see Access control on page 38.
1 Open the BMC Server Automation dialog box by doing one of the following:
From the Start menu, select Programs > BMC Software > BladeLogic Server
Automation Suite > Server Automation Console releaseNumber.
From the directory where BMC Server Automation is installed (for example,
C:\Program Files\BMC Software\BladeLogic\CM), enter:
.\rcp\BSAClient.exe
You can append parameters to this command to provide locations of files
that should be used during logon. For more information, see Additional
command line options for logon on page 51.
If more than one version of the client is installed, the different versions
reside in directories called BladeLogicN, such as BladeLogic2.
(UNIX) From the directory where BMC Server Automation is installed (for
example, /opt/bmc/BladeLogic/CM), enter:
./rcp/launcher.sh
You can append parameters to this command to provide locations of files that
may be used during logon. For more information, see Additional command
line options for logon on page 51.
A logon dialog box appears. The appearance of the dialog box varies, depending
on whether you have a valid session credential cached.
If you have a valid cached session credential, you can examine it by clicking
Show Credential.
3 If you:
Possess a valid cached session credential, skip this step and go to the next step.
Are using SRP, LDAP, or SecurID authentication, enter your user name and
password. For SecurID, your password consists of a PIN followed by the
current token code displayed on your RSA SecurID token.
Are using Domain Authentication, enter your user name and domain. The
domain name must always be capitalized. If you are defined as a member of
the default realm, you do not have to enter a domain name. For information
about how to set up the default realm for Domain Authentication, see BMC
technical documentation at https://docs.bmc.com/docs/display/bsa82/
Configuring+Domain+Authentication.
4 To change the setting for caching session credentials or the display language, click
Options. The logon window expands to show additional options in a tabbed
format. By default the General tab is open.
By default, this option is not checked. The setting for this option remains in
effect for future logons until you change the setting. If a session credential is
already cached, this option is dimmed.
Language
5 Click Connect.
If the Application Server presents the BMC Server Automation Console with an X.
509 certificate that is not trusted, a security alert appears. Most Application
Servers use self-signed certificates, so typically you encounter this dialog box the
first time you access a particular Application Server.
6 If a security alert does not display, skip this step and go to the next step. If a
security alert describes an untrusted certificate, do one of the following:
To return to the logon dialog box, click No. You can cancel the logon session or
use a different authentication profile to log on.
To accept the unknown certificate and proceed with the logon, click Yes.
To examine details about the certificate, click View Certificate. For more
information about this procedure, see Viewing an untrusted certificate on page
50. After examining the certificate, click Yes or No, as described above.
7 If multiple roles are associated with your user name, the Assume Role dialog box
appears. From this dialog box, for Select Role, choose the role you want to use.
If you prefer, you can switch roles later at any time during a session. (See
Switching roles on page 54.)
Note
When the console starts, by default it loads certain types of information by
running a background operation. The Show background operations icon in
the lower right corner of the console indicates a background process is running.
For information about background processes, see Running background
operations on page 77.
Typically Application Servers use self-signed certificates, so the first time you
attempt to connect to an Application Server you will probably encounter a certificate
that your client application does not already trust.
If your installation uses multiple Application Servers, they may share the same
certificates. In this situation, you should not encounter the security warning when
you connect to different Application Servers.
If this security warning appears, BMC recommends that you examine the certificate.
If the certificate's details indicate it should be trusted, accept the certificate. After you
choose to trust the certificate, it is added to the keystore for your client application.
The keystore contains a list of all trusted certificates.
When you click Connect, a Security Alert dialog box appears if the Application
Server is presenting a certificate that the client application does not trust.
The Certificate dialog box opens, showing the General tab. The tab shows the
certificate issuer and to whom the certificate was issued.
3 To obtain more information about the certificate, click the Details tab.
To refuse the certificate and return to the logon dialog box, click No. You can
then select a different authentication profile and attempt to log on again.
For example, when you start the console on Windows, you can identify the location
of the authentication profile file by entering the following command:
.\rcp\BSAClient.exe -w "C:\bmc_doc\Doc\authenticationProfiles.xml"
If you do not append parameters to the command, the logon process assumes the
files reside in default locations. For information about the files, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Setting+override
+locations+for+client+SSO+files.
The parameters you can append during logon are described below.
To log on to BMC Server Automation as a different user, you must first delete all
cached session credentials.
1 Open the BMC Server Automation logon window by doing one of the following:
From the Start menu, select Programs > BMC Software > BladeLogic Server
Automation Suite > Server Automation Console releaseNumber.
From the directory where BMC Server Automation is installed (for example,
C:\Program Files\BMC Software\BladeLogic\CM), enter:
.\rcp\BSAClient.exe
If you have more than one version of the client installed, the different
versions reside in directories called BladeLogicN, such as BladeLogic2.
(UNIX) From the directory where BMC Server Automation is installed (for
example, /opt/bmc/BladeLogic/ CM), enter:
./rcp/launcher.sh
1 Open the BMC Server Automation logon window by doing one of the following:
From the Start menu, select Programs > BMC Software > BladeLogic Server
Automation Suite > Server Automation Console releaseNumber.
From the directory where BMC Server Automation is installed (for example,
C:\Program Files\BMC Software\BladeLogic\CM), enter:
.\rcp\BSAClient.exe
(UNIX) From the directory where BMC Server Automation is installed (for
example, /opt/bmc/BladeLogic/CM), enter:
./rcp/launcher.sh
The Cached Session Credential window opens. It displays information about the
credential, such as the authentication protocol in effect and the credential
expiration date.
When you use the BMC Server Automation console to establish a connection with an
Application Server, a certificate appears. You can choose to trust the certificate. If
you do, the certificate is used to secure the connection with the BMC Server
Automation client, and the certificate is added to the keystore for client applications.
This procedure shows the list of certificates in the keystore. You can view each
certificate, and you can choose to delete one or more of the certificates.
1 Open the BMC Server Automation logon window by doing one of the following:
From the Start menu, select Programs > BMC Software > BladeLogic Server
Automation Suite > Server Automation Console releaseNumber.
From the directory where BMC Server Automation is installed (for example,
C:\Program Files\BMC Software\BladeLogic\CM), enter:
.\rcp\BSAClient.exe
If you more than one version of the client is installed, the different versions
reside in directories called BladeLogicN, such as BladeLogic2.
(UNIX) From the directory where BMC Server Automation is installed (for
example, /opt/bmc/BladeLogic/ CM), entering:
./rcp/launcher.sh
3 Click the Certificates tab. The logon window lists all certificates in the client
keystore.
Click View. The Certificate View window opens. This tab shows the certificate
issuer and the role and user to whom the certificate was issued. To obtain more
detailed information about the certificate, click the Details tab. Click Close to
close the Certificate dialog box.
Switching roles
When you log on to the BMC Server Automation Console and are assigned to
multiple roles, or when you are already running the console and want to change
roles, you can choose a role to assume.
Through RBAC, users can be granted multiple roles, but a user can only assume one
role at a time.
To switch roles
Log on to BMC Server Automation. If you are assigned to multiple roles, the
Assume Role dialog box appears.
While you are running BMC Server Automation, select Configuration =>
Switch Role. The Assume Role dialog box appears.
3 Click OK.
The servers and other objects displayed in BMC Server Automation may change if
the new role grants you access to different resources.
Changing passwords
If you use the SRP authentication method, you can change your SRP password while
running the BMC Server Automation Console.
If you attempt to log on using an expired SRP password, the Change Password
dialog box box appears. Use the dialog box box to provide a new password, as
described below.
You can also use the RBAC Manager folder to change passwords.
To change passwords
4 For Retype New Password, confirm the new password by typing it again.
5 Click OK.
//unixtest1/usr/bin
//win2ktest1/c/winnt/system32
Applications/IIS Utilities/Activation
When entering a path to an item in the registry, use backslashes. The following is an
example of a path to a registry value:
When you enter a file path, if you do not specify a disk drive for a Windows
machine, BMC Server Automation defaults the path to the C drive. For example,
BMC Server Automation considers the following paths to be the same:
//win2ktest1/winnt
//win2ktest1/c/winnt
/c/winnt/odbc.ini//Excel files/Driver32
Note
The Windows registry is an exception because its path separator is a backslash. If
you enter a value in a Windows registry path that includes a backslash, you must
escape the backslash by preceding it with a slash. For example, to create a registry
value named C:\winnt, enter C:/\winnt.
If you enter a path to a registry value with a name of empty string (that is, ""), you
can use a trailing slash, as follows:
Console overview
Use the BMC Server Automation Console console to perform the tasks required to
provision and manage your data center efficiently.
The following sections describe console elements and global capabilities such as
import and export and customizing the interface.
The following figure shows the console when you log on the first time. This is called
the Classic perspective. The next figure is an exploded view of a Classic perspective.
In the exploded view, a server is open in the Folders view at left. You can browse the
contents of the server in the content editor at right. The object title appears in a tab at
the top left of the content editor. In this example, the object title is an IP address,
10.20.93.81. The tabs at the bottom of the content editor let you review different
aspects of the serverLive Browse, Activity, Snapshot Results, and Audit Results.
At bottom left, properties for the currently selected object automatically populate the
Properties view.
The following table lists console elements and provides a brief description of each.
Editors
Just as there are different types of filestext, html, shell scripts, javathere are
different types of content editors. When you select (or create) an object, the system
opens it using the most appropriate editor.
Simple text documentThe document opens in the console's built-in text editor.
Java source fileThe document opens in the Java Development Toolkit editor,
which has special features such as the ability to check syntax as code is typed.
You can have multiple content editors and objects open simultaneously, with only
one being in focus. To change the focus from one content editor or object to another,
click the tab of the content editor or object with which you want to work.
When you log on to the product the first time, the default perspective is called the
Classic. It is preconfigured with views to provide you with the tools and objects you
use most often to perform common tasks in the content editor, such as working with
a shell script, browsing servers, or configuring jobs.
As you work in the console, you can choose perspectives by selecting Window =>
Open Perspective => perspectiveName or click Open Perspective in the
perspective title bar.
The view in the upper left is called the Folders view; it shows a hierarchy of the
workspace and all of the objects in it. Initially the folders in this view are empty. It is
the jumping off point for creating and working with objects in the console.
The main menu appears at the top of the console, below the title bar. You can invoke
most actions from the main menu or its submenus. For example, if you are editing a
document, you can save it by selecting File => Save => fileName from the main
menu. The Delete, Open, and Refresh commands are available throughout the console.
Below the main menu is a simple toolbar which contains icons that provide
convenient shortcuts for commonly performed actions. If you position the mouse
pointer over an icon on a toolbar, a short text description, or tool tip, appears.
There are several ways to open perspectives. You can choose Window => Open
Perspective => perspectiveName from the main menu. You can also click Open
Perspective , which is adjacent to the perspective title tab.
Gutters on the left side and bottom of the console serve as shortcut toolbars for
minimized views and their Restore icons. When you minimize a view, the views
icon and a Restore icon are displayed together in the shortcut toolbar nearest the
minimized view. For example, when you minimize the Tasks in Progress view, its
icon and a Restore icon appear in the gutter across the bottom of the console. When
you minimize the Folders view, the Folders icon and Restore icon appear in the
gutter on the left side of the console.
In addition to the console's global menus and toolbars, views can also have menus
and toolbars. Each view has a system menu you can access by right-clicking
anywhere in the view title tab. This menu lets you perform actions on the view's
window, such as maximizing it or closing it.
Views can also have view-specific menus. A triangle in the views title tab indicates
the presence of a view-specific menu. In the Classic perspective, the Properties and
Permissions views have view-specific menus.
All views also have a toolbar containing icons to minimize or maximize the view.
They may also contain a triangle representing the system menu, or icons to add, edit,
or delete entries in the view.
Changing perspectives
You can change perspectives to suit your content by reconfiguring the views and
editors within a perspective.
For example, you may find that a view is not the proper size for the work you are doing
perhaps your source code is too wide for the content editor. The solution is to
hover the cursor over a view or editor border until the cursor turns into a two-
headed arrow. Drag the border until the view is the right size.
To use the entire window for a specific view, double-click the title bar for the view or
click the maximize icon. The view is maximized and the other views appear in the
shortcut toolbar. To reduce the view to its normal size and restore the other views to
their normal locations and sizes, double-click the title bar again.
You can rearrange views by dragging their title bars. Dragging one view on top of
another causes them to appear as a tab group of views. Selecting a view in a tab group
is like selecting a document in the content editor. To bring a view into focus, click its
tab at the top or bottom of the tab group.
Dragging a view below, above, or beside another view enables the views to dock.
When views dock, the space occupied by the stationary view is redistributed to
accommodate both views. As you drag the window, the cursor becomes a black
arrow over a grid location where docking is allowed.
For example, to create more vertical space for the content editor, add the Tasks in
Progress view to the Properties, Permissions, and Audit Trail views tab group by
dragging and dropping it on top of the tab group. The Tasks in Progress becomes
another view in the tab group and opens the pane for the content editor.
You can remove a view from a perspective by selecting Close from the view's title
bar menu or clicking the Close icon. You can also add a new view to a perspective
by selecting Window => Show View => viewName from the main menu.
The configuration changes you make to perspectives are saved automatically. For
example, if you end a session with the content editor expanded to fill all available
space, that is the configuration you will see when you begin your next session. To
restore a perspective to the default appearance, select Window => Reset
Perspective.
Typically, a perspective contains one or more pre-configured views and a space for
content editors. Views are organized around specific work themes such as objects,
properties, commands, jobs, and so on. You can work with a pre-configured
perspective, or you can use a pre-configured perspective as the basis for building a
customized perspective to support your workflow.
The views within the pre-configured perspectives support the tasks you perform in
the content editor. All of the views in the Classic perspective support the most
frequently performed tasks associated with BMC Server Automation. For example, if
you select a server in the Folders view, the selected server appears in the Properties
view, Permissions view, and Audit Trail view tab group. The Tasks in Progress view
updates jobs that are run against the objects selected in the Folders view, including
the selected server.
The following table shows preselected perspectives and the views they contain.
Perspective Views
All Folders, Group Explorer, Properties, Permissions, Audit Trail, Property
Dictionary, Error Log, Custom Commands, Tasks in Progress
Classic - the default perspective Folders, Properties, Permissions, Audit Trail, Tasks in Progress
Classic2 Folders, Tasks in Progress
Explorer Group Explorer, Properties, Permissions, Audit Trail
Help Desk Folders, Properties, Permissions, Audit Trail, Custom Commands
When you open a perspective, its name appears in a tab at top right. Only one
perspective is active at a time. To activate a perspective, select the tab. For more
information, see Working with perspectives and views on page 68.
It contains two views, a view tab group, and a content editor. The views include:
Folders viewProvides you with access to resources in your data center and lets
you provision devices, manage servers, jobs, users, and other assets needed for
data center automation, and search the data center. For more information, see
Folders view and resource management on page 101.
Properties, Permissions, Audit Trail views(tab group) Includes three views for
managing properties, permissions, and audit trails for objects selected in the
Folders view. You can manage each view individually or as a tab group. For more
information, see Properties, Permissions, and Audit Trail tab group on page
115.
Tasks in Progress viewManages and monitors the status of jobs. For more
information, see Managing jobs in progress on page 621.
In the Classic perspective, the Folders view at left provides access to functional areas
or resources known as folders (see Folders view and resource management on page
101).
When you select an item from the Folders view, it opens in the content editor at
right. Tabs on the content editor provide information about assets, such as the
contents of a file or BLPackage.
You can snap or dock the views into locations in the perspective grid, change the
shape from vertical to horizontal, or create groups of views with multiple tabs called
tab groups.
To open a perspective
Choose Open Perspective in the perspective title tab and choose a perspective.
2 At the prompt to reset the defaults for the active perspective, click OK.
To customize a perspective
1 With the perspective you plan to customize open, choose Window => Customize
Perspective.
2 On the Shortcuts tab, select one or more submenus to customize the current
perspective: New, Open Perspective, Show View. The items you check appear as
cascading items under the selected menu.
For example, if you routinely use the file navigation view, add it to a perspective
by choosing Submenus => Show View => File Explorer.
3 On the Commands tab, select one or more items to add to the Menu bar or the
toolbar in the current perspective. Depending upon the Command group with
which they are associated, the selected commands appear in the Menu or toolbar.
1 To activate the view, click in the view title tab. As you drag the view, a frame
shows locations to dock the view and possible shapes within the perspective grid.
Drop the view in the location where you want to dock it.
If you drop a view on top of another view, the views become a tab group which
operates as a single unit.
2 Choose Move => Tab Group. The group of views becomes one unit with an
arrow that changes direction as you move the frame in the perspective grid.
3 To dock the Tab Group view in the perspective, click the desired location.
2 Choose Detached. An additional toolbar appears over the view title tab.
3 To drag and drop the view anywhere in the console, click in the Detached toolbar.
Click the tab title bar to change the view back to an attached view.
Right-click the view title tab or toolbar and choose Minimize or Maximize.
To expand a view, double-click the view title tab. The other views in the
perspective become icons in the shortcut toolbar.
To return the view to its original size and location, double-click again. The
other views in the perspective resume their original location and size in the
perspective.
To resize a view
Move the cursor over the view border until it becomes a double-arrow.
Right-click the view title tab and choose Size => viewSide. The border you
select is highlighted.
The following sections describe other BMC Server Automation global capabilities:
2 Type a portion of the command or resource in the text box at the top of the pop-
up. As you enter more letters, the selection list changes as more items are located
that match your entry.
For example, if you do not remember the command specifics for changing the
build order, enter build in the text box. The system shows you the available
choices, organized by resource. In the case of build, the system displays the
commands: Copy Build ID to Clipboard and Preferences (Preference page:
General => Workspace => Build Order) and the Preference: Build Order.
To see all matches, press Ctrl+3 again while in the Quick Access pop-up.
3 Click your corresponding choice from the list to execute the command or access
the resource.
Only objects that include the string, which can appear anywhere in the object name,
are displayed in the results. This lets you narrow the number of objects that are
displayed in the tree.
Component Templates
Components
Depot
Devices
Jobs
Servers
2 Right-click the icon representing the folder, smart group, or group you want to
filter and choose Apply Filter.
Specify a string in the Name text box. The string may appear anywhere in the
object name.
4 To add an additional line that lets you use a text string in the Description field as
a filter, click More.
Note
The More option is enabled only when the Group Explorer view is available in
the perspective. When the Group Explorer view is not available, Name is the only
intrinsic property displayed.
5 Click Filter.
The refreshed tree displays only the objects that contain the text string. The
objects that do not contain the string are not displayed or removed from the group.
Clearing filters
You can use filters to identify a subset of objects that need your attention. When you
have finished filtering objects, you may want to display all of your data again.
Because filters only affect the display of objects, clearing the filter returns those
objects to the display.
To clear filters
1 When you are ready to view all members of the group, do one of the following:
Right-click the icon representing the object (smart group, group, folders, and so
on) whose filter you want to clear and choose Clear Filter.
When working with groups, smart groups, folders, search groups, database assets,
custom objects, and server objects in the Configuration Object Dictionary, a large
number of objects can make viewing and manipulating the objects cumbersome.
To make working with large numbers of objects manageable, the objects are
presented in groups of 50 through which you can page.
Note
You can modify the number of items displayed per page by selecting Window =>
Preferences. Expand BMC and Paging Options to change the default. You must
choose File => Refresh after changing the default to have the change take effect.
The corresponding Properties view tells you the page number you are on, the
number of items per page, the quantity of items in total, and the quantity of pages in
total. With custom configuration objects, the number of assets may be unknown. In
that case, the Properties view cannot identify the page or item numbers.
Double-click the up (Previous) and down (Next) arrows to scroll through the
objects.
Right-click an arrow and select one of the following: Next Page, Previous Page,
First Page, Last Page, Jump to Page.
Note
When the number of custom object or database assets are unknown, no page
count appears and the Jump to Page and Last Page options are not available.
Jobs are often executed many times against large numbers of managed servers,
resulting in large data sets. To prevent a waiting period when you browse job results
data, the system displays data in groups so that all job runs and job run results are
not loaded at the same time.
For some job types such as Audit, you can view job results either by managed server
target or by server object.
1 In the Jobs folder in the Folders view, navigate to the job whose results you want
to browse.
The job and job runs display in a pane in the content editor at left. The job runs
display in the paging table at right. Depending on the job type, use the icons to go
to Next Page, Previous Page, First Page, Last Page, Jump to Page.
3 To display job run objects in the paging table at right, click a job run at left. You
can filter on All, Errors, Success, Warnings.
4 To view the details of the job run log, right-click a job run and choose Show Log.
The BMC Server Automation online help system corresponds to the information in
the BMC Server Automation User Guide.
1 While using the BMC Server Automation Console on a Windows machine, press
F1. When running the console on platforms other than Windows, invoke help by
pressing F1 or Shift F1.
In a separate window, with a table of contents at left and a help topic associated
with your current context at right.
In a view adjoining the current wizard. The view contains a short description as
well as a related topic. Click the link to the related topic. It appears in the
current view. To display the help in a separate window, click Show in external
window .
If no context-sensitive help is available, the welcome page for the help system
appears.
3 Use the Go Back and Go Forward arrows to navigate within the history of
viewed topics.
To search
2 Use the following icons in the toolbar to modify the Search Results frame.
Show result categoriesDisplays only the titles of topics that match your
search criteria.
3 In the Search Results frame, choose the topic you want to view.
Required fields
Throughout the BMC Server Automation Console, an asterisk (*) marks all fields that
are required to continue or complete the current task.
Some wizards and other GUI elements in the the BMC Server Automation Console
dynamically explain what field is required. For example, in the wizard panel shown
below, several fields are required. After you enter a value for the required Name
field, the message at the top of the panel states that the Server field is required. After
you enter a value for Server, the panel tells you that Certificate is required.
For example, when you add a software package to the Depot or export a BLPackage,
the system offers the option to run the operation in the background.
A dialog box telling you the operation is in progress provides the mechanism for
running the operation in the background. If you do not run the operation in the
background, the dialog box remains displayed, effectively locking your console. If
you choose to run the operation in the background, the system places the operation
in a queue with other running operations. You can see these operations in the
Progress view.
When a task is executing in the background and you try to close the BMC Server
Automation Console, a dialog box informs you that operations are currently
running. The operations are canceled if you close BMC Server Automation. The
dialog box gives you 30 seconds to make a decision. Otherwise, the system shuts
down and background operations are canceled.
1 When you start an operation that allows you to run it in the background, a
progress dialog box gives you the following options:
Click Always run in background and then click Run in Background. The
progress dialog box is no longer displayed. The Show background operations
icon appears in the lower right corner. In the future, when you perform any
operation that can potentially run in the background, it will. To turn off this
capability and set operations to run in the foreground, use Window =>
Preferences => General => Global. For more information, see Customizing
preferences on page 84.
Content editors
BMC Server Automation integrates multiple editors to provide you with access to
files based on the file type.
BL EditorA Text and XML editor that supports different encoding methods as
well as standard text editing capabilities. For more information, see Viewing and
editing text files using BL Editor on page 79.
DefaultA default editor that can be modfied using Window => Preferences =>
Editors menu to specify a default editor (for more information about setting
preferences, see Customizing preferences on page 84).
ShellEdA third-party Shell Script editor that supports opening, editing, and
saving Network Shell Script files. For more information, see Viewing and editing
Network Shell Script files using ShellEd on page 80.
Tail -fA read-only editor that lets you dynamically monitor the most recent
additions to a log file. For more information, see Viewing files using a tail -f
editor on page 81.
OtherA window that displays all editors available on your system. If the editor
you select is not appropriate for the object, the system generates an error message.
Note
When you are interacting with dialog boxes or windows in the BMC Server
Automation Console, all the keys function in the global menu context. For example,
if you are using one of the New Object Wizards, the key bindings reflect the global
menu key bindings.
When you open a text editor, all of the key bindings function in the context of the
specific editor. For example, if you open a Network Shell Script file, the key bindings
are specific to the ShellEd content editor.
In some cases key bindings are the same between editors. For example, Copy (Ctrl-
C) and Paste (Ctrl-V) tend to be universal.
To use BL Editor
Depot
Jobs
Servers
3 From Encoding, select the type of character encoding used to display the file,
such as UTF8.
4 Edit the file, using the systems basic editing tools, which include cut, copy, paste,
select all, undo, redo, and search and replace. To access a menu of these tools, right-
click in the body of the file.
5 To save the file, right-click the tab representing the file and select Save.
6 To close the tab representing the file, click Close in the file title tab.
ShellEd has the standard features that are available with BL Editor as well as Shell
Script help and syntax color formatting. It offers flexible Network Shell script
content editing. Use ShellEd for viewing and editing files and Network Shell scripts
stored in the Depot.
To use ShellEd
2 On the Live Browse tab, expand the File System server object type.
3 Right-click a Network Shell object and select Open with => ShellEd.
From encoding, select the type of character encoding used to display the file, such
as UTF8.
4 Edit the file using the systems basic editing tools as well as the ShellEd syntax
color formatting, line highlighting, preferences, and so on.
To save the file to a different name or location, choose File => Save As. Use the
dialog box to specify a name and location for the file.
6 To close the tab representing the file, click Close in the file title tab.
The Tail File editor is a read-only editor with an available copy function. You can
open multiple log files in multiple editors and move between the open files. The
default number is five files but you can reset the number (Preferences => BMC =>
Tail File Options => Open Files). An informational message alerts you if you
attempt to open a file that exceeds the maximum number of open files.
The Options pull-down menu enables you to collapse and expand non-file portions
of the file to speed through the scrolling. By default, the non-file portions are
expanded. You can also tile the open files.
1 Navigate to the Live Browse tab of the object whose log files you want to
monitor.
The Tail File editor opens in the content editor at right with the path name of the
file shown.
3 To work with the log file, use any of the following controls:
FilterEnter text to filter the log file. The filter is not case sensitive, and it does
not require exact words. To execute the search, click Apply. To clear the filter
string, click Clear. The filter stores up to five searches, accessible from the drop-
down list.
Interval (seconds).) When you choose Pause Polling, the button toggles to
Resume Polling. When you click Resume Polling, the Tail File editor continues
polling, filtering, and displaying the log.
An error message generated during polling is displayed at the end of the text
editor and highlighted in red. The error message instructs you to click Refresh
to resume polling. If an error occurs, the Pause and Resume Polling button is
disabled.
You can associate editors by file type or content type. You can specify the default
editor for a particular file or content type.
4 To associate editors by file types, click File Associations at the top of the Editors
page or click File Associations in the Preferences tree at left. Add, edit, or remove
associated editors in the Associated Editors window.
For example, you can add files with the extension .doc to the File Types list and
choose the editor with which you want the file to be associated by selecting Add.
A windows lists the available editors.
5 To associate files by content type, click Content Types at the top of the Editors
page or click Content Types in the Preferences tree at left. Add, edit, or remove
file associations in the File associations window.
For example, you can add .doc to associate with a Text content.
6 To modify the presentation of editors, click Appearance at the top of the Editors
page or click Appearance in the Preferences tree at left. To override the defaults,
clear existing settings.
7 Click Apply to implement the new settings or Restore Defaults to return to the
original values.
Selecting editors
The system provides many editing options, including the BL editor and additional
internal and external editors.
If you select an external editor, you can only use it for read-only operations.
To select an editor
The Editor Selection dialog box displays the list of all BMC Server Automation
and third-party editors that are available within the system.
3 To use a BMC Server Automation internal editor, select one from the list, and
click OK.
5 Select one of the external editors from the list or select Browse to view a list of
additional editors.
Console management
Several options let you manage the appearance of the BMC Server Automation console.
Customizing preferences
The BMC Server Automation Preferences window provides you with a centralized
location for managing the look and behavior of your console.
Enter text in the filter text box to narrow your choices in the preferences tree.
For example, to set preferences for keystroke combinations, enter Key in the
filter text box. Click Key in the preference explorer to open the Keys preference
window. Click Clear Filter to see all choices again.
Navigate through the preference explorer to the preference settings you want.
3 Use the tools in the toolbar at right to navigate the different preference windows
settings.
Use the arrows to cycle backwards (left) and forward (right) through the
preference windows to which you have navigated.
Use the down arrows to list the preference windows (back and forward) to
which you have navigated.
Use the down arrow to resize the preferences settings tree at left or execute key
scrolling.
6 Select each node that is currently expanded or was expanded during the current
session. Then select File => Refresh or press F5.
The new preferences are applied to the refreshed node and its children.
While not all new settings require a refresh, it is a good practice to perform a
refresh on each node to ensure that the new preferences are applied.
7 To exit the Preferences window, click OK. The console automatically saves your
preferences.
Display Options
Dependency view optionsSets the number of objects displayed in the
dependency view when you show an object's dependencies (Show
Dependency Upward View) or delete an object (Delete Dialog Dependency
View). By default, the maximum number of objects displayed is 100.
Show no access nodesShows a system object even though the user does
not have appropriate permissions to interact with the object.
RBAC Manager shows nodes to which the user has no access. Clearing this
option means that users cannot see nodes to which they have no access. For
more information about no access nodes, see No access nodes on page 173.
The display of no access nodes can also be controlled using the Application
Server. If the Application Server forbids the display of no access nodes, you
cannot access this option in the BMC Server Automation console. For more
information see BMC technical documentation at https://docs.bmc.com/
docs/display/bsa82/Displaying+no+access+nodes+in+the+BMC+Server
+Automation+Console.
Enable server check for live browse and active nodesInstructs the
console to determine whether a server is available when you select the
servers Live node or display the server in the Active Node view. If a server
is unavailable, the console must wait while it determines the servers status,
and the server is marked with a red X. If you clear this option, the console
only determines if a server is available when you expand objects in the
servers Live node or the Active Node view. By default, this preference is
selected.
Display Options
(continued) Show running jobs in Tasks in Progress window for jobs
For which the current role has access permissionShows all running
jobs for which the current role has access permission.
Block level update Minimum size (in kb) for a file that should invoke
large file management during a deployment. Files smaller than this value are
copied in full.
Update block sizeBlock size (in kb) to use for comparison and update
purposes.
Default backup suffixSuffix that is appended to all files that otherwise are
overwritten during a copy. Adding a backup suffix creates a backup copy of
those files.
Buffer LinesNumber of lines that can be cached on the client side. The
Tail -f command may return a large amount of data, which may cause a
memory exception. The default value is 2000; the range is 1 to 10,000.
The following preferences are standard for an Eclipse interface. For more
information about any preference, see http://help.eclipse.org.
For more information about preferences specific to BMC, see Preference settings
BMC category on page 85.
General settings
Appearance general
Enable animationsenabled
Set preferences for the appearance of dialog boxes, text comparisons, and other
aspects of the interface
Compare/patch
General tab
Specify the expressions that are used to identify lines that are added or removed
from a patch
Specify the object types that you do not want to be compared with the same object
types
Content types
Properties (Preferences)
File associationsDisplays the files associated with a specific content type. You can
add new file associations and edit or remove existing associations.
Editors general
The File types box displays the files types and the Associated editors box displays
the editor with which the types are associated. You can add new file types or editors,
or edit or remove existing file types or associated editors.
Close hover
Enrich immediately
Enrich on click
Shows preference settings for the type of hyperlinking navigation enabled and the
default modifier key
To show changes within the text editor instead of the compare editor, enable Quick
Diff.
To quickly determine how many changes you have made to a file since your last
commit, show differences in an overview ruler.
Not available
Keys
Add, edit, and remove key bindings for the system. For more information, see
Customizing keystroke combinations on page 94.
Perspectives
Manage the behavior of perspectives, such as where a perspective opens and which
perspective is the default.
Web Browser
The system provides a quick review of all the keystroke combinations in a simple,
filterable window.
1 Press Ctrl+Shift+L to open a window that lists the command and the
corresponding keystroke combination.
2 Use the keyboard shortcut or click the command to execute a command in the list.
3 Press Ctrl+Shift+L again to go to the Keys page of the Preferences window. For
more information, see Customizing keystroke combinations on page 94.
The system uses standard keystroke combinations for common commands. For
example, Ctrl+C is the same as choosing Edit => Copy. You can customize
keystroke combinations using the Preferences window.
Note
When you are interacting with dialogs or windows in the BMC Server Automation
Console, all of the keys function in the global menu context. For example, if you are
using one of the new object wizards, the key bindings reflect the global menu key
bindings.
When you open a text editor, all the key bindings function in the context of the
specific editor. For example, if you open a Network Shell Script file, the key bindings
are specific to the ShellEd content editor.
2 Select the default keyboard scheme or EMACS, the Apple MacIntosh editor
keyboard command scheme.
3 To filter the list of commands, enter one or more characters. For example, enter
mov to narrow the list of available commands to Move Lines Down, Move Lines
Up, Move Resources, and so on.
Command details are populated to the editing area below the command list.
5 Enter the keystroke combinations you want to associate with the command in the
Binding field. The left arrow lets you select Backspace, Tab, and Shift-Tab.
6 In the When field, select the circumstances in which you want the keystroke
combinations to be active: Comparing in an Editor, In Console view, In
Windows, and so on.
The Conflicts window lets you know if and when that keystroke combination is
already assigned to a command.
To clear some of the default filter actions or restore filters, select Filters.
To save the keystroke commands as a .csv file to a location other than the
system folder, select Export.
To remove key bindings you have made or changed, select Restore Defaults.
8 Click OK to exit the Preferences window. The console automatically saves your
preferences.
You can add and remove columns from a table, size columns, change the column
sort order, choose the column header alignment, and change the name of the
column. The changes you make to columns in a table persist until you change them
again.
2 In the Name column, clear or select the columns you want included in the table.
3 To reposition the columns in the table, select a row and use the up and down
arrows at right.
4 To expand the Column Customization window, click the arrow beside Format.
See Formatting columns on page 98.
5 To apply the changes and view the customized table, click OK.
2 To add a column, select an attribute or property from the Available Columns list
at left and click Select to add it to the Columns list at right.
3 To remove a row from the table, select the row in the Columns list and click
Unselect to remove it.
4 In the Sort column, add the order in which you want the columns to appear in the
table, from left to right. For example, 1 appears in the first position, 2 in the
second position, and so on.
6 To reposition the columns in the table, select a row and use the up and down
arrows at right.
8 To apply the changes and view the customized table, click OK.
2 To add a column, select an attribute or property from the Available Columns list
on the left and click Select to add it to the Columns list at right.
3 To remove a row from the table, select the row in the Columns list and click
Unselect to remove it.
4 To reposition the columns in the table, select a row and use the up and down
arrows at right.
6 To apply the changes and view the customized table, click OK.
A pop-up menu displays all columns that can be displayed. If a column cannot be
removed from the display, its name is dimmed.
2 To display or remove a column from the display, click the name of a column.
1 Click the column header. If it is a sortable column, an arrow appears in the header
to indicate sort direction. To reverse the sort direction, click the column header
again.
For information about sorting columns in a paging table, see Customizing fixed-
column tables on page 96.
Formatting columns
You can format a column.
To format a column
2 Select the row you want to format from the Columns list.
The details of the row are populated to the Format window. The object name is
read only.
3 Change the display name of the object that appears in the column header. To
return to the original value, select Reset.
4 To modify the value when it is a date or a number, use the Field Format menu.
Preview demonstrates the new format.
5 Adjust the width of the column or accept the default value (1). All of the columns
auto-size, meaning they expand or contract to fit the space available. The column
width changes dynamically.
If you change the width of the column to 2, that means that the column equals the
same space as two columns; 3 equals the width of three columns, and so on.
6 Choose the alignment of the column header and its content: left, center, right.
Refreshing data
Refreshing the product displays the most current information available in the database.
The console automatically refreshes the database so that you work with the current
information. For example, when you create, remove, or modify an object, the
changes you make to that objectjob, template, and so onare automatically
cascaded across the Folders view, wherever the object appears.
Dependent objects are refreshed in tree and Group Explorer views. For example, if
you add an item to a template, the components associated with the template reflect
the addition.
To refresh data
Press F5.
Click Refresh .
To refresh a hierarchical object, select the parent object and then select Refresh.
You can drag and drop a job on an appropriate target, and you can drag and drop a
target onto an appropriate job. In addition to dragging and dropping single targets,
you can also drag target groups such as Servers, Components, Server Groups, and
Component Groups.
For example, you can drag a job from the Folders view and Group Explorer view
and drop it onto a target object (such as a server group or job) that is relevant to the
job type. The action executes the selected job against the selected target.
If the action needs additional information to execute successfully, you are prompted
for information. For example, the list of Available Servers appears so that you can
choose additional targets. The behavior is similar to the Execute against action (see
Executing a job against specific targets on page 612).
You cannot use drag and drop to execute a Batch Job if the Batch Job is set up so it
uses target servers defined in individual jobs.
Using the Jobs folder, navigate to a job. Select the job and drag it to a target
server or server group in the Servers folder. If the target can be a component,
drag the job to a component or component group in the Components or
Component Templates folder.
Using the Servers folder, navigate to a server or server folder and drag it to a
job in the Jobs folder. If the target can be a component, use the Components or
Components Templates folders to drag a component or a component group to
the job.
If necessary, you can specify additional targets before executing the job.
Components folder
The Components folder provides a central location for managing components.
Using the Components folder, you can organize components, run Snapshot, Audit,
and Compliance Jobs on components, and change the properties and permissions of
a component. For a complete description of the Components folder, see
Components and component templates on page 351.
Using this folder, you can create and edit component templates and components,
run Snapshot, Audit, and Component Discovery Jobs, and change the properties and
Depot folder
The Depot folder holds objects that are needed to execute jobs. The Depot folder is
commonly referred to as the Depot.
You can use the Depot to store the following types of objects:
Files
BLPackages
Software packages
System packages
For procedures explaining how to create depot objects (except system packages) and
how to set up and manage the Depot, see Depot object overview on page 477. For
information about system packages, see Creating a system package on page 1214.
Devices folder
The Devices folder lets you view discovered servers (servers that have booted but
are not yet provisioned), prediscovered servers (servers that have not yet booted but
are added to the system), and provisioned servers.
The Devices folder also lets you create and run Provision Jobs on servers. For more
information, see Monitoring the provisioning status of devices on page 1349 and
Creating a Provision Job on page 1354.
Jobs folder
The Jobs folder lets you create, modify, and execute jobs and view job results.
For a list of available jobs and procedures explaining how to set up and manage the
Jobs folder, see Managing jobs on page 605.
After you define roles, you can assign users to those roles, and the users are granted
the authorizations assigned to their current roles. The RBAC Manager folder also
provides other tools for managing authorizations. For a complete description of the
RBAC Manager folder, see Access management on page 165.
Search
Search lets you scan and retrieve information about objects in the BMC Server
Automation environment.
You specify search criteria to construct queries that search all objects in the BMC
Server Automation database. Search results appear in a Search view and can be
saved to a Smart Group (see Defining a smart group on page 108). For more
information about Search, see Searching for objects on page 106.
Servers folder
The Servers folder shows the servers to which your role has access.
You can browse each server to examine its contents, and you can perform many
types of actions on a server. The Servers folder also provides some capabilities for
managing server objects, such as editing text files and starting and stopping
Windows services. For a complete description of the Servers folder, see Servers
folder overview on page 319.
Choose File => New => Other to open the New dialog box from the Global
menu. Enter a filter string to narrow the choice of wizards or scroll through the
list in the Wizard explorer tree.
For example, choose File => New => Other to open the New dialog box. Enter
Servers in the filter box to narrow the display of wizards. Highlight Server
Group and click Next to open the New Server Group wizard.
When you select a server or job, the Active Node view can automatically show
information for the object; you do not have to browse the server or show job results.
This allows you to quickly display information when moving from one object to
another.
1 In the Servers or Jobs folder, right-click a server or job and select Active Node
view.
The Active Node view opens. By default, the view appears in the lower right
corner. For servers, the view shows live-browse information. For jobs, the view
shows job results.
The Active Node view shows information about the object you select.
If you select items other than a server or job, the Active Node view says "No data
supported."
A folder is a collection of unique system objects. Each system object in a folder can
only occur in one place.
Groups and smart groups are collections of system objects or references to system
objects. In groups and smart groups, references to system objects are not necessarily
unique. References to the same object can occur in more than one group or smart
group. To populate a group or folder, you must explicitly add system objects.
Smart groups are groups for which you define membership conditions based on
object properties. Any object with properties matching the conditions you specify
automatically becomes a member of a smart group. For example, you can define a
server smart group that requires all member servers to be running a Windows
operating system. (The operating system is a property assigned to all servers.) Using
a smart group in this way, you can group all Windows servers together
automatically. The contents of a smart group can change depending on changes in
the properties of system objects.
The Jobs, Depot, and Component Template folders let you organize objects into
folders and smart groups. The Servers and Components folders let you organize
objects into groups and smart groups. You cannot group objects in the RBAC
Manager folder.
The table describes which BMC Server Automation folder objects can be combined
into folders, groups, and smart groups.
To define folders, groups, and smart groups, use the following procedures:
Within each folder, the console provides easy methods for managing groups, folders,
and their content. You can cut and paste folders and the system objects they contain.
You can copy, cut, and paste groups, smart groups, and the system objects they
contain. For more information, see Copying, cutting, and pasting groups, folders,
and system objects on page 112. You can also delete folders and groups and the
objects they contain (see Deleting a folder, group, smart group, or system object on
page 113).
Note
If you select multiple system objects, menu options that allow you to perform actions
on those object are always enabledeven if you do not have permission to perform
an action on all of the selected system objects. For example, if you select three system
objects and you only have permission to delete one, the Delete option is still enabled.
If you attempt to delete the selected objects, warnings inform you that you do not
have permission to delete some objects.
Component Templates
Components
Depot
Jobs
Servers
anyObjects must match at least one of the membership conditions you define
(equivalent to a logical or for the conditions you specify).
In the next drop-down box to the right, select the name of a property. For
example, select DATE_CREATED.
In the next field to the right, provide a value or values for the property.
For example, to search for all windows computers, select OS in the first drop-
down, then select equals, then select windows.
To create another condition, click the plus sign to the right of the condition you
have just defined. An additional line for another condition appears.
To delete a row representing a condition, click the minus sign to the right of
that condition.
The results are saved until you perform another search or until you use the
returned search results to define a Smart Group (see Defining a smart group on
page 108).
To modify an existing folder or group, see Setting values for system object
properties on page 161.
Select any of the following folders or any subfolder or subgroup and right-click:
Component Templates
Components
Depot
Devices
Jobs
Servers
To add a new folder, select New => objectType Folder from the pop-up menu.
In this menu option, objectType is the type of object for which you are creating a
folder, including Component Templates, Jobs, or Depot objects.
To add a new group, select New => objectType => Group from the pop-up
menu. In this menu option, objectType is the type of object for which you are
creating a group, such as a server or component.
Choose File => New => Other to open the New Select a wizard. Enter a
phrase in the filter text box to narrow the search list or expand the General or
BMC trees to browse to the component folder or group type you want to create.
A wizard appears.
2 For Name, enter a name for the folder or group. For Description, you can
optionally provide descriptive text.
The Permissions panel is an access control list granting roles access to the folder
or group. Access to all objects, including the sharing of objects between roles, is
controlled through ACLs. For more information about defining an ACL, see
Defining permissions for a system object on page 231.
Note
You cannot manually add objects, folders, or groups to smart groups, nor can you
delete or cut objects from smart groups.
You cannot create smart groups that are based on properties of the type List of
String. These are properties whose values can be chosen from a list of pre-defined
strings.
Select any of the following folders or any subfolder or subgroup and right-click:
Component Templates
Components
Depot
Devices
Jobs
Servers
To add a new smart group, select New => objectType => Smart Group from
the pop-up menu. In this menu option, objectType is the type of object for which
you are creating a smart group, such as a server of component.
Choose File => New => Other to open the New Select window. Enter a phrase
in the filter text box to narrow the search list or expand the General or BMC
trees to browse to the type of smart group you want to create.
A wizard opens that lets you define the membership conditions for a smart group.
2 Provide information for the smart group wizard, as described in the following
sections:
3 Click Finish.
The new smart group is created. Objects matching the conditions you have
specified automatically populate the group.
Name
Identifying name.
Description
Member of
Click Browse to navigate to a folder where you want to add this smart
group.
Match
Condition list
1 When defining smart job or smart depot groups, use the drop-down box at
left to select a type of object. If you are defining smart server, smart
component, or smart component template groups, this box does not
appear. Skip to the next step.
For example, when defining a depot group you can select NSH Script.
Choosing Depot Object means you want the smart depot group to include
any type of depot object. Choosing Job means you want the smart job
group to include any type of job.
2 In the next drop-down box to the right, select the name of a property for
the type of object you are collecting in a smart group, such as
DATE_CREATED. For example, you can select a server property or a
component template property.
4 In the next field to the right, provide a value or values for the property.
For example, to create a smart depot group containing all BLPackages
created between two dates, select BLPackage in the first drop-down, then
select DATE_CREATED, and then select between. Finally, select two
dates in the fields furthest to the right.
For a smart component group, the following example is especially useful.
Select the TEMPLATE object (rather than a property) in the first drop-
down, then select equals as the operator, and finally select a component
template. The resulting smart component group is populated with all
components that satisfy the signature in the selected component template.
5 To create another condition, click the plus sign to the right of the condition
you just defined. An additional line for another condition appears.
To delete a row representing a condition, click the minus sign to the right
of the condition.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
By default, when you copy and paste an object, the newly created object has the
same permissions as the object that you copied. However, BMC Server Automation
provides a mechanism for changing this default behavior, as described in Default
permissions for cutting and pasting on page 113.
Tip
Rather than cut and paste groups and folders, you can drag and drop them.
In addition to this procedure, copy and paste actions are available from the global
Edit menu and the standard keystroke combinations (Ctrl+V, Ctrl+C).
1 Open any folder and navigate to the folder, group, or system object you want to
copy and paste or cut and paste. Select the folder, group, or system object.
3 Right-click a folder or group and select Paste from the pop-up menu.
The folder, group, or system object appears in its new location. You cannot paste
into a smart group.
When you paste, a dialog box appears and tells you that a move or a copy is
occrring in the background.
Note
When you copy and paste a job, all scheduling information is removed from the
pasted job.
By default, when you copy and paste an object, a newly created object is granted the
same permissions as the object that you copied. Using the Application Server
Administration console (that is, the blasadmin utility), you can specify alternative
behavior. In this other approach, when you copy and paste objects, a newly created
object is granted the permissions that are specified for that type of object in the object
permissions template defined for your role. Also, your role is granted full
permission to the object (that is, a * authorization). In effect, the object has the same
permissions that this type of object would have if you had created a new object.
You have the option of making it impossible to delete a folder or group unless that
folder or group is empty. To perform this procedure, use the Application Server
Administration console (that is, the blasadmin utility), as described in BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Deleting+groups+in
+the+BMC+Server+Automation+Console. This procedure has no effect on smart
groups, which you can always delete.
Note
You cannot delete or remove objects from smart groups.
If other objects depend on the object you plan to delete, you can delete the other
objects and the object you choose to delete. Alternatively, if you are deleting an
object and a component template, Deploy Job, or Batch Job depends on that object,
you can choose to delete only the original object and break all dependencies those
component templates, Deploy Jobs, or Batch Jobs might have on the deleted object. If
you choose to break dependencies, the component templates, Deploy Jobs, or Batch
Jobs with broken dependencies appear in the content editor with a red X in one corner.
Note
To break a dependency with a component template, you must have, at minimum,
the ComponentTemplate.Break authorization. To break a dependency with a Deploy
Job, you must have, at minimum a DeployJob.Break authorization. To break a
dependency with a Batch Job, you must have, at minimum, a BatchJob.Break
authorization.
You can use a smart group to locate system objects with broken dependencies. For
details, see Finding system objects with broken dependencies on page 115.
1 Open any folder and navigate to the folder, group, or system object you want to
delete.
2 Right-click and select Delete from the pop-up menu. If you are removing servers
from a folder in the Servers folder, select Remove from Group.
The Delete dialog box shows the objects you have selected for deletion.
3 If you do not want to view any dependencies on the object being deleted, select
Skip dependency view and directly delete object and dependencies.
Selecting this option instructs the system to delete the object and any other objects
that have a dependency on it. You cannot view or break dependencies, as
described in step Step 4 on page 114.
4 Click OK.
If any of the folders, groups, or system objects being deleted have dependencies
on other objects, the Found Dependencies dialog box lists the other items affected
by the deletion of the first object in the Delete dialog box. For example, if you
have chosen to delete a BLPackage, the Found Dependencies dialog box might
show that a Deploy Job and a Batch Job have dependencies on that BLPackage.
5 Review the contents of the Found Dependencies dialog box and click one of the
following:
OKDeletes the folder, group, or object listed in the dialog box along with all
of its dependent objects.
IgnoreDoes not delete the folder, group, or object listed in the dialog box.
BreakDeletes the object listed at the top of the dialog box and breaks any
dependencies with component templates, Deploy Jobs, or Batch Jobs.
If the Delete dialog box in the previous step shows multiple objects being deleted,
the Found Dependencies dialog box displays dependencies for the next item
listed in the Delete dialog box.
6 Continue to repeat step Step 4 on page 114 until the Delete dialog box shows the
results of your actions.
1 Create a smart group with a condition stating that BROKEN_OBJECT must equal
True.
For example, you could create a component template smart group with a
condition stating that BROKEN_OBJECT must equal True. This smart group
displays all component templates with broken dependencies.
Properties view
The Properties view provides a list of properties associated with the current system
object. The Properties view is part of the Properties, Permissions, and Audit Trail tab
group in the Classic perspective.
Basic
Extended
Full
All system objects have the same set of Basic properties. These properties provide
information such as the name and description of the object and the role that created
the object.
The Extended set of properties provides information that applies to this type of
system object, such as properties for servers or jobs. Extended properties also
includes user-defined properties.
The Full set of properties consists of properties similar to Extended properties. They
provide information about the type of system object. However, Full properties are data-
intensive. Displaying information for any of the Full properties may slow the
performance of the BMC Server Automation Console.
For a complete discussion of properties in the BMC Server Automation system, see
Properties on page 143. For a description of using the Properties view to set
values for system object properties, see Setting values for system object properties
on page 161.
Permissions view
The Permissions view lists permissions that have been granted to the system object
that is currently selected. The Permissions view is part of the Properties,
Permissions, and Audit Trail tab group in the Classic perspective.
These permissions take the form of an access control list (ACL). The ACL specifies
the roles that have access to the object and the types of actions each role is
authorized to perform.
Authorization requested
Audit trail records only capture information about users seeking authorization. They
do not capture changes to an object itself.
You can define the types of actions to log in an audit trail (see Defining audit trails
on page 179).
Viewing dependencies
You can visually depict dependent relationships between objects.
You can display relationships with the objects on which an object is based (a
downward point of view) or the objects that are dependent on the current object (an
Visually displaying object relationships lets you quickly spot incorrect object
relationships. For example, if you are using a Batch Job to run multiple Deploy Jobs,
and you have to create a new revision of one Deploy Job, you can see if the Batch Job
is updated to include the latest revision of the Deploy Job.
The Dependency display also lets you right-click an item and immediately go to the
object. For example, if you select a Deploy Job in the Dependency display, the system
lets you jump to the Jobs folder holding that Deploy Job. The Deploy Job you
selected in the Dependency display should be selected in the Jobs folder.
Note
You can only go to an object if you have permission to access the path to that object
and to read the object.
To view dependencies
2 Right-click and select Show Dependency from the pop-up menu. The
Dependencies tab in the content editor opens. It shows dependencies for the
selected object. By default, an upward view of dependencies is displayed.
To display an object listed in the Dependencies tab, right-click the object and
select Go To from the pop-up menu. The console opens the folder of the
selected object and highlights the object itself.
You can import and export the following types of BMC Server Automation objects:
BLPackages
Configuration files
Component templates
Depot software
Extended objects
Files
Application Discovery
Provision
Virtual Guest
System packages
Using the capability to import and export BMC Server Automation objects, you can:
Move objects between separate BMC Server Automation systems. This is typically
required in situations where expert users develop objects, such as complex Batch
Jobs or BLPackages, and then less sophisticated users actually use those objects. If
the two classes of users operate on separate systems, objects must be exported
from one system and imported into the other.
Place BMC Server Automation objects under version control. You can store
exported object definitions as files and then place those files under a version
control system. This provides an extra layer of protection for complex objects that
may require substantial work to define.
For more information about the export and import processes that are available for all
supported object types, see Exporting BMC Server Automation objects on page 120
and Importing BMC Server Automation objects on page 123.
Another mechanism for the export and import of component templates along with
their referenced objects is available. The mechanism is version-neutral, allowing you
to export component templates from one BMC Server Automation version 8.x
system and import them to any other BMC Server Automation system of the same
version or of any later version. In addition, this mechanism allows you to preserve
objects that already exist on the target system. For more information, see Exporting
templates using a version-neutral mechanism on page 136 and Importing
templates using a version-neutral mechanism on page 138.
Note
To export to machines other than your local machine, you must have, at minimum,
the Server.Browse authorization.
To export an object
Application Discovery
Deregister Configuration Objects
Distribute Configuration Objects
Patching (all operating systems)
Provision
Upgrade Model Objects
Virtual Guest
Select Configuration => Config Object Dictionary. Then, select one or more
configuration files or extended objects in the left pane of the Config Object
Dictionary.
3 If you chose a component template for export in Step 1 on page 120, choose
between the standard export and the version-neutral export.
The remaining steps in this section describe the standard export process. For a
description of the version-neutral export process, see Exporting templates using
a version-neutral mechanism on page 136.
4 For Save to, enter the path or use the hierarchical tree to select the directory
where you want to save exported objects.
5 Specify objects you want to exclude from the export by selecting any of the
following:
To reduce the size of the object being exported, exclude referenced objects.
When you exclude an object from an export, you must map the exported object to
a comparable object on the importing system unless the automapping mechanism
can do so automatically.
By default, soft links are retained when you export and then import a BLPackage.
Note
If you check this option, export/import functionality for BLPackages matches
functionality earlier than release 7.4.3.
This option only appears if the object you plan to export is a configuration file or
extended object, or if the object refers to a configuration file or extended object. If
a configuration file or extended object references a built-in grammar file, that
grammar file is never exported even if you check this option.
8 Click Export.
A dialog box appears, indicating that the export has begun. In some situations,
this operation can take time. The dialog box provides options for running the
operation in the background. For information about this dialog box and running
background operations, see Running background operations on page 77.
When the export is complete, a new directory is created in the directory you
specified in step 3. The directory has the same name as the object you plan to
export. If you are exporting a configuration file or extended object, the operating
system is appended to the object name, such as objectName_Windows.
The behavior of the Import wizard, which steps you through this procedure,
depends on the type of object you plan to import.
When you import an object, the import process places imported objects into a default
group. You must review those group assignments and, if necessary, assign the
imported objects to their correct locations. You can optionally instruct the import
process to create a group structure on the importing system that matches the group
structure on the exporting system and then assign the imported objects to those
groups. In this way, the importing system can have a group structure identical to the
exporting system. The import process cannot create smart groups.
If you import an object that includes any associated objects stored in the file server of
the exporting system, those associated objects are stored in a directory in the file
server of the importing system. The directory on the importing systems file server is
called /imported. For example, if you import a component template that includes a
BLPackage and the file server on the importing system is a directory called /storage,
the imported BLPackage is placed in the /storage/imported directory.
If you import an object that includes references to URL-based objects, those objects
are not copied into the importing system.
Note
You can only import system objects into the same version of BMC Server
Automation from which the objects were exported.
When you export or import a Workflow Job, targets, server groups, and child jobs
that are associated with the job through input parameters are not included in the
export or import. You must define these objects on the target system or import them
to the target system before you import the Workflow Job.
To import an object
2 If you chose a component template folder or group for import in Step 1 on page
124, choose between the standard import and the version-neutral import.
The rest of this section describes the standard import process. For a description of
the version-neutral import process, see Importing templates using a version-
neutral mechanism on page 138.
In some situations, after you specify a source directory (the first section listed
above), a dialog box warns that the import process cannot automatically map all
properties in the imported object to properties on the destination system. You can
map these properties manually later in the import procedure.
Field definitions
Import from
Enter the path to a directory or use the hierarchical tree to select the top-level
directory representing the BMC Server Automation object you want to import.
The directory has the same name as the object being imported and contains a
blexport.xml file and a subdirectory structure containing the file representing
the BMC Server Automation object.
If you do not check this option, the import process assigns imported objects
to a default group. You may have to manually map some objects to their
correct groups, as described in Import Select destination group on page
127.
The Import contents panel is for review only; you cannot modify its contents.
The Import wizard always displays this panel when you import a configuration file,
extended object, or component template that includes a local configuration object. If
the Import wizard finds a matching grammar file on the importing system, the
wizard shows the match in the Destination Grammar column. If the Import wizard
cannot find a match, the Destination Column is blank, and you must use this
procedure to map the referenced grammar file to an existing grammar file on the
importing system.
Field definitions
Grammar Selection
In the Grammar Selection list, select a grammar and click Change Selected
Grammar .
When the Grammar Selection dialog box opens, use it to select a grammar file
on the importing system that should be used in place of the selected
grammar file and click OK.
Repeat this process for each grammar file so that the correct grammar is
defined for each grammar file in the list.
For example, if you plan to import a Deploy Job that deploys a BLPackage, you must
identify a job folder in which to store the imported Deploy Job, and you must
identify a depot folder to store the imported BLPackage.
Field definitions
Group Selection
In the Group Selection list, select an object and click Change Selected Group
.
When the Select Group dialog box opens, use it to navigate to the folder that
should hold the selected object and click OK.
Repeat this process for each object so that the correct folder is defined for
each object in the list.
You can select and map more than one object at a time as long as they are all
the same type of object. For example, they must all be component templates
or BLPackages.
The Select Remediation Groups panel also lets you identify groups to contain all
BLPackages, Deploy Jobs, and Batch Jobs that are created automatically when you
run the imported Compliance Job.
Field definitions
Group Selection
In the Group Selection list, select an object and click Change Selected Group
.
When the Select Group dialog box opens, use it to navigate to the folder that
should hold the selected object and click OK.
Repeat this process for each object so that the correct folder is defined for
each object in the list.
You can select and map more than one object at a time as long as they are all
the same type of object. For example, they must all be component templates
or BLPackages.
The Import wizard only displays this panel when the object you are importing
references a server not available to your role.
During the import of most types of jobs, servers and job targets are not considered
relevant so they are not mapped when you export and import jobs. An exception is a
server object-based Audit Job. In this case, when the exported job references a master
server that does not exist on your current system, the Map Missing Servers and
Server Groups panel appears.
When the Import utility attempts to match an imported server with the servers
available to your role, it checks to ensure the server name, IP address, and operating
system all match.
Field definitions
Server Selection
In the Server Selection list, select a server or server group and click Change
Server Mapping .
When the Select Server dialog box opens, navigate to the server or server
group to replace the selected item, and click OK.
Repeat this process for each server and server group in the list.
If a property does not already exist, the import process attempts to automatically
create a matching property. The newly created property has the same name, type,
and parent class as the property referenced by the imported object. If the property
being imported belongs to or references a custom property class that does not exist
on the destination system, the import process creates a custom property class with
the same name.
The Map Missing Properties panel displays all properties that require mapping and
displays properties that have been automatically created to match the property being
imported. If necessary, you can change this mapping. You can also create another
property and map it to an imported property.
In some situations, the import process cannot automatically create a property on the
destination system. Instead, you must manually map the imported property to a
property on the destination system. If necessary, you can create the property you
need. When a property cannot be automatically mapped, the Reason column of the
Map Missing Properties panel provides an explanation for the failed mapping. For a
list of possible reasons, see the table below. If a property is successfully mapped, the
Reason column is blank.
Reason Explanation
Matching type not found The importing system has a property with the same
name as an exported property but the property on
the importing system is defined to have a different
type.
Matching enumeration with same element not found A property is exported, and the property is defined
to use enumerated values. On the importing system,
a property with the same name exists, but the
property is defined to use a different type of
enumerated data.
Matching enumeration values not found A property is exported, and the property is defined
to use enumerated values. On the importing system,
a property with the same name exists and the
property is defined to use the same type of
enumerated data. However, on the importing system
the enumerated data has different values.
You can turn off the automatic creation of properties during the import process. To
perform this procedure, use the Application Server Administration console (that is,
the blasadmin utility), as described in BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Creating+properties+automatically+in+the
+BMC+Server+Automation+Console.
Field definitions
Property Selection
Review the properties listed and the properties to which they are mapped.
The Replacement Property column shows the property to which each
property is mapped.
When the Select Property dialog box opens, you can do one of the following:
On the Select Property dialog box, click OK. Repeat this process for each
property in the list that is not properly mapped.
The Property Values Mapping panel only appears if all of the following
circumstances occur:
An object is exported that includes a custom property class and an instance of that
custom property class.
The exported object is imported into another system in which the same custom
property class exists.
On the importing system, the custom property class includes a required property
for which no default value is defined. On the exporting system, one of the
following is true:
The same property exists but no value is defined. (Note that if the property on
the exporting system had a default value, the value is not exported because
default values are never exported.)
Field definitions
In the Missing Property Name list, you can select a property and click
Change Property Mapping . When the local field for the selected property
becomes active, it displays utilities for editing the value of the selected property.
Depending on the type of property you are editing, you can take different
actions to set a new value, such as entering an alphanumeric string, choosing
from an enumerated list, or selecting a date. To insert a parameter into the
value, enter the value, bracketed with double question mark delimiters (for
example, ??MyPARAMETER??) or click Select Property . For more
information, see Inserting a parameter on page 163.
Repeat this procedure for each property listed in the Missing Property Name
list.
You can map the system package type to a system package type that is defined for
your system, or you can map it to any name that you provide. The Import wizard
only shows this panel when you import system packages.
Field definitions
In the System Package Type Selection list, select a system package type and
click Change System Package Type Mapping .
When the Edit System Package Type Name dialog box opens, you can:
Choose Enter new name. Then, for Enter new system package type name,
enter a name for the system package type.
Repeat this process for each system package type in the System Package Type
Selection list.
The Import wizard only displays this panel in the following circumstances:
When the object was exported, Exclude BLPackages was selected, which means no
associated BLPackages were exported with this object.
The importing system does not include a BLPackage with the same name that is
accessible to your role.
Field definitions
BLPackage Selection
In the BLPackage Selection list, select a BLPackage type and click Change
BLPackage Mapping .
When the Select Depot Object dialog box opens, navigate to the BLPackage to
replace the missing BLPackage you selected, and click OK.
The Import wizard only displays this panel in the following circumstances:
When the object was exported, Exclude Component Templates was selected. That
setting means no associated component templates were exported with this object.
The importing system does not include a component template with the same
name that is accessible to your role.
Field definitions
The Import wizard only displays this panel if the object you plan to import
references depot files or software that do not exist in your Depot. When an imported
object references a file or software that already exists in the Depot, the import
process automatically maps the file or software to an existing depot object with the
same name.
Field definitions
In the Depot Object Selection list, select a file or software item and click
Change Depot Object Mapping .
When the Select Depot Object dialog box opens, navigate to the file or
software item to replace the missing soft-linked depot object you have
selected, and click OK.
If you are mapping a missing file, the dialog box only lets you map to a depot
file on the importing system; if you are mapping missing software, the dialog
box only lets you map to depot software.
The Import wizard only displays this panel if the object you plan to import is a Batch
Job and it references Component Discovery Jobs that do not exist in your Jobs folder.
When an imported Batch Job references Component Discovery Jobs, the import
process automatically maps the Batch Job to existing Component Discovery Jobs if
they have the same name. If the import process fails to do this mapping, you must
manually map the Batch Job to existing Component Discovery Jobs on the
destination system.
Field definitions
When the Select Component Discovery Job dialog box opens, navigate to the
Component Discovery Job to replace the missing job you have selected, and
click OK.
Repeat this process for each Component Discovery Job in the list.
The Import wizard only displays this panel if the object you plan to import is a Batch
Job and it references Compliance Jobs that do not exist in your Jobs folder.
When an imported Batch Job references Compliance Jobs, the import process
automatically maps the Batch Job to existing Compliance Jobs if they have the same
name. If the import process fails to do this mapping, you must manually map the
Batch Job to existing Compliance Jobs on the destination system.
Field definitions
In the Compliance Jobs Selection list, select a Compliance Job and click
Change Compliance Job Mapping .
When the Select Compliance Job dialog box opens, navigate to a Compliance
Job to replace the missing job you have selected, and click OK.
The Import wizard only displays this panel if the object you pan to import is a Batch
Job and it references Deploy Jobs that do not exist in your Jobs folder.
When an imported Batch Job references Deploy Jobs, the import process
automatically maps the Batch Job to existing Deploy Jobs if they have the same
name. If the import process fails to do this mapping, you must manually map the
Batch Job to existing Deploy Jobs on the destination system.
Field definitions
In the Deploy Jobs Selection list, select a Deploy Job and click Change
Deploy Job Mapping .
When the Select a Deploy Job dialog box opens, navigate to the Deploy Job to
replace the missing job you have selected, and click OK.
The Import wizard only displays this panel if the object you plan to import is a
Network Shell Script Job and it references a script that does not exist in your Depot,
or you are importing a Batch Job that includes a Network Shell Script Job referencing
a missing script.
When an imported Network Shell Script Job references a missing script, the import
process automatically maps the job to an existing Network Shell script if the script
has the same name as the missing script. If the import process fails to do this
mapping, you must manually map the script job to an existing script on the
destination system.
Field definitions
In the NSH Scripts Selection list, select a script and click Change NSH Script
Mapping .
When the Select Depot Object dialog box opens, navigate to the script to
replace the missing script you selected, and click OK.
The version-neutral export and import mechanism allows you to export objects from
any BMC Server Automation version 8.x system and import those same objects to
any other BMC Server Automation system of the same version or of any later version.
During the import of a version-neutral export package, you can preserve existing
objects found on the target system.
Note
To export to machines other than your local machine, you must have, at minimum,
the Server.Browse authorization.
2 If you chose a component template (and not a group or folder) for export in Step 1
on page 137, use the Export Mode Selection panel to choose between the standard
export and the version-neutral export.
The remaining steps in this section describe the version-neutral export process.
For a description of the standard export process, see Exporting BMC Server
Automation objects on page 120.
3 Through the Export Destination Selection panel, enter the path in the Save to field
or use the hierarchical tree to select the directory where you want to save
exported objects.
4 To exclude certain types of referenced objects from the export, select any of the
following check boxes:
Exclude BLPackages
Often you can dramatically reduce the size of the export package by excluding
referenced objects. However, if you exclude objects, ensure that the referenced
objects exist on the target system.
By default, grammar files are not included in the export package due to their
typical size.
6 Click Export.
The export process runs in the background. When the export is complete, a new
zipped export package is created in the directory that you specified in Step 3 on
page 137. This zipped export package has the same name as the object being
exported, and it contains the XML-based content format file and all relevant
payload files.
The version-neutral export and import mechanism allows you to export objects from
any BMC Server Automation version 8.x system and import the same objects to any
other BMC Server Automation system of the same version or of any later version.
During the import of a version-neutral export package, you can preserve any
existing objects found on the target system.
For more information about the XML-based content format file contained within the
zipped export package and used during the import process, see Content format on
page 1461.
2 On the Import Mode Selection panel, choose between a standard import and a
version-neutral import.
The remaining steps in this section describe the version-neutral import process.
For a description of the standard import process, see Importing BMC Server
Automation objects on page 123.
3 On the Import Source File Selection panel, enter the path to the zipped export
package that you want to import (including the name of the .zip file) in the
Import from field, or use the hierarchical tree to select the relevant .zip file. Then
click Next.
Choose one of the following options for handling objects that are referenced
by the imported templates and already exist on the target system:
Keep existing objectsKeep the objects that exist on the target system.
Template location
Choose one of the following options for the hierarchical positioning of the
imported templates under the Component Templates folder on the target
system:
5 To start the import process, without first viewing the list of contents within the
imported package or previewing and validating that the import will end
successfully, click Finish.
To continue with the additional steps before starting the import process, click
Next.
6 On the Import Contents panel, review the list of package contents to be imported.
This list includes templates, BLPackages in the Depot, grammars, configuration
objects (configuration files or extended objects), and Property Dictionary objects.
For each object, the name, type, and destination location are provided.
If necessary, click Back to return to the previous panels and modify the import
settings.
7 To preview and validate the import before running the actual import process:
Run a preview while you remain in the Import wizard by clicking Preview.
All import objects are analyzed (this may take time), and the results are displayed
either on the Import Contents panel (if you ran the preview within the Import
wizard) or through the Import Preview panel (which is displayed after a
background preview).
The results are displayed for each object in the Status and Action columns. For a
description of the possible values displayed in these columns, see Import object
status and action on page 140.
To view more preview details in the log messages issued during the preview
process, click Show Log.
Note
If only one object fails, the entire import process fails. In such a case, check the log
for the reason that the object could not be imported. Address the issue by
modifying the existing object on the target system, and then try running the
import process again.
8 To start the import process, click Finish (on the Import Contents panel) or Import
(on the Import Preview panel).
Note
A local configuration object in the imported component template cannot coexist
with a global configuration object defined in the Configuration Object Dictionary
on the target system. If a configuration file with the same name and path or an
extended object with the same name and operating system already exists in the
Configuration Object Dictionary on the target system, the import of the
conflicting local configuration object is skipped. The imported component
template is associated with the global configuration object that already existed on
the target system.
Similarly, a global configuration object associated with the imported component
template cannot coexist with a local configuration object defined in any
component template on the target system. The import process fails, and an error
message prompts you to delete or rename the conflicting local configuration
object on the target system before you run the import process again.
Status Description
The following table describes the possible actions for import objects:
Action Description
Action Description
The Property Dictionary organizes properties into classes and subclasses. Each class
inherits the properties defined for the root system object in the Property Dictionary.
Each subclass inherits all properties defined for its parent class.
The Property Dictionary presents users with two types of property classes: built-in
and custom.
Both built-in and custom property classes are hierarchical collections of classes and
subclasses. Built-in property classes are the same for all BMC Server Automation
installations. The define the standard properties for the objects you interact with in
the server automation system. Custom property classes are user-defined and have
multiple applications.
In general, all roles can read the Property Dictionary; no special permissions are
required to view it. However, to view instances of custom property classes, your role
must have, at minimum, a PropertyInstance.Read authorization. For information
about granting authorizations to roles, see Creating roles on page 210.
Add a new property to a built-in Use BMC Server Automation to add a new property to a built-in class
class or modify an existing property or modify an existing property. Built-in property classes are associated
with types of system objects.
For example, all properties in the Jobs class are automatically
associated with each job in the system. If you add a new property to the
Jobs built-in class, it is automatically associated with all jobs. Similarly,
all properties in the Network Shell Script Jobs subclass are
automatically associated with all Network Shell Script Jobs.
Note that many of the properties in the Network Shell Script Jobs subclass
and all job subclassesare inherited from the Jobs class.
See Adding or modifying properties on page 152 and Removing or
deprecating a property, custom property class, or instance on page 157.
For example, the Server built-in class corresponds to servers. The Deploy Job sub-
class (whose parent is the Job class) corresponds to Deploy Jobs. Every system object
in BMC Server Automation automatically inherits all the properties assigned to its
corresponding class or sub-class in the Property Dictionary. If you add a property to
the Server class, every server automatically inherits that property.
All system objects in BMC Server Automation inherit the properties assigned to the
root system object in the Property Dictionary. These properties assign basic
information that is common to all system objects, such as the role who created the
object and its date of creation.
Properties description
A property is a symbolic representation of information that is likely to change from
object to object in BMC Server Automation, such as the path to an installation
directory on a server. You can assign properties to most objects.
Assigning values to objects so those values can be used elsewhere in BMC Server
Automation. For example, a property can indicate an objects development status
(such as DEV, QA, or PROD).
Defining smart groups, which are groups of objects that are automatically
populated based on criteria in the form of property settings. All folders except
RBAC Manager let you create smart groups. In BMC Server Automation you can
perform many actions on server and component groups, so a well designed
scheme for assigning properties to servers can enhance productivity. For example,
you can create a property, such as OWNER, and then assign different values for
that property to different servers. If some servers have OWNER set to QA and
others have OWNER set to DEV, then smart groups can automatically separate
QA servers into one group and development servers into another.
BLPackages, component templates, and system packages let you assign local
properties that only apply to a particular object. Local properties are primarily used to
create multiple instances of an object on a single server. For example, you can use
local properties to deploy a BLPackage to multiple locations on the same server.
Parameters description
Throughout BMC Server Automation, an important use for properties is to create
parameters, which are references to properties. For example, when you deploy an
Apache server to Windows and UNIX platforms, you can specify a different
installation directory for each platform by defining a server property that might be
called APACHE_INSTALL_DIR.
In the BLPackage that encapsulates the Apache server, you can insert a parameter
that refers to APACHE_INSTALL_DIR. When that BLPackage is deployed to a
server, BMC Server Automation obtains the servers value for
APACHE_INSTALL_DIR. Using a parameter in this way, you can deploy the same
BLPackage to multiple servers running different operating systems.
Because subclasses inherit any properties defined in a parent custom class, you can
create a hierarchical structure with multiple levels and different properties defined
at the various levels. Each class inherits all properties defined for its parent class.
Consider a custom property structure like the following, which is four classes deep.
For each of the lowest classes in this structure, three instances are defined, as shown
in the following illustration.
The following graphic shows one branch in this custom class structure. For any
custom class, you can define an unlimited number of properties, which are then
inherited by its subclasses. The graphic shows how one property defined at each
level propagates downward through the structure.
The properties in this graphic can be used to identify an installation location for a
BLPackage. In this example, the BLPackage is assigned a local property called
DEPLOY_LOC. This local property is a property class propertythat is, a type of
property that refers to a specific property class or subclass. In this example, the
DEPLOY_LOC property refers to the DEV custom property subclass, which includes
The path to the BLPackage installation directory uses the following series of
parameters.
??DEPLOY_LOC.ROOT_DIR??/??DEPLOY_LOC.APP_DIR??/ ??
DEPLOY_LOC.VER_DIR??/??DEPLOY_LOC.LEVEL_DIR??
In this path, each parameter refers to the DEPLOY_LOC local property, which in
turn refers to the DEV custom property class.
When you deploy the BLPackage, you must provide a value for the DEPLOY_LOC
property. The value of a property class type of property is an instance of the
referenced property classin this case, an instance of the DEV property class.
In each instance of the DEV property class, a different value is assigned to the
LEVEL_DIR property. For two instances, different values are assigned to the
APP_DIR property. In the first instance, LEVEL_DIR is set to dev1. When all the
parameters in the path to the BLPackage are resolved, the path becomes /c/apps/a/211/
dev1. In the second instance, LEVEL_DIR is set to dev2 and APP_DIR is set to apps/
sandbox/a, so the path resolves to /c/apps/sandbox/a/211/dev2. In the third instance,
LEVEL_DIR is set to dev3 and APP_DIR is set to apps/experimental/a, so the path
resolves to /c/apps/experimental/a/211/dev3. All three paths identify different
locations on the same server.
This example examines one set of properties on one branch of a custom property
class hierarchy. You can use the same approach on each branch of the hierarchy. You
can also use other properties to establish other types of information that are
inherited downward throughout the hierarchy.
The following table describes the types of data that properties can accept, including
limitations inherent to each data type.
When you create a custom property class, the permissions you define for that system
object are not inherited by any subclasses. This lets you create a custom property
class and define some properties for it. Then, you can create a subclass that inherits
the properties defined for the parent class. For the subclass, you can grant the
Modify permission to another role (for example, the JuniorAdmin role).
With a custom property class structure like this, the subclass inherits the properties
defined for the parent class. The JuniorAdmin role cannot delete the properties that
the subclass inherits, nor can the JuniorAdmin role change enumerated values for
any inherited property. However, the JuniorAdmin role can change default values
for properties and add properties to the subclass.
To modify an existing custom property class, you must modify its properties, much
like you would for any other system object. For more information about this
procedure, see Setting values for system object properties on page 161.
3 Right-click and select New Class or New sub-class from the pop-up menu. The
General panel of the Create New Property Class wizard opens.
4 For Name, enter the name of a custom property class. For Description, you can
optionally provide descriptive text.
5 Click Next.
The Properties panel of the Create New Property Class wizard opens. Use the
Properties panel to specify the properties that should be associated with this
property class. The panel automatically includes all built-in properties that are
associated by default with a property class.
6 Click Next.
The Permissions panel of the Create New Property Class wizard opens. Use the
Permissions panel to define permissions for this property class. The Permissions
panel is an access control list granting roles access to this property class. BMC
Server Automation uses ACLs to control access to all objects.
For more information about defining ACLs, see Defining permissions for a
system object on page 231.
When you add a property to a built-in property class, the property is automatically
associated with all existing instances of those types of objects. For example, if you
add a new property to the Jobs class, the property is:
When you create a property in the Property Dictionary, the property is available
globally throughout BMC Server Automation. All roles have access to the property.
You can use a parameter to reference the new property in any situation where BMC
Server Automation supports parameters. When defining BLPackages, component
templates, and system packages, you can also create local properties. Properties
created in those contexts are not available globally.
To assign a value for a property class property, you must select an instance of the
referenced property class. For more information, see Creating or modifying an
instance of a property class on page 155.
Note
When you create an instance of a custom property class, many dependencies are
established for the properties included in the custom property class. Therefore, you
may encounter the following limitations when an instance of a custom class already
exists:
When adding a required property to a custom property class, the property must
have a default value. It cannot have a null value.
An existing property cannot be made into a required property unless you also
provide a default value for the property.
Options for an enumerated list cannot be removed. You can only add options to
properties that use an enumerated list.
Using the Property Dictionary, add a new custom property class (see Adding a
custom property class on page 150). In the property list at right, select the
Properties tab.
Import an object that references a missing property. When the Import wizard
asks you to map a property, add a new property to the Property Dictionary.
To modify an existing property, select the property and click Edit Property .
A property dialog box opens. Depending on your context, the name of this dialog
box may vary.
3 For Name, enter the name of the property. For Description, you can optionally
provide descriptive text.
Option Action
Simple From the drop-down list at right, select one of the possible values. These values
describe the type of data that is possible for a simple property. If you select String
enumeration or Integer enumeration, do the following:
1 Click Browse to the right of Possible values. The Edit Enumeration dialog box
box opens.
2 Click Add New Value . The Enumeration Editor dialog box box opens.
3 For Name, enter a text string that clearly identifies the potential property value.
This string is the name that users see when choosing a value for this property. For
Value, enter a value.
For example, if you are adding a list of integers, you might assign a name of High
to the value 3, Medium to the value 2, and Low to the value 1.
4 Click OK.
Simple, and then From the drop-down list at right, select the type of data that can be provided for this
select Complex property.
Property class Click Browse at right. The Property Class Selection dialog box box opens. Use this
dialog box box to select a custom or built-in property class or subclass. Click OK.
For an extended discussion of using property classes and property class property
types, see Custom property class description on page 146.
5 To specify a default value for the property, check Use this default value. For
Default value, enter a default.
The method you use for entering a default value depends on the property type
you select in the previous step. For example, if the property type is Boolean, you
can select True or False from a drop-down list.
If the property type is Encrypted String, you must enter a value and then confirm
your typing by entering it a second time.
If the property type is Long Text, click Browse to the right of Default value, which
displays the Edit Long Text dialog box. Enter a long block of text, such as a script.
The text block can be a maximum of 2000 characters.
Note
When using the Property Dictionary to add a property to a property class or
subclass, you must always define a default value for the property. That default
value can be null (that is, an empty value). Because of this requirement, the Use
this default value option is always checked when you are creating a property. If
you are modifying a property inherited from a parent class, you can choose not to
use a default value by clearing Use this default value.
RequiredA value must be provided for this property. If you check this, you
must provide a default value, and the default value cannot be null (that is, an
empty value).
7 Click OK. The property is added to the list on the Properties tab.
DataStore
DeployOptions
ProxyServer
Instances of property classes are often used in conjunction with property class
properties. (A property class property is a reference to a property class.) To define
property values for a property class property, you must first define an instance of the
property class and then assign values to the properties in that property class
instance. For an extended example explaining how to use custom property classes
and property class properties, see Custom property class description on page 146.
2 Navigate to the property class or subclass for which you want to create an
instance.
To create an instance of a property class, click Add New Property Set Instance
.
The New Instance wizard opens, displaying the General panel.
5 On the General panel, for Name, enter the name of the instance. For Description,
you can optionally provide descriptive text.
Note
The NAME and DESCRIPTION properties of a custom property class refer to the
name and description of an instance of the custom property class. For example,
suppose a custom property class includes a property called LEVEL and the value
of that property is defined as ??NAME??. (In other words, the value of the
property is a parameter referring to the NAME property.) If you create an
instance of the custom property class and the instance is named QA1, then the
value of the LEVEL property for this instance is QA1.
6 To set values for a property in the custom property class, double-click the
property. The Set Property Value dialog box opens. Enter a value for the property
and click OK. For more information, see Setting values for system object
properties on page 161.
7 Click Next or select the Permissions tab to display the Permissions panel. Use this
panel to define an ACL for the instance.
The Permissions panel is an access control list granting roles access to this
instance. Access to all objects in BMC Server Automation, including the sharing of
objects between roles, is controlled through ACLs. For more information about
defining an ACL, see Defining permissions for a system object on page 231.
8 Click Finish.
Note
If a property class property references a custom property class and that
property class property is applied to a versioned object such as a job or
component, you can never remove the custom property class. Even if you
remove the custom property class from the versioned object, an earlier version
of that object continues to use the custom property class.
Instead of removing a property, custom property class, or instance that is in use, you
can deprecate the item. Deprecation means that the property, custom property class,
or instance still exists, but it no longer appears in the Property Dictionary. After it is
deprecated, you cannot create another property, custom property class, or instance
with the same name. If you attempt this, the system prompts you to undeprecate the
item. If you do, the property, custom property class, or instance is returned to the
Properties Dictionary.
Select the property class or subclass from which you want to delete a property.
Click the Properties tab and select the properties to remove.
Select a property class or subclass for which you want to delete an instance.
Click the Instance tab and select the instances to remove.
3 Click Remove .
The selected items are removed unless an item is being used elsewhere in BMC
Server Automation. If an item is in use, you are prompted to mark the item as
deprecated.
The General tab of the properties dialog box for a property class provides
information identifying the object. The information on the General tab cannot be
modified.
The Audit Trail tab provides a record of roles and users that have sought
authorization for this object.
1 Right-click a property class in the Property Dictionary and select Properties from
the pop-up menu. A tabbed dialog box box appears.
3 Click OK.
Defining permissions
All property classes in the Property Dictionary include permissions in the form of an
access control list (ACL). The ACL specifies the roles that have access to the property
class and the types of actions those roles are authorized to perform.
Use these procedures to add a set of authorizations for a role, add a predefined set of
permissions to one or more roles, apply ACL policies, or to delete an entry.
1 In the Property Dictionary, right-click a property class and select Properties from
the pop-up menu.
1 From the Permissions tab, click Add Entry . The Add New Entry window
opens.
To assign individual system authorizations, click the System tab at the bottom
of the Available Authorizations list. Then, select the system authorizations you
want to make available to the role you chose in the previous step.
To assign authorization profiles, click the Profiles tab at the bottom of the
Available Authorizations list. Then, select the authorization profiles you want
to make available to the role you chose in the previous step.
Tip
To select multiple authorizations, use Shift-click or Control-click. Click the right
arrow to move your selections to the Selected Authorizations list.
4 Click OK.
1 From the Permissions tab, click Use ACL Template . The Select ACL
Template dialog box opens.
3 To set the contents of the selected ACL templates to replace all entries in the
access control list, check Replace ACL with selected templates.
Note
If you do not check this option, the contents of the selected ACL templates are
appended to any existing entries in the access control list. Replacing the current
set of permissions with the contents of an ACL template is particularly useful
when promoting a system object between roles.
4 Click OK.
1 From the Permissions tab, click Use ACL Policy . The Select ACL Policy
dialog box opens.
3 To set the contents of the selected ACL policies to replace all entries in the access
control list, check Replace ACL with selected policies.
Note
If you do not check this option, the contents of the selected ACL policies are
appended to any existing entries in the access control list. Replacing the current
set of permissions with the contents of an ACL template is particularly useful
when promoting a system object between roles.
4 Click OK.
To delete an entry
You cannot use this procedure to change property values for custom server objects.
You can edit the value of any property defined as editable. When you select a
property, if it is editable, the Edit Property Value icon becomes active.
Select an existing system object, which displays that objects properties in the
Properties view.
2 In the properties list, click in the Value column for the property you want to edit.
If the property is editable, the Value field becomes active and displays utilities for
editing the selected property value.
To set a property value back to its default value, click Reset to Default Value
.
The value of the property is reset to the value it inherits from a built-in
property class.
Depending on the type of property you are editing, you can take different
actions to set a new value, such as entering an alphanumeric string, choosing
from an enumerated list, or selecting a date. To insert a parameter into the
value, enter the value, bracketed with double question mark delimiters (for
example, ??MyPARAMETER??) or click the Select Property . For more
information, see Inserting a parameter on page 163.
You can change property values for all system objects within one or more groups,
folders, or smart groups. You can also select one or more individual system objects
and change property values for them.
1 Select the system objects for which you want to change property values. In the
Servers, Components, Component Templates, Depot, Jobs, Devices, or RBAC
Manager folders, select one or more system objects, groups, folders, or smart
groups.
in the RBAC Manager folder, you can only change property values for users and
roles.
For servers, right-click and select Administration Task => Set Server Property
from the pop-up menu.
For all other types of objects, right-click and select Set objectType Property
from the pop-up menu. In this command, objectType is the type of object to
which you are assigning a property value, such as Patches or Depot Objects.
3 From Name, select the property for which you want to set a value.
4 For Value, enter a value for the selected property by doing any of the following:
To set a property value back to its default value, click Reset to Default Value
.
The value of the property is reset to the value it inherits from a built-in
property class.
Depending on the type of property you are editing, you can take different
actions to set a new value, such as entering an alphanumeric string, choosing
from an enumerated list, or selecting a date. To insert a parameter into the
value, enter the value, bracketed with double question mark delimiters (for
example, ??MyPARAMETER??) or click Select Property . For more
information, see Inserting a parameter on page 163.
5 Click OK.
Inserting a parameter
Inserting a parameter is a common activity throughout BMC Server Automation.
To insert a parameter, enter the name of the property delimited with two question
marks.
In a situation in which you can enter a parameter, BMC Server Automation provides
a tool that lists all contents of the Property Dictionary that are related to your current
context. From that list you can select a property and a parameter is generated at your
cursor position.
To insert a parameter
1 Access a situation in BMC Server Automation where you can use parameters.
2 Position your cursor in the spot where you want to insert a parameter.
Click Select Property . A list of properties appears. Use the list to do one of
the following:
The BMC Server Automation system of access control provides granular capabilities,
allowing you to restrict access to sensitive configurations and file systems and grant
authorization to execute particular tasks (such as executing a Network Shell script)
or specific commands (such as ls). You can maintain a complete and consistent audit
trail by recording the actions users perform on critical resources. All actions are
logged, and event notifications can be sent when certain actions occur.
Authorization overview
In BMC Server Automation, access control is managed through role-based and object-
based authorizations.
The definition of a role includes a set of authorizations and other information that
reflects the capabilities of an organizational entity, such as QA engineers or web
administrators. When a user is assigned to a role, he or she is granted the
authorizations defined for that role.
Performing any action in BMC Server Automation typically requires three levels of
authorization:
Role-based authorizations
Authorizations are granted to roles so they can perform certain types of actions.
To grant authorizations, you define an access control list for each role. Entries in that
list specify a class of actions, such as Server.Read, which lets a role read servers, or
DeployJob.Execute, which lets a role execute Deploy Jobs. Authorizations that are
granted to a role should mirror the responsibilities of an organizational entity. For
example, a JuniorAdmin role might be granted limited authorization to perform
actions such as reading servers, components, and jobs. A SeniorAdmin role might be
authorized to perform all types of actions on servers, components, and jobs.
Object-based authorizations
When you create any system object in BMC Server Automation, you must define an
access control list for that object. Each entry in the access control list grants
permission to a role to perform a certain type of action on that system object.
For example, if you are creating a Deploy Job, you might grant a role Read and
Execute authorizations for that job.
Resource-based authorizations
Authorizations at the resource level are granted in the same manner as object-based
authorizations.
Resources are system objects. For each resource, you must define an access control
list. However, the permissions you can set on resources are different than
permissions on other system objects. For a server, device, or component, you can
grant special-purpose permissions such as Browse, Snapshot, and Audit.
Role level
Object level
Target level
On the server that is the target of the Deploy Job, you role must be granted
Server.Read and Server.Modify.
Any time you run a job that modifies a target server, your role must be granted
Server.Read and Server.Modify on that server.
Effective authorizations
The combination of role-based and object-based authorizations (including resource-
based authorizations) determines a users effective permissions to perform actions
on any system object.
Managing authorizations
To manage authorizations, you must use the functionality of the RBAC Manager
folder as well as the ability to set permissions for any system object throughout BMC
Server Automation. When setting up and using authorizations, BMC Server
Automation recommends the work flow described in the following sections.
To manage authorizations
1 Set up authorizations.
When you define a role, you can specify an ACL template that functions as the
object permissions template. This ACL template defines a set of authorizations that
are automatically assigned to any object created by this role.
ACL templates are also useful when transferring responsibility for an object
between functional areas of an organization, such as when a development team
completes work on a job or BLPackage and promotes it to QA. In a situation like
this, permissions for the object must be redefined. An ACL template can
encapsulate all the necessary changes, with the new permissions replacing the
objects existing permissions.
Like ACL templates, ACL policies can be used to transfer responsibility for an
object between functional areas of an organization. An ACL template can
encapsulate all necessary permissions for an object. When you apply the new
ACL policy, the new permissions can replace the objects existing permissions.
An automation principal defines a user credential that can be used for accessing
external systems. The most typical use for automation principals is Windows user
mapping, a process that maps an RBAC role to a local or domain user on a
managed server. Automation principals can also be used for accessing Active
Directory servers, configuring Atrium Orchestrator, and other purposes.
For more information about using automation principals for managing Windows
and UNIX servers, see Automation principals and server management on page
171
To synchronize the users in the RBAC user database with an LDAP user registry
such as Active Directory, you must set up connections and queries that are used
for obtaining information from the LDAP server.
For more information, see Creating an LDAP connection on page 201 and
Creating an LDAP query on page 206.
7 Create roles.
8 Create users.
BMC Server Automation also provides a set of BLCLI commands that can
synchronize your RBAC user database with Active Directory. For more
information, see Synchronizing users with LDAP servers on page 227.
For each system object in BMC Server Automation, you must define a set of
permissions specifying which roles have access to the object. Object-based
authorizations let you make fine-grained decisions about access to individual
system objects, including the sharing of objects. For more information, see Object-
based permissions on page 230.
After you establish permissions for objects in your system, changes will inevitably
be necessary. For example, if you add a role, you must modify the permissions for
some or all of the objects in your system to accommodate the new role. To
accomplish this, you can group objects in a folder, define new permissions, and
then apply those permissions to all of the objects in the group. For more
information, see Updating permissions for one or more system objects on page
235.
On UNIX servers, the RSCD agent uses a setuid command to fully impersonate a
user on the managed server.
To set up UNIX user impersonation or Windows user privilege mapping, you must
use the BMC Server Automation configuration files (exports, users, and users.local)
on each managed server. For information, see BMC technical documentation at
https://docs.bmc.com/docs/display/bsa82/Setting+up+configuration+files.
Note
Only Windows servers running BMC Server Automation 8.0 or later can
recognize automation principals.
Deploy Jobs and File Deploy Jobs that include repeaters can only use Windows
user mapping when communicating with the repeater or a target server. When
the repeater communicates with targets running Windows, communication must
be based on user privilege mapping. The following table details how Deploy and
File Deploy Jobs can use automation principals during indirect deployments.
Authorization enforcement
When you are using the console, the BMC Server Automation Application Server
enforces all authorizations defined for roles and system objects.
If a role does not have at least Read authorization for an object (at both the role level
and the object level), the Application Server denies access to the object. A role must
have additional authorizations to perform other actions on an object, such as
executing a job or modifying a server.
in an access control list for that server. The ACL Push Job then copies that ACL to
the servers agent. On the agent this ACL is called the users configuration file. For
more information about how BMC Server Automation converts role information into
entries in a users configuration file, see Agent ACL description on page 240.
For Windows servers, you can optionally control access using an alternative
approach to configuration files: Windows user mapping. In this approach, you
define an automation principal who maps to a local or domain user on a Windows
server. Then you can associate the automation principal with a role. When that role
accesses the Windows server, the role is granted the permissions of the local or
domain user.
Agent ACLs can define other types of connection characteristics besides user
mapping. Because of that, you should run Agent ACL Push Jobs on servers when
you add or modify user or role information, even if you have set up Windows user
mapping on those servers. For more information about Windows user mapping, see
Creating automation principals on page 195.
No access nodes
A no access node represents a system object that you can see in a BMC Server
Automation console but you cannot interact with because you do not have the
appropriate authorizations.
BMC Server Automation uses italics to distinguish no access nodes from system
objects for which you have permissions. Using preferences you can specify whether
a BMC Server Automation console displays no access nodes (see Customizing
preferences on page 84).
The RBAC Manager folder never shows no access nodes. In that folder, if you are not
authorized to read a system object, you cannot see the object.
All actions in BMC Server Automation must be authorized. An audit trail entry can
be generated each time a user is successfully authorized for an action, each time a
user is denied authorization, or in both cases. To view an audit trail for any system
object, see Audit Trail view on page 117.
You can specify the authorizations to be logged in an audit trail. To accomplish this,
you define properties for the system authorizations listed in the Authorizations
node. For more information, see Defining audit trails on page 179.
RBACAdmins
BLAdmins
GlobalReportAdmins
GlobalReportViewers
The RBACAdmins and BLAdmins roles are granted a combination of built-in and out-
of-box authorizations. The GlobalReportAdmins and GlobalReportViewers roles are
only granted out-of-box authorizations.
The following table summarizes the authorizations granted to the built-in roles:
PatchAnalysisConfig.Modify
(used for modifying the
download locations for
Windows patch analysis
configurations)
BMC Server Automation provides built-in and out-of-box authorizations so you can
manage access permissions with no further modifications. However, for a more
granular system of permissions, you can modify the out-of-box authorizations
granted to the built-in roles. You can create additional roles to develop sets of
authorizations, and you can use object-based permissions to further restrict access
throughout the BMC Server Automation system.
In addition to the built-in roles, BMC Server Automation provides two other roles
that are used for special purposes:
Current RoleA role that is available when creating an ACL template. This role
grants permissions to the current role when that role creates an object. Using
Current Role permissions in an ACL template is an easy way to give the creator of
an object permission to use the object without having to revise an ACL template
for each different role. For more information, see Creating an ACL template on
page 184.
The RBACAdmin user is only assigned to the RBACAdmins role, and the BLAdmin
user is only assigned to the BLAdmins role. Because each of these users is assigned
to one role, that role automatically becomes the default Network Shell role for each
user. A special set of agent ACLs is generated for users associated with a Network
Shell role. Those ACLs give the user access to Network Shell. For more information
about the default Network Shell role, see User Role Selection on page 224.
Note
The RBACAdmin and BLAdmin users cannot be removed from their default roles.
However, they can be renamed.
To make your default users active, they must be assigned passwords and granted
access to servers in your network. You can use the RBAC Manager folder to perform
these actions, but to start the console the first time, you must define a password for
the RBACAdmin user. Typically, after installing BMC Server Automation, you use
the Post-install Configuration Wizard to set up a password for the RBACAdmin
user, as described in BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Home. However, you can also use the bladduser utility to set up the
RBACAdmin and BLAdmin users, as described in Using the bladduser utility on
page 251.
Setting up authorizations
In the RBAC Manager folder the Authorizations node lets you set up system and
command authorizations.
folder, the only action you can take to set up a system authorization is to specify how
the authorization is used to generate an audit trail.
To set up authorizations
1 Using the Authorization node, you can perform the following procedures:
4 For Name, enter the name you are assigning to the nexec command. Do not
include nexec. RBAC automatically attaches nexec to the command.
The only commands you can delete are custom nexec commands. You cannot delete
the commands that are included in a standard BMC Server Automation installation.
3 In the contents pane, right-click the custom nexec command you want to delete.
From the pop-up menu, select Delete. A dialog box prompts you to confirm the
deletion.
4 Click Yes.
You can specify whether an audit trail entry is recorded every time a user is
successfully authorized for an action, every time a user is denied authorization, or
both. Audit trail settings apply globally throughout BMC Server Automation.
For information about viewing the audit trail for a system object, see Audit Trail
view on page 117.
3 Select an authorization, right-click, and select Open from the pop-up menu. A
properties dialog box opens.
4 Check Success to log information every time this authorization is requested and
the authorization is granted. Check Failure to log information each time this
authorization is denied.
To send email notifications, check Send email to and enter the email address of
the accounts that should be notified based on a successful authorization.
Separate multiple email addresses with semicolons, such as
[email protected];[email protected].
To send SNMP trap notifications, check Send SNMP trap to and enter the
name or IP address of the server that should be notified based on an
authorization success. Alternatively, you can click Browse and use the
Select Server dialog box to choose a server.
6 Click OK.
Authorization profiles provide an easy way to assign complex sets of system and
command authorizations. For example, you could set up authorization profiles that
grant authorizations to read all objects or to execute all jobs.
Alternatively, you can copy and paste an existing authorization profile and then
modify the properties of the copied profile. See Modifying authorization profiles on
page 183.
4 To close the wizard and save your changes, click Finish at any time.
Field definitions
Name
Identifying name.
Description
SystemCommand
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
To move your selections to the Selected Authorizations list, click the right
arrow.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
1 Open the RBAC Manager folder, expand the Authorization Profiles node, and
navigate to an existing authorization profile.
Right-click the authorization profile and select Open from the pop-up menu. A
tab opens showing the authorizations chosen for he profile. Modify the
contents of this list. (For more information, see Authorization profile
Authorizations on page 181.)
Select the Properties, Permissions, or Audit Trail tab group to see or modify
any of properties, permissions, or audit trail information that apply to the
authorization profile.
Each entry in the ACL template grants permissions to a role based on individual
system or command authorizations or an authorization profile. ACL templates let
you set up complex access control lists that you can use repeatedly. You can use an
ACL template in the following contexts:
Granting default permissions to any system object created by a role (see Creating
roles on page 210).
Updating permissions for a group of system objects (see Updating permissions for
one or more system objects on page 235).
When you define entries in an ACL template, you can assign authorizations to a
special role called Current Role. This role grants permissions to the current role
when that role creates an object. To use this functionality, you must designate the
ACL template containing the Current Role authorizations as the object permissions
template for a role (see Creating roles on page 210). After being assigned to a role,
each Current Role authorization is automatically translated into permissions for that
action for the current role. For example:
2 You specify the ACL template as the object permissions template for a role.
3 That role creates an Audit Job. The role is automatically granted the AuditJob.*
permission for the job.
You can also use the Current Role functionality when assigning object-based
permissions. If you assign an ACL template containing Current Role authorizations
to an object and the ACL template contains a Current Role authorization for the type
of object you are defining, your current role automatically receives that authorization
for the current object. Using Current Role authorizations in an ACL template is an
easy way to give the creator of an object permission to use that object without having
to revise an ACL template for each role.
Use the following procedure to create an ACL template. Alternatively, you can copy
and paste an existing ACL template and then modify the properties of the copied
template. See Modifying ACL templates on page 189.
2 Create a new ACL template by right-clicking and selecting New => ACL
Template from the pop-up menu. The Create New ACL Template wizard
appears.
3 Provide information for the ACL template as described in the following sections:
4 To close the wizard and save changes, click Finish at any time. To close the ACL
Template Properties window and save changes. click OK.
Field Definitions
Name
Identifying name.
Description
To assign individual system authorizations, click the System tab at the bottom
of the Available Authorizations list. Then, select the system authorizations you
want to make available to the role you chose in the previous step.
To assign authorization profiles, click the Profiles tab at the bottom of the
Available Authorizations list. Then, select the authorization profiles you want
to make available to the role you chose in the previous step.
4 Click OK.
1 Click Use ACL Template . The Select ACL Template dialog box appears.
3 To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates.
If you do not check this option, the contents of the selected ACL templates are
appended to any existing entries in the access control list. Replacing the current
set of permissions with the contents of an ACL template is particularly useful for
promoting a system object between roles.
4 Click OK.
1 Click Use ACL Policy . The Select ACL Policy dialog box appears.
3 To set the contents of the selected ACL policies to replace all entries in the access
control list, check Replace ACL with selected policies.
If you do not check this option, the contents of the selected ACL policies are
appended to any existing entries in the access control list. Replacing the current
set of permissions with the contents of an ACL template is particularly useful for
promoting a system object between roles.
4 Click OK.
Deleting an entry
You can delete an entry.
To delete an entry
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
1 Open the RBAC Manager folder, expand the ACL Templates node, and navigate
to an existing ACL template.
To modify entries in the access control list of an existing ACL Template, right-
click the ACL template and select Open from the pop-up menu. The following
sections describe tabs in the content editor:
ACL template General on page 185
ACL template Template Access Control List on page 185
These tabs correspond to panels in the New ACL Template wizard. Use these
tabs to modify the ACL template.
Select the Properties, Permissions, or Audit Trail tab group to see or modify
any of properties, permissions, or audit trail information that apply to this ACL
template. For more information, see Properties, Permissions, and Audit Trail
tab group on page 115.
Changes you make to an ACL policy immediately become effective for any object
where that ACL policy is applied. If you delete an ACL policy, the system
immediately removes the permissions granted to any object using the ACL policy.
For information about modifying an existing ACL policy, see Modifying ACL
policies on page 195.
2 Create a new ACL policy by right-clicking and selecting New => ACL Policy
from the pop-up menu. The Create New ACL Policy wizard appears.
3 Provide information for the ACL policy as described in the following sections:
4 To close the wizard and save your changes, click Finish at any time.
Field Definitions
Name
Identifying name.
Description
If you use an authorization profile to define an ACL profile, the system uses the role/
authorization pairings listed in the authorization profile and inserts them into the list
of permissions for the ACL profile.
To assign individual system authorizations, click the System tab at the bottom
of the Available Authorizations list. Then, select the system authorizations to
make available to the role you chose in the previous step.
To assign authorization profiles, click the Profiles tab at the bottom of the
Available Authorizations list. Then, select the authorization profiles that should
be available to the role you chose in the previous step.
4 Click OK.
1 Click Use ACL Template . The Select ACL Template dialog box opens.
3 To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates.
If you do not check this option, the contents of the selected ACL templates are
appended to existing entries in the access control list. Replacing the current set of
permissions with the contents of an ACL template is particularly useful when
promoting a system object between roles.
4 Click OK.
1 On the Policy Access Control List panel, click Add under the Time Windows
section.
2 Complete the fields in the Time Windows tab as described in the following table.
Option Description
Name Enter the name you want to assign to the ACL policy.
Valid period Select the start and end dates for the time period.
Note: The end date is not inclusive. If you define a maintenance
window for an object, the system does not grant access to that object on
the end date, even if the maintenance window begins on an earlier date
and extends into the end date.
Time window Select the start time and the duration (in hours) for the time period,
which defines when the maintenance window for the server is open.
Note: For Start time, enter a time in 24-hour format, relative to the time
zone you select using the Time zone list at the bottom of the tab.
Option Description
Repetition Select how often the maintenance window is open. Select one of the
following options:
Daily
Time zone Select your time zone from the drop-down list.
a Click the Add Entry icon. The Add New Entry window opens.
b From Role, select a role to which you want to grant permissions to execute
against the maintenance window.
c Under Available Authorizations, grant the desired authorizations for the role,
for example SnapshotJobExecute.
To execute a job during a maintenance window, right-click the job, choose Add
permissions, and apply the ACL policy containing the maintenance window to
the job.
Deleting an entry
You can delete an entry.
To delete an entry
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
1 Open the RBAC Manager folder, expand the ACL Policies node, and navigate to
an existing ACL policy.
To modify an existing ACL policy, right-click the ACL policy and select Open
from the pop-up menu. The following sectopms descrobe tabs in the content
editor:
ACL policy General on page 190
ACL policy Policy Access Control List on page 190
These tabs correspond to panels in the New ACL Policy wizard. Use these tabs
to modify the ACL policy.
Select the Properties, Permissions, or Audit Trail tab group to see or modify
any of properties, permissions, or audit trail information that apply to this ACL
policy.
You can define an automation principal to access a server running any supported
operating system. Some common uses for automation principals are:
Windows user mappingMap one or more RBAC roles to a local or domain user
on a managed server.
You may need to create an automation principal that provides credentials for a
superuser on UNIX systems. A superuser automation principal is the same as any
other automation principal. It simply includes credentials for a superuser.
Note
Only servers running BMC Server Automation version 8.0 or later can recognize
automation principals. Only Windows servers running BMC Server Automation
version 8.0 or later can recognize automation principals used for Windows user
mapping.
If you are creating an automation principal for Windows user mapping, your
Application Server environment should be configured to use a Network Shell proxy
server. For a detailed description of that configuration, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Setting+up+a
+Network+Shell+proxy+server.
4 To close the wizard and save your changes, click Finish at any time.
Field Definitions
Name
Identifying name.
Description
Principal ID
Enter the name of the account to which a role should be mapped. For
example, you might enter Administrator.
Note:
If you are using an automation principal for Windows user mapping, the
account you identify in this step must be granted the Windows Logon as
a batch job privilege on each Windows server. To access this setting, use
the Control Panel and go to Administrative Tools\Local Security Policy
\Local Policies\User Rights Assignment. If you are using an automation
principal for agent installation, you must grant the Logon as a batch job
privilege to this account on the PsExec server.
Domain
Enter the name of the domain that the user being impersonated uses for
logging on to Windows.
The domain is optional. If the logon account is local to the managed server,
do not enter a domain.
Passphrase
This panel is only necessary if you are setting up an automation principal for
Windows user mapping purposes. If you are setting up an automation principal for
other purposes, such as agent installation, you can skip this panel.
Role Associations
Move roles from the list of available roles on the left to the list of selected
roles on the right. Selected roles are roles that are associated with this
automation principal.
Click to have the Available Roles list show only roles that are not currently
associated with automation principals or properties.
Click to have the Available Roles list show all roles, including roles that are
currently associated with automation principals or properties. If you show all
roles and then assign a role that is currently associated with another
automation principal or a property, the role is removed from its current
assignment and associated with this automation principal.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
1 Open the RBAC Manager folder, expand the Automation Principals node, and
navigate to an existing automation principal.
Select the Properties, Permissions, or Audit Trail tab group to see or modify
any of properties, permissions, or audit trail information that apply to this
automation principal.
You can also map a role to an automation principal by means of a server property.
By doing this, you can assign automation principals on a server-by-server basis, even
while the same role is accessing those servers.
For details on this procedure, see Creating automation principals on page 195. If
your system is set up to use default permissions, you must be logged on as
RBACAdmin to perform this step.
2 Using the Property Dictionary, create a property in the Server property class. The
property can be named anything. The property must be of the type Property
Class, and the property must reference the property class called
AutomationPrincipal.
3 In the Servers folder, select the servers where you want to map automation
principals. On each server, right-click and select Set Property. The Set Role
Property dialog box opens. (To select multiple servers, you must display them
using the Group Explorer option.) Set the value of the property to the name of the
automation principal you created in the first step.
For more information about setting property values, see Changing property
values for one or more system objects on page 161.
4 Associate a role with an automation principal by mapping the role to the server
property you defined in earlier in this procedure. Use the Agent ACL tab of the
role definition to perform this mapping.
For more information about mapping roles to properties, see Role Agent ACL
on page 213. If your system is set up to use default permissions, you must be
logged on as RBACAdmin to perform this step.
Obtain the certificate needed to secure the connection between the Application
Server and the LDAP server. For more information about obtaining this certificate,
see Obtaining a certificate used to trust the LDAP server on page 203.
2 Create a new LDAP connection by right-clicking and selecting New => LDAP
Connection.
4 Click Finish at any time to close the wizard and save your changes.
Field Definitions
Name
Identifying name.
Description
Server
The URL of the LDAP server. Enter the URL using any of the following formats:
hostname
ipAddress
ldap://hostname : port
ldap://ipAddress : port
If you use either of the first two formats, the system assumes a port number
of 389.
If you check this option, the system compares the host name included in the
certificate that the LDAP server presents when connecting with the
Application Server to the host name specified in the URL of the LDAP server
(provided in the Server option).
Certificate
Specifies the certificate on the client that can be used to ensure trust when
establishing a connection with the LDAP server. Click Browse and navigate
to the file containing the certificate to be associated with the LDAP connection.
To select files of type .pem, you must choose the All Files filter.
After you have specified the certificate, you can click Details to show
detailed information about the certificate.
The certificate in the trust store should be the issuing certificate for the LDAP
servers certificate. If the LDAP server is provisioned with a certificate chain, the
certificate that you import should be the issuing certificate for the top of the
certificate chain.
You can obtain the certificate from a CA, or you can use the blcred utility to retrieve
the LDAP servers certificate and store it in file form. When setting up the LDAP
connection, you can choose the file obtained from a CA or the file generated by blcred.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
1 Open the RBAC Manager folder, select LDAP Synchronization => LDAP
Connections, and select an existing LDAP connection
To modify information defining the server used for an LDAP connection, right-
click the LDAP connection and select Open. The content editor displays a tab
showing details for this LDAP connection. For more information about these
options, see LDAP Connection General on page 202.)
Select the Properties, Permissions, or Audit Trail tab group to see or modify
any of properties, permissions, or audit trail information that apply to this
LDAP connection.
When preparing to synchronize with an LDAP user registry, you need to define two
queries: one to identify groups and a second to identify the users in those groups.
1 In the RBAC Manager folder, select LDAP Synchronization => LDAP Queries.
2 Create a new LDAP query by right-clicking and selecting New => LDAP Query.
3 Provide information for the LDAP query, as described in the following sections:
4 Click Finish at any time to close the wizard and save your changes.
Typically you set up two queries, one to identify specific groups in the LDAP
hierarchy and another to identify the users in those groups.
For a general discussion and examples of how to form LDAP queries based on the
information you provide in this panel, see LDAP query basics on page 207.
Field Definitions
Name
Identifying name.
Description
The top level of the LDAP directory tree that you want to query. Identify that
top level in terms of a distinguished name (DN).
Filter
Attribute
A value that distinguishes the type of information the query is searching for.
Typically, if you are searching for groups of users, the attribute would be
member. The attribute for individual users would be userPrincipalName.
Base distinguished name (DN)Identifies the top level of the LDAP directory
tree. For example, when querying users, you could create a base DN such as
FilterSpecifies one or more attributes that must be fulfilled. If you are creating a
query for user information, a typical filter might be objectClass=user. For a group,
a typical filter is objectClass=group.
AttributeNarrows the type of data for which the query is searching. If you are
creating a query for user information, a typical attribute is userPrincipalName.
For a group, a typical attribute is member.
For example, the following queries could be paired to obtain user information from
ADsyncTestGroup and all of its subgroups.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
1 Open the RBAC Manager folder, select LDAP Synchronization => LDAP
Queries, and select an existing LDAP query.
To modify information defining terms of the LDAP query, right-click the LDAP
query and select Open. The content editor displays a tab showing details for
this LDAP query. For more information about these options, see LDAP
Connection General on page 202.)
Select the Properties, Permissions, or Audit Trail tab group to see or modify
any of properties, permissions, or audit trail information that apply to this
LDAP query.
Creating roles
A role defines a set of authorizations and other information that reflects the
capabilities of an organizational entity.
For example, you can create a role for QA testers, web administrators, or application
developers. Each of these roles has a different set of permissions. When users are
assigned to a role, they are granted the permissions defined for that role. Users can
be assigned to multiple roles, but a user can only assume one role at a time.
Roles let you tailor permissions to the tasks a group usually performs. Even though a
user may function in one context where he or she needs a full set of permissions, in
other contexts that same user may not need such sweeping privileges. In such a
situation, the user can easily switch roles, so he or she always operates with the
appropriate level of authorization.
When defining authorizations for a role, you specify authorizations that apply
throughout BMC Server Automation whenever that role performs a particular type
of action. For example, if you grant a role the DeployJob.Read authorization, that
role is always capable of reading Deploy Jobsassuming the role is also granted
permission to read an individual Deploy Job object. (For more information about the
interactions between authorizations, see Authorization overview on page 165.)
When defining a role, you can specify an ACL template that functions as an object
permissions template. When a role creates an object, any permissions defined in the
object permissions template are automatically applied to the object being created.
For example, if the ACL template grants a role DeployJob.* (that is, full authority to
do anything with Deploy Jobs), that role is granted DeployJob.* whenever the role
creates a Deploy Job object. For more information about ACL templates, see Creating
an ACL template on page 184.
When you add users to a role, delete users, or change settings on the Agent ACL
panel of a role, you should run an ACL Push Job for all servers to which that role has
been granted access. The ACL Push Job uses information from the role definition to
translate the ACL for each server into a users configuration file on that server. For
more information about pushing ACLs, see Agent ACL description on page 240.
Use the following procedure to create a role. Alternatively, you can copy and paste
an existing role and then modify the properties of the copied role. See Modifying
Roles on page 218 for information about modifying an existing role.
To create a role
2 Create a new role by right-clicking and selecting New => Role from the pop-up
menu. The Role Creation wizard appears.
3 Provide information for different aspects of the role, as described in the following
sections:
4 Click Finish at any time to close the wizard and save your changes.
Role General
The General panel lets you provide a name and description for the role, choose an
object permissions template, and assign system authorizations, command
authorizations, and authorization profiles to the role.
You can grant varying levels of system authorizations to a role. For example, Server.*
authorizes a user to perform all possible actions relating to servers. AuditJob.*
authorizes a user to perform all possible actions relating to Audit Jobs. You can also
choose to authorize more specific classes of actions. For example, AuditJob.Read lets
a user view Audit Jobs. For a full listing of all possible system authorizations, see
System authorizations on page 1477.
Similarly, you can grant authorizations to perform specific Network Shell and nexec
commands. If you do not authorize specific commands, a role faces no restrictions
when using commands. In other words, a user who assumes that role can perform
any command. If you do assign commands to a role, users who assume that role are
restricted to those commands.
Note
If you change authorizations for a role while a user is active, the console may give
the appearance of that user being incorrectly authorized or not authorized for certain
actions. The console will not correctly display all changed user options until the user
exits and logs on again. Although the console may give the appearance of incorrectly
displaying some options, the correct authorizations are always in effect at the
Application Server. Thus the user can never perform an action for which he or she is
not authorized.
Field Definitions
Name
Identifying name.
Description
If you do not specify an object permissions template, the role is granted full
permission to any object that the role creates. For example, when creating a
BLPackage, the role is granted BLPackage.*. For more information about
defining an ACL template, see Creating an ACL template on page 184.
System Commands
To grant the role individual system authorizations, click the System tab at
the bottom of the Available Authorizations list. Then, select the system
authorizations you want to make available to the role.
To assign authorization profiles to the role, click the Profiles tab at the
bottom of the Available Authorization list. Then, select the authorization
profiles you want to assign to the role.
Use Shift-click or Control-click to select multiple items. Click the right arrow
to move your selections to the Selected Authorizations list.
BMC Server Automation allows you to perform certain functions when that
connection is established, and the definitions you provide on this page control those
functions. For example, you can specify that a user with this role has privileges
equivalent to root on the remote server. You can associate a Windows automation
principal with a role. Or, you can specify that a user with this role only has access to
a particular directory on the remote server.
The Agent ACL panel provides most of the same functionality as the users
configuration file on an RSCD agent. For more information about the users file, see
BMC technical documentation at https://docs.bmc.com/docs/display/bsa82/Users
+and+users.local+files+overview.
After you have defined a role, you should run an ACL Push Job on servers that the
role is authorized to access. The ACL Push Job copies ACL information derived from
the role definition and uses it to overwrite the users configuration file. After you
have pushed ACL information to an agent, the settings you have defined for the role
are used to control all incoming connections to that agent. For more information
about pushing ACLs, see Agent ACL description on page 240.
Field definitions
User must exist Check to instruct a server to allow a connection from a user only when an account with
on agent the same user name exists on the server. This option is analogous to the exists option in
the users configuration file.
Allowed Hosts Specify the hosts from which a user can connect to a server. Separate host names with a
colon, such as host1:host2:host3.
Read Only and Specify whether all users in the role are granted either read-only or read/write
Read/Write permission on servers. You cannot use a role to give read-only permission to some users
and read/write permission to others. Use the users.local file to create a more fine-
grained set of permissions. For more information, see BMC technical documentation at
https://docs.bmc.com/docs/display/bsa82/Users+and+users.local+files+overview.
Map to user Check to force a user connecting to a server to have the same permissions as a user with
name that same name on the server. For example, if you check this option and user betty
connects to a server, she will have the same permissions as those already defined for user
betty on the server. If you check this option, a user cannot connect to a server unless an
identical user name is already defined on the server.
Platform Define permissions that vary by platform. Click the UNIX tab and enter the following
Related values as they apply to UNIX servers. Then click the WINDOWS tab and enter the
following values as they apply to Windows servers:
Select Use property and enter a property name or use Select Property , which
displays a list of server properties.
User mapping forces users who have assumed this role to operate with the same
permissions as the user name to which they are mapped. For example, you might enter
root or anon for UNIX systems or Administrator or Guest for Windows. If you do not
specify a user name to which incoming connections should be mapped and you have not
checked the Map to user name flag, RBAC automatically maps each incoming user to a
user with the same name on the server. For example, incoming user joe is
automatically mapped to user joe on the server. If joe does not exist on the server, RBAC
maps joe to nobody on UNIX systems and Anonymous on Windows.
Using a property rather than a name allows you to map a role to different user names on
different servers. For example, if you map to a property called ADMIN_USER, that
property could be defined as Administrator on one server and a different name on
another server. If you specify a property that identifies an automation principal, the role
of the incoming user is mapped to the user specified in the automation principal. For
more information on mapping to an automation principal, see Using server properties to
map automation principals for Windows user mapping on page 200.
For more information on user mapping, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Impersonation+and+privilege+mapping.
Root DirectoryEnter the highest directory that the user can see. The user will be able to
see that directory and all of its subdirectories. This option applies exclusively to Network
Shell-only user entries that are generated and pushed to agents. The Root Directory
option is analogous to the rootdir option in the users configuration file.
FlagsFor UNIX, the following flags are available:
Silently ignore setting of setuid and setgid bitsInstructs a UNIX server to prevent
users from setting the setuid or setgid bits when creating a file or changing a files
permissions. This option is analogous to the nosuid option in the users configuration
file. It is only available on the UNIX tab.
Fail on mknod(2) system callInstructs a UNIX server to prevent users from making
calls to the mknod system call. This option is analogous to the nomknod option in the
users configuration file. It is only available on the UNIX tab
Role Users
The Users panel lets you choose users that should be assigned to this role.
For example, if you have created a role for junior administrators, you can use this
panel to assign any users who should function as junior administrators to the role.
You can also assign a role to a user when you create that user.
Note
To manage users with this panel, your current role must be assigned the
Role.ManageUsers authorization and the role you are currently modifying must also
be assigned the Role.ManageUsers authorization. If both of these conditions are not
true, the arrows that allow you to move users between columns are dimmed.
Field Definitions
Available Users, Selected Users
In the list under Available Users, select users who should assume this role
and click the right arrow, which moves your selections to the Selected Users
list on the right.
Role Summary
The Summary panel lets you review the choices you have made while defining this
role. You can review those choices before finalizing your decisions for the role
definition. If you assigned an authorization profile to this role, the Summary panel
lists the authorizations defined in that profile and identifies the profile as the source
of that authorization.
Role Properties
The Properties panel provides a list of properties automatically assigned to an object.
In this list you can modify the value of any properties that are defined as editable.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
Role Permissions
The Permissions list is an access control list (ACL) granting roles access to any
objects created in the system, such as jobs, servers, or depot objects.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
Modifying Roles
You can modify an existing role.
To modify a role
1 Open the RBAC Manager folder, expand the Roles node, and navigate to an
existing role.
To modify an existing role, right-click the role and select Open from the pop-up
menu. The following sections describe tabs in the content editor:
Role General on page 212
Role Agent ACL on page 213
Role Users on page 216
Role Group Mappings on page 219
Role Summary on page 216
These tabs correspond to panels in the New Role wizard. Use them to modify
the role definition.
The Group Mappings panel is only available when you are editing an existing role.
The Role wizard does not display this panel when you are creating a new role.
Define an automation principal that will be used for accessing the LDAP server. For
more information about creating automation principals that can be used when
obtaining information from an LDAP server, see Synchronizing users with LDAP
servers on page 227.
Field Definitions
Add or Modify
Click Add to create a new group mapping or select an existing mapping and
click Modify. The Group Mappings dialog box opens. It gives you the
following options:
LDAP Connection
Automation Principal
Group Query
User Query
If there are existing users assigned to this role and they are not found among the
LDAP users being added to RBAC, you can specify how those users should be
handled. Select any of the following:
Existing users assigned to this role are deleted from the RBAC database. If
you select this option, you cannot select any of the following options.
Existing users assigned to this role are disabled. They continue to be assigned
to this role. If you select this option, you cannot also select the Delete users
not found option.
Existing users are removed from this role but remain in the RBAC database.
If you select this option, you can also select the Disable users not found option.
The user is assigned to the role being synchronized, if he or she is not already
included in that role.
Creating users
Creating a user in RBAC sets up a user account so individuals can access BMC
Server Automation.
The definition of a user includes the users password, and it assigns one or more
roles to the user. For example, you can create a user named mary and assign her
Senior Administrator and Web Administrator roles. You can create another user
named joe and assign him a Junior Administrator Role.
A user can be assigned to multiple roles, but that user can only assume one role at a
time. If a user is assigned to multiple roles, BMC Server Automation forces the user
to select a role when logging on. However, users have the option to change roles
during a session. If you have set up Network Shell to authenticate users via SRP,
those users too are forced to choose a role if they have been assigned to multiple roles.
When you add a user to a role or delete a user from a role, you should run an ACL
Push Job for all servers to which that role has been granted access. The ACL Push
Job uses information from the role definition to translate the ACL for each server
into a users configuration file on that server. For more information about pushing
ACLs, see Agent ACL description on page 240.
Use the following procedure to create a user. Alternatively, you can copy and paste
an existing user and then modify the properties of the copied user. See Modifying
users on page 226 for information about modifying an existing user.
BMC Server Automation also lets you create users by synchronizing your RBAC user
database with an LDAP registry such as Active Directory. For more information, see
Synchronizing users with LDAP servers on page 227.
To create a user
2 Create a new user by right-clicking and selecting New => User from the pop-up
menu. The User Creation wizard appears.
3 Provide information for different aspects of the user, as described in the following
sections:
4 Click Finish at any time to close the wizard and save your changes.
This panel also lets you establish security settings for users who are using SRP
authentication, the default approach to authentication. For a complete description of
how to set up authentication, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Administering+security.
When entering a user name, you can use special characters. However, because RSCD
agents cannot accommodate special characters in user names, all special characters
are automatically encoded for use by RSCD agents. (You can see examples of this
encoding if you examine the users file on a managed server.) To make encoded user
names readable to humans, the system uses standard URL encoding for the
following special characters.
Character Encoding
% %25
, %2c
: %3a
# %23
space %20
tab %09
Field Definitions
Name
Identifying name.
Description
User is disabled
A disabled user cannot access the BMC Server Automation system until you
enable the user by clearing User is disabled. When you disable a user, that
user is no longer pushed to agents the next time you perform an ACL Push Job.
To specify that a user is not subject to processes that synchronize users in the
RBAC database with external user databases such as Active Directory, clear
User participates in directory synchronization.
Enables the user to authenticate using SRP. If you check this option you must
fill in the SRP Authentication Options listed below.
Check this option if you want to enable the user to authenticate using AD/
Kerberos or Domain Authentication.
Check this option if you want to enable the user to authenticate using LDAP.
Check this option if you want to enable the user to authenticate using RSA
SecurID.
Check this option if you want to enable the user to authenticate using public
key infrastructure.
Check this option to disable this user's account if he or she does not log on
during a specified period of time.
You must use a blasadmin utility to enable a task that runs every 24 hours
and disables inactive users. For more information, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Setting+logon
+requirements. You can also use blasadmin to specify the period of time
during which a user must log on to remain active.
These SRP options apply only if you checked Allow Secure Remote
Password Authentication.
For Password, enter the users password. Then, confirm the password by
entering it again in Retype Password.
To specify that a user must change his or her password the next time he or
she logs on, check User must change password at next logon.
To unlock a user whose logon is locked out, clear User is locked out.
Users are locked out when their logon attempts repeatedly fail and the
number of failed attempts exceeds a certain threshold. To specify that
threshold, use the blasadmin utility to set a value for the
AccountLockoutThreshold option.
This panel also lets you choose a role to which all Network Shell users are assigned.
You should specify a Network Shell role for all users who are expected to use
Network Shell.
Note
To use this panel, your role must be granted the Role.ManagerUsers authorization.
The Available Roles list will show any roles to which your role has been granted
access. If your role is not granted the Role.ManagerUsers authorization, this panel is
blank.
WARNING
System limitations can prevent a user from logging on if you assign the user to more
than 200 roles.
Field Definitions
Available Roles, Selected Roles
In the list under Available Roles, select roles that should be assigned to this
user and click the right arrow, which moves your selections to the Selected
Roles list on the right. Use Control-click or Shift-click to select multiple items.
Use the left arrow to remove an item from the selected list.
From Default Network Shell Role , select the role to which all Network Shell
users should be assigned. If you only assign one role to a user, that role
automatically becomes the users default Network Shell role. For more on the
default Network Shell role, see Agent ACL description on page 240.
User Properties
The Properties panel provides a list of properties automatically assigned to an object.
In this list you can modify the value of any properties that are defined as editable.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
User Permissions
The Permissions list is an access control list (ACL) granting roles access to any
objects created in the system, such as jobs, servers, or depot objects.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
Modifying users
You can modify an existing user.
To modify a user
1 Open the RBAC Manager folder, expand the Users node, and navigate to an
existing user.
To modify an existing user, right-click the user and select Open from the pop-
up menu. The following sections describe tabs in the content editor:
User General Information on page 221
User Role Selection on page 224
The tabs correspond to panels in the New User wizard. Use them to modify the
user definition.
When you synchronize users, they are added to the RBAC user database and
assigned to a role. You can reassign users to different roles as needed.
Before you perform this procedure, you can specify whether existing users should be
subject to synchronization by setting the User participates in directory
synchronization option in the New User wizard. For more information, see User
General Information on page 221.
If you plan to synchronize LDAP user information regularly, you may want to
perform that task using a BLCLI command instead of this procedure. The BLCLI
command is:
To synchronize users
1 Ensure that the LDAP server has a certificate installed for secure LDAP
communication.
When defining an automation principal, the value you set for Principal ID must
be a users distinguished name for a privileged directory user. For example, you
might enter
CN=Administrator,CN=Users,DC=company,DC=com
When defining an automation principal, the Domain field is ignored. You must
provide a passphrase for the directory user.
To set up an LDAP connection, you must have the host name or IP address of the
LDAP server and a certificate that can be used to validate the certificate of LDAP
server. For example, if the server MyLDAPServer.mycompany.domain.com hosts
the LDAP server, then enter MyLDAPServer.mycompany.domain.com as the
name of the server. Browse to the certificate file that has either the certificate for
MyLDAPServer.mycompany.domain.com or the CA certificate that signed it.
4 Set up an LDAP query for the groups and users that must be queried and
ultimately registered in RBAC.
You must set up at least two queries: one for identifying an LDAP group and
another for identifying LDAP users. For example, if the LDAP server has a group
called LDAPsyncTestGroup in the OU Test, you must determine the
distinguished name of this group and enter it as the Base Distinguished Name of
the LDAP query. Set Attribute equal to member and Filter equal to
objectClass=group. For the user query, set Attribute equal to
userPrincipalName. Leave Base Distinguished Name and Filter set to their
default values, or you can set Filter to objectClass=user for a faster search.
5 Create the RBAC role that should be synchronized with an LDAP group if the
role does not already exist. Associate an automation principal, an LDAP
connection, and an LDAP group and user query with the role.
6 In the RBAC Manager folder, select Roles and then select the role to which you
have mapped an LDAP connection and LDAP queries (that is, the role set up in
step Step 5 on page 228).
The synchronization process begins. Users in the LDAP registry are added to the
RBAC database and assigned to this role. Depending on how you have set up the
Group Mappings options for the role, any existing users can be deleted, disabled,
or removed from the role.
To perform this procedure with a minimum set of authorizations, you must set up a
role with the permissions described below. For the objects you are acting on, you
must define authorizations as described below.
Role-level authorizations
Role.read
Role.modify
Role.Manageusers
User.*
AutomationPrincipal.read
LdapConnection.read
Object-level authorizations
Type of object Authorization required Additional information
Object-based permissions
BMC Server Automation offers flexibility when assigning permissions to system
objects.
You can define the permissions of an object when you first create it or modify those
permissions later (see Defining permissions for a system object on page 231). You
can also modify permissions for multiple system objects (described in Updating
permissions for one or more system objects on page 235).
Using object-based permissions, you can delegate authority for managing different
objects within BMC Server Automation. For example, a web administrator might be
granted permission to run jobs relating to web servers while database administrators
might be granted permission to run jobs relating to database servers. In the same
manner, you can use permissions to define access to servers and server groups.
See Common issues while using permissions on page 239 for information about
common issues users encounter when defining permissions for system objects.
When creating an object, full access to the object is granted by default to the current
role. However, if you have specified an object permissions template for a role, a list
of permissions can be automatically granted for an object when that object is created.
That list of permissions is derived from an ACL template that you can assign to the
role. For more information about object permissions templates, see Creating roles on
page 210.
When you create or modify a system object, you can specify individual system
authorizations or authorization profiles. If the object is a server, you can add
individual command authorizations. You can also use authorization profiles, ACL
templates, and ACL policies to add multiple entries to the objects ACL.
When defining permissions for a system object, you can assign authorizations to a
role called Everyone. Permissions granted to Everyone are available to all roles in
BMC Server Automation. Using the Everyone role is an easy way to make a system
object public. For example, if you are assigning permissions to a BLPackage and you
grant BLPackage.Read to the Everyone role, any role can read this BLPackage
(assuming that role also has a class-level permission to read BLPackages).
Tip
If a role is deleted from the RBAC Manager folder and that role has permissions for
an object, the ACL for that object is automatically updated to remove the deleted role
from the ACL list. If no other roles are granted permission to the object, remember
that the RBACAdmins role always has permission to read and modify the ACL for
any object in BMC Server Automation.
If you use an ACL template or ACL policy to assign permissions to an object, you
have the option of either merging the permissions in the ACL template or policy
with the objects current list of permissions or replacing the current list with the
permissions included in the ACL template or policy. Replacing the current list is
particularly useful when you promote an object from one role to another. For
example, when software developers complete work on an object such as a Deploy
Job, they typically promote the object to QA. The Developer role might have a
permission such as DeployJob.*. When the Developer role completes work on the
Deploy Job and promotes it to QA, the Developer role no longer needs the same
level of permissions. From then on, it only needs DeployJob.Read. During testing of
the job, the QA role only needs DeployJob.Read and DeployJob.Execute permissions.
These varying permission levels can all be captured in an ACL template or policy,
making it easy to reset permissions for an object when it is promoted between roles.
When you select a system object, the Permissions view lists the current permissions
for that object. You encounter a similar list when using a wizard to create most types
of system objects. The following procedure can be used in either context. This
procedure is referenced by many other procedures that describe how to create or
modify system objects.
1 Display a list of permissions for a system object by doing any of the following:
2 Use the access control list on the Permissions tab or panel to take any of the
following actions:
To assign individual system authorizations, click the System tab at the bottom
of the Available Authorizations list. Then, select the system authorizations you
want to make available to the role you chose in the previous step.
To assign authorization profiles, click the Profiles tab at the bottom of the
Available Authorizations list. Then, select the authorization profiles you want
to make available to the role you chose in the previous step.
Click the right arrow to move your selections to the Selected Authorizations list.
4 Click OK.
1 If you are using the Permissions view to perform this procedure, make sure the
Access Control List tab is selected. It should be selected by default. If you are
using a wizard to perform this procedure, skip this step.
2 Click ACL template to open a dialog box for specifying ACL templates.
4 If you want the contents of the selected ACL templates to replace all entries in the
access control list, check Replace ACL with Selected Templates.
If you do not check this option, the contents of the selected ACL templates are
appended to any existing entries in the access control list. Replacing the current
set of permissions with the contents of an ACL template is particularly useful
when promoting a system object between roles.
5 Click OK.
1 If you are using the Permissions view to perform this procedure, click the ACL
Policy tab. If you are using a wizard to perform this procedure, skip this step.
2 Click ACL Policy to open a dialog box for selecting ACL policies.
4 If you want the contents of the selected ACL policies to replace all entries in the
access control list, check Replace ACL with selected policies.
If you do not check this option, the contents of the selected ACL policies are
appended to any existing entries in the access control list. Replacing the current
set of permissions with the contents of an ACL template is particularly useful
when promoting a system object between roles.
5 Click OK.
1 Click Delete .
If you are using a wizard, select the policy and then click Delete.
If you are using the Permissions view, select the ACL Policy tab, then select the
policy and click Delete.
You can update permissions for all system objects within one or more groups,
folders, or smart groups. You can also select one or more individual system objects
and update permissions for them. Use this procedure to replace the current access
control list for the selected system objects or to append new entries to an existing
access control list for the system objects.
1 Select the system objects for which you want to update permissions. To
accomplish this, do any of the following:
The Update Permissions window opens. The window does not show permissions
already assigned to the selected items.
3 Add, modify, or delete entries in the access control list. This procedure is the same
as the procedure described in Defining permissions for a system object on page
231.
5 Click OK.
The Update Permissions Progress window opens. It lists the system objects where
ACLs are updated.
To make viewing ACLs easier, you can use the ACL Summary view. It lets you see
authorizations using two types of views:
Effective PermissionsA list of effective authorizations for the object. This view
takes into account the combination of role- and object-based authorizations to
show the roles and actions that can actually be performed on the object.
See Authorization overview on page 165 for a more detailed explanation of the
differences between role- and object-based authorizations.
The ACL Summary view lets you filter the authorization information displayed. For
more information about the filters available on this view, see ACL Summary view
filters on page 238.
The ACL Summary view displays authorizations for an object. If the authorizations
for that object change while the ACL Summary view is open, the authorizations in
the summary view are not automatically updated. You can click Refresh to
update the view with the latest authorizations assigned to the object. This
requirement applies when viewing both ACL summaries and effective permissions.
A view opens, showing all authorizations defined for the selected object.
2 To see the combination of role- and object-based authorizations, use the drop-
down list to select Effective Permissions.
The view shows a list of authorizations that take into account the combination of
all object- and role-based permissions.
Using the filters available for every column in the ACL Summary view, you can
restrict the permission information that this view displays.
The view updates to show information that matches the filtering criteria you have
selected.
Role
Lists roles that have been granted permissions in the ACL. You can select an
entry called All Roles, which displays information for all roles that have been
granted permission to this object. Filtering for a particular a role shows the
permissions granted to that role.
Auth
Lists authorizations that are valid for the selected object. You can select an
entry called All Auths, which displays information for all valid
authorizations. Filtering for a particular authorization displays all
authorizations that include the selected authorization. For example, if you
select Server.Read, the authorization Server.* appears because it includes the
Server.Read authorization.
Note
Your selection in this column persists if you close the ACL Summary view
and then re-open it for another object of the same type.
ACL Policy
Lists ACL policies that have been applied to the selected object. You can
select an entry called All Policies, which displays all ACL policies that have
been applied to the select object, or No Policy, which displays no ACL polices.
Maint Window
Lists maintenance windows that are defined in any ACL policies that have
been defined for the object. You can select an entry called All Windows,
which displays all maintenance windows defined for ACL policies assigned
to the object, or No Window, which displays no maintenance windows.
Lists start and stop times for maintenance windows that occur within a range
of time that you specify. The default range is one day, beginning at the
current time and lasting until tomorrow at the same time. Clicking on the
current filtering value displays a dialog box that you can use to specify a new
start and stop time.
The following are common issues users encounter when assigning permissions to
system objects:
To deploy a BLPackage, you must have permissions for both the Deploy Job
(DeployJob.Execute and DeployJob.Read) and the BLPackage (BLPackage.Read).
A role cannot execute a Batch Job containing Deploy Jobs unless the role has both
Read and Execute authorizations on those underlying Deploy Jobs
(DeployJob.Read and DeployJob.Execute).
To cancel any job, a role must be granted both Read and Cancel permissions for
that type of job. For example, to cancel a Deploy Job, you must be granted
DeployJob.Cancel and DeployJob.Read.
A role with Read authorization for a server can see all server activity, snapshot
activity, and audit activity on that server. However, the role cannot open any jobs
or view any snapshot or audit results on that server without Read authorization
for those jobs.
A role with Read authorization for a server can see all components on the server,
but the role cannot see properties of a component without Read authorization for
components (Component.Read).
Permissions needed when browsing a component from Permissions needed when browsing components from
the Components folder or while live browsing a server the Component Templates folder
Component.Browse Component.Browse
Component.Read Component.Read
ComponentGroup.Read ComponentGroup.Read
ComponentTemplate.Read ComponentTemplateGroup.Read
ServerGroup.Read ComponentTemplateFolder.Read
Server.Read ComponentTemplate.Read
ServerGroup.Read
Server.Read
Any authorization granted at the object level must also be granted at the role level.
For example, to deploy a BLPackage, you must have DeployJob.Read,
DeployJob.Execute, and BLPackage.Read at both the object level and the role level.
For more information about the multiple levels of authorization needed to perform
actions in BMC Server Automation, see Authorization overview on page 165.
When you define permissions for a server, you are controlling access to the server
within the BMC Server Automation system. The BMC Server Automation
Application Server enforces these permissions. However, you can also manage
servers using Network Shell and the BLCLI. To completely control access to a server,
you must modify configuration files on each servers RSCD agent.
Several methods exist to control access using agent configuration files. (For an
extended discussion of this subject, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Setting+up+configuration+files. If you are
using Windows user mapping, see Windows user mapping and agent ACLs on page
242.) Typically, you control agent access by letting BMC Server Automation
automatically translate the permissions you have defined for a server in the BMC
Server Automation console into a users configuration file on the agent. You
accomplish this by running an ACL Push Job on a server, which overwrites the users
file for that servers RSCD agent (see Creating ACL Push Jobs on page 243). After
you have pushed ACLs, the users file settings control all incoming connections to
that agent.
When BMC Server Automation generates entries for a users file, it creates an entry
for each user associated with each role that has access to the server. BMC Server
Automation does not generate an entry for disabled users. An entry is formed by
pairing a role and a user using the format role:user. In the example users file shown
below, DBAdmins is the role and george and betty are users assigned to the
DBAdmins role.
For example, in the users file shown above, the users george and betty have their
default Network Shell role set to DBAdmins. In addition to the role:user entries for
george and betty, BMC Server Automation generates entries for george and betty
that are not paired with any role but are based on the same information as the
DBAdmins role. These entries are default Network Shell roles, and they let george
and betty access the server using Network Shell.
The users file that BMC Server Automation pushes to an agent can also include a
nouser entry. Including this entry instructs a server to allow a connection from a
user only when that user has been explicitly defined in the users configuration file.
BMC Server Automation places a nouser entry in the users file of a particular server
if the server property called PUSH_ACL_NO_USERS_FLAG is set to true.
any corresponding settings in the users file. If the users file includes entries that are
not superseded, those entries still apply.
Tip
BMC recommends adding an entry for RBACAdmins:RBACAdmin and
BLAdmins:BLAdmin to the users.local file for every server. Because these roles
cannot be deleted, they provide a way to access a server in case you accidentally
revoke everyone elses permissions for that server. If you choose to rename the
RBACAdmins or BLAdmins roles, the entries you make in the users.local file should
reflect those naming decisions.
Before you push agent ACLs to a server, you can preview the entries to be created in
the users file (see Previewing and pushing agent ACLs on page 242). When you
define permissions for a server, you can also preview agent ACLs (see Adding a
server to the system on page 261.
You can view the ACLs that BMC Server Automation will write into a users
configuration file on the agent of a remote server when you run an ACL Push Job on
that server (see Creating ACL Push Jobs on page 243). For more information about
agent ACL files, see Agent ACL description on page 240.
After you preview ACLs, this procedure gives you the option of pushing ACLs
immediately to the server. This option provides a quick alternative to pushing agent
ACLs by launching an ACL Push Job.
2 Right-click and select Administration Task => Agent ACLs from the pop-up
menu.
A window displays the entries that will appear in the users file on that server
after you push ACLs to the server.
To push ACLs to the selected server without running an ACL Push Job, click
Push. A dialog box asks you to confirm. Click OK. A progress bar shows the
progress of the ACL push. A dialog box announces that the push was
successful, or it lists any failures.
To create an ACL Push Job to push the ACLs you are previewing to a server,
click Schedule Job. The New ACL Push Job wizard opens. For information
about using this wizard, see Creating ACL Push Jobs on page 243.
Typically you run an ACL Push Job on a server when a role granted access to that
server has new user information or you have changed agent ACL information for
that role. For more information about the contents of an agent ACL, see Agent ACL
description on page 240.
If you are using Windows user mapping to control user permissions on agents, you
may not have to use ACL Push Jobs to push ACLs to agents. For more information,
see Windows user mapping and agent ACLs on page 242.
An ACL Push Job generates users file entries that grant a variety of permissions,
including permissions for commands. The job uses the following algorithm to create
users file entries relating to command authorizations:
See Modifying ACL Push Jobs on page 251 for information about modifying an
existing ACL Push Job.
Tip
To prevent a role from using any Network Shell and nexec commands on a server,
you can create a dummy nexec command (see Adding or modifying an nexec
command on page 178). Then, add an authorization for the dummy command to the
definition of a role. Do not add any other command authorizations to the role.
Finally, run an ACL Push Job, which pushes the authorization for the dummy
command to the agents you specify in the job. On those agents, the role is only
authorized to perform the dummy command and no other Network Shell and nexec
commands.
Open the Server folder and select a server. Right-click and select
Administration Task => Agent ACLsfrom the pop-up menu. A dialog box
prompts you to push ACLs immediately or to schedule a job. Click Schedule
Job.
If you prefer, you can push ACLs without scheduling a job. For more
information, see Previewing and pushing agent ACLs on page 242.
Open the Jobs folder and select a job folder. Right-click and select New =>
Administration Task => ACL Push Job from the pop-up menu.
The New ACL Push Job wizard opens.
Field Definitions
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Field definitions
Available Servers
Specify the operating system of the servers you want to select. To display
servers running any operating system, select All.
By Group, By Name
Select servers from a tree or sortable list by doing one of the following:
Click the By Group tab at the bottom of the window. The left panel
displays servers in a hierarchical list arranged by server group. Choose
servers by doing one of the following:
To select all servers within the group, click a server group.
Click one or more servers, if necessary, to expand server groups.
Click the By Name tab at the bottom of the window. The left panel lists
servers by name in a Group Explorer view. Sort servers in ascending or
descending order by clicking on any column header. Click one or more
servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
Click the right arrow to move your selections to the right panel.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see ACL Push Job Scheduling on page 248.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see ACL Push Job Scheduled
Job Notifications on page 248.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing ACL Push Job, open the Jobs folder and
navigate to an existing job. Right-click the job and select Open from the pop-up
menu. The content editor displays a series of tabs, which are described in the
following sections:
ACL Push Job General on page 245
ACL Push Job Targets on page 246
ACL Push Job Default Notifications on page 246
ACL Push Job Schedules on page 247
These tabs correspond to panels in the New ACL Push Job wizard. Use them to
modify the job definition.
A BMC Server Automation system by default provides two predefined roles and
users, including the RBACAdmin and BLAdmin users. Neither of those users can log
on, however, until you have defined a password for them, which is possible with the
bladduser utility.
1 To create a user, do one of the following from the directory where an Application
Server is installed:
The bladduser utility starts and prompts you for a user name.
2 Enter a user name, such as RBACAdmin. The utility prompts you for a password.
3 Enter a password. The utility prompts you to reenter the password. Confirm the
password by typing it again.
Note
When using the bladduser utility, you can pass a user name and password as a
string of parameters, effectively skipping the need to enter user information about
the command line. For example, you can add a user named betty by entering the
following command:
bladduser betty password
user,password
user,password
user,password
where user is a user ID and password is the password associated with that user ID.
Job type level - which changes the default priority for the
job Type
Jobtype.ModifySchedule Change the priority for a scheduled job, or override the job
default while creating the schedule.
Note: The corresponding Jobtype.ModifyPriority and
Jobtype.ModifySchedule authorizations are required.
BL_Administration.ModifyRuntimeJobPriori Change priority of a currently executing job instance. By
ty default, only the BLAdmins role has this authorization.
Note: The highest available priority for a user is controlled
by the MAXIMUM_ALLOWED_JOB_PRIORITY* property
value of that users role, even if that role is granted the
BL_Administration.ModifyRuntimeJobPriority
authorization.
MAXIMUM_ALLOWED_RUNTIME_JOB_PRIORITY*
This property determines the upper bound for the runtime priority of a job,
regardless of the value specified in the job PRIORITY* property value or the job
schedules PRIORITY*.
The default value is JOB.NORMAL_PRIORITY*. You can set this boundary on a per
role basis. For example, you may want to limit the higher priority levels (CRITICAL
and HIGH) to a small set of users with a specific role.
Note
Administrators with the BL_Administration.ModifyRuntimePriority authorization
can override the MAXIMUM_ALLOWED_RUNTIME_JOB_PRIORITY* while
modifying the priority of the running job.
User scenario
Suppose that Deploy Jobs in your environment are configured with a job priority of
normal. However, you want to create a new Deploy Job that you need executed with
a job priority of critical. To change the default priority while creating the Deploy Job,
your active role must contain all of the following authorizations:
Jobtype.Create
Jobtype.ModifyProperties
Jobtype.ModifyPriority
If the Deploy Job is already running, and you want to pause it and change the
priority, you need the following authorizations:
DeployJob.Read
DeployJob.ModifyProperties
DeployJob.ModifyPriority
BL_Administration.ModifyRuntimeJobPriority
To change the priority of a currently executing job instance (including pausing the
job instance), the global role-level authorization
BL_Administration.ModifyRuntimeJobPriority is required. By default, only the
BLAdmins role has this authorization.
Note
The greatest available priority for a user is controlled by the
MAXIMUM_ALLOWED_JOB_PRIORITY* property value of that users role, even if
that role has been granted the BL_Administration.ModifyRuntimeJobPriority
authorization.
BMC recommends that job priority change permission be granted to only a few super-
user roles.
All changes made to a jobs priority are tracked in the audit trail, so that you can
review them and take corrective action if needed.
The following table describes the authorizations needed to use the capabilities of the
Configuration menu.
Installation options
BMC Server Automation provides the following methods for installing agents:
Install one or more agents using the BMC Server Automation ConsoleRun an
Agent Installer Job, which installs agents on one or more servers simultaneously.
For information about the console's agent installation capabilities, see Agent
installation overview on page 260. You cannot use the console to upgrade
existing agents.
Agentless objects
BMC Server Automation can support devices that do not have agents installed. BMC
calls these agentless managed objects (AMOs). Typically, AMOs are used for
virtualization (see Working with virtual environments on page 853), but they are
also commonly used with related products such as BMC Application Automation.
BMC Server Automation manages AMOs through servers equipped with a custom
configuration object that can communicate with the agentless device. BMC refers to
these intermediary servers as AMO proxies.
Run the Unified Agent Installer, which creates the many objects needed to install
agents. This approach requires the following steps:
2 Run the Unified Agent Installer. See Running the Unified Agent Installer on
page 273.
Create the objects needed to install agents. This approach requires the following
steps:
2 Perform the tasks required to create the objects needed to install agents. See
Creating objects for agent installation on page 287.
Note
The agent installation process:
Importing agentless devices. See Importing servers into the system on page
265.
Both procedures give you the option of installing agents when you add or import
the agentless devices. However, you cannot install agents until other prerequisites
are complete.
When you add a server to the system, you have the option of installing an agent on
the server by running an Agent Installer Job. Some preliminary procedures are
required before you can run an Agent Installer Job. For information about those
requirements, see Agent installation overview on page 260.
When you use this procedure to add a server, the server is added to the systems
internal list of managed servers and automatically appears in any smart server
groups whose criteria it matches. When you add a server to a server group, the
server appears in that group. When you add a server to the Servers node, the server
is not added to any server group. If you want to add the new server to a server
group, you must explicitly add the server (see Assigning servers to server groups on
page 333).
To add a new server, your role must be granted the Server.Create authorization. For
more information about granting authorizations, see Access control overview on
page 165.
2 Right-click the Servers node (the top node in the Servers folder) or any server
group. Then select Add Server from the pop-up menu.
3 Provide information for the Add New Server wizard, as described in the
following sections:
4 Click Finish.
The server is added to a server group and it is included in the systems internal
list of servers being managed. The server will now appear in the list of available
servers that you can add to a server group. (See Assigning a server to a server
group on page 334.)
Field Definitions
Name/IP Address
Description
Properties
Allows you to set values for properties associated with this server. For more
information, see Setting values for system object properties on page 161.
If the server is a VMware vCenter server or IBM frame, you should define
values for certain properties that allow the Application Server to
communicate with a web service (VMware vCenter) or HMC (IBM frame)
that accesses the virtual infrastructure. For more details about these
properties, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Home.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To create the text file that lists servers to be imported, follow the formatting
instructions in Server import file format on page 266.
When you import servers into the system, you have the option of installing agents
on the servers by running an Agent Installer Job. Some preliminary procedures are
required before you can run an Agent Installer Job. For information about those
requirements, see Agent installation overview on page 260.
You can import server to the Servers node (the top node in the Servers folder) or a
server group. When you import servers to the Servers node, the system adds those
servers to its internal list of servers being managed. However, the system does not
display the new servers in the server hierarchy so no visible changes occur unless the
imported servers are automatically included in a smart group. After importing
servers to the Servers node, you can manually assign the imported servers to server
groups (see Assigning servers to server groups on page 333).
To import servers, your role must be granted the Server.Create authorization. For
more information about granting authorizations, see Access control overview on
page 165.
To import servers
Right-click the Servers node (the top node in the Servers folder) and select
Import Servers from the pop-up menu.
Right-click a server group and select Import Servers to Group from the pop-up
menu.
2 Provide information for the Import Server wizard, as described in the following
sections:
3 Click Finish.
A background process imports the servers in the list. Depending on how you
have specified behavior for background processes, either a dialog box will display
or the Show background operations icon will appear in the lower right corner
of the console. Both indicate an operation is running in the background.
When the import is complete, a dialog box tells you how many servers were
successfully imported and lists any servers that may have failed to import, along
with a reason for each failure.
Lets you select the file containing the list of servers you want to import. For
information about how to format this list, see Server import file format on
page 266.
File Encoding
The type of character encoding that should be used for exported data, such as
UTF8 or UTF16.
Instructs the system to check the values of the servers' intrinsic properties.
If you do not select this option, the servers will be added to the list of
managed servers but the system will not contact the agent on each server and
retrieve the servers intrinsic properties. As a result, these servers will not be
operational. To make them operational later, you can select each server and
then select Verify from the pop-up menu or run an Update Server Properties
Job on those servers.
Check to instruct the system to install agent on the imported servers. Then
click Browse to navigate to the Agent Installer Job that installs the agents.
For more information, see Creating an Agent Installer Job on page 303.
The first line of the file must contain the column header:
Name
followed by optional comma-separated property names for any properties you
want to set for each server.
Note
Any property name you include in this import file must already exist in the
Property Dictionary. For information about how to add a property to the
property dictionary, see Property Dictionary overview on page 143.
Subsequent lines of the file must contain valid host names for each server you
want to add, followed by optional comma-separated property values for each server.
This first example shows the simplest syntaxyou simply list the host names of the
servers you want to add:
Name
host1
host2
host3
The following example shows how to set the Customer property for each server:
Name,Customer
host1,CustomerA
host2,CustomerB
host3,CustomerC
If you need to include spaces in a property value, you must enclose the property
value in double quotes:
Name,Customer
host1,"Customer A"
host2,"Customer B"
host3,"Customer C"
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
When you add a server to the system, the system sets the server's STAGING_DIR
property to the directory /temp/stage for Windows targets and /var/tmp/stage for
UNIX. During agent installation, the system temporarily copies the files it needs to
the staging directory. When the system has finished installing the agent, it
automatically deletes the files.
The directory specified by the STAGING_DIR property must meet the following
requirements:
It must have enough space to accommodate the installer files that the agent
installation process places there. These installer files can be quite large, often
several hundred megabytes.
The user account that the agent installation process uses to connect to the target
server must have access to this directory. This user account is identified by the
automation principal used during remote host authentication (see Specifying or
modifying information for remote host authentication on page 288).
If the default directory does not meet these requirements, change the STAGING_DIR
property to point to a directory that does meet the requirements.
Obtain agent installation files from the BMC EPD site. See BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Obtaining+the
+installation+files.
The following table provides the names of the files to add for the various platforms
on which you can install agents:
Solaris prerequisites
To install Solaris agents, you must use Solaris packages, which are available in .gz
format from BMC. Before you can add one of these Solaris packages to the Depot,
you must uncompress it (using gunzip or the equivalent). Attempting to create a
Solaris package from one of these .gz files directly does not work.
1 Use the Add Depot Software wizard to add an agent installation package to the
Depot. To launch the wizard, navigate to a depot folder, right-click, and select
New => Software => software_type where software_type refers to one of the
following platform-specific types:
MSI Package
Solaris Package
RPM
AIX Package
2 Use the wizard to navigate to a directory containing the installation files you
obtained from the BMC EPD site.
For more information about using the Add Depot Software wizard, see Adding
software to the Depot on page 482.
In the Select Installable Sources window, make sure Upload source to File Server
is selected. This is the default and is required for running an Agent Installer Job.
When you install a Windows agent, you use an MSI installation package by
default. For more information about installing a Windows agent, see BMC
technical documentation at BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Installing+an+RSCD+agent+%28Windows
%29. Agent Installer Jobs perform an unattended installation of agent packages.
To set up an unattended installation of an MSI package, see https://docs.bmc.com/
docs/display/bsa82/Using+silent+mode+to+install+an+RSCD+agent+
%28Windows%29.
For more information about installing the agent with an RPM installation
package, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Using+RPM+to+install+NSH+or+the+RSCD+agent. Agent
Installer Jobs perform an unattended installation of agent packages. To set up an
unattended installation of an RPM installation package, see https://docs.bmc.com/
docs/display/bsa82/Configuring+environment+settings+for+the+package+or
+RPM+installer.
If you are adding a Solaris package to the Depot, you must perform additional
steps in the Support Files section of the Add Software panel:
For more information about installing the agent with a Solaris installation
package, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Using+the+Solaris+SVR4+package+installer+to+install+NSH
+and+the+RSCD+agent. Agent Installer Jobs perform an unattended installation
of agent packages. To set up an unattended installation of a Solaris installation
package, see https://docs.bmc.com/docs/display/bsa82/Configuring
+environment+settings+for+the+package+or+RPM+installer.
For more information about installing the agent with an AIX installation package,
see BMC technical documentation at https://docs.bmc.com/docs/display/bsa82/
Using+AIX+BFF+to+install+NSH+or+the+RSCD+agent. Note that you cannot
change the default installation path or other local settings for AIX agents.
2 Using the BMC Server Automation Console, add the server to the Servers folder.
3 Ensure that the agent is running and that you can browse the contents of the
server.
4 Download PsExec.
6 If you are installing agents on Windows servers using a domain account, the
account must be granted the Windows Logon as a batch job privilege on the
PsExec server.
When an Agent Installer Job runs, the Application Server must access the PsExec
server. To accomplish this, the Application Server uses the account information
defined in an automation principal that the remote host authentication specifies.
If the account information is a domain account, the account must be granted the
Windows Logon as a batch job privilege on the PsExec server.
To access the Logon as a batch job setting, use the Control Panel on the PsExec
server and go to Administrative Tools\Local Security Policy\Local Policies\User
Rights Assignment.
7 To confirm that the PsExec server is functioning correctly, update the status of a
remote host authentication that is based on the PsExec protocol. See Managing
remote host authentication for agent installations on page 1011.
The Unified Agent Installer is a wizard that steps you through the entire process
needed to install agents on multiple agentless devices. The Unified Agent Installer
creates the following objects, which are all necessary to install agents:
Agent bundle
Remote host authentication (for Windows targets, non-Windows targets, or both)
Remote host authentication rules
Agent Installer Job
The Unified Agent Installer gives you the option of running the Agent Installer Job
immediately. If you do not choose this option, you can define the Agent Installer Job
at some later point to run at your convenience.
You can perform other functions in the console without closing the Unified Agent
Installer. This capability allows you to perform prerequisite actions while the
Unified Agent Installer remains open.
When you finish running the Unified Agent Installer, it creates the objects needed for
agent installation. Afterwards, you cannot edit the choices you made in the Unified
Agent Installer, although you can edit the objects that Unified Agent Installer created.
process requires you to create the necessary objects before you can create and
execute an Agent Installer Job, which actually installs agents.
Before you can run the Unified Agent Installer, you must perform preliminary tasks,
as described in Preliminary tasks for installing agents on page 261.
Required authorizations
See Authorizations for the Unified Agent Installer on page 275 for a complete list
of authorizations required to launch and use the Unified Agent Installer.
2 Provide information for the Unified Agent Installer, as described in the following
sections:
The Unified Agent Installer creates all objects necessary to install agents. If you
defined the Agent Installer Job to run immediately, the job runs now. If you did
not select that option, you can execute the job at your convenience (see Executing
a job on page 612).
AgentBundle.Create
AgentBundle.Read
AgentInstallerJob.Create
AgentInstallerJob.Read
DepotFolder.Read
DepotFolder.Write
JobFolder.Read
JobFolder.Write
BL_Administration.Read
RemoteHostAuthentication.Read
RoutingPolicy.Read
Object permissions
The following permissions must be assigned to objects used by the Unified Agent
Installer:
JobFolder.Read, JobFolder.Write on the job folder used to store the Agent Installer
Job
Server.Read on any server selected as a target for the job, either directly or
through a group
Server.AgentInstall on any server selected as a target for the job, either directly or
through a group
Server.PushACL on any server selected as a target for the job, either directly or
through a group (assuming you have chose to push ACLs to target servers)
Field Definitions
Name
Provides a prefix that is prepended to the name of all objects that Unified
Agent Installer creates.
Field Definitions
Platform list
Select each platform and click Edit , which opens the Select depot object
window. Navigate to the agent installer package to use when installing an agent on
the selected platform.
If you have not previously added agent installer packages to the Depot, see Adding
agent installer packages to the Depot on page 269.
Select each platform and click Edit . The Modify Agent Bundle Configuration
window opens.
This window lets you define settings for the following configuration files:
exports Sets access permissions for client machines that communicate with a
server.
secure Sets communication parameters that define how client and server
machines communicate.
See Defining configuration file settings on page 279 for instructions on using the
Modify Agent Bundle Configuration window.
This procedure is optional. If you do not define configuration file settings, default
settings are applied to each newly installed agent. If you do make changes, the
configuration files that you define are copied to the agent during execution of the
Agent Installer Job.
For more information about settings for configuration files, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Setting+up
+configuration+files.
Use care when defining non-default configurations. The installation process does not
validate configuration settings. An incorrect setting can prevent an agent from
starting or block users from accessing the agent.
1 For the exports, users.local, or secure file, enter the appropriate configuration file
setting, or do any of the following:
To import text into the text box, click Import. The Select File dialog box opens.
Use it to navigate to a file that contains the text you want to use.
To edit existing text, click Edit. A dialog box for editing opens.
2 Apply the settings you have defined for the exports, users.local, and secure files
by selecting the applicable platforms in the Apply To list. Use the right arrow to
move your selection to the list at right.
The Remote Host Authentication (non-Windows) panel only displays if you have
chosen to install agents on a platform other than Windows.
Note
If remote host authentications have been defined outside of the Unified Agent
Installer, you cannot edit or delete them. To edit or delete one of these remote host
authentications, use the Infrastructure Management window.
The Remote Host Authentication (non-Windows) window lets you provide the
following information, which is used for authenticating to agentless devices. If you
are installing on multiple platforms, typically you define at least one set of
authentication information for each platform.
Create new automation principal Select this option. Then, provide a user
name and password for the automation principal.
Select existing automation principalSelect this option and then click Browse
to navigate to an automation principal that should be used for the superuser.
Create new automation principal Select this option. Then, provide a user
name and password for the automation principal that should be used for the
superuser.
The Remote Host Authentication (Windows) panel only displays if you have chosen
to install agents on a Windows platform.
Click Add to open the Add Remote Host Authentication (Windows) window, or
select an existing remote host authentication and click Edit .
Note
If remote host authentications have been defined outside of the Unified Agent
Installer, you cannot edit or delete them. To edit or delete one of these remote host
authentications, use the Infrastructure Management window.
The Remote Host Authentication (Windows) window lets you provide the following
information, which is used for authenticating to agentless devices. If you are
installing on multiple platforms, typically you define at least one set of
authentication information for each platform.
Select existing automation principalSelect this option and then click Browse
to navigate to an automation principal.
Create new automation principal Select this option. Then, provide a user
name and password for the automation principal. Optionally, you can identify
a domain for the user.
Click Add to open the New Rule wizard, or select an existing remote host
authentication rule and click Edit .
The New Rule wizard provides two panels, described in the following sections:
After you create more than one rule, you can use icons on this panel to rearrange
their order. The Agent Installer Job tries remote host authentications rules in the
order you establish here.
Note
To create, modify or delete remote host authentication rules, your role must be
granted the following authorizations:
RemoteHostAuthentication.*
BL_Administration.Read
RoutingPolicy.Read
RoutingPolicy.Modify
Agent Options
If an agent is successfully installed, the actions you select below are performed.
Update the system with properties from the target servers on which you are
installing agents.
Register any configuration objects that are found on the agent and defined in
the Configuration Object Dictionary.
To push ACLs, the system converts the access control list defined for a server
into a users configuration file and pushes that file to the agent. The access
control list is derived from user permissions defined in the RBAC system.
Job Options
Preserve Staging Area On Failure
Field definitions
Available Servers
Specify the operating system of the servers you want to select. To display
servers running any operating system, select All.
By Group, By Name
Select servers from a tree or sortable list by doing one of the following:
Click the By Group tab at the bottom of the window. The left panel
displays servers in a hierarchical list arranged by server group. Choose
servers by doing one of the following:
To select all servers within the group, click a server group.
Click one or more servers, if necessary, to expand server groups.
Click the By Name tab at the bottom of the window. The left panel lists
servers by name in a Group Explorer view. Sort servers in ascending or
descending order by clicking on any column header. Click one or more
servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
Click the right arrow to move your selections to the right panel.
Execute on approval
This option only appears when a BMC Server Automation administrator has
specified that an Agent Installer Job requires BMC Remedy ITSM approval prior to
execution.
When approval is required, select the Execute on Approval option, and then select
an Approval type. Optionally, you can select to use an existing change ticket for
approval.
For more information, see Executing a job with BMC Remedy ITSM approval on
page 617.
Agent bundles
Automation principals
The Required Properties panel always appears if agent bundles or Agent Installer
Jobs require a user-defined property for which no default value exists. The Unified
Agent Installer creates an agent bundle and an Agent Installer Job, and it must be
able to provide a value for the required property.
The Required Properties panel also appears if you create a new automation principal
as part of the Unified Agent Installer process and the automation principal requires a
user-created property without a default value. If you specify an existing automation
principal while running the Unified Agent Installer, the Required Properties panel
does not appear.
When the Required Properties panel appears, select each property listed under
Missing Property Name. Then click Change Property Mapping . An editable
field appears under <local>. Take one of the following actions:
Instead of following the process described below, you can run the Unified Agent
Installer, which is a wizard that steps you through the process of creating all objects
necessary to install agents on agentless devices. See Running the Unified Agent
Installer on page 273.
Before you can perform the tasks listed below, you must perform preliminary tasks,
as described in Preliminary tasks for installing agents on page 261.
For each type of device on which you want to install agents, provide information
that is needed to access the device. See Specifying or modifying information for
remote host authentication on page 288.
Remote host authentication rules specify which servers use the remote host
authentication information defined in the previous step. See Creating or
modifying rules for remote host authentication on page 293.
An agent bundle maps target platform types to the corresponding agent installers
located in the Depot. Optionally, the agent bundle can also specify the contents of
agent configuration files. See Creating an agent bundle on page 296.
The Agent Installer Job identifies an agent bundle and targets devices on which
agents must be installed. See Creating an Agent Installer Job on page 303.
You can run an Agent Installer job by doing any of the following:
Schedule the job or run it immediately. See Agent Installer Job Schedules
on page 310.
Invoke the job by adding an agentless device. See Adding a server to the
system on page 261.
Invoke the job by importing agentless devices. See Importing servers into the
system on page 265.
If you are installing on multiple platforms, you typically define at least one set of
authentication information for each platform.
See modify the information you provide for a remote host authentication, see To
modify existing information for remote host authentication on page 291.
Create automation principals, which specify user credentials that can be used to
access remote hosts. For more information about automation principals, see
Creating automation principals on page 195.
Required authorizations
To create a remote host authentication, your role must be granted the following
authorizations:
BL_Administration.Read
RemoteHostAuthentication.Read
RemoteHostAuthentication.Create
AutomationPrincipal.Read (to access automation principals specified in this
procedure)
Server.Read on the PsExec server, if you are specifying a remote host
authentication for Windows
Name
Name for this set of authentication information. You can enter any name. The
BMC Server Automation system uses the name for identification and display
within the system.
Description
Specifies the mechanism for accessing an agentless device. Select one of the
following:
PsExec Server
BMC recommends that when you install agents on Windows 7 and Windows
2008 devices that are not enabled for a domain, specify a PsExec server that is
not part of a domain. When you install agents on Windows 7 and Windows
2008 devices that are enabled for a domain, specify a PsExec server that
belongs to the same domain. Ensure that the automation principals you are
using to access the agentless devices are associated with the same domain.
For more information about the PsExec server, see Setting up a PsExec
server on page 272.
Specifies the maximum number of PsExec connections that the PsExec server
can run simultaneously. By default this option is set to 20.
You can set a level of parallel execution for the Agent Installer Job with the
"Number of targets to process in parallel" option. (See Agent Installer Job
General on page 306). Regardless of that level, no active PsExec server ever
exceeds the level of parallelism set with Maximum Execution Parallelism
option.
Automation Principal
4 Click Finish. The Infrastructure Management window lists the remote host
authentication you created.
Name
Name for this set of authentication information. You can enter any name. The
BMC Server Automation system uses the name for identification and display
within the system.
Description
Specifies the mechanism for accessing an agentless device. Select one of the
following:
PsExec Server
BMC recommends that when you install agents on Windows 7 and Windows
2008 devices that are not enabled for a domain, specify a PsExec server that is
not part of a domain. When you install agents on Windows 7 and Windows
2008 devices that are enabled for a domain, specify a PsExec server that
belongs to the same domain. Ensure that the automation principals you are
using to access the agentless devices are associated with the same domain.
For more information about the PsExec server, see Setting up a PsExec
server on page 272.
Specifies the maximum number of PsExec connections that the PsExec server
can run simultaneously. By default this option is set to 20.
You can set a level of parallel execution for the Agent Installer Job with the
"Number of targets to process in parallel" option. (See Agent Installer Job
General on page 306). Regardless of that level, no active PsExec server ever
exceeds the level of parallelism set with Maximum Execution Parallelism
option.
Automation Principal
4 Click Finish. The Infrastructure Management window lists the remote host
authentication you created.
Required authorizations
To create, modify or delete remote host authentication rules, your role must be
granted the following authorizations:
BL_Administration.Read
RemoteHostAuthentication.Read
RoutingPolicy.Read
RoutingPolicy.Modify
2 In the left pane of the Infrastructure Management window, right-click the Remote
Host Authentication Routing Rules node, and then select New Rule. The New
Rule wizard opens.
2 In the left pane of the Infrastructure Management window, expand the Remote
Host Authentication Routing Rules node. Select the rule you want to modify, right-
click, and select Properties. The Modify Rule window opens. It displays a series
of tabs, which are described in the following sections:
3 Click OK.
Field definitions
Name
Description
The order of rules on this panel determines the order in which the system uses the
rules to evaluate whether an agentless device matches.
To re-position a rule, select the rule and use the Move Up, Move Down, Move to
Top, and Move to Bottom icons.
2 In the first text box at left, enter a property name or click Select Property to
choose a property from a list.
If you click the Select Property icon, you can view a subordinate list of properties
by clicking the right arrow that appears next to the TARGET* property. When
defining remote host authentication rules, use any of following subordinate
properties:
In addition, you can also use any custom properties that you have defined.
4 Use the next field to the right to specify a property value or range of values.
5 Click OK. The Rule Definition panel shows the condition. To edit the condition,
select it and click Edit Selected Condition. To add further conditions, click Add
Property Condition again.
6 If you create multiple conditions, by default the operator for each newly added
condition is AND. To change the operator, click in the Operator column at left.
Select AND, OR, AND NOT, or OR NOT.
A typical remost host authentication condition might be:
(??TARGET*.NAME?? starts with win2k3) OR (??TARGET*.NAME?? starts
with win2k8)
Under Select the remote host authentications for this rule, select one or more
remote host authentications that should be used to authenticate to servers that match
the criteria specified in this rule. Click the right arrow, which moves your selections
to the list on the right.
If you select multiple remote host authentications, the system checks each remote
host authentication during agent installation until it finds one that allows a
successful connection to an agentless device.
Maps target platform types to the corresponding agent installers that are located
in the Depot.
For example, suppose you want to install agents on Windows 32-bit servers.
Following the instructions in Adding agent installer packages to the Depot on
page 269, you would have created a Depot software object for the Windows 32-bit
agent installer package, and this object would be based on the installer file RSCD82-
WIN32.msi.
Continuing with this example, when you create an agent bundle, you include a
line that says: for each Windows 32-bit target system, use the RSCD82-
WIN32.msi package to install an agent.
Specifies the contents of the following agent configuration files: exports,
users.local, and secure (optionally different settings for each platform).
You may need to create only one agent bundle to specify the installers and settings
for all your platforms. However, there are some situations where you need to create
more than one bundle:
You need agent bundles with different permissions for each bundle.
You need to have different agent configuration file contents for the same platform.
Required authorizations
To create and use agent bundles, your role must be granted the following
authorizations:
AgentBundle.Read
AgentBundle.Create
When you create an agent bundle, you do not have to specify the contents of the
exports, users.local, and secure files. If you omit these settings, the system uses the
defaults from the agent installer package.
However, if you want to specify these configuration settings in the agent bundle,
familiarize yourself with the various options and syntax for these files. See BMC
technical documentation at https://docs.bmc.com/docs/display/bsa82/Setting+up
+configuration+files. Use care when defining non-default configurations. The
installation process does not validate configuration settings. An incorrect setting can
prevent an agent from starting or block users from accessing the agent.
1 Open the Depot folder. Select a sub-folder, right-click and select New => Agent
Bundle.
Field Definitions
Name
Identifying name.
Description
Save in
You can optionally specify the contents of the following agent configuration files:
exports, users.local, and secure. These files specify the type of access various BMC
Server Automation clients have to the managed servers containing RSCD agents.
For detailed information about the contents of these files, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Setting+up
+configuration+files.
Click Edit to type entries manually; click Import to import the contents of an existing
file.
If you do not specify the contents of the exports, users.local, and secure files here,
the system uses the following defaults from the agent installer package. If you do
make changes, the configuration file that you have defined is copied to the agent
during execution of the Agent Installer Job.
exports * rw
users.local <empty>
secure default:port=4750:protocol=5:tls_mode=encryption_
only:encryption=tls
rscd:port=4750:protocol=5:tls_mode=encryption_onl
y:encryption=tls
The settings on this panel apply to all the installer packages for all the target
platforms on which you want to install agents.
However, you can override these global settings for individual platforms, as
described in Agent Bundle Configuration on page 299.
Add a new mapping. To do this, click Add Agent Installer . This opens the
Add Agent Installer window, where you can fill in the details, as described in
Add Agent Installer window on page 300.
Update an existing mapping. To do this, select the mapping and click Edit Agent
Installer . This opens the Edit Agent Installer window, where you can modify
the details.
Delete a mapping. To do this, select a mapping and click Delete Agent Installer
.
Platform
Click the drop-down menu and select one of the following target platforms:
AIX
Linux 32-bit
Linux 64-bit
Windows 32-bit
Windows 64-bit
Installer
Click Browse . The Select depot object window opens. Use it to browse
to the installer you added to the Depot for this platform type.
If you have not previously added agent installer packages to the Depot, see
Adding agent installer packages to the Depot on page 269.
Configuration
The previous panel (Agent Bundle Default Configuration on page 298) let
you set global configuration values for the exports, users.local, and secure
files. If you want to override these global values for this particular platform,
click Configuration and specify new values.
This panel displays the installers you have selected for this bundle, and the
configuration settings in the exports, users.local, and secure files.
If you are satisfied with your choices, click Next to proceed to the next panel.
For any property that has a check in the Editable column, select the property and
click in the Value column.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing agent bundle, open the Depot folder
and navigate to an existing agent bundle. Right-click the agent bundle and
select Open. The content editor displays a series of tabs, which are described in
the following sections:
Agent Bundle General on page 298
Agent Bundle Default Configuration on page 298
Agent Bundle Configuration on page 299
Agent Bundle Summary on page 301
These tabs correspond to panels in the New Agent Bundle wizard. Use them to
modify the agent bundle definition.
The target servers against which you want to run the job.
Running an Agent Installer Job installs agents on target servers. You can run an
Agent Installer Job in two different scenarios:
During the process of adding or importing servers, you can specify that you want
to install agents on these servers as part of the add/import.
You can add/import servers to the system without installing agents. Then, at a
later time, you can execute an Agent Installer Job to install agents on the servers.
For more information on these two scenarios, Scenarios for installing agents on
page 315. Alternatively, you can run the Unified Agent Installer, which guides you
through the entire process needed to install agents, including creation of an Agent
Installer Job. For more information, see Running the Unified Agent Installer on
page 273.
If an Agent Installer Job fails to install an agent because it cannot determine the
operating system of a target device, you must manually specify the device's
operating system. For more information about that process, see Operating system
detection and the AGENT_PLATFORM* property on page 313.
Note
Agent Installer Jobs:
Do the following:
Set up remote host authentication rules. See Creating or modifying rules for
remote host authentication on page 293.
Required authorizations
See Authorizations for the Agent Installer Job on page 305 for a complete list of
required authorizations to create and run an Agent Installer Job.
Open the Depot folder. Navigate to the agent bundle you want to use for this
job. Right-click the bundle and select Install Agent.
Open the Job folder and right-click the subfolder where you want to create the
job. Select New => Agent Installer Job.
Open the Servers folder and navigate to a server on which you want to install
an agent. Right-click and select Install Agent.
Open the Servers folder and navigate to folder or smart group containing
servers on which you want to install agents. Right-click and select Install
Agents.
Select File => New => Other. The New window opens. Expand the BMC
Server Automation Console node. Expand the Jobs node. Select Agent
Installer Job and click Next.
To create Agent Installer Jobs, your role must be granted the following authorizations:
AgentInstaller.Create
AgentInstaller.Read
To execute Agent Installer Jobs, your role must be granted the following authorizations:
DepotFolder.Read on the folder where the agent bundle referenced by the job is
stored
Server.AgentInstall on any server selected as a target for the job, either directly or
through a group
Server.PushACL on any server selected as a target for the job, either directly or
through a group (assuming you have defined the job to push ACLs to the target)
BL_Administration.Read
RemoteHostAuthentication.Read
RoutingPolicy.Read
Field Definitions
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Agent Bundle
Displays the agent bundle on which this job is based. To base this job on a different
agent bundle, use this option to navigate to the bundle.
Agent Options
Update the system with properties from the target servers on which you are
installing agents.
Register any configuration objects that are found on the agent and defined in
the Configuration Object Dictionary.
To push ACLs, the system converts the access control list defined for a server
into a users configuration file and pushes that file to the agent. The access
control list is derived from user permissions defined in the RBAC system.
Job Options
Field definitions
Available Servers
Specify the operating system of the servers you want to select. To display
servers running any operating system, select All.
By Group, By Name
Select servers from a tree or sortable list by doing one of the following:
Click the By Group tab at the bottom of the window. The left panel
displays servers in a hierarchical list arranged by server group. Choose
servers by doing one of the following:
To select all servers within the group, click a server group.
Click one or more servers, if necessary, to expand server groups.
Click the By Name tab at the bottom of the window. The left panel lists
servers by name in a Group Explorer view. Sort servers in ascending or
descending order by clicking on any column header. Click one or more
servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
Click the right arrow to move your selections to the right panel.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs.
Agent Installer Job Scheduled Job Notifications
The Scheduled Job Notifications tab lets you send notifications when a scheduled job
completes.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Agent Installer Job Scheduling
The Schedule tab lets you schedule a job so it can run once, recur hourly, daily,
weekly, or monthly, or recur at some arbitrary interval.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
Agent Installer Job Execute on approval and Approval type settings
The Approval information tab lets you select an approval type and enter approval
parameters when you configure the schedule.
The Approval information tab only appears when the BMC Server Automation
administrator has specified that this job type requires BMC Remedy ITSM approval
prior to execution. When approval is required, you must use this tab to select the
approval type and enter the approval parameters.
To specify an approval type, select the Execute on Approval option, and then select
an Approval type. Optionally, you can select to use an existing change ticket for
approval. The Execute on Approval field appears when you:
For more information, see Executing a job with BMC Remedy ITSM approval on
page 617.
For any property that has a check in the Editable column, select the property and
click in the Value column.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
In some situations you may have to manually provide a value for the
AGENT_PLATFORM* property. Its possible values are:
AIX
Linux 32-bit
Linux 64-bit
Linux 64-bit S390
Solaris 10/11 SPARC
Solaris 10/11 x86
Solaris 8/9 SPARC
Solaris 8/9 x86
Windows 32-bit
Windows 64-bit
For a procedure describing how to set property values, see Setting values for
system object properties on page 161.
When an Agent Installer Job executes, it attempts to determine the operating system
of the target devices. The job uses the following sequence:
1 The job checks the AGENT_PLATFORM* property for each target device. If the
value of the property is "Unknown," the job continues with the next step. If the
value of the property is set to a valid entry for an operating system, the job
continues, as described in step 5.
2 Using remote host authentication routing rules, the job determines which remote
host authentication definitions to use. The job attempts the remote host
authentications in the order in which they are listed in the remote host
authentication routing rule until an authentication succeeds.
3 Using the command execution protocol specified in the successful remote host
authentication (that is, PsExec, SSH, SUDO, or SU), the system runs a series of
commands to determine the host operating system. These commands include
uname for UNIX platforms and regedit for Windows.
4 The job enters a value for the AGENT_PLATFORM* property to identify the
operating system of the target device.
5 The job installs an agent using the installation package that the agent bundle maps
to the operating system identified during the authentication process.
If an Agent Installer Job fails to identify the operating system for a target host, you
must manually provide a value for the AGENT_PLATFORM* property to enable
agent installation.
To modify the definition of an existing Agent Installer Job, open the Jobs folder
and navigate to an existing job. Right-click the job and select Open from the pop-
up menu. The content editor displays a series of tabs, which are described in
the following sections:
Agent Installer Job General on page 306
Agent Installer Job Options on page 307
Agent Installer Job Targets on page 308
Agent Installer Job Default Notifications on page 309
Agent Installer Job Schedules on page 310
These tabs correspond to panels in the New Agent Installer Job wizard. Use
them to modify the job definition.
Running the Unified Agent Installer or an Agent Installer Job after you add
servers on page 316
2 On the Add New Server Properties panel or the Import Servers Import Servers
panel, check If agent does not exist, install using Agent Installer Job.
3 Click Browse to navigate to the Agent Installer Job you want to use to install
the agent. For more information, see Creating an Agent Installer Job on page
303.
2 On the Add New Server Properties panel or the Import Servers Import Servers
panel, do NOTcheck If agent does not exist, install using Agent Installer Job.
This adds the server(s) to the system without installing agents.
3 At a later time, when you want to install agents on these agentless servers, do one
of the following:
Run the Unified Agent Installer to target the agentless devices (see Running
the Unified Agent Installer on page 273). The Unified Agent Installer wizard
guides you through all steps necessary to install agents, including creation of
an Agent Installer Job. You can run the Agent Installer Job immediately or
schedule it to run later.
Create or modify the objects necessary to install agents (see Creating objects
for agent installation on page 287 ). One of the objects you must create is an
Agent Installer Job, which targets the agentless on which you want to install
agents. (For information about this job, see Creating an Agent Installer Job on
page 303). Execute the Agent Installer Job to install agents.
target machine. For Windows Vista and later operating systems, if you are a local
administrator on a server and you are not the default administrator account, then by
default you do not have access to these shares. This results in "Access Denied" errors
during the install.
Use a domain administrator account that has permissions for the target device
To resolve this issue, configure /etc/sudoers so it accepts passwords other than the
root password.
Before you can perform other tasks in BMC Server Automation, you must populate
the Servers folder with the servers you want to manage, either by adding individual
servers or by importing servers in bulk. After you add servers to the Servers folder,
you must install agents on those servers. For information about adding servers and
installing agents, see Agent installation on page 259.
After populating the Servers folder, you must organize servers into a structure that
matches your needs. BMC Server Automation lets you perform many actions on
server groups, so a well-designed server structure can enhance productivity. For
more information about structuring server groups, see Server organization concepts
on page 333.
Many of the capabilities of BMC Server Automation are based on properties that
change from server to server. See Properties and servers on page 320 for an
explanation of how properties are used in conjunction with servers.
Occasionally, you might want to remove a server from the system. For example, a
server may become obsolete, or you may want to repurpose a server by installing a
different operating system and different applications on the same physical
hardware. To do this, you must decommission the server, as described in
Decommissioning a server on page 335.
You can use the Servers folder to browse the contents of each server, including the
server objects that reside on each server. For more information, see Server browse
options on page 338.
Primarily, you manage server objects by performing jobs on them (see Managing
jobs on page 605), but BMC Server Automation also provides some capabilities for
managing individual server objects, such as the ability to start and stop Windows
services. For more information, see Server objects: management concepts on page
342.
The Servers folder lets you launch a script or executable program on a server. For
more information, see Executing custom commands on page 347.
Each server inherits a set of properties defined for the Servers property class in the
Property Dictionary. Using the Property Dictionary, you can specify the properties
that should be inherited by all servers (see Property Dictionary overview on page
143). At the server level, you can change the value of these properties to match the
configuration and function of each server (see Setting values for system object
properties on page 161).
For example, if you are deploying an Apache server to various platforms, you can
specify a different installation directory for each platform by defining a property in
the Property Dictionary that represents the installation directory. For Windows
servers, you could set the value of that property to /c/Program Files/Apache. For
UNIX servers you could set the property to /usr/local/Apache.
You can also use properties to organize servers into smart groups (see Defining a
smart group on page 108). For example, you can create a property in the Property
Dictionary called Owner, and then assign different values for that property to
different servers. If some servers have Owner set to QA and others have Owner set
to Development, then smart groups can automatically group QA servers into one
group and Development servers into another.
Some server properties are considered intrinsic, meaning the property is derived
from the nature and configuration of a server, such as the servers name or root
directory. Some intrinsic properties are editable. For a list of these, see Editable
intrinsic properties for servers on page 321.
After you add a server, you may change some of the servers intrinsic values by
doing various things to the server itself. For example, you may apply a new patch to
the server, which would change the value of its patch level property. If you want
BMC Server Automation to retrieve and display new property values from the
server, you need to update the servers properties, as described in Server properties:
update concepts on page 322.
The following is a list of editable intrinsic properties. For more information about
editing property values, see Setting values for system object properties on page
161.
Note
For properties associated with virtual environments, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Home.
Property Meaning
AGENTLESS_MANAGED_OBJECT_ICO Identifies the file used to store icons representing agentless
N_FILE devices and their contents.
AGENTLESS_MANAGED_OBJECT_PRO Indicates this server is used to manage agentless devices.
XY_HOST
CUSTOM_OBJECTS_ENVIRONMENT Lets you set JVM parameters when you are running a Java
custom configuration object.
DEPLOY_ALLOW_NFS_DURING_SUM Indicates that, during a Deploy Job, an agent on a target server
running in single user mode can mount a source location using
NFS. By default this property is set to False. For more
information, see Using NFS to mount a location while running
single-user mode on page 771.
IS_DEPLOYABLE Designates a server as not being subject to a Deploy Job. For
more information, see Designating servers that cannot be
targeted by Deploy Jobs on page 770.
IS_ONLINE Indicates that the server is available for use within the system.
IS_SOLARIS_LIVE_UPGRADE Indicates an Oracle Solaris server should be remediated using
Live Upgrade. By default this is set to False.
MS_OFFICE_INSTALL_LOCATION Provides the path used to access installation media for
Microsoft Office. The path must be provided in UNC format.
For more information, see Defining the location of Microsoft
Windows installation media for Microsoft Office patch
deployment on page 1032.
MS_OFFICE_INSTALL_USERNAME Provides the user name that should be used to access the
installation media for Microsoft Office. For more information,
see Defining the location of Microsoft Windows installation
media for Microsoft Office patch deployment on page 1032.
MS_OFFICE_INSTALL_PWD Provides the password for a user name that is needed when
installing Microsoft Office. For more information, see
Defining the location of Microsoft Windows installation
media for Microsoft Office patch deployment on page 1032.
Property Meaning
PUSH_ACL_NO_USERS_FLAG Restricts server access to only those users listed in the servers
users file. See Agent ACL description on page 240.
REPEATER_MAX_CACHE_SIZE Specifies the maximum size for the cache on repeaters where
BLPackages and software is stored until it is deployed. See
Configuring servers to use repeaters during deployments on
page 989.
REPEATER_NAME The host name of a BMC Server Automation repeater used to
stage a deployment to this server. This option is only provided
for compatibility with earlier releases. For information about
using repeaters, see Configuring servers to use repeaters
during deployments on page 989.
REPEATER_STAGING_DIR The repeaters staging directory. This option is only provided
for compatibility with earlier releases. For information about
using repeaters, see Configuring servers to use repeaters
during deployments on page 989.
SOLARIS_ALTERNATIVE_BOOT_ENV Identifies the Alternate Boot Environment present on the
server. This property should only be used when
IS_SOLARIS_LIVE_UPGRADE is set to True.
STAGING_DIR A local path that identifies a location on this server to store the
following:
TRANSACTION_DIR A local path that identifies a location that stores rollback and
log information for Deploy Jobs. For more information, see
Configuring the location of the transactions directory on
page 770.
When you first add a server, BMC Server Automation retrieves the servers intrinsic
properties (operating system, patch level, and so forth) over the network and
displays these properties in the Properties view. Over time, some of these properties
may change for the serverfor example, you may apply a new patch. To instruct the
system to retrieve and display new property values from the server, you must
update the servers properties.
Creating an Update Server Properties Job, which updates intrinsic server property
values for a list of targeted servers. For more information, see Creating Update
Server Properties Jobs on page 325.
If you are using servers in a virtual environment (such as a VMware vCenter or IBM
frames), you must define values for certain properties that allow communication
with the servers virtual infrastructure. For more information, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Home.
3 Right-click the server name and select Properties from the drop-down menu. The
server properties window appears.
4 Click Verify .
BMC Server Automation updates the property values shown in the window to
match the current property values for the server. Note that the system updates
only intrinsic properties. Intrinsic properties are properties that are derived from
the nature and configuration of a server, such as the servers name, root directory,
operating system, and so forth.
This communication occurs through the RSCD agent running on the server (for IBM
frame environments, the agent running on the proxy server). If necessary, the agent
can communicate with the web service or HMC using a secure connection. For
secure connections, the agent automatically accepts a certificate issued by the server.
To set up communication with the vCenter server or IBM HMC, you must provide
values for certain properties on each server. These properties must be configured
whenever you add a vCenter server or IBM frame to the Servers folder or
reconfigure an existing one. The properties that must be configured are:
CONNECTION_URL
CONNECTION_USER
CONNECTION_PASSWORD
For more details on these properties, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Home.
WARNING
BMC strongly recommends you only perform this procedure when renaming the
same physical device. That device should also be running the same operating
system. Renaming a server so it points to a new physical device or a new operating
system can introduce many problems. The only technique BMC Server Automation
supports for changing a servers physical location is to decommission the existing
server and add the new device.
To rename a server
1 Using the Servers Folder, select the server you want to rename.
2 In the Properties view, find the NAME property, and click in the Value column.
4 Run an Update Server Properties Job, targeting the server whose name has
changed. For more information, see Creating Update Server Properties Jobs on
page 325.
5 In the Servers folder, refresh the folder holding the renamed server.
Running this job ensures that BMC Server Automation reflects the current values for
all the intrinsic properties on your servers. Intrinsic properties are properties that are
derived from the nature and configuration of a server, such as the servers name,
root directory, operating system, and so forth. For a complete list of intrinsic
properties, see Intrinsic properties on page 1479.
Open the Servers folder and select a server. Right-click and select
Administration Task => Update Server Properties from the pop-up menu.
Open the Jobs folder and navigate to the job folder where you want to create a
new Update Server Properties Job. Right-click the job folder and select New =>
Administration Task => Update Server Properties Job from the pop-up menu.
2 Provide information for the Update Server Properties Job, as described in the
following sections:
Field Definitions
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Field definitions
Available Servers
Specify the operating system of the servers you want to select. To display
servers running any operating system, select All.
By Group, By Name
Select servers from a tree or sortable list by doing one of the following:
Click the By Group tab at the bottom of the window. The left panel
displays servers in a hierarchical list arranged by server group. Choose
servers by doing one of the following:
To select all servers within the group, click a server group.
Click one or more servers, if necessary, to expand server groups.
Click the By Name tab at the bottom of the window. The left panel lists
servers by name in a Group Explorer view. Sort servers in ascending or
descending order by clicking on any column header. Click one or more
servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
Click the right arrow to move your selections to the right panel.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing Update Server Properties Job, open the
Jobs folder and navigate to an existing job. Right-click the job and select Open
from the pop-up menu. The content editor displays a series of tabs, which are
described in the following sections:
Update Server Properties Job General on page 326
Update Server Properties Job Targets on page 327
Update Server Properties Job Default Notifications on page 328
Update Server Properties Job Schedules on page 328
These tabs correspond to panels in the New Update Server Properties Job
wizard. Use them to modify the job definition.
BMC Server Automation lets you perform many actions on server groups, so a well-
designed server structure can enhance productivity. You can group servers using a
combination of the following approaches:
Server groups
Using server groups, you can organize servers hierarchically. Often, system
administrators organize groups by geographical location or operating system. For
example, you might create a server group for the eastern and western divisions of
your company, and within those server groups create another level of the
hierarchy for Windows, Linux, and AIX platforms. After you define a server
hierarchy, you populate it by assigning servers to groups.
In addition to creating server groups and smart server groups, you can organize
servers using any of the following procedures:
Copying, cutting, and pasting servers from one server group to another.
For a description of the procedures listed above, including procedures for creating
server groups and smart server groups, see Folders view and resource
management on page 101.
Move existing servers between server groups (see Moving or copying a server
between server groups on page 335).
2 Right-click the server group where you want to add a server. Then select Assign
Servers to Group from the pop-up menu. The Assign Servers to Group dialog box
opens.
3 The Available Servers list shows all the servers in the systems internal list of
servers. These servers have either been added manually (see Adding a server to
the system on page 261) or imported through a text file (see Importing servers
into the system on page 265).
You can use the Available Servers drop-down menu if you want to limit your
display to servers of a particular operating system.
4 If the Available Servers list includes multiple servers, their names may be listed in
pages. The number of servers displayed in each page is determined by the Page
Size preference (see Customizing preferences on page 84). If servers are
presented in pages, you can do any of the following to navigate through the list:
Enter the number of the page of servers that you want to display. For example,
suppose there are 120 servers in the list and the Page Size preference is set at 20
(meaning there are six pages of 20 servers). If you want to display the third
page, enter 3/6. The system displays the third of six possible pages.
Click Filter to display the Filters dialog box. For Name, enter a string and click
Filter. The list of servers is narrowed to display only servers with names that
include the string you entered in the Filters dialog box.
5 Use the arrow buttons to move servers between the Available Servers list and the
Selected Servers list.
6 When the Selected Servers list shows the servers you want, click OK to finish
adding the servers. The servers now appear under the server group you specified.
3 Right-click the server and select Cut (to move the server) or Copy (to copy the
server).
5 Right-click the server group name and click Paste. The server is now included in
the new server group.
Decommissioning a server
In the provisioning environment, to remove one or more servers from BMC Server
Automation, you can decommission the servers.
In general, decommissioning a server removes that server from view in the BMC
Server Automation console and makes it unavailable for any operation. However,
the server's data and references (jobs, job results, job runs, and provision history) are
maintained in the database. For detailed information about decommissioning a
server, see About decommissioning servers on page 336.
system. Repurposing a server in this way lets you keep the same host name for the
machine.
Note
When you repurpose a server and add it back into the system, you must redefine
jobs for the newly configured server. Any jobs you defined for the server before you
decommissioned it do not run on the server when you add the server back into the
system, even if you keep the same host name for the machine. For information about
jobs, see Basic concepts for jobs on page 605.
To decommission a server
Use the Servers folder to select the group or smart group containing the servers
you want to decommission. Right-click and select Group Explorer. A Group
Explorer view opens. Select the servers you want to decommission.
3 Click OK to confirm that you want to decommission the servers listed in this
dialog.
You can remove a server from BMC Server Automation by decommissioning it.
Decommissioning a server has the following effects:
The server no longer appears when you live browse in the BMC Server
Automation Console.
The server is no longer available for any operation. For example, the server no
longer appears in server groups. In addition, if you show the targets of a job, the
decommissioned server is dimmed and marked as decommissioned.
Components associated with the server are marked for deletion in the database.
When you run the database cleanup utility, these components are deleted from
the database.
However, a decommissioned server is not marked for deletion in the BMC Server
Automation database.
For jobs that use servers as targets, decommissioning a server has the following effects:
The server's provision history is maintained in the database (not marked for
deletion):
Jobs, job results, and job runs previously associated with that server are
maintained in the database (not marked for deletion)
Note
Decommissioning a server has the following effects on Snapshot and Audit Jobs:
For jobs that use components as targets, decommissioning a server has the following
effects:
Job results from job runs against components associated with the server are
marked for deletion in the database and no longer appear in the BMC Server
Automation Console. When you run the database cleanup utility, these job results
are deleted from the database.
If a job run only includes one or more components discovered against the
decommissioned server, then the entire job run is marked for deletion in the
database and no longer appears in the console.
A tab showing the servers name opens in the content editor. At the bottom of the
tab, there are four sub-tabs:
ActivityShows job activity that has occurred on the server. For more
information, see Viewing job activity on page 638.
Snapshot ResultsShows the results of all Snapshot Jobs involving the server. For
more information, see Viewing snapshot and change tracking results on page
669.
Audit ResultsShows the results of all Audit Jobs involving the server. For more
information, see Viewing audit results by object on page 697 and Viewing
audit results by server on page 698.
Virtual environments contain specialized Live node children, which are described in
Browsing virtual inventory on page 857.
HP-UX
BLPackages
Bundles
Components
Configuration
Daemons
Extended Objects
File System
Hardware Information
Patches
Processes
Products
System Info
UNIX Groups
UNIX Users
Oracle Solaris
BLPackages
Components
Configuration
Daemons
Extended Objects
File System
Hardware Information
Packages
Patches
Processes
System Info
UNIX Groups
UNIX Users
The following list provides additional information about nodes that are children of
the Live node:
ConfigurationLists files that present the contents of configuration files for the
operating systems BMC Server Automation supports. To deliver this information
in a standard format, BMC Server Automation parses the contents of those files
using grammar files. (In this respect, configuration file objects are similar to
extended objects.) If necessary, you can identify additional configuration files. For
more information, see Identifying additional configuration files on page 574
and Configuration files on page 570.
Here are the most common actions you perform on server objects:
The Servers folder also lets you perform the following administrative tasks while
managing server objects:
1 In the Servers folder, right-click a server and select Browse from the pop-up
menu. Then, select the Live node, and then select the File System server object
type.
4 Navigate to the server where you want to paste the files and directories. Right-
click and select Browse from the pop-up menu. A tab appears in the content
editor. Using that tab, select the Live node and then select the File System server
object type. Navigate to the directory where you want to paste.
You cannot paste onto a CD-ROM drive, a floppy drive, or a network drive.
5 Right-click, and select Paste from the pop-up menu. The copied files and
directories are pasted into the new location.
1 In the Servers folder, right-click a server and select Browse from the pop-up
menu. Then, select the Live node and select the File System server object type.
3 Right-click and select Delete from the pop-up menu. A dialog box prompts you to
confirm the deletion.
1 In the Servers folder, navigate to a Windows server, select the Live node, and
then select the Services server object type.
2 Right-click a service. From the pop-up menu, select Stop Services or Start
Services. A message prompts you to confirm your action. If stopping a service
also stops a dependent service, a dialog box prompts you to confirm the action.
1 In the Servers folder, right-click a server and select Browse from the pop-up
menu. Then, use the Live node to select one of the following server object types:
Files and directories Windows and UNIX (including VMware VMFS file
systems)
Hotfixes Windows
Services Windows
2 Navigate to the server object for which you want information. Right-click it and
select Properties from the pop-up menu.
The Properties dialog box displays attributes for the selected server object. The
categories of information provided on the Properties dialog box differ for
different types of server object. See Viewing security information for files and
registry keys on page 345 for more about viewing security information for files.
This procedure lets you view discretionary ACLs (DACLs) and system ACLs
(SACLs) for a selected file or registry key.
Using the Servers folder, expand a server, select the Live node and then select
the File System or Registry server object type. Navigate to the file or registry
key for which you want information. Right-click the file or registry key, and
select Properties from the pop-up menu. A Properties dialog box appears. If
you are displaying properties for a file, click the Security tab.
Using the results of a snapshot job, right-click a file or registry key displayed
within the Server View node of the Snapshot Job results and select Properties
from the pop-up menu. A Properties dialog box appears. If you are displaying
properties for a file, click the Security tab.
The Security tab shows users and groups who are granted permissions for the
selected file or registry key.
Note
The inheritance check box at the bottom of the screen refers to standard
Windows permissions, not BMC Server Automation permissions.
To display security information for snapshot results, the Snapshot Job must
be defined to include file or registry ACLs.
3 To view audit settings, click the Auditing side tab. A dialog box displays setup
information about events that are logged to the Windows system security event
log. Setup information is listed by user and by type of event (that is, failure or
success).
Note
By default, the Auditing tab is only available when you are using user privilege
mapping to access a server. If you are using Windows user mapping, you must
explicitly grant the "Manage auditing and security log permission to the user to
which you are mapped on the server in question. To accomplish this, as an
Administrator, open the Windows Administrative Tools on the server you are
accessing. Then open Local Security Policy followed by User Rights Assignment.
Select the properties for the Manage auditing and security log permission and
add the user who should have this permission.
For more information about user privilege mapping and Windows user mapping,
see Automation principals and server management on page 171.
You can:
If a custom command such as NSH Here requires a connection to an agent and you
are set up to use a Network Shell Proxy Server, the custom command will
authenticate to the proxy server using the single sign-on credential that the system
generated when you logged on to the console. For more information about
configuration needed to use a Network Shell Proxy Server, see Configuration for
Network Shell Proxy Server traffic on page 349.
1 In the Servers folder, select the server or server group where you want to execute
a custom command. If the custom command should run against a file or
directory, use the File System object to navigate to the correct file or directory.
Note
Custom commands can be defined to run locally on servers where no RSCD agent
is installed. For more information, see Custom commands on page 977.
2 Right-click the server group, server, file, or directory and select Run Custom
Command from the pop-up menu. The Command Selection dialog box opens.
Select the command you want to execute or enter text into the text box at the top.
The choice of commands is filtered to only those commands with names that
begin with the text you have entered.
3 Click OK.
If the command is defined so that it only executes against a single host, the
command executes and the procedure is complete.
If the command is defined so you can choose additional hosts against which the
command should execute, a window opens, allowing you to choose additional
servers. Proceed to the next step.
If you select a server, the only commands you can choose are those designed for
that servers operating system. If you select a server group, you can choose any
custom command. However, the command only executes against servers running
the operating system for which that custom command is designed.
4 From Available Servers, specify the operating system of the servers you want to
select. To display servers running any operating system, select All.
5 Select servers from a tree or sortable list by doing one of the following:
Click the By Group tab at the bottom of the window. The left panel displays
servers in a hierarchical list arranged by server group. Choose servers by doing
one of the following:
Click the By Name tab at the bottom of the window. The left panel lists servers
by name in a Group Explorer view. Sort servers in ascending or descending
order by clicking on any column header. Click one or more servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can change
dynamically based on their server properties. You can modify static server groups
manually by adding or removing servers.
6 Click the right arrow to move your selections to the right panel.
If the command is defined so you can modify the commands arguments, enter
your changes in the Command Options field.
8 Click Execute and the remote command runs on the servers you have specified.
For details on the required configuration, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Setting+up+a+Network+Shell+client+to+run
+in+proxy+mode.
After you perform configuration needed for Network Shell traffic, the NSH Here
custom command authenticates to the Network Shell Proxy Server using the
credential that the system generates when you log on to the console.
If you configure a Network Shell client to run in proxy mode and you plan to use
Network Shell on the same machine where the console is installed, you must specify
an authentication profile. Network Shell needs an authentication profile to access the
Network Shell Proxy Server. You can use the secure file to specify an authentication
profile. For more information, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Secure+file+overview. You can also use an
environment variable to specify an authentication profile. For more information, see
BMC technical documentation at https://docs.bmc.com/docs/display/bsa82/
Environment+variables.
Components can simplify many data center management tasks because a component
provides a higher level of abstraction than the servers and server objects that make
up the component. For example, a component can group the files, configuration
entries, and registry values needed to support an Apache server, Oracle WebLogic,
or an Oracle database. A component can also specify a collection of configuration
settings that your organization must implement, such as Center for Internet Security
(CIS) recommendations for a particular operating system.
Compliance rulesA collection of one or more rules that express corporate policy
about some or all of the parts included in a component template. For example,
compliance rules can specify security requirements or test for an applications
required configuration. If a component does not satisfy a compliance rule, you can
specify remediation in the form of a BLPackage that can be deployed to correct the
components configuration.
After an expert user has discovered the component, less sophisticated users can use
that component to browse, snapshot, and audit the service, application, or policy
that the component represents, even when those users may not have a deep
understanding of the complexity underlying the component. Less sophisticated
users can also run Compliance Jobs on components to ensure their integrity and
remediate problems by deploying BLPackages specified in the component template
definition.
Component requirements
During the requirements phase, you must decide which aspects of your data center
infrastructure should be implemented as components.
Most commonly, components are used to implement policies and services that affect
multiple servers and are prone to misconfiguration. These uses can be categorized into:
Component design
During the design phase, expert administrators use the Component Templates folder
to model the requirements for component templates in a controlled test environment.
Component templates identify the server objects and configuration settings needed
to make a component. For example, a component template might specify a collection
of files, software, and registry settings needed for an application. Or, a component
template might include a collection of configuration settings, such as password
lengths and expiration requirements. A component template also includes decisions
about how the component should be used and maintained.
There are several stages to component template design. A wizard helps you initially
create a basic component template, as described in Creating a component template
on page 359. You then refine the templates definition during an editing process, as
described in Editing a component template on page 371. When editing the template,
you can specify any of the following:
list of conditions. If you want to add signature conditions in the form of property
values, you can create lists of properties and evaluate those properties with an
extensive list of operators, much like you can with parts.
After you have defined a signature, you can test some representative servers to
determine whether you can successfully associate this component template with
servers. After a component template is complete, you can run a Component
Discovery Job, which examines a server to determine whether it matches the
conditions in the component signature. If it does match, a component is associated
with the server.
Snapshot and AuditSpecifies the individual template parts that will be used in
Snapshot and Audit Jobs after a component has been associated with a server.
You can use includes and excludes to refine this list of template parts. For
example, you can include only DLLs or exclude log files. You can also specify
options that apply when using these template parts in snapshots and audits, such
as whether the snapshots and audits should include MD5 checksums.
Component discovery
After you are confident that a component template developed during the design
phase satisfies your requirements, you can use it to run a Component Discovery Job.
Instructions for the creation of a Component Discovery Job are provided in Creating
Component Discovery Jobs on page 416. This job compares the signature of a
component template with the configuration of a server. If the server configuration
satisfies the signature, the Discovery Job creates a component by associating the
component template with the server. If a component includes multiple instances of a
local property, the Component Discovery Job compares the signature to each
instance of that local property on each server, creating a separate component every
time the test succeeds. In this way you can rapidly create multiple instances of the
same component on a single server.
Note
Discovering components does not actually change the physical configuration of a
server. It simply associates a higher-level object with a server.
Typically, if you are using components to ensure compliance with a policy, you use a
Discovery Job to create components. Discovery Jobs let you rapidly create
components on many servers, which is typically necessary if you are enforcing a
policy such as security requirement. On the other hand, if you are using components
to distribute a consistent software model, you can use a Discovery Job to create a
component, or you can use the manual process for component discovery if you are
only creating a few components based on a component template.
The installer Batch Jobs can run a series of jobs that deploy all parts necessary to
create a component. Then the Batch Job can run a Component Discovery Job to
discover components. The uninstaller Batch Job can remove component parts and
then run a Component Discovery Job to invalidate an existing component. Similarly,
if you have the BMC Application Automation product installed, you can run an
Application Discovery Job to discover applications during an install and invalidate
applications during an uninstall.
For more information about how to define a component template to allow installs
and uninstalls, see Install/Uninstall tab for a component template on page 415.
If you are distributing software based on a software model, you typically package
and deploy components based on a component template (see Packaging and
deploying a component on page 470).
If you are ensuring compliance to a policy, you typically run a Compliance Job (see
Creating Compliance Jobs on page 439) based on a component template. Then you
can view the Compliance Job results (see Compliance results on page 458). If you
prefer, you can export the results to view them in another format (see Exporting
compliance results on page 471).
When you set up a Compliance Job, you can enable the automatic remediation of any
compliance rule failures. If you do, a Compliance Job can gather BLPackages
containing the settings and server objects needed to ensure compliance and deploy
those packages to any servers where components require remediation. You can also
deploy packages directly to components, which is particularly useful if you have
multiple components on the same server.
Alternatively, after a Compliance Job finishes, you can view Compliance Job results,
where you can see which compliance rules have not been satisfied and manually
choose the situations that require remediation. For those, you can gather BLPackages
and deploy them to servers or components needing remediation (see Manually
remediating compliance results on page 467).
Some compliance failures may not require remediation. For these you can define
compliance rules that ignore the failure. In addition, you can create components that
do not satisfy compliance rules in the component template but are nonetheless
classified as consistent when you run a Compliance Job. You can even define
exceptions for a particular server object as long as the object can be expressed in the
form of a path. Exceptions must be set up on a component-by-component basis,
using the same procedure that you follow when manually creating a component (see
Adding components to servers manually on page 425) or modifying an existing
component (see Modifying components on page 432).
In some situations, you may determine that a compliance rule needs adjustment or
that some other aspect of the component template definition needs adjustment. If
you modify the definition of the component template, your changes are
automatically applied to any existing components.
After you are satisfied that the deployed components are compliant with the
component template, you can begin to treat components like any other server object
you can browse, snap, audit, and deploy them. You may also want to continue to run
Compliance Jobs on the components to ensure that they remain consistent with the
component template. To run a Compliance Job, you must first define compliance
rules, a task performed when you edit a component template.
You can use snapshots and audits of components for tracking change. For example,
you can take snapshots of components on a regular schedule so you can monitor
change on an ongoing basis. You can use those snapshots to identify what changes
are occurring in server configurations and when those changes have occurred.
Because you can run Snapshot and Audit Jobs on multiple components
simultaneously, you can group components together according to the business
service they perform. For example, if you are using an enterprise resource planning
(ERP) system that consists of multiple applications, you can encapsulate each
application into a component. Then you can use regularly scheduled snapshots to
record the configuration of all applications in the ERP. You can use audits to identify
and correct discrepancies in those configurations.
For an example that demonstrates how to ensure application compliance using many
aspects of component-related functionality, see Using component templates to
ensure compliance for multiple instances of an application on page 472.
In the Components and Component Templates folders, you can perform any of the
following procedures to organize content:
Create folders, groups, and smart groups. (A smart group is a group for which
you define membership conditions based on properties.)
Copy, cut, and paste smart groups, component groups, components, and
component templates.
For a description of any of the procedures listed above, see Folder content
organization on page 104.
Using this procedure, you can create a component template and specify its parts, or
you can define an empty component template with no component parts and later
add parts during the editing process. To more fully develop the component
definition, including its signature and compliance rules, you must edit the component.
Field definitions
Name
Description
Save in
The component template folder where you want to store this component
template.
Click Browse , and then select a group in the Select Folder dialog box and
click OK. If necessary, you can create a new folder during this process by
clicking Create New Folder .
Allowed Operations
You can create an empty component template by skipping this panel when you
create the component template. Later, during the editing process, you can add
parts to the component template.
If you add rules on the Discover or Compliance tab, the rules editor automatically
adds parts that are referenced in the rules to this panel. The rules editor also
checks the appropriate Discover or Compliance check box.
You can specify parts by choosing them from live servers or Snapshot Job results.
Alternatively, you can enter a path to a part without first selecting a particular server
object or local object. If you are editing an existing component template, you can also
select from local configuration, extended, or server objects.
This allows you to add a level of abstraction to the template part definition so it can
apply to multiple configurations. For example, a parameter like ??
TARGET.WINDIR?? lets you choose a template part that applies to /c/winnt on
some Windows servers and /c/windows on others.
The Parts list lets you select any version of a custom configuration object, even
though that version of the object may not be included in your Configuration Object
Dictionary.
Tip
When you use component template parts as the basis for compliance rules, consider
system performance when choosing those parts. Often, you can improve
performance by selecting a collection of server objects rather than many individual
server objects. For example, you can select the Applications list rather than
individual applications. Or, you can select a configuration file rather than many
individual settings in that configuration file. Every time the system processes a
component template part, it must contact an agent for information about that part. If
compliance rules reference ten separate template parts, the system must contact the
agent ten times. If compliance rules reference ten parts that are all part of the same
collection, the system only contacts the agent to retrieve the collection.
1 On the Parts list, click Add to open the Add Parts window.
2 Using the tree on the left, navigate to the server object that should be included in
the component template. Click the right arrow to move your selections to the
right panel.
If you are editing an existing component template, you can also expand Local
Config Files, Local Server Objects, or Local Extended Objects and select an object
to include in the component template (for information about these objects, see
Local Configuration Objects tab for a component template on page 414). If you
are creating a new component template, no local objects are available because you
have not yet had the opportunity to define any.
If you want to select hierarchical server objects, (that is, file system, Windows
registry, COM+/MTS, Metabase, or configuration file information), you must
expand the tree and select the directories or individual items that you want.
To remove a server object from the list on the right, select it and click the left
arrow. To remove all server objects from the list on the right, click the double left
arrow.
To add a server object without searching through the tree on the left, click Add
New to display the New Component Template Part dialog box. From Type,
select the server object type that you want to add. For Name/path, click Browse
to select a server object or enter the name of a server object and its path. To
insert a parameter in the path, use Select Property . Finally, click OK. The
path and server object that you specify appears in the Selected Parts list on the right.
2 For Name/path, click Browse to select a different server object or enter the
name of a server object and its path. To insert a parameter in the path, use Select
Property .
3 Click OK.
The specified path and server object appear in the Parts list.
For example, you can exclude all log files or backup files in a directory. For
information, see Includes and Excludes on page 365.
When you define an include or exclude for a component template and you browse a
component based on that component template, the results are somewhat different
than when you examine a snapshot or audit based on that same component. In a
snapshot or audit, when an include or exclude definition means a folder should not
contain any server objects, the snapshot or audit does not display the folder. If you
browse a component and an include or exclude definition means a folder should not
contain any server objects, you still see the folder, but it does not contain any server
objects.
1 Select an item in the Template Parts list and do one of the following actions:
Click Add New Include/Exclude . A dialog box appears. For Name, enter a
path to the server object you want to include or exclude, relative to the object
you selected in the Server Objects list. Include a leading slash when specifying
the server object to be included or excluded. For example, enter /autoconf
instead of autoconf. If necessary, use wildcards in the path.
Click Add New Include/Exclude . A dialog box appears. In the list at left,
select the server objects you want to include or exclude. You can select software
or hierarchical server objects. Then click the right-arrow to move your
selections to the Selected Parts list. When you select a server object in the
Selected Parts list, its name appears in the Name field. If necessary, use the
Name field to edit the path to the server object to include or exclude, relative to
the object you selected in the first step. The path can include wildcards. The
path can also include parameters, which you can type or enter by clicking
Select Property .
3 Click OK.
Includes and Excludes
When you are selecting server objects, the Includes/Excludes list lets you include or
exclude certain types of server objects.
The Includes/Excludes list lets you include or exclude software objects, such as
packages or hotfixes. It also lets you include or exclude any of the following types of
hierarchical server objects:
You can include or exclude server objects by name, and you can define matching
patterns to identify multiple server objects to include or exclude. Matching patterns
are based on wildcards, as described in the following table:
Wildcard Explanation
When you define an include, only the server objects that match the definition are
included. For example, if you define an include as *.exe, only server objects that end
in .exe are included.
When you define an exclude, any server objects matching the definition are
excluded. For example, if you define the exclude as *.log, any objects ending in .log
are excluded.
If you define an include and an exclude, the result only shows objects that match the
include criteria; the exclude criteria are ignored.
If you apply the include or exclude recursively, the include or exclude rules apply to
all levels of the hierarchical object.
For many server objects included in a component template, you can use the Snapshot/
Audit Options section to specify object attributes that you want to snapshot or audit.
Some attributes only apply to certain platforms, and those platforms are listed
within parentheses in the Name column. A non-editable check mark in the Snapshot
column shows attributes that are always included in a snapshot. Similarly, a non-
editable check mark in the Audit column shows attributes that are always compared
during an audit. Many other attributes give you the option of choosing whether they
should be included in a snapshot or audit.
Note
If you have disabled snapshots or audits for the entire component template using the
General panel, the Snapshot or Audit column does not display in the Snapshot/
Audit Options section of this panel.
1 Select a part in the Parts list and select any attribute in the Snapshot or Audit
column that should have snapshot or audit functionality enabled.
Select all snapshot or audit attributes by clicking Select All next to Snapshot or
Audit; de-select all by clicking Unselect All. If an attribute is dimmed, selecting
or de-selecting all has no effect.
For descriptions of several important attributes that are available for selection, see
Examples of user-selectable attributes for snapshot and audit options on page
367.
Examples of user-selectable attributes for snapshot and audit options
The following list describes user-selectable attributes for built-in server objects. This
list describes some of the more important attributes as well as attributes with names
that may not completely describe their function. There are many additional
attributes that you can select.
Account Disabled
ACL Owner
Auditing ACL
Compare access control entries in the System Access Control List (SACL) for
a file or registry key. SACL entries are used to audit actions so they are
recorded in a security log. Each access control entry specifies what
circumstances trigger an audit, identifies a group or user to monitor, and lists
operations to audit.
Checksum
Calculate a unique key (an MD5 checksum) based on all the data in a file and
use that key to compare entire files and detect changes that occur anywhere
in a file. Computing full checksums requires significant processing.
Code Page
Contents
Full Name
Group members
Group owner
Home Path
Light Checksum
Calculate a unique key based on the first 512 bytes of a file (a light MD5
checksum) and then use the light checksum to compare header information
in files without expending the processing necessary for calculating full
checksums. Light checksums are useful for binary files; they are not
recommended for text files.
Login Script
Logon Server
Max Size
Member of
Permission ACL
Permissions
Privilege Level
Profile Path
Retention
Size
User members
User owner
Version
Compare file version information for DLL, EXE, and other types of files.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
While editing you can add additional parts, define a signature for the template,
define compliance rules, and add local properties. Usually editing a component
template is essential because you can only develop signatures and compliance rules
during the editing process. You cannot perform these vital procedures while using
the wizard to initially create the component template.
If components based on a component template already exist and you modify the
definition of that component template, your changes to the component template are
automatically applied to the existing component. However, if you change the
signature of a component template, you could invalidate existing components if their
configuration does not satisfy the revised signature. Running a Component
Discovery Job flags any existing components that are invalid. If necessary, you can re-
validate individual components against the new signature (as described in
Validating a component on page 433).
The content editor displays a new tab bearing the name of the selected component
template. At the bottom of the content editor, a series of tabs show the different
categories of information that you can edit for the component template.
Note
If you open a component template that references a custom configuration object
and a more recent version of that object exists, a tab called Version Warnings
appears when the component template cannot be automatically upgraded to refer
to the new object. In cases where the component template is automatically
upgraded to the new version, the console displays a message informing you of
that fact. When you save the component template, the upgrade to the new version
of the custom configuration object is finalized.
2 Edit the component template by clicking a tab in the content editor that represents
a category of information, as described in the following sections:
3 After editing the component template, click Save to save your changes.
The General tab contains the following fields and screen elements:
Allowed Operations
Notes
You can perform the following procedures on the Parts tab. The first three
procedures are the same as if you were adding the parts during component template
creation.
2 On the All Parts list, select one or more parts and then click Update . If you
selected one part, the Update Part window opens. If you selected multiple parts,
the Update Parts window opens.
3 If you selected a single part to update, for Name/path, use Browse to select a
different server object or enter the path to a server object. To insert a parameter in
the path, use Select Property . If you selected multiple parts to update, skip
this step.
BrowseBrowse this part in any components that have been discovered using
this component template.
SnapshotRun Snapshot Jobs on this part for any components that have been
discovered using this component template. For Audit Jobs, this part can be
included in the master or it can be the target of the Audit Job.
AuditRun Audit Jobs on this part for any components that have been
discovered using this component template. You can also include this part in the
master for any Audit Job.
Note
The Discover operation, which controls whether the part is included in signature
matching in Component Discovery Jobs, appears dimmed and cannot be
controlled here. To select the Discover operation for a part, you must include the
part in the signature on the Discover tab.
If you are updating multiple parts, and an operation is not applied consistently
for the parts, that operation has a dimmed check. For example, if you can browse
one part but not browse another, the Browse operation shows a dimmed check.
You can select a dimmed operation to make it applicable to all selected parts, or
you can clear it to make it not applicable to all selected parts.
5 Click OK.
The specified server object appears in the All Parts list. The list also shows the
operations that are allowed for the part.
6 If you are adding hierarchical server objects such as directories, and you want
those server objects to include all subfolders, select those server objects in the All
Parts list. Then check Recurse subfolders at the bottom of the Includes/Excludes
list.
Selecting this option instructs the system to include all folders subordinate to the
server object that you selected in the All Parts list.
All of the possible conditions are derived from parts included in the component
template and properties of the target server or the component template itself.
The procedures that you can perform on the Discover tab are described in the
following sections:
Note
To associate the components to all servers, define an empty signature. To define an
empty signature, do not add any signature conditions. When you select the Discover
operation (on the General tab) for a component template with an empty signature,
all servers satisfy the signature.
For example, the conditions in a signature can check for membership in a list,
determine whether creation dates fall within a certain range, check for inequalities,
or compare text that you provide with text contained in configuration files, registry
values, or metabase values.
For more information, see Defining a basic condition on page 395 and Defining a
conditional construct on page 398.
Note
The process of defining a signature is very similar to the process of defining a
compliance rule, and the Discover tab is very similar to the Rule Definition tab of the
Compliance Rule Editor (see Defining a rule in the Rule Editor on page 389). Note,
however, that loops can exist in compliance rules but not in a signature.
A status bar below the Rule Editor guides you through the process of creating or
editing a signature, with information about what to do next or short error messages
(in red) to help you correct invalid input.
1 On the content editor for the component template, click the Discover tab.
The lower half of the panel, Rule Definition, displays the rule definition for the
signature. In this area, you can connect to the Rule Editor to edit the signature.
The upper half, Parts to Include in Discovery Operation, lists the parts specified
for analysis within the signature.
Note
The only way to include a part in signature matching and have it appear in the
upper half of the panel is to include that part in a condition within the signature,
on the lower half of the panel.
Note
Only one icon (either the Edit icon or the Add icon) appears in the top
right corner of the Rule Definition area, depending on whether or not a signature
currently exists within the component template.
A new tab in the content editor displays the Rule Editor for defining a signature.
To add the first condition to an empty signature, click the New Condition
icon for a basic condition, or click the drop-down arrow beside this icon and
select from the full range of available condition types.
To edit an existing condition within the signature, double-click the line that you
want to edit. The text within the selected line is displayed in editable fields.
To copy conditions from another location, select the relevant lines in the
current signature or in a different signature, and click either Copy selected
conditions or Cut selected conditions . Then place your cursor in the
line above where you want to paste the conditions and click Paste conditions
.
4 In the displayed fields, provide the necessary input (such as operands and
operators), as discussed separately for each type of condition in the following
sections:
Note
These procedures are almost identical for compliance rules and for a discovery
signature, with the one difference that loops can be used within compliance rules
but not within a signature.
5 Repeat steps Step 3 on page 377 and Step 4 on page 378 for all the conditions that
you want to include in the signature.
6 To modify the logical organization of multiple conditions, you can use any of the
following additional options:
To set logical operators between conditions (either AND or OR), use the last drop-
down box at the end of each line. Within one block of conditions, all conditions
on the same level must be connected using the same logical operator.
To rearrange the order of conditions in the signature, select the relevant lines
and click either Move up selected conditions or Move down selected
conditions .
Use the Not icon to add the NOT logical operator to a selected line. This will
logically reverse the TRUE/FALSE outcome of the full expression.
To delete a condition, select the relevant line and click Delete Selected
Condition .
Note
In the display of conditions in the signature, condition operands that are very
long are truncated and end with an ellipsis (). To view the full text within such
conditions, click the Condition Zoom In View icon and select the relevant
lines. The selected lines are presented in the read-only Rule Editor Condition
Zoom view.
7 Click Save .
This procedure does not actually associate a component with any servers. To
perform that procedure, see Creating Component Discovery Jobs on page 416 or
Adding components to servers manually on page 425.
1 On the Discover tab of the component template, click the Edit icon on the
right.
4 Select one or more servers on which you want to test the component template
signature, and click the right arrow to move your selections to the right panel.
The selected servers appear in the Target Selection area. To view the list, you
might need to expand the Servers tree.
The test runs. Discovered components appear under the servers, each with a
green success or red failure icon beside it.
Note
To stop the test run before it completes running, click Stop Test .
7 For more details about the success or failure of component discovery on a specific
server, select the discovered component.
Two panes display on the right. The top pane displays the full signature as
defined through the Rule Editor, including all its conditions and if-then
conditional constructs. Any condition within the rule that caused the rule to end
in Non-compliant status appears in red. The overall compliance status for the full
signature appears at the top, as well as an indication of whether any exceptions
were defined. The bottom pane displays compliance details on the target
component for a selected condition.
In the bottom pane, the condition is parsed into columns for the left-hand-side
(LHS) operand, comparison operator, and right-hand-side (RHS) operand. An
additional Success column indicates whether the component satisfied the
condition (either for true or for false). The actual value detected on the
target component appears in brackets after the LHS operand so that you can see
how it compares to the value in the RHS operand.
Note
In the top pane, condition operands that are very long are truncated and end with
an ellipsis ().
Cardinality conditions are not parsed in the bottom pane. A basic condition is not
parsed if it contains wild cards and was satisfied by the component.
If a basic condition is preceded by a NOT logical operator, the Success column in
the bottom pane shows a value of true when the condition appears in red in the
top pane.
Lines that were not analyzed appear in gray in the rule in the top pane. For
example: if, then, or else blocks in a conditional construct that were skipped or
not reached.
In a conditional construct only one then line, or the last else line, may appear in
red. All if and elseif lines always appear in black font.
9 If a condition includes ACL information, you can view detailed ACL information
for a target server by doing the following:
a Select an entry in the Target pane that includes ACL information and click
View ACL Details . A details window opens. It provides a list of applicable
permissions.
b Select a name in the Access Control List, and then click View ACL Details .
Another detail window shows permissions granted to the name you selected.
c Click Close and then click Close again to close both detail windows.
For instructions on how to select component parts for browsing, see Specifying parts
available for browsing on page 381.
3 From the All Parts list, select the parts that should be available for browsing.
The All Parts list shows all the component templates parts. To move a part
between lists, select the part and click the left or right arrow. Use Shift-click or
Control-click to select multiple parts. To move all parts from the Parts Included in
Live Browse list, click the double-left arrow.
Alternatively, you can add a part to the component template by clicking Add
New . The Add Part window opens. Use this window to add a part, just as
you would add a part in the Create New Component Template wizard. If you add
a part, the only operation allowed on that part is browsing. You can modify that
setting using the Parts tab.
Browsing a component from the Components folder or Browsing a component from the Component Templates
while live-browsing a server folder
Component.Browse Component.Browse
Component.Read Component.Read
ComponentGroup.Read ComponentGroup.Read
ComponentTemplate.Read ComponentTemplateGroup.Read
ServerGroup.Read ComponentTemplateFolder.Read
Server.Read ComponentTemplate.Read
ServerGroup.Read
Server.Read
By default, all component template parts can be included in Snapshot and Audit
Jobs. The Snapshot/Audit tab also lets you modify snapshot and audit options for
individual component template parts.
The following sections describe the procedures that the Snapshot/Audit tab lets you
perform:
3 From the All Parts list, select the parts that should be available for snapshots and
audit.
The All Parts list shows all the component templates parts. To move a part
between lists, select the part and click the left or right arrow. Use Shift-click or
Control-click to select multiple parts. To move all parts from the Parts Included in
Snapshots and Audits list, click the double-left arrow.
Alternatively, you can add a part to the component template by clicking Add
New . The Add Part window opens. Use this window to add a part, just as you
would add a part in the Create New Component Template wizard (as described
in Adding template parts on page 362). If you add a part, it can only be used for
snapshots and audits. You can modify that setting using the Parts tab (as
discussed in Parts tab for a component template on page 374).
4 Click OK.
For many server objects, you can use the Snapshot/Audit Options section to specify
object attributes that you want to snapshot or audit. Some attributes only apply to
certain platforms, and those platforms are listed within parentheses in the Name
column. A non-editable check mark in the Snapshot column shows attributes that are
always included in a snapshot. Similarly, a non-editable check mark in the Audit
column shows attributes that are always compared during an audit. Many other
attributes give you the option of choosing whether they should be included in a
snapshot or audit.
Note
If you disable audits for the entire component template using the General panel, the
Audit column does not display in the Snapshot/Audit Options section of this tab.
Note
If an attribute is marked with a non-editable check mark, selecting and clearing has
no effect on the attribute.
For descriptions of several important attributes that are available for selection, see
Examples of user-selectable attributes for snapshot and audit options on page 367.
1 To enable snapshot or audit functionality, select a part in the Parts list and select
any attribute in the Snapshot or Audit column.
To select all snapshot and audit attributes, click Select All next to Audit. This
checkbox selects both options because audit attributes are based on snapshot
attributes.
2 To clear all snapshot and audit attributes, click Unselect All next to Snapshot. To
clear only the audit attributes, click Unselect All next to Audit.
The compliance rules can include remediation options, which specify what action
should be taken when a component does not comply with a compliance rule.
When a Compliance Job runs, it considers all of the compliance parts on a target
server and compares them to the compliance rules. If the compliance parts do not
satisfy the compliance rule and remediation is enabled, BMC Server Automation can
deploy a BLPackage to the component to correct the failure. It can also ignore the
failure.
Tip
As you set up each compliance rule, you may also want to set up a BLPackage that
can be used to remediate failure for that rule. An easy way to accomplish this is to
launch two instances of the BMC Server Automation Console. As you set up a
compliance rule in one console, you can define the corresponding BLPackage in
another console.
When defining compliance rules, you can organize rules into rule groups. Rules and
rule groups are processed in the order in which you specify. In some situations this
order can be important. For example, if you are remediating by deploying patches,
you must often apply the patches in a certain order.
Parts are added to the Parts section of the Compliance panel in any of the following
ways:
When you create a component template, you can add parts on the Parts panel. If
you check Compliance as an allowed operation for a part, that part appears on the
Parts list on the Compliance panel.
When you edit a component template, you can add parts on the Parts panel. If
you check Compliance as an allowed operation for a part, that part appears on the
Parts list on the Compliance panel.
When you create a rule in the Rules section of the Compliance panel, if you
reference parts that are not already listed, the rules editor adds those parts to the
Parts panel and marks Compliance as an allowed operation. As a result, the
added part also appears on the Parts portion of the Compliance panel.
The Rules editor does not add a part under the following conditions:
Wild card parts. You must add parts that include wild card notations manually
using the Parts panel. For example, suppose that you want to create a
compliance rule that includes the following parts:
Directory://C/**
File://C/FolderA/*
You must make sure that those parts are on the Parts list and that Compliance
is checked as an Allowed Operation for them before you try to create the rule.
You can add them manually on the Parts panel.
Child parts if the parent part is already listed and the Recursive Subfolder
checkbox is selected. In this case, it is not necessary to add the child part to the
Parts list because the Recursive Subfolder feature on the parent covers the
child. For example, suppose that the Parts list includes the following line:
Directory://C (and Recursive Subfolder is checked)
You can write a rule using the following part without having to add that part to
the Parts list:
Directory://C/folderA/file_name.txt
When you create a local property for a compliance template, the property is
added to the Parts panel. It is not, however, marked for compliance at that time. If
you use the local property in a compliance rule, the Rules Editor makes
compliance an Allowed Operation for that property, and as a result, the property
appears in the Parts list on the Compliance panel.
Note
Certain types of parts cannot be included in compliance rules or Compliance Jobs.
Such parts are not inherited from the Parts panel and are not displayed on the
Compliance panel. These parts include various lists and containers of multiple server
objects, as represented by top-level Live nodes such as Configuration, Extended
Objects, and System Info.
3 From the All Parts list, select the parts that should be available for Compliance
Jobs.
The All Parts list shows the component templates parts. To move a part between
lists, select the part and click the left or right arrow. Use Shift-click or Control-
click to select multiple parts. To move all parts from the Selected Parts list, click
the double-left arrow.
Alternatively, you can add a part to the component template by clicking Add
New . Then use the displayed window to add a part, just as you would add a
part in the Create New Component Template wizard (see Adding template parts
on page 362). If you add a part, it can only be used in Compliance Jobs. You can
modify that setting using the Parts tab (see Parts tab for a component template on
page 374).
4 Click OK.
Note
You can also remove parts from association with Compliance Jobs by selecting
parts and clicking Remove Parts . This action is equivalent to disabling the
Compliance operation for these parts through the Parts tab when updating a
template part.
3 For Name, enter an identifying name for the rule group. For Description, you can
optionally provide descriptive text.
4 For Reference Number, enter any identifier needed to synchronize this rule
group with some external system.
5 For Notes, you can enter additional information about the compliance rule group.
6 Click OK.
2 If you want to add a compliance rule to a rule group, select that group in the
Rules on Collected Parts section.
If you do not select a rule group, the new rule is added to the top level of the rule
hierarchy.
To edit an existing compliance rule, select the rule and click Edit Selected Item
.
4 Define (or edit) the compliance rule through the tabs that appear at the bottom of
the Compliance Rule Editor panel, as described in the following sections:
6 Switch back to the component template editor and click Save to save the
component template.
1 On the General tab, enter an identifying name for the compliance rule in the
Name field. For Description, you can optionally provide descriptive text.
2 For Reference Number, enter any identifier needed to synchronize this rule with
some external system.
For more information about commenting out compliance rules, see Commenting
out and uncommenting a compliance rule on page 411.
4 For Notes, you can enter additional information about the compliance rule.
Compliance rules give you great flexibility when analyzing component parts or
properties. You can test for the presence or absence of template parts, or you can
evaluate characteristics of component properties, such as equivalence, inequality,
membership in a list, or inclusion in a range of values. If necessary, comparisons can
be case sensitive. Compliance rules based on parts can examine a wide range of part
attributes. For example, a compliance rule can examine an applications installation
date, a registry keys permissions, or a files content.
The Rule Definition tab lets you create or edit an individual compliance rule for
association with the component template. Compliance rules may vary in complexity,
and each rule can contain any number of the following types of conditions:
Note
A status bar below the Rule Editor guides you through the process of creating or
editing a rule, with information about what to do next or short error messages (in
red) to help you correct invalid input.
The Rule Definition tab of the Compliance Rule Editor also lets you test whether
particular components satisfy the compliance rule that you have defined through the
Compliance Rule Editor. This procedure does not actually run the compliance rule
on the components. To perform that procedure see Creating Compliance Jobs on
page 439 or Compliance results on page 458.
To add the first condition to an empty rule, click the New Condition icon
for a basic condition, or click the drop-down arrow beside this icon and select
from the full range of available condition types.
Foreach Loop, Count Loop, or Exists Loop for the loop of your choice
To add a new condition to a rule that already contains other conditions, select
the line above where you want the condition to appear before using the New
Condition icon.
To edit an existing condition, double-click the line that you want to edit. The
text within the selected line is displayed in editable fields.
To copy conditions from another location, select the relevant lines in the
current rule or in a different rule, and click either Copy selected conditions
or Cut selected conditions . Then place your cursor in the line above where
you want to paste the conditions and click Paste conditions .
2 In the displayed fields, provide the necessary input (such as operands and
operators), as discussed separately for each type of condition in the following
sections:
3 Repeat the previous steps for all of the conditions that you want to include in the
rule.
4 To modify the logical organization of multiple conditions, you can use any of the
following additional options:
Set logical operators between conditions (either AND or OR) through the last
drop-down box at the end of each line. Within one block of conditions, all
conditions on the same level must be connected using the same logical operator.
To rearrange the order of conditions in the rule, select the relevant lines and
click either Move up selected conditions or Move down selected
conditions .
Use the Not icon to add the NOT logical operator to a selected line. This will
logically reverse the TRUE/FALSE outcome of the full expression.
To delete a condition, select the relevant line and click Delete Selected
Condition .
Note
Within the display of conditions, condition operands or loop operands that are
very long are truncated and end with an ellipsis (). To view the full text within
such conditions or loops, click the Condition Zoom In View icon and select
the relevant lines. The selected lines are presented in the read-only Rule Editor
Condition Zoom view.
5 Click Save .
Wildcard Explanation
The * wildcard matches multiple characters, but not path separator characters, such
as /. Consequently, this wildcard does not cause recursive matching.
In path names
For example:
/usr/foo/*
finds:
/usr/foo/bar
/usr/foo/rab
but not:
/usr/foo/bar/foo1
In extended objects
In the output of an external object, * does not recurse in the values list.
For example:
extobj//*
finds:
but not
The following compliance rule matches all objects beginning with the phrase "discard":
]]>
</expression>
In configuration files
In configuration files, * does not recurse through the entries in the file.
For example:
somefile.conf//*ABC*
abc=FOO
xabcx=FOO1
xabc=FOO1
but not:
def/abc=FOO
def/abc/x=FOO
The following compliance rule searches a configuration file for specific settings:
In path names
For example:
/usr/foo/**
finds:
/usr/foo/bar
/usr/foo/bar/foo1
/usr/foo/rab
In extended objects
In the output of an external object, the ** wildcard recurses in the values list.
For example:
extobj//**
finds:
]]>
</expression>
In configuration files
In configuration files, the ** wildcard recurses through the entries in the file.
For example:
somefile.conf//**ABC**
abc=FOO
xabcx=FOO1
xabc=FOO1
def/abc=FOO
def/abc/x=FOO
but not:
def=FOO1
efg=FOO1
The following compliance rule searches a configuration file for an undesired string:
- <expression>
- <![CDATA[
foreach "Configuration File Entry:/etc/pam.conf//**"
"Value3 as String (All OS)" does not contain "rhosts_auth"
end
]]>
For example:
/usr/org?/*
finds
/usr/org1/mary
/usr/org2/john
but not
/usr/org10/mary
The [ ] wildcard matches any single character included in the bracketed characters.
For example:
log*201[12]
matches:
logJanuary52011
logJanuary52012
but not:
logJanuary52010
Basic conditions that analyze properties always consist of a left-hand side (LHS)
operand, a comparison operator, and a right-hand side (RHS) operand. For
example: ??TARGET.OS?? equals "Windows" (For the between operator, two RHS
operands are required.) Certain types of cardinality conditions have only one
operand and an operator, and do not have a right-hand side operand. For example:
"File:/C/a.log" exists
For a basic condition to be valid, the operands and operator must refer to the same
data type, as discussed in Operand data types and operator compatibility on page
402. Each condition returns a logical value of either TRUE or FALSE. Conditions can
be combined, nested, or used in conditional structures or loops to create complex
expressions for evaluation.
1 Within the basic condition line that you added (using the New Condition
icon), click the Select (down arrow) icon of the LHS (left-hand side) field.
The following table lists the top-level branches that appear in this selection box,
and describes how you can use each of these branches to define the LHS operand.
Component Properties Expand this branch to select a component property from a hierarchical
list of component properties.
2.a
Configuration Objects To select a new configuration object, click New Configuration Object
under this branch to open the Configuration Object Selection box. In this
box, select a configuration object (such as a file or directory), either from
a list of local template parts or from a tree-structure list of server objects,
and then click OK to return to the initial selection box. Afterwards, do
one of the following:
a Certain types of server objects cannot be included as configuration objects in compliance rules. Such
server objects cannot be selected from the tree-structure list of server objects and they do not appear in
the list of configuration object types. These object types include various lists and containers of multiple
server objects, as represented by top-level Live nodes such as Configuration, Extended Objects, and
System Info.
3 In addition to, or instead of, defining the LHS operand through the selection box
as described in Step 2 on page 94, you can edit or type directly into the LHS
operand field. In this way, you can parameterize the configuration object path (for
example: "File:??APP_DIR??/*.tmp"), or you can use the following wild cards in
the configuration object path:
Wildcard Explanation
* Match multiple characters. This pattern does not match a path separator
character, such as /. Consequently, a path using this wild card does not recurse
through lower directories.
Wildcard Explanation
** Match multiple characters, including path separator characters. Using this wild
card allows a path to recurse through lower directories.
[character sequence] Match any single character if it is included in the bracketed characters.
4 In the next drop-down box to the right, select a comparison operator (such as
contains or equals). Only relevant operators are available:
For a property, only those comparison operators that are relevant to the data
type of the property specified in the LHS field are available for selection.
For a full list of operators and the data types that support them, see Operand data
types and operator compatibility on page 402.
5 In the right-hand side (RHS) field, enter an operand in one of the following ways:
Note
No RHS operand is required for the exists and does not exist cardinality operators.
Click the Select (down arrow) icon and select a configuration object property, a
component property, or (within a loop) a loop variable property, as done in the
LHS field.
6 Click Apply Condition Value at the end of the condition line to apply your
changes to the condition (or, alternatively, leave the condition line by clicking
outside of it).
You can click Cancel Edit Operation to cancel any editing that you
performed on the condition line as long as you have not yet applied your changes.
A conditional construct always begins with one if-then block, which pairs two
conditions together. The second condition in this pair is evaluated for TRUE/FALSE
outcome only if the condition that preceded it returned a TRUE value.
After the initial if-then block, you can insert any number of optional elseif-then
blocks. Again, each elseif-then block pairs two conditions, and the second condition
in each pair is evaluated only if the condition that preceded it returned a TRUE value.
Finally, before the end of the full conditional construct, you can insert one last
optional else statement, with a condition to be evaluated if all preceding if and elseif
conditions returned FALSE values.
Example
The following simple if-then-else conditional construct contains several basic
conditions:
if
??TARGET.OS?? = "Windows"
then
"File:/C/a.log".size does not equal 3
elsif
??TARGET.OS?? = "LINUX"
then
"File:/C/a.log".size does not equal 4
else
"File:/C/a.log".size does not equal 5
end
1 To insert the main if-then block of the conditional construct, click the drop-down
arrow beside the New Condition icon and select the If Then End option.
2 Define a pair of conditions or loops for the if-then block, in the following manner:
b Click the New Condition icon for a basic condition, or click the drop-down
arrow beside this icon and select from the full range of available condition
types.
Foreach Loop, Count Loop, or Exists Loop for the loop of your choice
d Double-click the then line and repeat steps Step 2.b on page 399 and Step 2.c on
page 399 for the condition or loop that depends on the TRUE/FALSE outcome
of the preceding condition or loop.
3 (Optional) To insert an elseif-then block, select the line above where you want to
insert it, and then click the drop-down arrow beside the New Condition icon
and select the Elseif option. Then insert a pair of conditionsone after the elseif
line and the other after the then lineas described in step Step 2 on page 399 for
the if-then block.
Repeat this step for any number of elseif-then blocks that you want to create.
4 (Optional) To insert an else statement before the end line, use the Else option from
the drop-down arrow beside the New Condition icon, and then insert one
condition after the else line.
Defining a loop
Loops enable the iterative analysis of conditions (basic conditions or even
conditional constructs) within a group of configuration objects.
To define a loop
1 After selecting the relevant loop option (Foreach Loop, Count Loop, or Exists
Loop) through the drop-down arrow beside the New Condition icon, specify
the following element in the loop line:
For a count loop line, you must also specify the following elements:
a comparison operator for Integer-type data (such as equals, does not equal, is
one of, greater than, orbetween)
2 Click Apply Condition Value at the end of the loop line to apply your
changes (or, alternatively, leave the loop line by clicking outside of it).
You can click Cancel Edit Operation to cancel any editing that you
performed on the loop line as long as you have not yet applied your changes.
b Double-click the New Condition icon for a basic condition, or click the drop-
down arrow beside this icon and select from the full range of available
condition types.
The most typical condition for inclusion in the loop body is a basic condition
that evaluates a property of the configuration object specified in the loop line.
You can combine several conditions within the loop body for a more complex
expression.
The following table lists and describes all comparison operators that are available for
selection in conditions and specifies the operand data types that each operator
supports.
Decimal
Integer
String
count between not relevant (cardinality condition) the number of occurrences of the
configuration object falls within the range
defined by two RHS operands
count does not equal not relevant (cardinality condition) the number of occurrences of the
configuration object specified in the LHS
operand does not equal the value defined
by the RHS operand
count equals not relevant (cardinality condition) the number of occurrences of the
configuration object specified in the LHS
operand equals the value defined by the
RHS operand
count greater than not relevant (cardinality condition) the number of occurrences of the
configuration object specified in the LHS
operand is greater than the value defined
by the RHS operand
count greater than or not relevant (cardinality condition) the number of occurrences of the
equal to configuration object in the LHS operand is
greater than or equal to the value defined
by the RHS operand
count is not one of not relevant (cardinality condition) the number of occurrences of the
configuration object specified in the LHS
operand is not one of the values defined
by the RHS operand
count is one of not relevant (cardinality condition) the number of occurrences of the
configuration object specified in the LHS
operand is one of the values defined by
the RHS operand
count less than not relevant (cardinality condition) the number of occurrences of the
configuration object specified in the LHS
operand is less than the value defined by
the RHS operand
count less than or not relevant (cardinality condition) the number of occurrences of the
equal to configuration object specified in the LHS
operand is less than or equal to the value
defined by the RHS operand
does not contain the LHS operand does not contain the
Long Text string defined by the RHS operand
String
does not contain the LHS operand does not contain the case-
(case sensitive) Long Text sensitive string defined by the RHS
operand
String
does not end with the LHS operand does not end with the
Long Text string defined by the RHS operand
String
does not end with the LHS operand does not end with the
(case sensitive) Long Text case-sensitive string defined by the RHS
operand
String
does not equal all data types the LHS operand does not equal the string
or number defined by the RHS operand
does not equal (case the LHS operand does not equal the case-
sensitive) Long Text sensitive string defined by the RHS
operand
String
does not exist not relevant (cardinality condition) the configuration object specified in the
LHS operand is not present (the number
of occurrences equals zero)
does not have any UNIX Permission the LHS operand does not have any flag
flag matching any of the multiple UNIX
permissions defined by the RHS operand
does not have flag UNIX Permission the LHS operand does not have a flag
matching the UNIX permission defined by
the RHS operand
does not match the LHS operand does not match the
Long Text string defined by the RHS operand
String
does not match mask FilePermission ACE the LHS operand does not match the mask
defined by the RHS operand
does not start with the LHS operand does not start with the
Long Text string defined by the RHS operand
String
does not start with the LHS operand does not start with the
(case sensitive) Long Text case-sensitive string defined by the RHS
operand
String
String
ends with (case the LHS operand ends with the case-
sensitive) Long Text sensitive string defined by the RHS
operand
String
equals all data types the LHS operand equals the string or
number defined by the RHS operand
equals (case the LHS operand equals the case-sensitive
sensitive) Long Text string defined by the RHS operand
String
exists not relevant (cardinality condition) the configuration object specified in the
LHS operand is present at least once (the
number of occurrences is one or more)
greater than the LHS operand value is greater than the
Decimal value defined by the RHS operand
Integer
RegistryAudit ACE
RegistryPermission ACE
has all flags UNIX Permission the LHS operand does not have a flag
matching the UNIX permission defined by
the RHS operand
has any flag UNIX Permission the LHS operand has any flag matching
the UNIX permission defined by the RHS
operand
has flag UNIX Permission the LHS operand have a flag matching the
UNIX permission defined by the RHS
operand
RegistryAudit ACE
RegistryPermission ACE
has no flags UNIX Permission the LHS operand has no flags matching
the UNIX permission defined by the RHS
operand
has only ACEs the LHS operand has only ACE masks
matching masks FileAudit ACE matching the ones defined by the RHS
operand
FilePermission ACE
RegistryAudit ACE
RegistryPermission ACE
String
is one of all data types the LHS operand is one of the items
defined by the RHS operand
is substring of the LHS operand is a substring of the
Long Text string defined by the RHS operand
String
Integer
String
matches mask FilePermission ACE the LHS operand matches the ACE file
permission defined by the RHS operand
newer than days Date the date property of the LHS operand is
chronologically newer than the number of
days specified by the RHS operand
not instance of String the LHS operand is not an instance of the
string defined by the RHS operand
older than days Date the date property of the LHS operand is
chronologically older than the number of
days specified by the RHS operand
starts with the LHS operand starts with the string
Long Text defined by the RHS operand
String
You can test a rule against components on any managed server. You select the test
servers in this procedure. The test servers have no relationship to servers that are
selected on the Discover panel.
This procedure does not actually run the compliance rule on the components. To
perform that procedure, see Creating Compliance Jobs on page 439 or Compliance
results on page 458.
1 On the Compliance panel, select the rule you want to test and click Edit.
2 On the Rule Definition tab in the Compliance Rule Editor, click Test the Rule .
4 Select the components that you want to test against, and click the right arrow to
move your selections to the right panel.
Note
Testing is possible on up to 100 components. For a larger number of components,
create and run a Compliance Job.
5 In the same window, select the server whose components you want to test, and
click the right arrow to move your selections to the right panel.
8 For more details about the success or failure of a component to satisfy the
compliance rule, select the component.
Two panes display on the right. The top pane displays the full rule as defined
through the Rule Editor, including all its conditions (basic conditions, if-then
conditional constructs, or loops). Any condition within the rule that caused the
rule to end in Non-compliant status appears in red. The overall compliance status
for the full compliance rule appears at the top, as well as an indication of whether
any exceptions were defined. The bottom pane displays compliance details on the
target component for a selected condition.
In the bottom pane, the condition is parsed into columns for the left-hand-side
(LHS) operand, comparison operator, and right-hand-side (RHS) operand. An
additional Success column indicates whether the component satisfied the
condition (either true or false). The actual value detected on the target component
appears in brackets after the LHS operand so that you can see how it compares to
the value in the RHS operand.
Note
In the top pane, condition operands or loop operands that are very long are
truncated and end with an ellipsis ().
Cardinality conditions are not parsed in the bottom pane. A basic condition is not
parsed if it contains wild cards and was satisfied by the component.
If a basic condition is preceded by a NOT logical operator, the Success column in
the bottom pane shows a value of true when the condition appears in red in the
top pane.
Lines that were not analyzed appear in gray in the rule in the top pane. For
example: if, then, or else blocks in a conditional construct that were skipped or
not reached.
In a conditional construct only one then line, or the last else line, may appear in
red. All if and elseif lines always appear in black font.
In a Foreach loop, details are displayed in the bottom pane only for the non-
compliant configuration objects. In a Count loop, details are displayed for all
relevant configuration objects (whether compliant or not), but only if the entire
loop was non-compliant.
10 If a condition includes ACL information, you can view detailed ACL information
for a target component by doing the following:
a Select an entry in the Target pane that includes ACL information and click
View ACL Details . A details window opens. It provides a list of applicable
permissions.
b Select a name in the Access Control List, and then click View ACL Details .
Another detail window shows permissions granted to the name you selected.
c Click Close and then click Close again to close both detail windows.
When a Compliance Job runs, it uses the compliance parts on a target and compares
them with the compliance rules specified for that component template. If the parts
on a target do not satisfy a compliance rule, remediation is possible. You can choose
to ignore the failure for this rule, make no remediation on a component at all, or
deploy a BLPackage to resolve the issue.
If you deploy a package, you can specify values for any local properties assigned to
the BLPackage. When you assign values to the BLPackage, you can choose as a value
a local property assigned to the component template. By doing so, you essentially
map a component template property to a BLPackage property. If you have defined
property instances for the component template, a remediation job will apply this
BLPackage to all of those instances if any instance fails this compliance rule.
1 Under Specify Remediation Action on the Remediation tab, select one of the
following:
Disable remediation for all rules on servers where this rule failsNo
remediation is performed on the target component for any rule. In other words,
if this rule fails, do not attempt to perform any remediation on this component.
2 If you selected the Deploy the following BLPackage option for remediation of
the compliance rule, do the following:
a For Package, click Select an object from the Depot to navigate to the
BLPackage that you want to deploy to correct this rule failure.
not satisfied. This option is dimmed if you did not check Allow Auto-
remediation on the General tab of the Component Template definition (see
General tab for a component template on page 373).
c If the BLPackage that you are deploying includes local properties, you can use
the Properties list to edit their values. First select the property to edit. Then,
click in the Value column and enter a new value. Alternatively, you can click
Reset property to default value to enter the default value for this
property.
If any property in the list requires a value, you must provide one before you
can complete this panel of the Compliance Rule Editor.
When you comment out a rule, BMC Server Automation does not validate the rule
when you save the rule in the Compliance Rule Editor or when you save the
component template. When you run a Compliance Job, the job does not evaluate a
compliance rule that is commented out, nor does the rule appear in any Compliance
Job results.
3 Select one or more compliance rules. Right-click and select Comment Out or
Uncomment from the pop-up menu.
When you paste a rule, BMC Server Automation checks its validity, confirming
whether the component templates compliance parts include any parts referenced by
the rule. If the rule references a property, the system confirms that the property
exists and is defined to use the correct data type. When you paste an invalid rule, the
rule appears but is flagged as invalid with a red circle.
2 Navigate to the compliance rule or rules you want to copy and paste or cut and
paste.
3 Select one or more compliance rules. Right-click and select Copy or Cut from the
pop-up menu.
If you are pasting within the same component template, navigate to a rule
group and select Paste.
For either option, to paste at the top level of the rule group hierarchy (that is,
outside of any rule group), right-click in some empty area of the Rules on
Collected Parts panel and select Paste.
These are called local properties, and they only apply to the component template;
they are not available globally like properties created in the Property Dictionary.
The Local Properties tab lets you perform the following procedures:
2 Use the Definition tab to add a local property to the component template or
modify an existing local property.
To modify an existing instance, select the instance and click Edit Property Set
Instance .
Depending on what you select, the Add Property Set Instance or Edit Property Set
Instance dialog box opens.
3 For Name, enter the name of the instance. For Description, you can optionally
provide descriptive text.
4 Click in the Value column for the property that you want to edit.
The Value field becomes active, and it displays utilities for editing the selected
property value.
To set a property value back to its default value, click Reset to Default Value
.
The value of the property is reset to the value it inherits from a built-in
property class. The Value Source column shows the property class from which
the value is inherited.
Depending on the type of property you are editing, you can take different
actions to set a new value, such as entering an alphanumeric string, choosing
from an enumerated list, or selecting a date. To insert a parameter, click Select
Property .
6 Click OK.
For example, if you are setting up multiple instances of an Oracle database on the
same server, you might want to know who has permission to log into each database.
This information can be found in the /network/admin/tsnames.ora file for each
database. Using a local configuration file, you can obtain the contents of the
tsnames.ora file for each database. To accomplish this you first create a local
property called INSTALL_DIR. Then you define instances of that property, which
provide the path to each occurrence of tsnames.ora. Finally, you create a local
configuration file that parses the contents of tsnames.ora. In that local configuration
file, the path to tsnames.ora uses the INSTALL_DIR local property as a parameter,
such as /??INSTALL_DIR??/tsnames.ora. By creating a local configuration file in
this way, you can discover multiple instances of the same component on a server,
and each component can provide the contents of a different tsnames.ora file.
The Local Configuration Objects tab contains icons for adding, copying, and deleting
local configuration files and extended objects on the left panel and editing local
configuration files and extended objects on the right panel.
Note
A local configuration object that you create must not conflict with any global
configuration object defined in the Configuration Object Dictionary. If a
configuration file with the same name and path or an extended object with the same
name and operating system already exists in the Configuration Object Dictionary,
you can not save your local configuration object.
After you associate install and uninstall Batch Jobs with a component template, you
can install components or applications. For more information, see Installing or
uninstalling a component on page 438.
Associating Batch Jobs with a component template lets you manage the full life cycle
of a component or application. The Batch Job can run any type of job necessary to
deploy parts of a component or application. Then the Batch Job can run a Discovery
Job to create the component or application. Similarly, for uninstalls the Batch Job can
delete all parts of a component or application and then run a Discovery Job to
classify the existing component or application as invalid.
These Batch Jobs can include any combination of BLPackage Deploy, File Deploy,
and Network Shell Script Jobs needed to create or uninstall components or
applications. The Batch Job must also include either a Component Discovery Job or
an Application Discovery Job. Application Discovery Jobs are only available if you
have the BMC Application Automation product installed. Typically, discovery jobs
run last in the Batch Job sequence, although that is not a requirement. A Discovery
Job cannot be the first job in a Batch Job.
When you associate a Batch Job with a component template, the system will validate
the structure of the Batch Job when you save or export the template or when you run
an install or uninstall of the template.
After you discover components, you can browse them and run Compliance,
Snapshot, and Audit Jobs on them. You can also bundle the assets of a component
into a BLPackage and deploy that package to servers where the component should
reside.
If components based on a component template already exist and you modify the
definition of the component template, your changes to the component template are
automatically applied to the existing component. However, if you modify the
signature of a component template and then run a Component Discovery Job, the job
flags a component as invalid if its configuration does not satisfy the revised signature.
Open the Jobs folder and select a job group. Right-click and select New =>
Component Discovery Job from the pop-up menu.
Open the Component Templates folder and select a component template. Right-
click and select Discover from the pop-up menu.
Field Definitions
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
To select or remove component templates, you move templates (or template groups
or smart groups) between the Available Templates list and the Selected Templates
list using the arrows. If you opened the Component Discovery Job wizard by right-
clicking a template, that template already appears in the Selected Templates list.
For each component template that you select, you can specify a local property (under
Evaluate All Instances of Selected Property) that refers to a custom property class
when determining whether a target servers properties satisfy the component
templates signature. For a complete description of this capability, see Basing
discovery on a shared set of custom property values on page 419.
For example, you might need to set up several component templates to implement
WebSphere. To discover components based on those templates, you can define
multiple instances of a single custom property class and use those instances to satisfy
the signatures of many component templates. This approach can be much simpler
than defining an instance of a local property for each component template that you
want to discover (as discussed in Component Discovery Job Component Templates
on page 418).
1 Create a custom property class. Define multiple instances for the custom property
class.
2 Create a component template, and then define a local property for that
component template. The local property should be a property class property (a
property that refers to a property class or sub-class) that references the custom
property class that you created in Step 1 on page 419.
3 In the component template (on the Discover tab), define a signature that includes
one or more property values. The property values that are acceptable for the
template should include the property values defined for instances of the custom
property class that you set up in Step 1 on page 419.
4 Open the Component Discovery Job wizard and proceed to the Component
Templates panel.
When you check this property, the Component Discovery Job uses all instances of
the custom property class referenced by this property to determine whether the
target servers properties satisfy the component templates signature.
When you check a local property in the Evaluate All Instances of Select Property
section, the Component Discovery Job ignores any instances for that property that
are defined locally for a component template. If you do not check that local
property, the Component Discovery Job uses any local instances for the property
when determining whether the target servers properties satisfy the component
templates signature.
To select or remove target servers, use the arrows to move servers or server groups
between the Available Targets list and the Selected Targets list.
Note
If you select Linux servers, make sure that the RSCD agent on those servers is
configured with root permissions. Otherwise, a Compliance Job that references
discovered components on the Linux servers fails. The error message in this case is:
Root privileges are required for executing this script.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Component Discovery Job Scheduling on page 422.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Component Discovery Job
Scheduled Job Notifications on page 422.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
These tabs correspond to panels in the New Component Discovery Job wizard.
Use them to modify the job definition.
Select the Properties, Permissions, or Audit Trail tab group to see or modify
any of the properties, permissions, or audit trail information that apply to this
job.
This procedure is also useful if you want to create a component on a server and
bypass the use of local property sets when one or more local property sets are
defined for a component template. For example, suppose you create a component
template with an INSTALL_DIR property, and you define values for this property
using multiple instances of local property sets. One instance sets the value of
INSTALL_DIR to /opt/qa while another sets it to /opt/dev. If you run a Component
Discovery job, it substitutes the /opt/qa and /opt/dev values from the two local
property set instances. However, if you want to provide a different value for one
server, you can insert that value using this procedure.
1 In the Component Templates folder, right-click the component template that you
want to use to create the component. Then select New => Component.
2 Define the new component on the wizard panels, as described in the following
sections:
The component that you defined is associated with the designated server.
Component General
The General panel lets you provide information that identifies the component
template and the server where you want to create a component.
Name
By default, this field uses the name of the component template on which you
are basing this component, but you can enter a different name if necessary.
Description
Component Template
By default, this field uses the component template that you initially selected
when launching the New Component wizard. To choose a different
component template, click Browse , and then navigate to and select the
relevant component template.
The local property set instance that you want to use when creating this
component.
If this component should not use a local property set instance, leave this field
blank.
To provide property values that only apply to this component rather than
using a local property set instance, use the Properties panel of this wizard to
define values for individual local properties.
Server
Click Browse and then navigate to and select the relevant server.
Note
If you select Linux servers, make sure that the RSCD agent on those servers is
configured with root permissions. Otherwise, a Compliance Job that
references discovered components on the Linux servers fails. The error
message in this case is: Root privileges are required for executing
this script.
Component Properties
The Properties panel provides a list of properties automatically assigned to an object.
In this list you can modify the value of any properties that are defined as editable.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
Component Permissions
The Permissions list is an access control list (ACL) granting roles access to any
objects created in the system, such as jobs, servers, or depot objects.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
For more information about compliance exceptions and when you would want to
define them, see About compliance exceptions on page 429.
For instructions on how to specify exceptions to compliance rules through this panel,
see Defining compliance exceptions for a component on page 430.
Note
A similar procedure enables you to define compliance rule exceptions for multiple
components simultaneously. For more information about that procedure, see Setting
multiple components as exceptions to compliance rules on page 434.
For example, when defining a rule you can specify an acceptable range of values
rather than a single value. Even with this level of flexibility, a component may not
always satisfy compliance rules in some circumstances. In such a situation, you can
set up compliance exceptions that excuse a particular component from meeting some
or all compliance rules defined in the component template.
Exceptions can be defined for an entire compliance rule. You can also narrow the
applicability of an exception to a specific system object if that object can be expressed
as a path, such as a file with a particular name or a particular value within a
configuration file.
For example, suppose you want to define a rule stating that only two names can
exist within the etc/passwd file. You define a compliance rule stating that the /etc/
passwd configuration file must exist and that the only entries allowed within it are
Admin and SupportLevel2. Such a rule would look like this:
Using a wild card in the second condition instructs the compliance rule to examine
all values listed within the /etc/passwd configuration file.
For an individual component, you can grant an exception to this rule, which means
that the rule can be ignored for that component. If you want a more specific
exception, you can specify a particular user entry in the configuration file that
should be ignored. If you wanted to allow a user called SupportLevel1 in the /etc/
passwd file, you could instruct the system to ignore the path /etc/passwd//
SupportLevel1 when evaluating this compliance rule. The result is that Admin,
SupportLevel1, and SupportLevel2 are all permissible entries within the /etc/
passwd file for that component.
Depending on which action you take, the Add Compliance Exception or the Edit
Compliance Exception window opens.
Name
Description
Reference Number
Duration
Either click Never expires if you do not want to limit the exception by time,
or click Expires and pick the date when the exception should expire.
Notes
4 Click Add Compliance Rule . The Select Compliance Rules dialog box opens.
5 Use the Select Compliance Rules dialog box to define compliance rule exceptions
by doing the following:
a Select the compliance rule for which you want to grant an exception and move
it to the Selected Compliance Rules list on the right.
The All Compliance Rules list shows all compliance rules and compliance rule
groups. To move a rule between lists, select the rule and click the left or right
arrow. If necessary, expand compliance rule groups to select the appropriate
compliance rules. To move all rules from the Selected Compliance Rules list,
click the double-left arrow.
b If you do not want to limit this exception to particular system objects, click OK.
Then click OK on the Add Compliance Exception dialog box. The procedure is
complete.
If you want to limit this exception on the specific target component, specify a
path to a particular system object by clicking Edit Ignored Paths . The Edit
Ignored Paths dialog box opens.
1 On the Edit Ignored Paths dialog box, from Type, select the type of server
object that should be ignored.
2 For Path, enter the path to the server object. The path can include wild cards.
3 Click the right-arrow to move the server object you have defined to the
Detailed Exceptions list.
For example, you can create a compliance rule stating that the configuration
file /etc/passwd must exist and that the only entries allowed within it are
Admin and SupportLevel2. If you want to create an exception for a specific
component that allows the SupportLevel1 entry to appear as well within the
file, use this dialog box to specify a type of Configuration File and enter the
6 On the Add Compliance Exception dialog box, click OK. The exception you
defined is added to the Compliance Exceptions list. To add another exception,
repeat this procedure.
Modifying components
You can modify a component.
Typically, to modify a component, you change the component template (as described
in Editing a component template on page 371) and your changes are automatically
applied to all components that are based on that template. However, in some
situations you may want to modify general properties of a component. The most
common of these situations is when you want to define an exception for a
component so it does not have to satisfy one or more compliance rules. You can use
this procedure to view and modify other characteristics of the component, such as its
properties and permissions.
To modify a component
The Edit Component window opens. It includes a series of tabs, which are
described in the following sections:
The tabs on the Edit Component window correspond to the panels in the New
Component wizard (used for manually creating components). Use them to
modify various aspects of the component, including any compliance exceptions.
Validating a component
To quickly determine whether a components signature conditions are valid on its
associated target server, you can run a short validation process on any existing
component.
This validation process is useful in the case of components that you created
manually, or if you need to re-validate a component after modifying the signature in
the component template.
The Validate window is displayed. This window is divided into two panes. The
top pane displays the full signature as defined through the Rule Editor, including
all of its conditions and if-then conditional constructs.
2 Click Run Test at the top right corner of the Validate window.
The signature rule is validated. Any condition within the rule that caused the rule
to end in Non-compliant status appears in red in the top pane. The bottom pane
displays compliance details for a selected condition.
In the bottom pane, the condition is parsed into columns for the left-hand-side
(LHS) operand, comparison operator, and right-hand-side (RHS) operand. An
additional Result column indicates whether the component satisfied the
condition (either for true or for false). The actual value detected on the
target component appears in brackets after the LHS operand so that you can see
how it compares to the value in the RHS operand.
Note
In the top pane, condition operands that are very long are truncated and end with
an ellipsis ().
Cardinality conditions are not parsed in the bottom pane. A basic condition is not
parsed if it contains wild cards and was satisfied by the component.
If a basic condition is preceded by a NOT logical operator, the Success column in
the bottom pane shows a value of true when the condition appears in red in the
top pane.
Lines that were not analyzed appear in gray in the rule in the top pane. For
example: if, then, or else blocks in a conditional construct that were skipped or
not reached.
In a conditional construct only one then line, or the last else line, may appear in
red. All if and elseif lines always appear in black font.
For more information about compliance exceptions and when you would want to
define them, see About compliance exceptions on page 429.
1 Display the Set Components Exception wizard by doing any of the following:
In the Jobs folder, right-click a Compliance Job and select Show Results. Then
expand a run of the Compliance Job, and, using the Rules View or Servers
View nodes, navigate to a node that has multiple components associated with
it. Then, do one of the following:
The components that you specified are excused from the selected compliance rules.
Name
Description
Reference Number
Duration
To set an expiration date for the exception, click Expires and pick the date
when the exception should expire. Otherwise, click Never expires if you do
not want to limit the exception by time.
Notes
The All Compliance Rules list shows all compliance rules and compliance rule
groups. To move a rule between lists, select the rule and click the left or right arrow.
If necessary, expand compliance rule groups to select the appropriate compliance
rules. To move all rules from the Selected Compliance Rules list, click the double-left
arrow.
If you want to limit this exception on the specific target component, specify a path to
a particular system object by clicking Edit Ignored Paths . The Edit Ignored Paths
dialog box opens.
1 On the Edit Ignored Paths dialog box, from Type, select the type of server object
that should be ignored.
2 For Path, enter the path to the server object. The path can include wild cards.
3 Click the right-arrow to move the server object you defined to the Detailed
Exceptions list.
For example, you can create a compliance rule stating that the configuration file /
etc/passwd must exist and that the only entries allowed within it are Admin and
SupportLevel2. If you want to create an exception for a specific component that
allows the SupportLevel1 entry to appear as well within the file, use this dialog
box to specify a type of Configuration File and enter the path /etc/passwd//
SupportLevel1. During compliance analysis, if /etc/passwd on the target
component contains the two entries Admin and SupportLevel1, the component is
found to be compliant with the rule due to the defined exception.
Name
Description
Reference Number
Duration
To set an expiration date for the exception, click Expires and pick the date
when the exception should expire. Otherwise, click Never expires if you do
not want to limit the exception by time.
Notes
Identify the components where you want to define exceptions by moving those
components from the Available Components list to the Selected Components list. If
you opened the Set Components Exception wizard by selecting some components,
those components already appear in the Selected Components list.
For information about creating a new group, see Creating a folder or group on page
107. For information about creating a smart group, see Defining a smart group on
page 108.
2 Right-click the component group and select Add to Group from the pop-up
menu. The Add Components to Group window opens.
3 From the Available Components list, select the components that should be stored
in the component group and move them to the Selected Components list.
right arrow. Use Shift-click or Control-click to select multiple parts. To remove all
components from the Selected Components list, click the double-left arrow.
4 Click OK.
Using Batch Jobs in this way lets you manage the full life cycle of a component.
When creating a component, the Batch Job can include jobs that deploy component
parts and then run a Component Discovery Job to discover the component. When
uninstalling, the Batch Job can delete component parts and then run a Component
Discovery Job to invalidate the existing component. Similarly, the Batch Job can run
an Application Discovery Job to discover a new application or invalidate an existing
one. Application Discovery Jobs are only available if you have the BMC Application
Automation product installed.
Note
If you run a Batch Job that is associated with a component template manually rather
than using this procedure, no validation of the Batch Job occurs.
You must associate Batch Jobs with a component template so those jobs can be used
for installing or uninstalling components.
These Batch Jobs can include any combination of BLPackage Deploy, File Deploy,
and Network Shell Script Jobs needed to create or uninstall components or
applications. The Batch Job must also include either a Component Discovery Job or
an Application Discovery Job. Typically, discovery jobs run last in the Batch Job
sequence, although that is not a requirement. A discovery job cannot be the first job
in a Batch Job.
The system validates the Batch Job and then opens the Execute Job Now window
for the Batch Job associated with the component template.
3 Select targets for the Batch Job and then click OK to execute the job immediately.
The Compliance Job looks at the components compliance parts and compares them
to the part and property conditions that the compliance rules require. The
compliance parts must satisfy the compliance rules.
If a rule is not met and remediation is enabled, you can correct the compliance
failure by deploying a BLPackage to one or more servers, assuming that a BLPackage
is specified as part of the compliance rules. A Compliance Job can automatically
perform this remediation if you enable automatic remediation for both the job
definition and the component template. Alternatively, you can review the results of a
Compliance Job and manually choose the compliance rule failures that require
remediation (see Manually remediating compliance results on page 467).
After you run a Compliance Job, you can do any of the following:
View the results of the job (see Compliance results on page 458)
Export some or all of the results of the Compliance Job (see Exporting compliance
results on page 471)
Open the Jobs folder and select a job folder. Right-click and select New =>
Compliance Job.
2 Define the Compliance Job on the wizard panels, as described in the following
sections:
Field Definitions
Name
Identifying name.
Description
Save in
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Whether the job should continue even though it encounters required parts
that are missing.
If you check this option, the Compliance Job will complete with warnings
even though individual components may not satisfy some compliance rules
because parts are missing.
servers, server groups, or smart server groups. Move objects between the Available
Components list and the Selected Components list using the arrows. If you opened
the Compliance Job wizard by right-clicking a component, that component already
appears in the Selected Components list.
If you select a component group or smart component group, the Compliance Job
runs against the components assigned to that group at the time of execution. If you
select a server, the job runs against all components on that server. If you select a
server group or smart server group, the job runs against all components on all
servers in that group.
If you leave the Selected Components list empty, the job runs on all components that
have been discovered for the component templates specified in the Component
Templates for Filtering panel.
When you choose to autoremediate Compliance Job results, the remediation jobs
start immediately after the Compliance Job completes. The Compliance Job is not
considered complete until all remediation jobs complete. If you prefer, you can
manually create and deploy the package needed to remediate the results of a
Compliance Job. For information, see Manually remediating compliance results on
page 467.
For more information about remediation jobs and remediation packages, see About
remediation packages and remediation jobs on page 444.
This panel contains the following fields and screen elements for setting up
autoremediation:
Remediation name
BMC Server Automation generates a default name for the remediation job
based on the Compliance Job name, the remediation name, and the date. If
the job generates a Batch Job, the name you enter here is also assigned to the
Batch Job.
Save package in
The depot folder where you want to store the BLPackages that are generated
by the remediation job.
The job group where you want to store any Deploy Jobs (and potentially a
Batch Job) that this procedure generates.
Template
If you select this option, each property is indexed so that all references to a
particular property are retained, even though property names are the same.
In addition, the default value for each property is retained.
If you clear this option, property names are left untouched. However, the
default value assigned to the property becomes the value of the property for
the first failed compliance rule that is merged into the remediation package.
Indicates whether Deploy Jobs should target the servers (or other devices)
associated with the components that are the targets of this Compliance Job. If
you clear this option, the Deploy Jobs use the components that are targets of
this Compliance Job as the targets for the remediation job.
The items in a remediation package are arranged in the same order as compliance
rules are arranged in the component template. For example, if the first failed rule
specifies that a BLPackage called Fix1 should be deployed and the second failed rule
specifies that a BLPackage called Fix2 should be deployed, the remediation package
includes the items from Fix1 followed by the items from Fix2. If two or more of the
BLPackages being aggregated include local properties with the same name, the
properties are renamed and all references to each renamed property are updated.
When BMC Server Automation automatically creates Deploy Jobs for remediation
jobs, it applies default settings to those Deploy Jobs. BMC Server Automation
provides a procedure for specifying your own customized settings for Deploy Jobs
created for remediation purposes. This procedure can be very helpful if a
remediation job launches many Deploy Jobs. For more information about the
procedure, see Setting deploy options for remediation jobs on page 445.
When BMC Server Automation automatically creates Deploy Jobs or Batch Jobs for
remediation, it sets the AUTO_GENERATED property to True for those jobs.
Similarly, if BMC Server Automation automatically creates BLPackages for
remediation, it sets AUTO_GENERATED to True for those BLPackages. When these
objects have AUTO_GENERATED set to True, they are automatically deleted at a
later date according to the retention policy you set up for automatically generated
objects. For more information about managing BMC Server Automation data and
deletion of auto-generated objects, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Marking+data+for+deletion.
Typically, when you create remediation jobs, either automatically or manually, BMC
Server Automation automatically creates Deploy Jobs to deploy remediation
packages. Those Deploy Jobs use default settings. To modify those settings, you
modify the definition of each Deploy Job. If you are running many Deploy Jobs, that
task can become laborious.
This procedure provides a mechanism for customizing Deploy Job behavior for all
Deploy Jobs that are created automatically when you remediate Compliance Job
results.
3 When defining a Compliance Job, use the Properties panel to specify a value for
the DEPLOY_OPTIONS_INSTANCE_FOR_REMEDIATION property. The value
you specify should be the DeployOptions instance you created in the previous
step.
For more about setting these options, see Setting deploy options for remediation jobs
on page 445.
AGENT_CONNECTION Integer Enter a maximum period of time in minutes that the Deploy Job
_TIMEOUT can wait after the Application Server loses contact with the target
server. If the specified period of time elapses, the job fails.
If you do not enter any value or you enter 0, the job waits
indefinitely.
AGENT_QUEUE_WAIT Integer Enter a maximum period of time in minutes that the Deploy Job
_TIMEOUT can wait for the agent on the target server to process this Deploy
Job. Waits typically occur when agents have queued Deploy Jobs.
If the specified period of time elapses, the job fails.
If you do not enter any value or you enter 0, the job waits
indefinitely.
BY_PHASE_ALL_HOST Boolean Enter True to instruct the job to undo the Commit phase for all
_MUST_PASS_COMMIT target servers if any servers do not successfully complete the
Commit phase. By default this option is set to False. This option is
only applicable when the FLOW_CONTROL option is set to
ByPhase.
COPY_LOCKED_FILES Boolean Enter True to instruct a target server to create copy on boot files
when locked files are encountered during the Commit phase of a
Deploy Job.
Entering False means the job generates an error and fails if it
encounters locked files.
Note that a Deploy Job only creates copy on boot versions of read-
only files if the OVERWRITE_READONLY_FILES option is set to
True.
ENABLE_SINGLE_JOB_ Boolean Enter True to instruct the Deploy Job to run in single-job mode
MODE that is, it cannot run in parallel on a target server with any other
Deploy Jobs.
A job in single-job mode can only run when no other Deploy Job
is currently being processed on the same target server. If other
Deploy Jobs are processing, this Deploy Job waits until they are
complete. While this job is being processed on a target server, no
other Deploy Job can run.
FLOW_CONTROL Enumerated Specify how you want to control the flow of a job by choosing one
of the following:
FOLLOW_SYMLINKS_ Boolean Enter True if a Deploy Job should copy the target of a symbolic
ON_URL link included in a URL; enter False if a Deploy Job should copy
only the symbolic link itself. This option only applies when you
are using the Copy to Agent at staging option to provide a URL
that identifies source files for a patch or software package.
IGNORE_COPY_ON_BO Boolean Enter True to instruct a server to begin the Commit phase of the
OT_FILES Deploy Job even though a server requires a reboot to copy over
existing locked files.
Entering False means the Commit phase does not begin if locked
files requiring a reboot exist.
IS_ALLOW_ROLLBACK Boolean Enter True to instruct the Deploy Job to leave rollback files on the
target server so they can potentially be used later. In some
situations the rollback files left on the target server can be very large.
IS_AUTO_ROLLBACK Boolean Enter True to instruct the Deploy Job to leave the destination host
unchanged should the Commit phase fail.
When you set this option to True and the Commit phase fails for
any reason, the Deploy Job is automatically rolled back, leaving
the destination host unchanged. If you set this option to False and
the Commit phase fails, the deployment aborts and does not roll
back any transactions that are part of the deployment.
IS_COMMIT_ENABLED Boolean Enter True to enable the Commit phase of the Deploy Job. During
the Commit phase, packages are applied to target servers.
IS_RECONFIGURE_REB Boolean Enter True if any end-of-job reboots specified in
OOT REBOOT_OPTIONS should be Solaris reconfiguration reboots.
IS_SIMULATE_ENABLE Boolean Enter True to enable the Simulate phase of the Deploy Job. The
D Simulate phase performs a dry run of a deployment without
actually deploying a package. A dry run lets you review job
results, see the server objects that are changed during
deployment, and determine what actions, if any, are causing the
deployment to fail (that is, to generate a non-zero return code).
IS_STAGING_INDIREC Boolean Enter True to enable indirect staging, which means the Deploy
T Job delivers the package to a repeater. During the Commit phase,
the package is applied to the target server.
Entering False means the job delivers the package directly to a
target server.
Note: If you are staging indirectly, you must define a property
that identifies a repeater for each target server.
ITEM_RECONFIGURE_ Enumerated Specify how the Deploy Job should handle item-level
REBOOT_OPTIONS reconfiguration reboots by selecting one of the following:
LOGGING_LEVEL Enumerated Specify the amount of logging information that the Deploy Job
generates by choosing one of the following:
OVERWRITE_READON Boolean Enter True to instruct a server to overwrite read-only files when
LY_FILES read-only files are encountered during the Commit phase.
PRESERVE_STAGING_ Boolean Enter True to retain data copied to a staging area on a target
DIR_ON_FAILURE server even though the Deploy Job fails.
By default a Deploy Job deletes the staging directory on a target
server when a failure occurs during any phase of the job.
Preserving a staging area can potentially leave large files on a
target directory after a job failure.
REGISTER_COM_COMP Boolean Enter True to register COM objects during the Commit phase.
ONENTS When a deployment adds a file with an extension of DLL, EXE, or
OCX, the job determines whether the file is a COM object. If it is,
the deployment registers the new object during the Commit phase.
REGISTER_COM_COMP Boolean Enter True to register COM objects during the Undo phase.
ONENTS_FOR_UNDO If the Commit phase of a job run removes a file, the file is restored
when that job run is undone. If the file has an extension of DLL,
EXE, or OCX, the job determines whether the file is a COM object.
If it is and this option was set to True during the Commit phase of
the job run being undone, the file being restored is registered.
RESET_JOB_ON_FAILU Boolean Setting this option to True allows a job to be run again even
RE though the job failed at least one phase on at least one server. By
default this option is set to False.
If you set this option to True, failed jobs are placed into a Reset
state. If you do not set this option to True, a job cannot be run
again until it completes successfully
UNREGISTER_COM_C Boolean Enter True to unregister COM objects during the Commit phase.
OMPONENTS_FOR_CO When a deployment removes a file with an extension of DLL,
MMIT EXE, or OCX, the job determines whether the file is a COM object.
If it is, the deployment unregisters the object during the Commit
phase.
UNREGISTER_COM_C Boolean Enter True to unregister COM objects during the Undo phase.
OMPONENTS_FOR_UN If the Commit phase of a job run adds a file, the file is removed
DO when that job run is undone. If the file has an extension of DLL,
EXE, or OCX, the job determines whether the file is a COM object.
If it is and this option was set to True during the Commit phase of
the job run being undone, the file being removed is unregistered.
USER_MODE_OPTIONS Enumerated Specify user mode behavior (only applicable to UNIX target
_UNIX_ONLY systems) by choosing one of the following:
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
The Default Notifications panel also lets you define email messages and SNMP traps
that are generated based on the results of the Compliance Job. You can send
notifications when target components have compliant configurations, non-compliant
configurations, or both.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Compliance Job Scheduling on page 455.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Compliance Job
Scheduled Job Notifications on page 454.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Send email to
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job will always execute at the time you have specified. BMC
Server Automation automatically accounts for differences in time zones and changes
in daylight savings time. For example, if you schedule a job that should run weekly
at 06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing Compliance Job, open the Jobs folder
and navigate to an existing job. Right-click the job and select Open from the pop-
up menu. The content editor displays a series of tabs, which are described in
the following sections:
These tabs correspond to panels in the New Compliance Job wizard. Use them
to modify the job definition.
Select the Properties, Permissions, or Audit Trail tab group to see or modify
any of properties, permissions, or audit trail information that apply to this job.
Compliance results
The results of Compliance Jobs show how components satisfy or fail to satisfy the
compliance rules established in a component template. Compliance Job results also
show the outcome of any auto-remediation.
After running a Compliance Job, you can display job results in a tab in the content
editor. The tab contains a hierarchical tree that shows results for each run of the job.
The following nodes under each job run present different views of the results:
Selecting nodes below the Rules View or Server View nodes displays additional
details about a portion of the hierarchical tree.
To view Compliance Job results, any of the following procedures are possible:
To use Compliance Job results, any of the following procedures are possible:
After you display Compliance Job results, you can export some or all of the results of
the Compliance Job (see Exporting compliance results on page 471).
Note
The Application Server can be configured to set a maximum number of results that
are displayed for any failed condition in a compliance rule. If you are running a
Compliance Job that examines large numbers of component parts that fail a
compliance rule, you can potentially tax your system resources, particularly disk
space. If results for a Compliance Job exceed the limits defined for the Application
Server, the job run icon shows a warning and the job log includes a message saying
that job results are truncated.
By default the maximum number of results for a failed condition is set to 100. To
change this maximum, use the Application Server Administration console (that is,
the blasadmin utility) to set another value for the
ComplianceResultMaxNumberOfAssets option. For more information, see BMC
technical documentation at https://docs.bmc.com/docs/display/bsa82/Managing
+the+Application+Server.
Example
If a condition states that a symbolic link must start with the letter A, the condition is
Compliant if the symbolic link being evaluated actually does start with A.
1 In the Jobs folder, select a Compliance Job, right-click, and select Show Results.
A new tab opens in the content editor. It shows the Compliance Job results.
2 In the hierarchical tree on the left of the tab, expand a particular run of the
Compliance Job, and click the Rules View node.
Summary results are displayed for the Compliance Job, with the number of rules
in each compliance status (Compliant, Compliant with Exceptions, Non-
compliant, Failed, and Indeterminate).
3 Expand the tree under Rules View and select a component template or a rule
group.
The content editor provides summary information for the rule groups defined in
the component template or the rules included in the rule group.
The components on which the rule was analyzed are listed under the rule. The
Compliance column in the right pane shows the compliance status for each
component.
Note
The maximum number of components that are displayed under the expanded
compliance rule is controlled by the Page Size setting in the Preferences dialog
box, with a default value of 50. If more components exist, you can page through
the results, as described in Paging through job results on page 75.
1 In the Jobs folder, select a Compliance Job, right-click, and select Show Results.
A new tab opens in the content editor. It shows the Compliance Job results.
2 In the hierarchical tree on the left of the tab, expand a particular run of the
Compliance Job, and click the Server View node.
Summary results are displayed for each server examined by the Compliance Job,
with the number of rules in each compliance status (Compliant, Compliant with
Exceptions, Non-compliant, Failed, and Indeterminate).
3 Expand the tree under Server View and select a server or a component.
The servers examined by the Compliance Job are listed under the Server View
node. The components are listed on the next level, followed by the rule groups
and rules associated with the component.
The content editor provides summary information for the components on the
server or the rule groups associated with the component.
Note
The maximum number of servers that are displayed under the expanded Server
View node is controlled by the Page Size setting in the Preferences dialog box,
with a default value of 50. If more servers exist, you can page through the results,
as described in Paging through job results on page 75.
The Compliance column in the right pane shows the compliance status for each
rule within the rule group.
1 In the Jobs folder, select a Compliance Job, right-click, and select Show Results.
A new tab opens in the content editor. It shows the Compliance Job results.
2 In the hierarchical tree on the left of the tab, expand a particular run of the
Compliance Job, and do one of the following:
Select the Server View node, expand a server, expand a component, expand a
rule group, and then select a rule.
Select the Rules View node, expand a component template, expand a rule
group, expand a rule, and then select a component.
Two panes display on the right. The top pane displays the full rule as defined
through the Rule Editor, including all its conditions (basic conditions, if-then
conditional constructs, or loops). Any condition within the rule that caused the
rule to end in Non-compliant status appears in red. The overall compliance status
for the full compliance rule appears at the top, as well as an indication of whether
any exceptions were defined. The bottom pane displays compliance details on the
target component for a selected condition.
In the bottom pane, the condition is parsed into columns for the left-hand-side
(LHS) operand, comparison operator, and right-hand-side (RHS) operand. An
additional Success column indicates whether the component satisfied the
condition (either true or false). The actual value detected on the target component
appears in brackets after the LHS operand so that you can see how it compares to
the value in the RHS operand.
Note
In the top pane, condition operands or loop operands that are very long are
truncated and end with an ellipsis (). To view the full text within such
conditions or loops, click the Condition Zoom In View button and select the
relevant lines. The selected lines are presented in the read-only Rule Editor
Condition Zoom view.
Cardinality conditions are not parsed in the bottom pane. A basic condition is not
parsed if it contains wild cards and was satisfied by the component.
If a basic condition is preceded by a NOT logical operator, the Success column in
the bottom pane shows a value of true when the condition appears in red in the
top pane.
Lines that were not analyzed appear in gray in the rule in the top pane. For
example: if, then, or else blocks in a conditional construct that were skipped or
not reached.
In a conditional construct only one then line, or the last else line, may appear in
red. All if and elseif lines always appear in black font.
In a Foreach loop, details are displayed in the bottom pane only for the non-
compliant configuration objects. In a Count loop, details are displayed for all
relevant configuration objects (whether compliant or not), but only if the entire
loop was non-compliant.
4 If an exception has been defined for a rule, you can view that exception by doing
the following:
a Click View Exceptions. The View Associated Exceptions dialog box opens.
c To view the rules for which exceptions are granted, click the Associated
Compliance Rules tab. If you have specified particular paths that should not
be evaluated, the Ignored paths column lists them.
5 If a condition includes ACL information, you can view detailed ACL information
for a target component by doing the following:
a Select an entry in the Target pane that includes ACL information and click
View ACL Details . A details window opens. It provides a list of applicable
permissions.
b Select a name in the Access Control List, and then click View ACL Details .
Another detail window shows permissions granted to the name you selected.
c Click Close and then click Close again to close both detail windows.
For example, a Compliance Job may identify a particular component that does not
satisfy compliance rules for a component template but you are certain that the
component should be allowed in this context. For example, you may know that the
server will soon be modified so that it satisfies the compliance rule in the future.
When defining exceptions to compliance rules, you can flag either a single
component or multiple components.
1 In the Jobs folder, select a Compliance Job, right-click, and select Show Results.
A new tab opens in the content editor. It shows the Compliance Job results.
2 In the hierarchical tree on the left of the tab, expand a particular run of the
Compliance Job, and navigate to any single component listed under the Server
View or Rules View node.
The Edit Component dialog box opens, and the Compliance Exceptions tab is
automatically selected.
4 Use the Edit Component dialog box to define any compliance exceptions. For
more information about this procedure, see Component Compliance exceptions
on page 429.
1 In the Jobs folder, select a Compliance Job, right-click, and select Show Results.
A new tab opens in the content editor. It shows the Compliance Job results.
2 In the hierarchical tree on the left of the tab, expand a particular run of the
Compliance Job, and do any of the following:
Using the Rules View node, select a component template, compliance rule
group, or compliance rule that has multiple components associated with it. Right-
click and select Set Exception.
Using the Rules View node, select a component template, compliance rule
group, or compliance rule that has multiple components associated with it. In
the content editor, select multiple components. Right-click and select
Exceptions.
Using the Server View node, select a server that has multiple components
associated with it. In the content editor, select multiple components. Right-click
and select Exceptions.
3 Use the Set Component Exceptions wizard to define compliance exceptions. For
more information about this procedure, see Component Compliance exceptions
on page 429.
The Deploy Status tab presents a matrix. Each row shows information about a server
where a Deploy Job ran to remediate compliance rule failures. Each column shows
the results for each phase of the Deploy Job. The Log Messages tab shows messages
that were generated for the entire remediation job.
1 In the Jobs folder, select a Compliance Job, right-click, and select Show Results.
A new tab opens in the content editor. It shows the Compliance Job results.
2 In the hierarchical tree at the left of the tab, expand a particular run of the
Compliance Job, and select the Remediation View node.
To remove a server from the target servers for this job, select a server where the
job is incomplete, right-click, and select Remove.
To retry the job on a server, select a server where the job is incomplete, right-
click, and select Retry. The job immediately runs the phase of the job that did
not complete previously.
To retry the job for multiple servers and phases, select the cells where the job is
incomplete. Right-click and select Retry from the pop-up menu. The job
immediately runs the phases of the job that previously did not complete on the
selected servers. Use Control-click or Shift-click to select multiple cells.
To show the current status of all target servers, click Show Summary on the
Deploy Status tab. To show the history of all job attempts, click Show Details
on the Deploy Status tab
Undoing autoremediation
You can undo packages that are committed to target servers as part of a Deploy Job
that automatically remediated Compliance Job results.
When you perform this procedure on a job in an Incomplete state, the job remains in
an Incomplete state. If you perform it on a job in a Failed or Succeeded state, the job
remains in a Failed or Succeeded state.
To undo autoremediation
To undo all committed packages for the most recent run of a remediation job,
right-click the Remediation View node for that job run and select Undo.
To undo committed packages for selected servers, select cells in the Commit
column for those servers. Use Shift-click or Control-click to select multiple cells.
Right-click and select Undo.
A confirmation dialog box shows the remediation job that is rolled back and lists
the servers for which you are undoing remediation.
2 Click OK to confirm the undo. A dialog box announces that the undo is in process
and allows you to cancel the undo if necessary.
After undoing a remediation job, you can display the Deploy Status panel again.
It now includes a column called Rollback, which shows the status of the undo. To
display messages about the undo for a specific server, select a cell under the
Rollback column.
For more information about remediation jobs and remediation packages, see About
remediation packages and remediation jobs on page 444.
You can use a similar procedure to create a remediation package that is stored in the
Depot without also creating a Deploy Job to deploy the package. For the details of
that procedure, see Creating a remediation package on page 469.
When you manually remediate Compliance Job failures and BMC Server
Automation automatically creates Deploy Jobs for a remediation job, the system
applies default settings to those Deploy Jobs. BMC Server Automation provides a
procedure for specifying your own customized settings for Deploy Jobs that are
automatically created for remediation purposes. This procedure can be very helpful
if a remediation job launches many Deploy Jobs. For more information about the
procedure, see Setting deploy options for remediation jobs on page 445.
1 In the Jobs folder, select a Compliance Job, right-click, and select Show Results.
A new tab opens in the content editor. It shows the Compliance Job results.
2 In the hierarchical tree on the left of the tab, expand a particular run of the
Compliance Job, and do one of the following:
Using the navigation pane on the left, select any node under that job run from
the Server View or Rules View node down.
Use the navigation pane to select a node under the Compliance Job run, and
then select multiple sub-nodes on the content editor. For example, if you select
the Server View node on the left, you can select multiple servers on the right.
3 Right-click and select Remediate to open the Remediate Job Result window.
Note
The Remediate option is only available if the item you have selected includes one
or more compliance rules needing remediation and those compliance rules
include remediation options. For more information about defining compliance
rules, see Compliance tab for a component template on page 384.
4 For Remediation name, enter a name for the remediation job. If the job generates
a Batch Job, the name you enter here is also assigned to the Batch Job.
5 For Save package in, click Browse and navigate to the depot folder where you
want to store the BLPackage generated by this procedure.
6 For Save remediation/deploy job in, click Browse and navigate to the job group
where you want to store any Deploy Jobs (and potentially a Batch Job) that this
procedure generates.
7 Select Keep each local property name unique in remediation package if you
want the remediation package to include duplicate property names for individual
compliance rules that have failed. Although their names are the same, each
property is indexed so that all references to a particular property are retained. In
addition, the default value for each property is also retained.
If you clear this option, property names are left untouched. However, the default
value assigned to the property becomes the value of the property for the first
failed compliance rule that is merged into the remediation package.
8 Select Use servers as remediation target if you want any Deploy Jobs to target the
servers (or other devices) associated with the components that are the targets of a
Compliance Job. If you clear this option, the Deploy Jobs use the components that
are targets of the Compliance Job as the targets for the remediation job.
9 Click OK.
BMC Server Automation examines the failed compliance rules and creates a
remediation job by doing one of the following:
If you are remediating multiple components and BMC Server Automation has
created more than one Deploy Job to deploy multiple remediation packages, a
Batch Job appears. The Batch Job is defined to run the Deploy Jobs needed to
remediate the target components.
A remediation package is a BLPackage that contains all the items in each BLPackage
that is supposed to be deployed for each compliance rule that a target component
has failed. For more information about remediation jobs and remediation packages,
see About remediation packages and remediation jobs on page 444.
This procedure does not create a Deploy Job to deploy the remediation package. To
create and deploy a remediation package, see Manually remediating compliance
results on page 467. You can also define a Compliance Job to automatically
remediate failed components so that the job itself creates a remediation package and
deploys it to failed components (see Creating Compliance Jobs on page 439).
1 In the Jobs folder, select a Compliance Job, right-click, and select Show Results.
A new tab opens in the content editor. It shows the Compliance Job results.
2 In the hierarchical tree on the left of the tab, expand a particular run of the
Compliance Job, and do any of the following:
Under the Server View node, select any component or select one or more rule
groups or rules.
4 For Package name, enter a name for the BLPackage created for remediation.
5 For Save package in, click Browse and navigate to the depot folder where you
want to store the remediation package generated by this procedure.
6 Click OK.
The BLPackage is added to the Depot and the New Deploy Job wizard opens. The
wizard uses information from the BLPackage to complete the Name and
Description fields on its first panel.
4 Use the Deploy Job wizard to define and launch a Deploy Job for the BLPackage
that you have just saved, as described in Creating a Deploy Job on page 718.
The HTML format is especially suitable for printing or viewing with a web browser.
The CSV (comma-separated value) format can be imported into databases or
spreadsheets.
2 From the results tree displayed in the left pane, select the branch of the results
you want to exportany branch under a specific job run.
4 For Object Name, provide a file name and location where you want to store the
exported results. For Object Type, select one of the following file formats:
5 From File encoding, select the type of character encoding for the exported data,
such as UTF8 or UTF16.
This topic provides an example that demonstrates how these tools, when used
together, can monitor and enforce compliance for multiple instances of the same
application running on the same server.
In this example, suppose you are running multiple instances of an Oracle database
on the same server, and you want to ensure that none of these instances are
communicating over the standard Oracle port, 1521. Using the standard Oracle port
makes it easier to gain unauthorized access to the database.
For the purposes of this example, two Oracle 10g instances are installed in the D:
\oracle1 and D:\oracle2 directories:
a In the component template definition, create a local property that can be used
to define the path to the two Oracle instances. The property should be called
ORACLE_PATH.
b Create two property instances. For one, define the ORACLE_PATH property
to equal oracle1. For the other, define the ORACLE_PATH property to equal
oracle2.
For more information about local properties and property instances, see Local
properties for a component template on page 412.
c Create a local configuration file for the listener.ora file. The path to listener.ora
should include the local property you defined in the previous step, as shown
below:
/d/??ORACLE_PATH??/product/10.1.0/Client_1/network/ADMIN/
listener.ora
For more information about local configuration files, see Local Configuration
Objects tab for a component template on page 414.
/d/??ORACLE_PATH??/product/10.1.0/Client_1/network/ADMIN/
listener.ora
For more information about component template parts, see Parts tab for a
component template on page 374.
e Create a signature for the component template. The only requirement for the
signature is that the listener.ora file must exist.
For more information about creating signatures, see Discover tab for a
component template on page 375.
For more information about Component Discovery Jobs, see Creating Component
Discovery Jobs on page 416.
4 Open the Oracle Security component template and create a compliance rule
called Allowed Oracle Ports by doing the following:
For more information about creating compliance rules, see Compliance tab for
a component template on page 384.
c Define a value for the ORACLE_PATH local property of the BLPackage. Set
the value to ??ORACLE_PATH??, which is the local property you created for
the Oracle Security component template.
5 Create a Compliance Job that uses the Oracle Security component template.
Run the Compliance Job against the two components you discovered in Step 2 on
page 473.
Because you mapped the ORACLE_PATH local property for the BLPackage to
the ??ORACLE_PATH?? parameter for the component template, the Compliance
Job can iterate through all property instances defined for the Oracle Security
template and prepare a remediation package for each instance that does not
satisfy the compliance rule.
For more information about running Compliance Jobs, see Creating Compliance
Jobs on page 439.
6 Using the results of the Compliance Job, correct any discrepancies you have
identified in the listener.ora file by remediating the Allowed Oracle Ports
compliance rule. This action deploys the Oracle_port configuration file so that
the existing file is replaced with the approved version.
For more information about remediating the results of Compliance Jobs, see
Manually remediating compliance results on page 467.
Note that you can also define the component template, the compliance rule, and
the Compliance Job so that any compliance rule failures are automatically
remediated. In this case, after running the Compliance Job, no user intervention is
required.
You can create the following types of objects and store them in the Depot:
Network Shell ScriptsScripts that can be stored as depot objects and then
deployed using a Network Shell Script Job. See Adding a Network Shell script on
page 549.
FilesFiles that can be stored as depot objects and then added to BLPackages. See
Adding files to the Depot on page 556.
Note
There is a BMC Maintenance folder that is created by default in the Jobs folder. This
folder is created automatically, and contains a recommended database cleanup job.
See the http://docs.bmc.com/docs/display/bsa82/Managing+BMC+Server
+Automation+data topic on the BMC Server Automation wiki for more information.
BMC Server Automation provides built-in support for packaging the following types
of software. Built-in support means BMC Server Automation provides you with the
standard install and uninstall commands for that type of software. In addition, you
can also create a completely custom software package by providing your own install
and uninstall commands, along with any necessary parameters and file references.
MSI packages
InstallShield packages
Patches
Patch clusters
Linux
RPMs
IBM AIX
Packages
Patches
HP-UX
Products
Patches
Bundles
For a description of how to package software, see Adding software to the Depot
on page 482. Manually adding Windows patches and service packs to the Depot
requires a slightly different procedure as described in Adding a hotfix to the
Depot on page 496.
When you package software, the package is stored in the Depot. However, the
source files for the software can either reside on the file server or a network location.
When you use a Deploy Job to deploy software, the job can push software to
designated servers and then run the install command for that software.
Alternatively, the Deploy Job can instruct the agent on a target server to mount (for
UNIX) or map (for Windows) the server that holds the source files and deploy the
source files directly from there. For more information, see Creating a Deploy Job
on page 718.
BMC Server Automation lets you uninstall software, even from servers where you
did not originally install it. To uninstall software, you must first package the
software and store the package in the Depot. Then you can run an uninstall job for
that package. The uninstall job is actually a Deploy Job that pushes the software
package to a server, where it runs the uninstall command rather than the install
command. For more information, see Uninstalling software on page 762.
BLPackage overview
A BLPackage is a collection of server objects, software packages, and an XML
instruction set that functions as a manifest, explaining how to process the contents of
the BLPackage, such as adding or replacing a group of files. A BLPackage can be
deployed unattended on multiple remote hosts.
Bundling files and other server objects that you select from a live host.
Bundling files and other server objects that you select from the Depot.
Bundling files and other server objects that you select from a snapshot.
Contents of BLPackages
BLPackages can consist of either Windows or UNIX server objects. A BLPackage
cannot mix Windows and UNIX server objects.
Applications
COM+/MTS settings
Configuration files
Event logs
Hotfixes
Local groups
Local users
Metabase objects
Registry values
Services
External commands (that is, commands that can be issued on a command line
interface)
Configuration files
RPMs
Daemons
Processes
UNIX users
UNIX groups
External commands
Editing BLPackages
After you create a BLPackage, you must sometimes edit the package to insert new
values for server objects, including parameterized property values. You can also
change the order in which server objects are processed, insert additional commands
and server objects, and make many other package- and object-level modifications.
BMC Server Automation provides many tools for editing the contents of a
BLPackage (see BLPackage Editing on page 517).
Deploying BLPackages
When you deploy a BLPackage, BMC Server Automation can use two basic approaches:
The system can copy the files included in the package and an XML instruction file
to a staging directory on the remote hosts you have specified. (Source files can be
copied from the file server or a network location.) If you are using an indirect
deployment, the files are copied to a staging directory on a repeater. The
installation executes on the target servers from the staging directory.
The system can copy an XML instruction file to a staging directory on a repeater
or the remote hosts you have specified. Those instructions tell the agent on the
target server to mount or map a server at a network location that holds the source
files for this deployment. From that network location, the source files are
deployed directly to the target server.
When you add software to the Depot, the system provides built-in support for
packaging many types of software. If you are adding one of these types, the system
automatically generates the appropriate install and uninstall commands. If
necessary, the standard commands include references to support files. For example,
installation of some types of software requires a response file. When you add
software to the Depot, you must provide the location of any support files.
You can also add custom software to the Depot by packaging any kind of software
that provides a command line-based, unattended installation. For custom software
packages, you must determine the necessary command line options for silently
installing and uninstalling the software. The install and uninstall commands should
reference required support files.
Adding Windows hotfixes to the Depot requires a similar procedure. See Adding a
hotfix to the Depot on page 496.
After adding a software package to the Depot, you can deploy it using a Deploy Job.
For a description of this procedure, see Creating a Deploy Job on page 718. You
can also modify the definition of an existing software package (see Modifying the
Using the Depot folder, right-click the folder where you want to add a software
package. Select New => Software, and then select the type of software package
to create.
Using the Servers folder, right-click a server and select Browse, which displays
the Live node in a tab in the content editor. Using the File System object type,
select one or more files or directories and right-click. Or, using a software
server object type, such as a Solaris patch or an HP-UX bundle, select one or
more server objects, right-click, and select Add To Depot As. Then select the
type of software package to create.
Note
Selecting Add To Depot => Hotfix initiates a related procedure, described in
Adding a hotfix to the Depot on page 496.
Using the results of a Snapshot Job, select software packages to add to the
Depot, as described in Adding software to the Depot from snapshot results
on page 674.
Using the Select Matching Software window, you can add software packages to
the Depot, as described in Matching software with depot items on page 507.
The Select Matching Software window appears in many contexts throughout
the BMC Server Automation Console.
The Add Depot Software wizard opens.
For detailed instructions on using this panel, see Adding software on page 485.
When specifying a software package to add, you can choose how the software
package is stored until deployment. You can copy all the contents of the software
package to the file server, or you can specify a network location for the source files.
A Deploy Job can copy the software package directly from the network location to a
staging directory on the target, or the target can mount/map the source location and
execute the software from there. When a software package includes support files,
you can even mix storage approachesfor example, storing the package in the
Depot but using agent mounting to deploy extremely large CAB files from a network
location. Using a network location gives you the option of maintaining only one
copy of a source file. Network locations also let you avoid copying a software
package to a staging area on the target server, thus reducing the disk space used on
the target.
WARNING
If you package files for a large network-based deployment, consider the capabilities
of your network and the server being mounted or mapped. When you deploy a
package to a large number of target servers, the agents on those servers must mount
or map the host where source files are located.
The Add Software panel establishes the install and uninstall command for a software
package. A default install and uninstall command is provided automatically for each
software package you select. You may need to modify these commands. If you are
adding custom software, you will typically need to provide install and uninstall
commands.
The Add Software panel also lets you identify the location of support files needed
for an installation, such as a response file.
All software, when being installed or uninstalled, generates a return code that BMC
Server Automation processes. BMC Server Automation treats all nonzero return
codes as errors except the Windows return code of 3010, which indicates the job was
a success but a reboot is necessary. Using the BLCLI, you can define an override list
of return codes that indicate errors, warnings, successes, or successes that require a
reboot. (For more information, see the BLCLI Help.) BMC Server Automation
matches the softwares return code against the override list using this matching order:
Error
Warning
Success that requires a reboot
Success
Any return code that does not match the override list uses the default logicthat is,
all nonzero return codes are treated as errors (except 3010 for Windows).
Adding software
Use the Add Software panel to identify the software items to package and provide
additional information for the package.
To add software
If the Add Software window does not show the appropriate source file for a
software package, select that package in the left pane. Then, in the right pane,
for Installable source, click Browse to specify the source file for the
selected package. The Select Installable Source dialog box opens. Proceed to
Step 2 on page 485.
If the left pane of the Add Software window lists all software you want to add
to the Depot, and the source files for all of those software packages are correct,
continue to Step 3 on page 487.
At any time, you can add more software packages to the list of those being
packaged by clicking Add depot software . The Select Installable Sources
dialog box opens. For details about using the Select Installable Sources dialog
box, see the next step.
a Using the hierarchical tree in the dialog box, select one or more source files.
Your selections are listed in the Source Location field. If you select multiple
items, semicolons separate each item. You can skip this step and manually
enter the path to the source files as described in step 2.c.
If an agent is not installed on the server where the source files exist, you cannot
browse those files. You must manually enter the correct path to the source files
using the procedure described in step 2.c.
If you want to copy source files to the file server, select Upload source to
File Server. Proceed to step 2.e.
When you select this option, you cannot edit the contents of the Source
Location field.
If you do not want to copy the source files to the file server, select Refer to
source at its current location. Instead, the source files reside at their network
location until deployment. Proceed to step 2.c.
When you select this option, you cannot use the hierarchical tree to select
source files.
c Using the Source Location field, enter paths to the installable source files. If
paths are already displayed, you can modify them. Source file paths can
include parameters. You can enter parameters manually or click Select
Property . For more information about this tool, see Inserting a parameter
on page 163.
In the next step, you specify a method for accessing source files. One method
requires you to enter a source location using a URL that complies with the
BMC Server Automation standard for network data transmission. For more
information about using a network-based URL, see URL syntax for network
data transmission on page 492.
Note
If you manually enter a source location, BMC Server Automation does not
validate the entry. If the URL is incorrect, a Deploy Job could fail during
staging, deployment, or rollback.
Tip
Using parameters in a URL lets you specify servers to be mounted or mapped,
depending on target locations. You can also use parameters to allow for
different types of mounts/maps, depending on the targets operating system.
For example, you can create a server property called MOUNT_TYPE and then
insert ??TARGET.MOUNT_TYPE?? as a parameter representing the type of
mount/map. On some servers, this property resolves to smb; on others it
resolves to nfs.
d Under Refer to source at its current location, select one of the following:
Agent mounts source for direct use at deployment (no local copy)The
Deploy Job instructs an agent to mount or map the device specified in the
URL and deploy the software package directly to the agent. When you select
this option, the agent uses the data transmission protocol specified in the
URL to access the specified source files. The software package is not copied
to a staging area on the agent, so no local copy of the source file is created.
To use this option, the Source Location field (see step 2.c) must provide a
URL that complies with BMC Server Automation requirements for network
data transmission, including a data transmission protocol: either NFS or
SMB. For details information about the required syntax, see URL syntax for
network data transmission on page 492.
The files you have selected display in the left pane of the Add Depot Software
window.
a From Operating system, select the operating system for the software you are
packaging. This option only appears for custom software.
b From Custom software type, select the type of software you are packaging.
5 In the left pane, select a software item for which you want to provide information
and do the following:
This option is always checked if you have chosen to deploy source files using
agent mounting because the agent mounting technique never copies source
files to targets.
Although most types of software packages do not require their original source
files to be rolled back, some do (most notably Microsoft MSI packages). If you
are using agent mounting to deploy an MSI or some other package that
requires its source files for an undo, be certain those source files remain in their
original location before attempting the rollback.
Checking this option reduces the size of the rollback package that is stored on
each target server. To benefit from this, however, the job used to deploy this
package must be defined to allow rollback.
b For Name, enter the name of the software being installed if a name is not
completed automatically. To provide a description for the installable, enter one
in the Description field.
c In some situations, the Software info list may be empty. This list is used to
match software being deployed with software stored in the Depot or on the
network. If the Software info list is not already populated, do one of the
following:
(UNIX ) To identify the software being deployed, click Browse to the right of
the Software info list. The Select Installable Location dialog box opens. Use
it to navigate to an instance of the software you are packaging. Select the
software and click OK. Using that software package, BMC Server
Automation can automatically populate the Software Info list.
If you do not use parameters when providing a network location and an
agent is installed at the source location, the system can always automatically
determine the software to deploy for UNIX packages. It accomplishes this by
checking a list of applicable software packages and version numbers
contained within the software package. However, if you have used
parameters when specifying the location of a network-based URL, the
system may not be able to access that list to determine the software to
deploy. Similarly, BMC Server Automation cannot access the list if an agent
is not installed on the host where the source files are located.
(Windows) If you plan to add Windows software to the Depot, you must
manually identify the files that must be deployed. To add an item to the list,
click the + sign to the right of the Software info list. The Software Part
Information dialog box opens. Enter a name and optionally a version and
platform for the software. Then click OK. To delete an existing entry, select
the entry in the Software Info list and click the sign.
d If you plan to add a Windows MSI package, you can open the Optional MSI
Customization Properties dialog box by clicking Edit beside Optional Install
MSI Customization Properties or Optional Uninstall MSI Customization
Properties.
Use the dialog boxes to create answers that replace the standard answers used
in an MSI silent install or uninstall. To create custom properties, use Name and
Value to enter a name/value pair and then click . Ensure that the names
that you enter correspond to standard names used in an MSI file. Name/value
pairs are used when you execute the MSI file. They do not change the MSI
package. To delete an item from the list of name/value pairs, select the item
and click .
e For Install command, enter the command (including arguments) that invokes
installation of the package type you are creating. This field automatically
displays the default installation command for the type of software you are
packaging. To apply the command to all software listed in the left pane, click
Apply to All.
If you enter a parameter that references a server property, you can type the
parameter name, bracketed with two question marks, or click Select Property
to choose a property from a list. If you click Select Property, you can view
hierarchical properties by clicking the right arrow that appears next to some
properties. A subordinate list of properties appears. To return to the parent list,
click the left arrow next to the property at the top of the list.
Note
When you create an AIX package or patch and the software parts being
packaged cannot be parsed, the default install command is automatically
altered to replace the word all for the ??SUBPACKAGES?? or ??
SUBPATCHES?? parameter. However, if you modified the install command to
exclude a ??SUBPACKAGES?? or ??SUBPATCHES?? parameter, this
replacement does not occur. For AIX packages, if the uninstall command
includes the ??SUBPACKAGES?? parameter, the command is disabled.
However, if you modify the uninstall command so it does not include a ??
SUBPACKAGES?? parameter, the command remains enabled. No uninstall
command exists for AIX patches. Automatic modifications of AIX packages
and patches are not visible within the Add Software wizard. Modifications
occur when the software package is created.
The uninstall command works like the install command. The system replaces
parameters with an appropriate value. The uninstall command can reference
other files by including the string ??_ supportFile ??. Square brackets within an
install command enclose optional information.
g To provide a location for a support file, select an entry in the Support Files
table and then click the Edit Parameter Entry . The Set File Parameters
dialog box appears. For File location, use Browse or enter the location of the
file being referenced. Click Browse to display a dialog box that lets you choose
deployment options for the support file just as you chose options for the entire
software package in Step 2 on page 485. If necessary, enter a URL to identify a
network location. You can use parameters in the file name, but parameters are
not substituted if you enter a URL for a network location. If you do not want
the system to insert values for parameters that appear within the body of the
file, check Skip parameter substitution for this file. (This is typically
necessary if a support file is binary, such as an MSI package with a required
CAB file.) Click OK.
Note
When specifying support files, do not use agent mounting if you are packaging
software that generates a result file that is unique for each target server.
6 Repeat Step 5 on page 487 for each item listed in the left pane.
The URL syntax is shown below. Square brackets indicate optional components.
[[protocol:][//[Domain;][User][:password]@]Host[:port]]][/sharename]/
Path
Omitting all components except /Path specifies direct access to the file system of the
local host. When you provide only /Path, files are accessed using local system calls
rather than networking.
smbUse Windows file sharing. For the SMB protocol, you must provide a
Windows share name in front of the path. No other protocols require a share
name. The SMB protocol also requires you to provide all necessary connection
information (domain, user name, and password).
Note
Be aware of the following:
When defining a URL for Windows patch payloads, you can only use the
smb protocol.
PasswordThe password for the specified user. A password is only necessary for
the SMB protocol. URLs containing passwords are encrypted when passed
between devices.
Note
To ensure that a password remains encrypted throughout the Deploy Job
process, you can enter a password as a parameter, such as ??MOUNT_PWD??.
The parameter can reference a local property on a BLPackage used to deploy a
software package or it can reference a server property for the host to be
mounted. The value of the property contains the actual password. When
defining the property, choose a property type of Simple and set the type to
Encrypted String.
HostThe DNS host name or IP address. The default value is localhost (127.0.0.1).
PortThe IP port number that should be used to access the protocol service on
the host. The default value is based on the selected protocol, such as 4750 for rscd
or 2049 for nfs.
Examples
/etc/passwd
# /etc/passwd on the current default host
//hp11dev/etc/passwd
# /etc/passwd on hp11dev, using the rscd protocol
rscd://hp11dev/etc/passwd
# Same as above
nfs://hp11dev/etc/passwd
smb://myDomain;BLuser:??MOUNT_PWD??@winXP37/REPO/HOSTS
# The HOSTS file is in a shared directory called REPO. Access the # HOSTS
file using an SMB map.
# The user who can access the file is named BLuser in the domain called
myDomain. The password
# is a parameter referring to a local property called MOUNT_PWD. The host
name is winXP37.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
WARNING
When defining a dependency list, make sure that the default value for the
DEPENDENCY_LIST property that is assigned to a software package does not
include that software package as a dependency. In other words, the
DEPENDENCY_LIST property for Patch_A should not have a default value that
includes Patch_A. Use the Property Dictionary to define a default value for the
DEPENDENCY_LIST property.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
When you initiate the process of adding a hotfix to the Depot while browsing server
objects or running a Snapshot or Audit Job, the system automatically provides all
information required by the Add Depot Software wizard. Source files are
downloaded to the Depot from repositories maintained by trusted organizations.
You do not have to provide install and uninstall commands as you do when adding
other types of software to the Depot.
Alternatively, when adding a hotfix to the Depot, you have the option of specifying a
source file rather than using the pre-identified source files as you do when browsing
server objects or running a Snapshot or Audit Job. If you specify a source file, you
may have to manually enter information that the Add Depot Software wizard requires.
To add all types of software to the Depot other than hotfixesincluding custom
softwareyou can use a similar procedure. See Adding software to the Depot from
snapshot results on page 674.
After adding a hotfix to the Depot, you can deploy it using a Deploy Job. For a
description of this procedure, see Creating a Deploy Job on page 718.
Using the Depot folder, right-click the depot folder where you want to add the
software package. From the pop-up menu, select New => Software => Hotfix.
Using the Servers folder, right-click a server and select Browse from the pop-
up menu, which display the Live node in a tab in the content editor. Using the
Hotfixes server object type, select one or more hotfixes and right-click. From
the pop-up menu, select Add To Depot As => Hotfix.
Using the results of a Snapshot Job, select the hotfixes that should be added to
the Depot. For more information, see Adding software to the Depot from
snapshot results on page 674
Using the Select Matching Software window, you can add hotfixes to the
Depot, as described in Matching software with depot items on page 507. The
Select Matching Software window appears in many contexts throughout the
BMC Server Automation Console.
A background process saves the patch or hotfix to the Depot. Depending on how
you have specified behavior for background processes, either a dialog box opens
or the Show background operations icon appears in the lower right corner of
the console. Both indicate an operation is running in the background.
For instructions about using this panel, see Adding hotfixes on page 498.
When specifying a hotfix to add, you can choose how the hotfix is stored until
deployment. You can copy the hotfix to the file server, or you can specify a network
location for the hotfix. During a Deploy Job, the hotfix can be copied directly from
that network location to a staging directory on the target, or the target can mount/
map the source location and install the hotfix directly from there. Using a network
location gives you the option of maintaining only one copy of a source file. Network
locations also let you avoid copying a hotfix to a staging area on the target server,
thus reducing the disk space used on the target.
Note
If you are packaging patches or service packs for a large network-based deployment,
consider the capabilities of your network and the server being mounted or mapped.
When you deploy to a large number of target servers, the agents on those servers
will all need to mount or map the host where source files are located.
The Add Software panel provides identifying information for patches and service
packs, and it establishes the install and uninstall command. Typically, a default
install and uninstall command is automatically provided for each patch and service
pack. If you specify the source file for a patch or service pack (rather than
downloading from a trusted source), you may have to edit the default install and
uninstall command that the panel provides.
Adding hotfixes
Using the Add Software panel, you can identify the hotfixes you want to package
and provide any additional information needed for the package.
To add hotfixes
If you initiated the process of adding a hotfix to the Depot while browsing
server objects or running a Snapshot or Audit Job, in most situations the system
can automatically provide all information required by the Add Depot Software
window. If the Add Depot Software window appears, click Next to complete
the procedure.
If you initiated the process of adding a hotfix to the Depot while browsing
server objects or running a Snapshot or Audit Job but the system cannot
automatically download information for one or more hotfixes, the Hotfixes
Missing Download Information dialog box appears. You must manually
provide all of the required information for each of the hotfixes listed on this
window. Click OK on this dialog box and proceed to Step 2 on page 499 to
continue this procedure for those hotfixes.
If you initiated the process of adding a hotfix to the Depot by selecting a depot
folder or by using the Select Matching Software window, the Select Installable
Sources dialog box appears. Proceed to Step 2 on page 499.
If the Add Software window does not show the appropriate source file for a
hotfix, select that hotfix in the left pane. Then, in the right pane, for Installable
source, click Browse to specify the source file for the selected hotfix. The
Select Installable Source dialog box opens. Proceed to Step 2 on page 499.
At any time you can add hotfixes to the list of those being added to the Depot
by clicking Add depot software . The Select Installable Sources dialog box
opens. See the next step for details on using the Select Installable Sources dialog
box.
To delete a hotfix from the list on the left, select the item and click Delete .
a Using the hierarchical tree in the dialog box, select one or more source files.
Your selections are listed in the Source Location field. If you select multiple
items, semicolons separate each item. You can skip this step and manually
enter the path to the source files as described in step 2.c.
If an agent is not installed on the server where the source files exist, you cannot
browse those files. You must manually enter the correct path to the source files
using the procedure described in step 2.c.
If you want to copy source files to the file server, select Upload source to
File Server. Proceed to step 2.e.
When you select this option, you cannot edit the contents of the Source
Location field.
If you do not want to copy the source files to the file server, select Refer to
source at its current location. Instead, the source files reside at their network
location until deployment. Proceed to step 2.c.
When you select this option, you cannot use the hierarchical tree to select
source files.
c Using the Source Location field, enter paths to the installable source files. If
paths are already displayed, you can modify them. Source file paths can
include parameters. You can enter parameters manually or click Select
Property . For more information about this tool, see Inserting a parameter
on page 163.
In the next step, you specify a method for accessing source files. One method
requires you to enter a source location using a URL that complies with the
BMC Server Automation standard for network data transmission. For more
information about using a network-based URL, see URL syntax for network
data transmission on page 492.
Note
If you manually enter a source location, BMC Server Automation does not
validate the entry. If the URL is incorrect, a Deploy Job could fail during
staging, deployment, or rollback.
Tip
Using parameters in a URL lets you specify servers to be mounted or mapped,
depending on target locations. You can also use parameters to allow for
different types of mounts/maps, depending on the targets operating system.
For example, you can create a server property called MOUNT_TYPE and then
insert ??TARGET.MOUNT_TYPE?? as a parameter representing the type of
mount/map. On some servers, this property resolves to smb; on others it
resolves to nfs.
d Under Refer to source at its current location, select one of the following:
Agent mounts source for direct use at deployment (no local copy)The
Deploy Job instructs an agent to mount or map the device specified in the
URL and deploy the software package directly to the agent. When you select
this option, the agent uses the data transmission protocol specified in the
URL to access the specified source files. The software package is not copied
to a staging area on the agent, so no local copy of the source file is created.
To use this option, the Source Location field (see step 2.c) must provide a
URL that complies with BMC Server Automation requirements for network
data transmission, including a data transmission protocol: either NFS or
SMB. For details information about the required syntax, see URL syntax for
network data transmission on page 492.
The files you have selected display in the left pane of the Add Depot Software
window.
3 To identify a depot folder where the hotfix should be stored, click Browse to the
right of the Save in field. The Select Folder dialog box appears. Use the dialog box
to select the depot folder where you want to store the patch or service pack. Then
click OK.
4 In the left pane, select a hotfix for which you want to provide information and do
the following:
a If you are adding a service pack to the Depot, check Source is service pack. If
you are adding a patch, clear Source is service pack.
Checking the Source is service pack option makes other options on the Add
Depot Software window unavailable. These options only apply to patches.
This option is always checked if you have chosen to deploy source files using
agent mounting because the agent mounting technique never copies source
files to targets.
Checking this option reduces the amount of data that is copied during a
deployment. However, Microsoft hotfixes need their original source files to be
rolled back, so you typically should not check this option.
Checking this option reduces the size of the rollback package that is stored on
each target server. To benefit from this, however, the job used to deploy this
package must be defined to allow rollback.
c For Name, enter the name assigned to the patch or service pack being installed
if a name is not already entered in this field. To provide a description for the
hotfix, enter one in the Description field.
d If you are adding a patch to the Depot and you have manually specified the
source file for the patch, do the following:
e If you have manually specified the source file for the patch or service pack, do
the following:
From Product, select the product for which you are adding a patch or service
pack. For example, you might select Windows 2003 or SQL Server 2005.
From Service Pack, select the level of the service pack you are adding. If you
are adding a patch, enter the level of the service pack to which the patch applies.
From Language, select the language for the patch or service pack.
f If you want to specify custom install and uninstall commands, check Use
custom command for install/uninstall and do one or both of the following:
For Install command, enter the command, including any arguments, that
invokes installation of the package type you are creating. This field
automatically displays the default installation command for the patch or
service pack.
When executing the Install command, BMC Server Automation replaces a
parameter bracketed with two question marks, such as ??SOURCE??, with
its appropriate value. For example, the system replaces ??SOURCE?? with
the directory where software is stored in the package being deployed. The
following table describes all parameters included in default install and
uninstall commands for patches and service packs. If a command includes a
parameter not shown in the following table, that parameter must reference a
server property and any target servers must have a value defined for that
property. If a hotfix is encapsulated in a BLPackage, parameters can also
reference local properties for the BLPackage.
If you are entering a parameter that references a server property, you can
type the parameter name, bracketed with two question marks, or click Select
Property to choose a property from a list. If you click Select Property, you
can view hierarchical properties by clicking the right arrow that appears next
to some properties. This displays a subordinate list of properties. To return
to the parent list, click the left arrow next to the property at the top of the list.
For Uninstall command, enter the command, including any arguments, that
invokes the uninstall. This field automatically displays the default uninstall
command for the patch or service pack.
The uninstall command works like the install command. The system replaces
parameters with an appropriate value.
5 Repeat Step 4 on page 500 for each item listed in the left pane.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
WARNING
When defining a dependency list, make sure that the default value for the
DEPENDENCY_LIST property that is assigned to a software package does not
include that software package as a dependency. In other words, the
DEPENDENCY_LIST property for Patch_A should not have a default value that
includes Patch_A. Use the Property Dictionary to define a default value for the
DEPENDENCY_LIST property.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
If you want to modify the contents of a software package, see the related procedure
Modifying the contents of a software package on page 505.
Using this procedure to modify the contents of a software package ensures that your
changes do not affect other jobs that might also be using this software package.
If you want to modify the definition of a software package, see a related procedure,
Modifying the definition of a software package on page 505.
Note
This procedure is only available if you initially created the software package by
copying the source files to the file server (that is, you selected Upload source to File
Server on the Select Installable Sources dialog box when you first defined the
software package). Until the source files are copied to the file server, the Copy To
button (described below) is not activated.
1 Open the Depot folder and navigate to an existing software package. Right-click
the object and select Open.
The content editor displays a tab for the Software Properties Panel, which
corresponds to the options on the Add Software panel of the Add Depot Software
wizard. Those options are described in Adding software on page 485.
Performing this action copies a single file or recursively copies the contents of an
entire directory. The copy action runs as a background process. You cannot cancel
the process.
3 After the contents of the software package have been copied, use any tool or
external software to modify the contents of the software package at the location to
which you have copied them.
Performing this action copies the modified software package back to the Depot,
replacing the existing installable source files. The copy action runs as a
background process. You cannot cancel the process.
5 If the software package includes support files that should be modified, perform
the following actions for each support file:
a On the Software Properties Panel, select an entry in the Support Files table and
click Edit Parameter Entry .
c Using the Select Copy Location dialog box, specify a location to which the
support file should be copied.
Performing this action copies the support file as a background process. You
cannot cancel the process.
d After the contents of the file have been copied, use any tool or external
software to modify the support file at the location to which you have copied it.
e On the Set File Parameters dialog box, next to File location, click Browse to
open the Select Param File Location dialog box. Using that dialog box, you can
identify the modified support file.
Performing this action copies the modified file back to the Depot, replacing the
existing support file.
The following situations require you to match depot items with software:
When you perform this procedure, you are asked to identify a software package
stored in the Depot that matches software you are trying to deploy, package, or
uninstall. If the system finds multiple depot items that seemingly match, you can
choose the correct match from a list of possibilities. If a matching item is not already
stored in the Depot, you can instruct BMC Server Automation to add it, and the
system launches a utility for adding that software item to the Depot.
If you are adding software to the Depot as part of an uninstall process, you have the
option of instructing the system to use the default command to uninstall the
software. If you choose this option, you do not have to add a software package to the
Depot to perform the uninstall. This option is only available when you are selecting
software that should be uninstalled and the default uninstall command does not
require additional information to perform the uninstall. In some situations, such as
the creation of a BLPackage from audit results, you may be both installing and
uninstalling installables. In that situation, the Select Matching Software window
displays two tabs. Use one tab for matching software needed for installs. Use the
other tab for matching software needed for uninstalls.
1 If the Select Matching Software window displays tabs, do one of the following. If
the window does not display tabs, skip this step.
To match Depot packages with software you are installing, click the tab for
Install Software.
To match Depot packages with software you are uninstalling, click the tab for
Uninstall Software.
2 In the Action column, use the drop-down menu to select one of the following
actions for each item listed in the window:
Select Use installableName to use the software item called installableName as the
software you want to deploy, package, or uninstall.
Choose Select software from depot to select an existing software item in the
Depot or to add software to the Depot so it can be used when deploying,
packaging, or uninstalling this item. When you select this option, the Select
Matching Software window appears. Do one of the following:
Using the navigation tree in the window, find and select the correct software
in the Depot and click OK.
Click New. A drop-down menu lets you choose the type of software you
want to add to the Depot. Select the software type and the Add Depot
Software window opens.
For more information about this window, see Adding a hotfix to the Depot
on page 496, a procedure specifically for adding Windows patches and
service packs to the Depot, or Adding software to the Depot on page 482, a
generalized procedure for adding all other types of software.
Select Ignore to exclude an item from the group of installables you are
deploying, packaging, or uninstalling.
Select Use Default Uninstall Command if the default uninstall command for
this software item does not require additional information, such as an
installable source file. When you select this option, the system uses the default
command to uninstall the software. Selecting Use Default Uninstall Command
means you do not have to add an installable source file to the Depot to perform
an uninstall. This option is only available when you are uninstalling, and it is
only available for the following types of software:
RPM
Oracle Solaris package
Oracle Solaris patch
HP-UX bundle
HP-UX patch
HP-UX product
3 If the Select Matching Software window displays two tabs (one for Install
Software and the other for Uninstall Software), select the other tab and repeat
Step 2 on page 202.
4 Click OK.
A BLPackage consists of an instruction set and any files needed for implementing
configuration changes. Configuration changes can consist of additions, deletions,
and modifications to any of the server objects BMC Server Automation supports on
all operating systems.
Note
The BLPackage package creation process does not traverse symbolic links that
occur within subdirectories in a file system. If you create a BLPackage by selecting
a directory on a live server, comparing a snapshot to a live server, or bundling
audit results, the BLPackage creation process only traverses symbolic links that
occur at the top level of the file system. In this way, BMC Server Automation
ensures that you do not inadvertently attempt to package large portions of a file
system.
If a BLPackage contains Windows security settings, the package can only contain
local settings. It cannot contain effective settings, which are derived from domain-
level security settings.
If you are creating a BLPackage that includes virtual disk files, note that these files
can be extremely largeoften measured in gigabytes. Make certain your file
server has sufficient disk space. Take care not to create unnecessary copies of
these BLPackages. Packaging a virtual machine or any of its storage information
will not include the associated disk files in the package. Only the storage
configuration information will be included in the BLPackage.
Using the Depot folder, right-click the depot folder where you want to add the
BLPackage. From the pop-up menu, select New => BLPackage.
Using the Servers folder, right-click a server and select Browse from the pop-
up menu, which displays the Live node in the content editor. Select one or
more server objects and right-click. From the pop-up menu, select Add To
Depot As => BLPackage.
Using the Depot folder, select the files, components, or software packages you
want to bundle as a BLPackage. Right-click and select Add To Depot As =>
BLPackage from the pop-up menu.
Using the Jobs folder, display the Server View node for some Snapshot Job
results. Select the node representing a server. Right-click and select Add to
Depot as => BLPackage from the pop-up menu.
A background process saves the BLPackage to the Depot. Depending on how you
have specified behavior for background processes, either a dialog box will display
or the Show background operations icon will appear in the lower right corner
of the console. Both indicate an operation is running in the background.
After saving the BLPackage, you can use the BLPackage editor to modify the
package or deploy the package. For more information about modifying
BLPackages, see BLPackage Editing on page 517. For more information about
deploy the package, see Creating a Deploy Job on page 718.
Package name
Save in
Click Browse and navigate to the depot folder where you want to save
the BLPackage.
Live server objectsBundle server objects you select from a live server.
DeltaBundle the server objects on a live server that are different from
the corresponding server objects in a snapshot designated as the master.
The Server Objects panel lets you select any version of a custom configuration object,
even though that version of the object may not be included in your Configuration
Object Dictionary.
If the server objects you have selected with this panel include software that does not
match software stored in the Depot, the Select Matching Software window appears.
Use it to match software in the depot with software in the package you are bundling,
as described in Matching software with depot items on page 507.
Server Objects
Click Add to open the Select Server Objects window. In the Servers list on
the left, select the server objects you want to include in the BLPackage and
click the right arrow, which moves your selections to the Server Objects list in
the right panel.
Use this section to refine your choices for the server objects included in the
BLPackage. For example, you might want to exclude all log files or backup
files in a directory. For more information, see Specifying includes and
excludes on page 683.
Recurse subfolders
Click Add Components to open the Select Components dialog. Use it to select
the components you want to include in the BLPackage.
Click Add Snapshot to open the Select Snapshots dialog. Use it to select the
snapshots you want to include in the BLPackage.
Click Add Depot Files to open the Select Depot Files dialog. Use it to select the
depot files you want to include in the BLPackage.
Click Add Depot Software to open the Select Depot Software dialog. Use it to
select one or more software packages you want to include in the BLPackage.
Sometimes it is useful to create a BLPackage that does not contain any server objects
or other assets. For example, after creating an empty BLPackage you can
immediately edit the package and add an external command.
If this section is available, check Soft linked to gather the contents of the BLPackage
at the time of deployment rather than the time of package creation. When you finish
defining the job, clear Soft linked to gather the contents of the BLPackage.
By soft linking the contents of a BLPackage, you can change the software, patches, or
server objects referenced by the BLPackage without updating the BLPackage
definition.
Soft linking is only available for assets stored in the Depot. When creating
BLPackages based on depot software, you can create multiple soft links to the same
software package.
Note
When you copy a BLPackage to a repeater and the Soft linked option is selected, the
contents of a BLPackage are copied to the repeater and stored there. Afterwards,
other BLPackages can use those same objects without copying them to the repeater.
If the Soft linked option is not selected, the contents of the BLPackage are always
copied into the BLPackage. While the BLPackage can be cached on a repeater, its
contents cannot reference objects that may already be stored in the repeaters cache.
File Options
Collect file/directory attributes
Record the attributes of files and directories, such as their date of creation,
size, and permissions, so that information can be replicated when the
BLPackage is created.
Collect permission and log information for files. This option is only
applicable if the servers or snapshots being compared use Windows NT File
System (NTFS).
Registry Options
Collect access control list (ACL) attributes
Component Options
Local Property Name Conflicts
Keep pre-existing property valueKeeps the value for the first property
encountered and discards values for all other properties that have the
same name. If there are multiple properties with the same name but they
are different property types, an error is generated.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
BLPackage Editing
The BLPackage editor allows you to manually modify the contents of a BLPackage.
With the BLPackage editor, you can add or delete objects, including software
packages, move objects within the hierarchy, change the value of some types of
objects, add external commands, and make many other modifications to the objects
included in the package. You can insert parameters to represent information that is
likely to change between servers. You can also add local properties to the BLPackage
itself and then use parameters to refer to those properties (see Adding a local
property to a BLPackage on page 532). Local properties are particularly valuable
when deploying multiple instances of the same BLPackage to a single server.
Each BLPackage tab includes at least two sub-tabs: Package and Local Properties.
The Package tab displays information about each server object included in the
BLPackage. The Local Properties tab displays information about the properties
associated with the BLPackage. You can use this tab to assign properties that apply
to this BLPackage but are not available globally throughout the rest of the system.
The Package tab is divided into two panes. The left pane shows a hierarchical tree
structure that represents the server objects included in the BLPackage. A symbol on
each object indicates whether you are adding, deleting, or modifying the object.
When you select an object in the hierarchy view, the attributes associated with that
object display in the right pane.
Paths in BLPackages
When editing paths to server objects, you can include one or more parameters in the
path. These parameters refer to properties on the target server or the BLPackage
itself. For example, instead of using a path like /C/Windows/System32, you could
enter /??TARGET.WINDIR??/System32, allowing this server object to apply to
multiple Windows platforms. For more information about parameters, see Inserting
a parameter on page 163. For a discussion of the rules that apply when entering
paths, see Rules for entering paths on page 56.
Note
When packaging configuration options for VMware servers, many options are
mutually exclusive or have dependencies on other configuration options. Take
care not to deploy configuration options that are inconsistent. If necessary, refer
to the VMware administration documentation for more details.
One common use for BLPackages is to clone virtual servers. If you are using a
BLPackage for this reason, remember to edit the name of the server so it is unique.
(You cannot have two virtual machines with the same name, even when those
virtual machines reside on different virtual host servers if those servers are
managed within the same VMware vCenter.) You may also want to edit options
defining storage locations and networking information for the cloned server.
If you create a BLPackage from audit results, you should be aware of how the
system treats configuration files that contain multiple name/value pairs with the
same name. In some circumstances the system treats each name/value pair as a
separate entry in the configuration file. Consequently, in some situations
BLPackage instructions will include instructions to ADD and DELETE
configuration file entries rather than MODIFY existing configuration file entries.
For more information, see Audit results for configuration files on page 702.
When using a BLPackage to move a virtual machine from one resource pool to
another, structure the BLPackage so it first deletes the virtual machine from one
resource pool and then adds it to another resource pool. Structuring the
BLPackage in this way allows a rollback to delete the virtual machine from its
new resource pool and add the virtual machine back to its original resource pool.
WARNING
When creating a BLPackage that contains information for a virtual machine, do not
edit the number of virtual processors. Deploying a change like this can make a
virtual machine unstable.
You can edit multiple BLPackages concurrently. You can also edit a BLPackage
when another user is editing that package, but you run the risk of overwriting the
other users changes. The system warns you if another user is also editing a BLPackage.
1 Using the Depot folder, navigate to the depot folder holding the BLPackage you
want to edit.
2 Right-click the BLPackage and select Open from the pop-up menu.
When you open a BLPackage that includes an earlier version of a server object,
the system displays a message informing you that the template has been
upgraded so it now includes the most recent version of the object. When you save
the BLPackage, the upgrade to the new version of the object is finalized.
1 In the hierarchy view, select the object that you want to modify.
On the right you see the attributes associated with that object.
2 For Action, use the drop-down menu in the Value column to select an action.
For most assets, you can select an action of Add, Delete, or Modify.
If the selected asset is a custom configuration object, it may give you an option to
select other custom actions. If you select a custom action, a message warns you
that the package will be converted to use the custom action for the selected asset.
If you agree to proceed, the package cannot be converted back so it uses the
standard Add, Delete, or Modify actions. In addition, if you select a custom
action, asset attributes that are not applicable to the custom action are no longer
displayed.
3 Click in the Value column and enter new values for the attributes of the selected
object.
If you are using parameters in a path, enter them here or click Select Property
. For more information about tool, see Inserting a parameter on page 163.
Some attributes provide a drop-down list from which you can choose a value.
Actions for some custom configuration objects may require parameters that
only apply to a target server that satisfies a particular condition. The required
condition is enclosed in a parenthesis.
The values of attributes that require long text strings can be scrolled
horizontally, and text fields can be resized vertically to improve readability.
When editing a password field for a Windows object, the Password Required
dialog box opens. Use it to change the password, as described in Providing
password information in a BLPackage on page 535.
When editing a Windows local user, be aware that the Action field has the
following effects:
Also, when editing a local user, the various Update fields (for example,
UpdatePath or UpdateLoginScript) are only available when modifying a
BLPackage (that is, the Action field must be set to Modify).
The Permissions property of UNIX files lets you click Browse to display a
dialog box where you can edit the files permissions.
Note
For a discussion of the rules that apply when entering paths to server objects,
see Rules for entering paths on page 56.
When you use soft links, the assets included in the BLPackage are not gathered into a
packaging directory on the file server until the package is deployed. If you have
specified network locations for files, those files are never copied to the file server.
However, other soft-linked information, such as the commands used to install or
uninstall a package, are gathered at the time of deployment.
This procedure lets you remove the soft-linked setting for individual objects. In a
BLPackage only a few attributes are defined for a soft-linked object, such as the
objects name and path. When you remove the soft-linked setting, all the attributes
that must be defined for that object are added to the BLPackage. For example, the
objects permissions or the objects install and undo commands are added to the
BLPackage. Note that you can only remove a soft-linked setting; you cannot add a soft-
linked setting.
This procedure also lets you directly access the object that is the source of a soft link.
You can change settings on that object, such as modifying property values or setting
permissions.
On the right you see the attributes associated with that object. A bold italics font
and the phrase Soft Linked are used to denote objects that are soft-linked.
2 To modify the object that is the source of a soft link, do the following:
The system displays the properties panel for the object you have selected. For
most types of objects, this panel has multiple tabs.
b Use the properties panel to change the definition of the linked object and click
OK.
A dialog box asks for confirmation. After you remove the soft-linked setting,
you cannot reverse that action; a hard link cannot be changed to a soft link.
The change you make to the soft-linked setting does not take effect until you
save the BLPackage. You cannot see the results of the change until you close
and re-open the BLPackage.
Note
Solaris servers use reboots. All other UNIX servers use shutdowns. A reboot stops
and then restarts a system. A shutdown enters runlevel 1 or 0 (depending on the
operating system).
Single-user mode is available for all UNIX systems. Single user mode is not available
for server objects that are unique to Windows, such as COM+ or registry objects.
When a Deploy Job must run in single-user mode, it cannot run in parallel with
other Deploy Jobs. The Deploy Job waits until it is the only Deploy Job being
processed. After a Deploy Job starts running on a server in single-user mode, other
Deploy Jobs targeting the same server must wait until the Deploy Job running in single-
user mode completes. BMC Server Automation calls this single-job mode.
Single-user mode is available for any type of object that can be included in a
BLPackage. To maximize efficiency, you should arrange objects in a BLPackage that
require single-user mode so they are processed consecutively. This will minimize
inefficient switching between single-user and other user modes.
On the right you see the attributes associated with that object.
2 In the right pane, for Single-User Mode, select one of the following:
switching modes. When the object being deployed no longer requires single-
user mode, the job reverts to the previous mode.
Not requiredInstructs a Deploy Job that single-user mode is not required for
the object being deployed. The Deploy Job continues to run under its current
mode. This is the default value.
This procedure allows you to specify a reboot for any server running any operating
system.
This procedure also lets you indicate that an object being deployed includes
instructions for a reboot, and those instructions are not part of the BLPackage
instructions. This kind of reboot is called out-of-band. It is important to note any
requirements for out-of-band reboots. If you do not, a reboot might occur while
another Deploy Job is processing, which could leave a server in an unreliable state.
When a job requires a reboot, the job must run in single-job mode, which means only
the current job can be processed. Other Deploy Jobs must wait. Forcing a Deploy Job
into single-job mode prevents a job from rebooting a server while other Deploy Jobs
are also being processed. When a server reboots, the job that caused the reboot is
processed first when the server starts up again. All other jobs, whether they are
existing or new jobs, wait to process until the rebooting job completes.
This procedure allows you to specify that servers perform a reconfiguration reboot
after deploying an object. A reconfiguration reboot, which only applies to Oracle
Solaris servers, is required for some new hardware and for some software patches.
On the right you see the attributes associated with that object.
After item deploymentReboot after this object is deployed. You can override
this setting using Deploy Job options.
is not a Solaris machine and you select this option, a normal reboot occurs. You
can override this setting using Deploy Job options.
AbortA failure starts a rollback if a rollback is defined for this job. The
command generates a non-zero exit code. Deploy Job results show the job as failing.
IgnoreA failure is ignored and the job continues. Deploy Job results show the
job as succeeding. By ignoring the failure and letting the job continue, you can fix
any problems that caused the failure, comment out any successful elements in the
BLPackage (see Commenting out assets on page 548), and run the Deploy Job
again.
For example, suppose you are installing five RPMs named A, B, C, D, and E.
Installation of A and B have no effect on the operation of C, D, and E. If another
RPM is required to install A and B, their installation will fail. However, if you set
ActionOnFailure to Ignore the A and B RPMs, you could let the Deploy Job
continue so the C, D, and E RPMs install successfully. Later, you could install the
missing RPM, use the BLPackage editor to comment out the C, D, and E RPMs
that already installed successfully, and run the job again.
ContinueThe failure is ignored and the job continues. Deploy Job results show
the job as failing.
The Continue action takes precedence over the Ignore action. If a Deploy Job
includes multiple commands that have failed and the ActionOnFailure for these
commands is defined as both Ignore and Continue, the overall job appears to have
failed.
2 Enter a value for ActionOnFailure by clicking in the Value column and selecting
an option from the drop-down menu. The following options are possible:
This procedure lets you modify the URL used to identify the location of a network-
based software package. It also lets you specify how a network-based software
package should be deployed to a target server.
The options described in this procedure are only available when a BLPackage
includes software that was packaged using source files from a network location
(rather than source files copied to the file server). In addition, the BLPackage cannot
specify that the source files are soft-linked.
1 In the hierarchy view, select a software package included in the BLPackage. The
right pane shows the attributes associated with that object.
Select Location and modify the path to the installable source files. A source file
path can include parameters. Enter a parameter manually or click Select
Property , which appears when you click in the Value column. (For more
information about this tool, see Inserting a parameter on page 163.) If the
package has a network-based location, the URL you enter must comply with
the BMC Server Automation standard for network data transmission (see URL
syntax for network data transmission on page 492).
Select Staging and then click in the Value column. A drop-down list appears.
Select one of the following:
Agent mounts source for direct useThe agent on the target server mounts/
maps the device specified in the URL and deploys the software package
directly to the target server. The software package is not copied to a staging
area on the server. The agent uses the protocol specified in the URL to access
the specified source files. This option does not create a local copy of the
source files on the target server.
To use this option, the object being deployed must provide a URL that
complies with BMC Server Automation requirements for network data
transmission, including a data transmission protocol: either NFS or SMB. See
URL syntax for network data transmission on page 492 for detailed
information about the required syntax.
Note
If you deploy this package using a large network-based deployment, first
consider the capabilities of your network and the server being mounted or
mapped. When you deploy to a large number of target servers, the agents on
those servers will all need to mount or map the host where source files are
located.
This capability is particularly useful when deploying files or rolling back a file
deployment. Sometimes a Deploy Job or a rollback can fail because users who are
not owners of the existing files cannot change the ownership attributes of those files.
Using this procedure, you can choose to apply or ignore the attributes of a files
owner, group, and permissions. Applying any of these attributes means that the file
attribute, as specified in the BLPackage, is applied to the file during deployment or
rollback. Ignoring any of these ownership attributes means that file attribute is
ignored during deployment or rollback and the existing files attribute is used instead.
If you specify that ownership attributes should be ignored and a file does not
already exist on target server, then ownership attributes default to those of the user
executing the job and permissions are set to full access. If you specify that ownership
attributes should be ignored and a file already exists, the existing files attributes
remain intact.
On the right you see the attributes associated with that object.
For OwnerOption, select Apply to apply the owner attributes of this file
during deployment or rollback. Select Ignore to ignore the owner attributes of
this file.
For GroupOption, select Apply to apply the group attributes of this file during
deployment or rollback. Select Ignore to ignore the group attributes of this file.
This option only applies to UNIX file deployments.
Note
Each child node shows a Modify action, but selecting that action does not modify the
entry. You can only add or delete entries.
The Data field for the registry value concatenates the names of all nodes and
displays their names in encoded form. If the Multivalue property for the registry
value is set to 1, the BLPackage uses the name set for each individual node. If the
Multivalue property is set to 0, the BLPackage uses the collective name created by
concatenating the names of all nodes.
When you use a BLPackage to add an entry to a registry value, the entry is added to
the end of the list of entries. When you use a BLPackage to delete an entry from a
registry value, the system deletes the first entry it encounters that matches the entry
you have specified.
Note
You cannot use a BLPackage to change the sequencing of nodes in a multi-value
registry value. Also, BLPackages cannot accommodate multi-value registry values
with multiple nodes that have the same name.
Below, a table describes what happens during deployment and rollback depending
on how you define the three editable fields for a security setting: Action, Replace,
and Value. For Value, the table below only notes whether you provide an empty
value for the security setting. Although the Replace field only applies to security
settings that allow multiple values, the table below describes behavior for all
packaged security settings, whether they have single or multiple values.
Note
If a Windows security setting includes a Replace field, you can only change the value
of that field when the Action field is set to Add or Modify. When the Action field is
set to Delete, the Replace field is automatically set to No, and you cannot change its
value.
The table below also presents a column specifying whether the BLPackage includes a
single or multiple value key. Multiple values can alter the behavior of deployments
and rollbacks. The key type (single or multiple) is not something you can change in
the definition of a BLPackage. The key type is determined by data that is loaded
during package creation.
Assigning local properties to a BLPackage allows you to deploy the same BLPackage
to the same server more than once. For example, suppose you want to install two
instances of an Apache server on the same machine. To accomplish this you can
insert a parameter ??INSTALL_DIR?? into the path for the BLPackage that
encapsulates the Apache server (for example, ??INSTALL_DIR??/apache). Then you
can create a Deploy Job for that BLPackage. The first time you run the Deploy Job,
you can assign one value for the INSTALL_DIR local property. The next time you
run the Deploy Job, you can assign a different value. In this way you can deploy the
same BLPackage to the same server multiple times.
1 Use the Local Properties tab to add a local property to the BLPackage or to
modify an existing local property. For description of this procedure, see Adding
or modifying properties on page 152.
You cannot move an object to a higher level in the hierarchy, in effect changing the
parent of that object.
2 Right-click and select any of the following from the pop-up menu:
Move UpThe selected object moves above the preceding sibling in the
hierarchy.
Move DownThe selected object moves below the nearest succeeding sibling
in the hierarchy.
When creating a BLPackage, you should order items in the package so that each
Components/name item precedes any Components/name/
InterfacesForComponents items. BMC Server Automation has no understanding of
the hierarchy within a COM+ object. You must define the hierarchy by specifying
the path to each item.
1 In the hierarchy view of the BLPackage editor, select an object. Right-click and
select Cut from the pop-up menu.
If you are pasting files or folders, you can select a location in a file hierarchy. If
you are pasting any other kind of object, select the root of the BLPackage.
The selected object is pasted into the BLPackage at your current location. The
object disappears from the location where you originally cut the object. You can
paste repeatedly if necessary.
Note
If you cut an object and close the BLPackage without pasting, the object you cut
will remain in the BLPackage. You are not prompted to save the BLPackage.
For example, if you are deploying a package called Patch_A, and it depends on
another package called Patch_B, the BLPackage should process Patch_B before
Patch_A.
1 In the hierarchy view, select the BLPackage or any software package included in
the BLPackage.
To delete an object
The Password Required window appears when you do any of the following:
Delete a Windows local user. The password you provide is used if you undo
deployment of the BLPackage, and the local user is recreated as part of that undo.
WARNING
If deployment of a BLPackage that modifies a users password fails, the
rollback of that BLPackage will succeed and the user will keep his or her old
password. If an undo is performed on deployment of a BLPackage that has
modified a users password, the undo will fail and the user will keep the new
password. To undo that deployment, you must create and deploy a new
BLPackage that sets the users password back to his or her original password.
Select Enter user ID and password. Then, for User ID, enter the appropriate
user ID. (If you are creating a BLPackage for a Windows local user, this field
will not be editable.) For Password, enter the password. For Confirm
Password, enter the password again to confirm your typing. The password you
enter is used for all objects requiring password access in this BLPackage.
Select Enter user ID/password property names. Then, for User ID property,
enter a parameter name, such as ??USERIDS??. A matching parameter name
must be assigned to target servers so the parameter can be resolved and the
appropriate user ID provided when the BLPackage is deployed. Similarly, for
Password property, enter a parameter name, such as ??PASSWORD??, which
provides a password that is resolved when the package is deployed.
2 Check Use the same credentials every time the user <user_name> is found if
you want the user ID and password you have entered for <user_name> to apply
to every target server where that user name exists.
3 Click OK.
Searching for and replacing text can be particularly useful when editing large
BLPackages.
1 In the hierarchy view, select an object, right-click, and take one of the following
actions:
The Find dialog appears. Contents of the dialog vary depending on whether
you are finding text or finding and replacing text.
Find what
Replace with
Enter the text string that should replace the string you have found. This
option is not available if you selected Find rather than Replace in Step 1 on
page 537.
Options
Case sensitiveSearches for text that matches the case of the text string you
have entered.
Pattern match (? & *)Searches for text using wild card input. A question
mark (?) instructs the search to search for any single character. For example,
two question marks instruct the search to look for any two consecutive
characters. An asterisk (*) instructs the search to look for a string of characters
of any length.
Whole words onlySearches only for complete text strings that match the
string you have entered.
Object Types
Specify the type of objects you want to search by doing one of the following:
Select All object types to search all types of objects included in the BLPackage.
Select Selected object types to search for instances of a particular object type.
You can choose from any of the object types that might be included in the
BLPackage, such as File System, Registry, or Metabase.
Object Scope
Specify the portion of the BLPackage you want to search by selecting one of
the following:
Selected object and its childrenSearches the selected object and any objects
nested beneath the selected object.
Specify the object properties you want to search by doing one of the following:
Select the text box and enter the object property you want to search, such as
FILELOCATION or UNIQUEFILENAME.
To find text, click Find. When the search utility finds a match, it highlights the
text string and displays a dialog. Click one of the following:
To find and replace text, click Replace. When the search utility finds a match, it
highlights the text string and displays a dialog. Click one of the following:
SkipIgnores the current match and searches for another instance of the
text string.
You can also add assets to a package by adding files. See Adding files to a
BLPackage on page 541.
1 In the hierarchy view, right-click anywhere in the BLPackage, and select Import
Assets from the pop-up menu. The Import wizard appears.
The Import wizard provides the same options for identifying the contents of a
BLPackage as the Create BLPackage wizard (see Adding a BLPackage to the
Depot on page 509). The only difference is that you do not assign a name as you
would when creating a BLPackage.
2 Use the Import wizard to identify the assets you want to import. When you finish
the wizard, the BLPackage editor inserts new nodes representing the imported
assets.
3 Move, delete, or change the value of the newly added assets, as necessary.
For example, if you were deploying a package to a web server, you might include an
external command to restart the web server, as shown in this example.
Note
The cd command does not work as an external command because an external
command executes in a different process than the transactions in a BLPackage,
which execute in the current working directory for the BLPackage.
1 Right-click in the hierarchy view and select Add => External Command from the
pop-up menu.
When entering a longer command or script, you can click Browse to display
an Edit window. It provides a larger space for entering text. You can also use the
Edit window to import an existing script.
While entering the text of an external command, you can include a reference to a
property value that is resolved when the script runs. To do this, enter a variable
for the property, bracketed with double question marks (such as ??WINDIR??/
rsc). Alternatively, you can click Select Property to find and enter the
appropriate property.
4 Move the external command to the correct position in the BLPackage (see Moving
an object within a BLPackage on page 533).
1 In the hierarchy view, click anywhere in the BLPackage, right-click, and select
Add => Asset Custom Action from the pop-up menu. The Add Asset Custom
Action dialog box appears.
2 From Type, select the type of asset for which you would like to add a custom
action.
The drop-down list displays all custom configuration objects that have deployable
actions.
3 For Path, click Browse , which displays a selection dialog box. (The name of the
dialog box depends on the type of asset you selected in the previous step.) Using
the dialog box, navigate to the custom asset you want to import.
You can only navigate to assets that are applicable to the type of server object you
selected in the previous step.
4 Click OK. The right pane shows the custom asset you have imported.
5 In the right pane, using the drop-down list for Action, select the custom action
you want to add to the BLPackage.
You can also add files to a package by importing assets. See Importing assets into a
BLPackage on page 539.
1 In the BLPackage hierarchy, select the top node or select an existing directory.
3 In the Select file window, use the Servers node to navigate to the file or files you
want to add. Select one or more files.
4 To copy the contents of the files into the BLPackage, select Copy file contents. If
you do not select this option, you add only file metadata to the package, such as a
file's creation date and permissions.
5 If you want to include Windows ACL information for the files, select Collect
access control list (ACL) attributes.
This option only applies to files on a Windows system. Selecting this option has
no effect on files that reside on other operating systems.
6 Click OK.
The files are added to the BLPackage and stored in the file server.
If you add a file to the top node of the BLPackage, the file retains the path of the
file you selected to add. When the BLPackage is deployed, the file is deployed to
that path. If you add a file to any directory in the BLPackage, the file does not
retain its original path. Instead, the file is added as a child of the selected
directory. When the BLPackage is deployed, the file is deployed as a child of the
selected directory.
After adding a file, you can optionally take any of the following actions:
Cut and paste Select the file, right-click, and select Cut. After cutting it, you
can select another node, right-click, and select Paste.
For payloads, you can add the contents of any type of file, including binary files.
3 Navigate to the file or files with content you want to add to the custom
configuration object. Select one or more files.
4 Click OK.
The file content is added to the BLPackage and stored in the file server. The new
payloads appear as one or more nodes under the node you selected in the first
step. Note that the paths to new payloads are the paths that the custom
configuration object uses to access payload information. Do not change these
paths in an attempt to install this content to a different location.
After adding payload information, you can optionally take any of the following
actions:
Cut and paste Select the payload, right-click, and select Cut. After cutting it,
you can select another node in the custom configuration object, right-click, and
select Paste.
4 If you want the file in the BLPackage to use the create and modify dates for the
file you have selected in this window, select Replace Create and Modify dates
using selected file.
5 Click OK.
The contents of the file you select in this procedure replace the contents of the
existing file or custom configuration object payload.
2 In the hierarchy view, select the RPMs you want to include in a single group (that
is, they should all be installed or uninstalled together), right-click, and select
Create RPM Group from the pop-up menu.
The BLPackage editor displays a new item called New RPM Group. The system
automatically generates an install and an uninstall command that apply to all the
RPMs included in the RPM group.
3 If necessary, modify the install and uninstall commands (that is, the Cmd and
UndoCmd properties). You can also modify the name of the RPM group.
For more information about asset groups, see Asset group concepts on page 546.
1 Import assets into a BLPackage from a custom configuration object that is defined
to allow asset groups. For more information about importing assets, see
Importing assets into a BLPackage on page 539.
2 In the hierarchy view of the BLPackage editor, select one or more first-level nodes
that you want to include in an asset group. Right-click and select Create Asset
Group.
The system creates an asset group called "New Asset Group" and adds the
selected nodes to the group.
The definition of a custom configuration object might not allow asset grouping for
some nodes. If you select a node that cannot be included in a group, the Create
Asset Group option is dimmed. For more information, see Asset group
concepts on page 546.
3 After defining an asset group, you can optionally take any of the following
actions:
Import assets
Select an asset group in the BLPackage, right-click, and select Import Assets. A
wizard appears. Use of the wizard is described in Importing assets into a
BLPackage on page 539. Various factors can limit the assets you can import
into an asset group as described in Asset group concepts on page 546.
Re-order assets
Select a first-level asset in an asset group, right-click, and select options for re-
ordering items as described in Moving an object within a BLPackage on page
533.
Delete assets
Select an item in an asset group, right-click, and select Delete as described in
Deleting an object in a BLPackage on page 535.
Another
asset group based on the same custom configuration object.
The
root of the same BLPackage.
Another
BLPackage (the root, an empty asset group, or an existing asset
group based on the same custom configuration object).
An item in an asset group and paste it into the root of the BLPackage and auto-
grouping is enabled, the system creates a new asset group at the end of the
BLPackage and places the item in that group. For more information about auto-
grouping, see Asset group concepts on page 546.
An asset group and paste it into an asset group in another BLPackage, the
contents of the asset group are pasted into the new group. An asset group
cannot contain another asset group.
Asset groups are valuable because Deploy Jobs process all of the assets in an asset
group together. No actions for items in the asset group take effect until the entire
asset group is processed. Without an asset group, a Deploy Job processes each item
in a BLPackage one at time. Currently, only BMC Application Automation uses asset
grouping.
See Creating an asset group on page 545 for instructions about creating asset groups.
Grouping restrictions
You can only group assets imported from one custom configuration object. After you
have created an asset group, you can only add additional assets from the same
custom configuration object to the asset group.
Auto-grouping
Custom configuration objects can be defined so that some or all of their assets should
always be grouped within a BLPackage. BMC calls this behavior auto-grouping.
When you import an auto-grouping asset into a BLPackage or the system adds the
asset to a BLPackage as part of compliance remediation or audit results packaging,
the asset being added must be automatically assigned to an asset group. This
automatic grouping results in the following behavior:
If the last item in the BLPackage is not an asset group, when an auto-grouping
asset is added, the system automatically creates an asset group and adds the
newly imported asset to the group.
If the last item in the BLPackage is an asset group, when an auto-grouping asset is
added, the system looks at the last asset group and does one of the following:
If the group is empty or contains assets that match the asset being imported, the
asset is added to the last group.
If the group contains assets that do not match the newly imported asset, the
system automatically creates an asset group and adds the imported asset to the
group.
User-defined actions
You can specify actions for items in an asset group. You can always specify an Add,
Modify, or Delete action for any asset. Additionally, you may be able to perform a
custom action on items.
You can also define ActionOnFailure for items in an asset group. The available
options (Abort, Ignore, and Continue) are the same as any ActionOnFailure setting
in a BLPackage (see Setting action on failure on page 526). The ActionOnFailure
settings for items in an asset group determine processing behavior of items in the
group, while the setting for the overall asset group determines processing behavior
for the BLPackage. For example, if you set ActionOnFailure to Abort for the items in
an asset group, and processing fails for an item, processing stops for all items in the
asset group. However, if ActionOnFailure for the asset group is set to Ignore,
processing for the rest of the BLPackage continues even though the asset group
processing has aborted.
Rollback behavior
1 Select any asset in the hierarchy view, such as an object or an external command.
Right-click and select Comment Out from the pop-up menu.
To remove the commented out item, select it, right-click, and select Uncomment
from the pop-up menu.
Always use care when editing a BLPackage. While verification can detect most
problems in a BLPackage, it is important that you also inspect a BLPackage for
logical flaws before saving it. For example, if you are adding a file and a directory
and the file should reside within that directory, then the add directory command
must appear in the BLPackage before the add file command. Otherwise, the file
cannot be added to a target server unless the directory already exists on that server.
1 Right-click in the hierarchy view and select Verify. If the BLPackage fails to
verify, errors and warnings are displayed in the Verification Messages panel at
the bottom of the BLPackage editor.
2 Click an error or message to see which node in the package has generated the
error or warning.
Click the X on the tab representing the BLPackage you are editing.
If you have made changes to the BLPackage, you are prompted to save your changes.
Right-click a depot folder and select New => NSH Script from the pop-up menu.
Open the Servers folder and navigate to a file that you want to add to the
Depot as a Network Shell script. Right-click the file and select Add to Depot
As => NSH Script.
2 Using the wizard, define the script, as described in the following sections:
For information about creating a job that runs the script you have added, see
Creating Network Shell Script Jobs on page 791.
You can specify whether a script executes repeatedly, each time against a separate
host, or the script executes once against multiple hosts. You can also specify that a
script use the Perl interpreter.
Name
Identifying name
Description
Save in
File location
Full path to the script (including host name for remote locations)
File encoding
Type of character encoding that is used for the script, such as UTF8 or UTF16
Script type
Execute the script once, passing the host list as a parameter to the script
The script executes once against many servers. If you select this option,
you must create a parameter that has a default value of %h or %f. When
you execute the script, the %h macro is replaced by a space-delimited list
of host names. The %f macro is replaced by a file containing a list of host
names. The script uses environment variables local to the Application
Server.
Copy and execute the script against each host separatelyThe script is
repeatedly copied to different servers and then executed on each of those
servers. The script uses environment variables local to the server where
the script is executed. After execution, the script is deleted. Use this option
for scripts that do not use Network Shell.
Execute the script using the PERL interpreter, passing the host list as a
parameter to the scriptThe script executes using the Perl interpreter. If
you select this option, you must create a parameter that has a default
value of %h or %f. When you execute the script, the %h macro is replaced
by a space-delimited list of host names. The %f macro is replaced by a file
containing a list of host names.
Note
If you define a script to use either of the first two options and you want to
grant permission to run the script on Windows target servers by means of
Windows user mapping, the appserver_protocol setting in the Application
Servers secure file must be set to ssoproxy. For more information about
Windows user mapping, see Creating automation principals on page 195.
For more information about setting up a secure file, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Secure+file
+overview.
Using this panel, you can add flags to parameters, you can specify whether the flag
is required at runtime, and, if necessary, require a value to be provided for the flag.
In addition, you can define a default value for a flag, make the default value editable
when the script is run, and require a value to be entered for the flag at runtime.
When you deploy a Network Shell script, BMC Server Automation automatically
generates a master script that controls the scripts deployment and execution. The
system uses the parameters you define here to generate values in the master script.
If you are running a script one time against multiple hosts (as defined using the Add
NSH Script Script Options on page 550 panel), you must pass the %h or %f macro
as a parameter when you execute the script. The %h macro is replaced by a space-
delimited list of host names. The %f macro is replaced by a file containing a list of
host names.
of these actions displays the Add parameter dialog box, which has the following
options:
Name
Identifying name.
Description
Flag
For example, you could enter a flag like -d to indicate that a script runs in
debug mode. Or, you might enter a flag, such as -b, that requires a build
number for the script to execute. In the latter case, check the Accepts value
option to ensure that a value is specified for the flag.
Check if the flag is used when the Network Shell Script Job runs. If you do
not check this option, the person who runs the Network Shell Script Job can
choose whether the job should use the flag. By default this option is not checked.
Accepts value
Default value
Enter a value.
If you want the default value to include a reference to a property value that is
resolved when the script runs, enter a variable for that property in the Value
column, bracketed with double question marks (such as ??WINDIR??/rsc).
Alternatively, you can click Select Property to find and enter the
appropriate property. For more information about this tool, see Inserting a
parameter on page 163.
If you want to enter a custom property class instance as a default value, click
Browse . (Typically, you enter a custom property class instance when you
are analyzing AIX patches.) The Property Class Instance dialog box opens.
For Property class, click Browse. The Property Class Selection dialog box
opens. Select a custom property class and click OK. Then, for Property class
instance, click Browse. The Choose Property Class Instance dialog box
opens. Select an instance of a custom property class and click OK. Then click
OK to close the Property Class Instance dialog box.
Editable
Check if the value can be edited when you run the script.
To reposition a parameter within the list, select the parameter and click the up or
down arrow.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing Network Shell script, open the Depot
folder and navigate to the script. Right-click the script and select Open from the
pop-up menu. The content editor displays a tab bearing the name of the script.
The tab includes subtabs that correspond to the options on the Add NSH Script
to Depot wizard. For more information about these options, see any of the
following:
To modify the content of a script, open the Depot folder and navigate to an
existing Network Shell script. Right-click the script, select Open with, and then
select your preferred editor from the pop-up menu. The script appears in a tab
in the content editor. After you are done editing the script, close the tab. The
system prompts you to save your changes. For more information about editors,
see Content editors on page 78.
Script
The Script tab lets you review and edit a script you have added to the Depot.
The Script panel is only available after you finish adding a script to the Depot (see
Adding a Network Shell script on page 549).
Although you can edit a script displayed in the Script tab, you may want to open the
script using an editor so you can use tools such as search and replace. For more
information about editors, see Content editors on page 78.
You can edit multiple Network Shell scripts concurrently. You can also edit a
Network Shell script when another user is editing that script, but you run the risk of
overwriting the other users changes. The system warns you if another user is also
editing the same Network Shell script.
If you edit a script using the Script tab, the system prompts you to save your changes
when you close the Network Shell script.
After you have added a file to the Depot you can edit it using your choice of editors.
For more information about editors, see Content editors on page 78.
To see or modify any properties, permissions, or audit trail information that apply to
this file, select the Properties, Permissions, and Audit Trail view.
Instead of adding a file to the Depot, you can store it as a BLPackage. Deploying files
as BLPackages provides many advantages over using a File Deploy Job to deploy a
file, including the ability to simulate, stage, and undo the deployment.
Click the Depot folder. Right-click the depot folder where you want to add a
file. From the pop-up menu, select New => File.
Using the Servers folder, navigate to the Live assets node of a server. Using the
File System object type, select a file and right-click. From the pop-up menu,
select Add To Depot As => Files.
File
Click Browse and navigate to the location of the file you are adding to the
Depot, or use the text box to enter the path to the file.
Name
Identifying name.
Description
Save in
File encoding
Type of character encoding that is used for the script, such as UTF8 or UTF16
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
In BMC Server Automation, a custom configuration object is a plug-in that extends the
capability of the agent. A custom configuration object can present information and
perform functions not available from built-in BMC Server Automation server objects.
A configuration file is a file that appears under the Configuration object of a server in
the Servers folder. You can add your own configuration files to the system.
When you select a configuration object in the list on the left side of the Configuration
Object Dictionary, the right side shows the attributes associated with that object. For
some objects, this information is presented in a tabbed display. If the configuration
object applies to multiple operating systems, the right side provides tabs for
applicable operating systems. Each tab shows the objects attributes for the
applicable operating systems.
The Configuration Object Dictionary provides the version number of all server and
configuration objects. Multiple versions of custom configuration objects may exist.
Note
Using preferences, you can limit the number of server objects that the Configuration
Object Dictionary displays at one time. For more information, see Preference
settings BMC category on page 85.
Using the Configuration Object Dictionary, you can perform any of the following
procedures:
Note
BMC Server Automation lets you restrict the number of records that a
configuration file or extended object can return. Setting a limit like this can help
prevent an Application Server from running out of memory when processing
very large configuration files or extended objects, particularly when those
objects appear on multiple servers. For more information about setting this
limit, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Restricting+the+size+of+configuration+and+extended+objects.
There are special considerations for custom configuration objects when upgrading
agents to a later version. See Upgrading custom configuration objects on page
566.
In addition to that list, custom configuration objects that run in conjunction with
other products such as BMC Application Automation may also use the custom object
server.
Note
To communicate properly with the custom object server, in some situations you
must ensure that users on servers to which roles are mapped have write permission
to the RSCD agent's installation directory. This requirement is necessary when all of
the following are true:
Object type Available as part of Requires distribution Uses custom object server
agent installation
Object type Available as part of Requires distribution Uses custom object server
agent installation
For additional information about setting up the Active Directory object, see Setting
up an Active Directory object on page 565. Besides the Active Directory object, all
other custom configuration objects that are provided in the Configuration Object
Dictionary are used for virtual environments. For information about setting them up,
see BMC technical documentation at https://docs.bmc.com/docs/display/bsa82/
Home.
Stop, start, restart, and reload UNIX daemons (including a start with
dependencies for Solaris 10)
Versioning format
BMC Server Automation assigns version numbers to the custom configuration
objects that it distributes. Each version number has a Vvssbbbb format, where:
VMajor version
vMinor version
ssService pack
bbbbBuild number, which can provide patch or hotfix numbers
For release 8.1 BMC Server Automation assigned numbers to custom configuration
objects using a scheme that provided the major and minor release level as well as an
identifier for the custom object itself.
Before release 8.1, BMC Server Automation assigned version numbers using positive
integers such as 2, 3, and 4.
Version availability
Several factors determine what version of custom configuration objects are available
when you access a server.
If your Application Server is newly installed, then the custom configuration objects
provided for that release are available when you install an agent running the same
release. For example, if you have just installed an Application Server for version 8.2,
when you install an agent running 8.2, custom configuration objects that correspond
to version 8.2 are automatically installed and ready for your use on that server.
If your Application Server has been upgraded from an earlier release, then you should
be able to see and use custom configuration objects on servers running versions of
agents that correspond to the version history of the Application Server. For example,
if your Application Server was originally running release 8.0 and then was upgraded
to release 8.2, you should be able to see and use custom configuration objects on
servers running release 8.0 and release 8.2. However, if agents were added to your
system when they were running an earlier release and those agents were later
upgraded, to see and use custom configuration objects on those servers, you must
run an Update Server Properties Job on those servers.
The following table lists the deployable actions possible with UNIX objects.
Note
If you attempt to undo a deployment that includes actions for any of the UNIX
objects in the table below, the undo will succeed for all items that can be undone but
the actions for the UNIX objects will not be undone.
In addition to distributing the Active Directory object, you must also set up an
automation principal so you can impersonate a domain user.
Consider the following guidelines when setting up the Active Directory object:
If your environment has stricter security needs, you may need to add an
automation principal in order to view one or more domains in the forest. In such a
scenario, using an automation principal with credentials for the top-most domain
will work best because it allows you to view all the child domains.
If you have additional questions about access requirements for Active Directory,
consult your domain administrator.
When you select objects to distribute, select the Active Directory object.
When you select targets for the job, select the appropriate Windows servers.
Ideally you would select at least one Windows server in each domain.
For more information about running this type of job, see Creating or modifying a
Distribute Configuration Objects Job on page 583.
3 Associate the automation principal with a role that should have access to Active
Directory information.
Any custom configuration objects that are included as part of an agent installation
are automatically upgraded to the appropriate version when you upgrade the agent.
(See Custom configuration objects on page 561 for a list of those objects.) You
should upgrade any custom configuration objects not included with the agent by
running a Distribute Configuration Objects Job. The job should target servers to
which custom configuration objects should be distributed.
After you upgrade agents and the Application Server, use the following procedure to
ensure continued use of custom configuration objects.
1 Run an Update Server Properties Job on the agents you have upgraded.
For more information, see Creating Update Server Properties Jobs on page 325.
The job should target agents that you have upgraded. The system prevents you
from distributing custom configuration objects to agents running an incompatible
version.
3 If you are not upgrading all of your agents at this time, make copies of all
component templates, BLPackages, Snapshot Jobs, and Audit Jobs that reference
custom configuration objects that have dependencies on agents running earlier
versions.
4 Run an Upgrade Model Objects Job that targets any component templates,
BLPackages, Snapshot Jobs, or Audit jobs that you want to upgrade. Do not run
the job against the copies of objects that you created in the previous step.
Note
If you open an existing component template, BLPackage, Snapshot Job, or Audit
Job that references a custom configuration object and a later version of that
custom configuration object exists, the system displays a message saying it will
automatically upgrade the referenced custom configuration object. To maintain a
version match with an earlier agent, close the component template, BLPackage,
Snapshot Job, or Audit Job without saving.
Note
1 Obtain a ZIP file for the custom configuation object you want to add.
4 The New Configuration Object wizard opens. Select Server Object, if it is not
already selected, and click Next. The Server Object Definition panel of the wizard
appears.
5 Click the browse button and navigate to the ZIP file you obtained in Step 1 on
page 82.
6 Click Next.
The Permissions panel appears. The Permissions panel is an access control list
granting roles access to this server object. Access to all objects, including the
sharing of objects between roles, is controlled through ACLs.
7 Define an ACL for the server object. For more information, see Defining
permissions for a system object on page 231.
8 Click Finish to close the wizard and save the new server object.
9 Distribute the new server object to managed servers where you want to use it. See
Creating or modifying a Distribute Configuration Objects Job on page 583.
To perform this procedure, the custom configuration object you want to delete
cannot exist on any servers, and the latest version of any policy-based objectsthat
is, component templates, BLPackages, and server object-based Snapshot and Audit
Jobscannot refer to the custom configuration object.
To remove a custom configuration object from any servers, you must run the
Deregister Configuration Object Job (see Creating or modifying a Deregister
Configuration Object Job on page 597) on those servers. To remove the custom
configuration object from any policy-based objects, you can manually edit those
objects or you can use this procedure.
Note
When you perform this procedure, you cannot delete the most recent version of a
custom configuration object without also deleting all earlier versions of the same object.
1 Deregister the custom configuration object from any servers to which it has been
distributed. See Creating or modifying a Deregister Configuration Object Job on
page 597.
2 From the Configuration menu, select Config Object Dictionary view. The
Configuration Object Dictionary opens.
3 Select one or more custom configuration objects and click Delete Configuration
Object . A message prompts you to confirm your action.
If you are deleting the latest version of a custom configuration object, a message
informs you that you must first delete all earlier versions of the object. The
message asks if you would like to delete all versions of the object. Click Yes to
delete all versions.
If there are dependencies on any of the objects you want to delete, the Found
Dependencies dialog box displays the dependent objects. See Deleting a folder,
group, smart group, or system object on page 113 for a description of the actions
you can take using the Found Dependencies dialog box.
You can only delete root-level custom configuration objects. If you select a custom
configuration object that is not a root-level object, the Delete Configuration
Object icon is dimmed.
Configuration files
By default BMC Server Automation automatically recognizes standard configuration
files for all supported operating systems.
For BMC Server Automation to read a configuration file correctly, it must adhere to
configuration file standards for the relevant operating system. BMC Server
Automation can also treat most types of XML files as configuration files.
After configuration file records are created, you can browse, snapshot, audit, run
compliance on, and deploy them like other server objects. Using these standard
procedures, you can manipulate the contents of configuration files with great
precision, down to their individual lines. In this way you can monitor configuration
files on servers throughout your system and if necessary correct inconsistencies.
Although BMC Server Automation provides many grammar files, the following are
the basic types:
name space valueParses files with name/value pairs connected by white space
instead of an equal sign (=)
XMLParses XML files using the Xerces DOM parser to generate a DOM tree.
Configuration files are then created by traversing the tree. Various schemes are
used to generate a unique key for each record.
The following table lists all the grammar files BMC Server Automation supports by
default. These grammar files reside in installDirectory /scripts. For additional
information about how an individual grammar file is used to parse configuration
files, refer to information provided in each grammar file.
For information about creating custom grammars, see BMC technical documentation
at https://docs.bmc.com/docs/display/bsa82/Creating+custom+grammars.
When performing this procedure, you must choose the grammar file used to parse
information that is displayed as a configuration file. BMC Server Automation
supports many types of grammars that can parse files and output file contents in a
format consistent with other information you view when browsing server objects or
viewing the results of snapshots or audits. For a description of the available
grammar files, see Grammar files supported by BMC Server Automation on page
570.
The following procedure also explains how to add local configuration objects to a
component template.
Note
BMC Server Automation does not support configuration files that include binary
data.
You can set a limit to the number of records that a server can provide an
Application Server for a single configuration file. To accomplish this, you must
use the Application Server Administration console (that is, the blasadmin utility)
to set a value for the MaxConfigRecords option. By default this value is set to
50,000. For more information, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Restricting+the+size+of+configuration+and
+extended+objects.
To add a new configuration file, click Add Configuration Object . The New
Configuration Object wizard opens. Select Configuration File, if it is not
already selected, and click Next. The Configuration File panel of the wizard
appears.
To modify an existing configuration file, select the file and click Edit
Configuration Object .
The Edit Configuration Object: Configuration File window appears. It provides
the same options as the Configuration File panel of the Configuration Object
wizard.
When using the Configuration Object Dictionary, you can filter the list of
configuration objects displayed using the drop-down lists at the top of the
window to select the category of configuration objects, the relevant operating
system, or both. These filters are not available when creating local
configuration objects.
If you select Server Objects in the drop-down list at the top, two additional
types of filtering are possible. A drop-down list lets you select All or Root.
Selecting All displays all types of server objects, including all built-in server
objects and all custom configuration objects. Selecting Root displays only root
objects (both built-in and custom configuration objects). You can also filter on
server object names by entering text in the text box and pressing Enter. The
system shows all server objects with names that include the text you entered.
To copy an existing configuration file, select that file and click Copy
Configuration Object .
This option functions the same as the Add Configuration Object icon except
that all fields are automatically completed using information from the
configuration file you are copying.
To delete one or more configuration files, select those files and click Delete
Configuration Object . A message prompts you to confirm your action.
Click Yes to confirm.
Note
A global configuration object defined in the Configuration Object Dictionary must
not conflict with a local configuration object created within any component
template. You will not be allowed to save your configuration file in the
Configuration Object Dictionary if a configuration file with the same name and
path already exists in any component template. Similarly, you will not be allowed
to save your component template after adding a local configuration file with the
same name and path as any configuration file that already exists in the
Configuration Object Dictionary.
3 From Operating Systems, select the class of operating system to which this
configuration file applies.
4 To add one or more new configuration files using wild cards in a file path, check
Add multiple files (wildcarded File path) from server. Then, from the drop-
down list to the right, select the server with the file path you are specifying.
If you are adding a single file, enter the path to the file or use Browse to
navigate to the file.
If you are using the wild card approach, enter the path to a directory or use
Browse to navigate to the directory containing configuration files. Then use a
wild card to identify multiple files in that directory.
When entering a path, you can include one or more parameters. For example,
you can enter $$TARGET.PATH??/??TARGET.CONFIG_DIR??/*.xml to add
all the XML files at a location identified by the combination of the
TARGET.PATH and the TARGET.CONFIG_DIR properties. You can enter a
parameter manually, or you can click Select Property .
If you are defining a local configuration object for a component template, use
the local properties of the component template to make the path applicable to
multiple instances of the same component on a server.
Select Uses default character encoding to use your systems default character
encoding when displaying the configuration file.
Select Uses encoding and then select the type of character encoding that is used
when displaying the configuration file. For example, you might select UTF8 or
UTF16.
7 From Grammar file, select the type of grammar used to parse the files you are
adding.
If you are copying or editing an existing configuration file, click OK. The
procedure is complete.
If you are creating a local configuration file for a component template, click
Finish. The procedure is complete.
If you are creating new configuration files, click Next. The Permissions panel
appears.
The Permissions panel is an access control list granting roles access to these
configuration files. Access to all objects, including the sharing of objects
between roles, is controlled through ACLs.
9 Define an ACL for the configuration files. For more information, see Defining
permissions for a system object on page 231.
10 Click Finish to close the wizard and save the new configuration files.
Extended objects
BMC Server Automation lets you create extended objects, which are custom objects
presenting information not included in a standard installation.
After creating an extended object, you can use the BMC Server Automation Console
to browse, snapshot, audit, and run compliance on the contents of the extended
object just as you would any other server object. For example, you can create custom
objects that do any of the following:
Provide IP and other configuration settings for all the installed network cards on a
server.
After you create an extended object, it can be displayed in a smart group. You can
execute Snapshot, Audit, and Compliance Jobs against that group to ensure that the
configurations represented by these extended objects do not drift from your
organizational standard.
Object node (under the Live node) of any server in the Servers folder running one of
the operating systems you specify in this procedure.
You also have the option of creating an extended object that is not associated with
any operating system. An extended object defined in this way is available directly
under the Live node.
Note
You can set a limit to the number of records that a server can provide an Application
Server for a single extended object. To accomplish this, you must use the Application
Server Administration console (that is, the blasadmin utility) to set a value for the
MaxConfigRecords option. By default this value is set to 50,000. For more
information, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Restricting+the+size+of+configuration+and+extended+objects.
Tip
Example scripts can be found at http://communities.bmc.com.
To create an extended object, you must identify a script that generates output
according to a prescribed format. Using one of the many grammar files BMC Server
Automation supports (see Grammar files supported by BMC Server Automation
on page 570), the system can parse that output and present it in a format consistent
with other information you view when browsing server objects or viewing the
results of snapshots or audits. When you access the extended object (using browse,
snap, audit, or compliance), the script executes and information for the object is
refreshed.
You can associate an extended object with a custom icon, making it easy to identify
the extended object when browsing.
To modify an existing extended object, select that object and click Edit
Configuration Object .
The Edit Configuration Object: Extended Object window appears. It provides
the same options as the Extended Object Definition panel of the Configuration
Object wizard.
To filter the list of extended objects displayed, use the drop-down lists at the
top of the window to select the category of extended objects, the relevant
operating system, or both.
To copy an existing extended object, select that object and click Copy
Configuration Object .
This option functions the same as the Add Configuration Object icon except
that all fields are automatically completed using information from the extended
object you are copying.
To delete one or more extended objects, select those objects and then click
Delete Configuration Object . A message prompts you to confirm your
action. Click Yes to confirm.
3 For Name, enter a name for the extended object. For Description, you can
optionally provide descriptive text.
4 From Operating Systems, select the class of operating system to which this
extended object applies. If you want to create an extended object that is associated
with an object that does not have a BMC Server Automation RSCD agent
installed, select None.
If you select None, the Application Server must centrally execute the script or
program associated with this extended object (as described in the explanation of
Central Execution below).
Note
A global configuration object defined in the Configuration Object Dictionary must
not conflict with a local configuration object created within any component
template. You will not be allowed to save your extended object in the
Configuration Object Dictionary if an extended object with the same name and
operating system already exists in any component template. Similarly, you will
not be allowed to save your component template after creating a local extended
object with the same name and operating system as any extended object that
already exists in the Configuration Object Dictionary.
5 From Icon, select the icon that should be associated with this extended object.
To populate this list with choices, you must create an icon library (see Defining
custom icons on page 581). If you select Default from this list, the standard icon
for extended objects is associated with the extended object you are defining.
6 For Command/Script, enter a command that the extended object should run or
enter the path or use Browse to navigate to the program or script generating
information for the extended object.
When entering a path, you can include one or more parameters. You can enter a
parameter manually, or you can click Select Property .
If you are defining a local extended object for a component template, use the local
properties of the component template to make the path applicable to multiple
instances of the same component on a server.
Note
If any of the characters shown below are included in a command, they could
potentially be interpreted as delimiters within a compound shell command. To
prevent this, if any of these characters appear without being escaped or enclosed
within quotes, BMC Server Automation treats the entire entry as a single string,
as if it was enclosed in quotation marks.
;&|><()
Select Output uses default encoding on executing system to use the default
character encoding for the system where the extended object is generating output.
Select Output uses encoding and then select the type of character encoding
that is used when displaying the output of the extended object. For example,
you might select UTF8 or UTF16.
9 From Grammar file, select a type of grammar that can process output generated
by the script you specified in the Command/Script field.
For more information, see Grammar files supported by BMC Server Automation
on page 570.
If you are copying or editing an existing extended object, click OK. The
procedure is complete.
If you are creating a local extended object for a component template, click
Finish. The procedure is complete.
If you are creating a new extended object, click Next. The Permissions panel
appears.
The Permissions panel is an access control list granting roles access to this
extended object. Access to all objects, including the sharing of objects between
roles, is controlled through ACLs.
11 Define an ACL for the extended object. For more information about defining an
ACL, see Defining permissions for a system object on page 231.
12 Click Finish to close the wizard and save the new extended object.
Use this procedure to create a set of custom icons that you can associate with
extended objects.
When selecting a custom icon, the image must be in a GIF format, and its resolution
must be 16 by 16 pixels.
1 Start the New Configuration Object wizard and then open the Extended Object
Definition panel, as described in Extended objects on page 577.
2 For Icon, click Browse . The Icon Library dialog box opens.
To add a new custom icon, click Add Custom Icon . The New Custom Icon
dialog box opens.
To modify an existing custom icon, select the icon and click Modify Custom
Icon . The Modify Custom Icon dialog box opens. It provides the same
options as the New Custom Icon dialog box.
To delete one or more custom icons, select those icons and click Delete Custom
Icon .
4 For Name, enter an identifying name for the icon. For Description, you can
optionally provide descriptive text.
5 For Location, click Browse. The Select Icon Location dialog box opens.
6 Use the Select Icon Location dialog box to navigate to the image you want to use
as an icon. Using Object Type, you can select the types of icons you want to
display. (Currently, you can only specify GIF.) When you have selected an image,
click OK.
7 On the New Custom Icon or Edit Custom Icon dialog box, click OK.
8 Click Close to close the Icon Library dialog box. If you are adding a new icon, it
appears in the list of icons available on the Extended Object Definition panel.
For more information, see Creating or modifying an Upgrade Model Objects Job
on page 590.
You cannot distribute a custom configuration object to a server where the version of
the agent is incompatible.
Open the Jobs folder and navigate to a subfolder where you want to create a
new Distribute Configuration Objects Job. Right-click the folder and select
New => Administration Task => Distribute Configuration Objects from the
pop-up menu.
Open the Servers folder and navigate to the server to which you want to
distribute a new custom configuration object. Right-click the server and select
Administration Task => Distribute Configuration Objects from the pop-up
menu.
These tabs correspond to panels in the New Distribute Configuration Objects Job
wizard. Use them to modify the job definition.
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
1 Check Show all configuration object versions if you want this panel to display
all versions of the available custom configuration objects. By default the panel
only displays the most recent version of a custom configuration object.
2 Check Always use latest configuration object versions when running job if you
want this job to distribute only the most recent version of a custom configuration
object. Clearing this option means the job distributes the version of the custom
configuration object that was selected when this job was created.
4 Click the right arrow to move your selections to the right panel.
To remove an object from the list on the right, select it and click the left arrow. To
remove all objects from the list on the right, click the double left arrow.
In the Available Targets list, select the servers or server groups where you want to
run this job. Then click the right arrow to move your selections to the right panel.
To remove an item from the list on the right, select it and click the left arrow. To
remove all items from the list on the right, click the double left arrow.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Distribute Configuration Objects Job Scheduling on page
588.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Distribute Configuration
Objects Job Scheduled Job Notifications on page 587.
Distribute Configuration Objects Job Scheduled Job Notifications
The Scheduled Job Notifications tab lets you send notifications when a scheduled job
completes.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
that integrate traps into your trap collection system. The MIB is located at
installDirectory/Share/BladeLogic.mib.
Indicates email notifications should list all servers on which a job has failed.
Distribute Configuration Objects Job Scheduling
The Schedule tab lets you schedule a job so it can run once, recur hourly, daily,
weekly, or monthly, or recur at some arbitrary interval.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
For any property that has a check in the Editable column, select the property and
click in the Value column.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
Policy-based objects are not automatically upgraded to reference the new version. If
you do want to upgrade them, one way to accomplish that is to run an Upgrade
Model Objects Job. Alternatively, you can edit each of the policy-based objects so it
includes the correct version of a custom configuration object.
1 Open the Jobs folder and navigate to a subfolder where you want to create a new
Upgrade Model Objects Job. Right-click the folder and select New =>
Administration Task => Upgrade Model Objects from the pop-up menu.
2 Provide information for the Upgrade Model Objects Job, as described in the
following sections:
1 To modify the definition of an existing Upgrade Model Objects Job, open the Jobs
folder and navigate to an existing job. Right-click the job and select Open from
the pop-up menu. The content editor displays a series of tabs, which are described
in the following sections:
These tabs correspond to panels in the Upgrade Model Objects Job wizard. Use
them to modify the job definition.
Field definitions
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
2 Click the right arrow to move your selections to the right panel.
To remove an object from the list on the right, select it and click the left arrow. To
remove all objects from the list on the right, click the double left arrow.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Upgrade Model Objects Job Scheduling on page 594.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Upgrade Model Objects Job
Scheduled Job Notifications on page 594.
Upgrade Model Objects Job Scheduled Job Notifications
The Scheduled Job Notifications tab lets you send notifications when a scheduled job
completes.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Upgrade Model Objects Job Scheduling
The Schedule tab lets you schedule a job so it can run once, recur hourly, daily,
weekly, or monthly, or recur at some arbitrary interval.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
For any property that has a check in the Editable column, select the property and
click in the Value column.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
Open the Jobs folder and navigate to a subfolder where you want to create a
new Deregister Configuration Object Job. Right-click the folder and select
New => Administration Task => Deregister Configuration Objects from the
pop-up menu.
Open the Servers folder and navigate to the server where you want to remove
custom configuration objects. Right-click the server and select Administration
Task => Deregister Configuration Objects from the pop-up menu.
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Field definitions
Check this option if you want this panel to display all versions of the
available custom configuration objects. By default the panel only displays the
most recent version of a custom configuration object.
Check this option if you want this job to remove all versions of a custom
configuration object on the target server. Clearing this option means the job
only removes the selected version of a custom configuration object.
Select one or more custom configuration objects. Click the right arrow to
move your selections to the right panel.
To remove an object from the list on the right, select it and click the left
arrow. To remove all objects from the list on the right, click the double left
arrow.
In the Available Targets list, select the servers or server groups where you want to
run this job. Then click the right arrow to move your selections to the right panel.
To remove an item from the list on the right, select it and click the left arrow. To
remove all items from the list on the right, click the double left arrow.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Deregister Configuration Objects Job Scheduling on
page 602.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Deregister Configuration
Objects Job Scheduled Job Notifications on page 601.
Deregister Configuration Objects Job Scheduled Job Notifications
The Scheduled Job Notifications tab lets you send notifications when a scheduled job
completes.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Deregister Configuration Objects Job Scheduling
The Schedule tab lets you schedule a job so it can run once, recur hourly, daily,
weekly, or monthly, or recur at some arbitrary interval.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
For any property that has a check in the Editable column, select the property and
click in the Value column.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
BMC Server Automation provides many types of jobs, as listed in Job types on
page 607. A job run is the result of executing a job at a particular time on one or
more servers. A single job may have many job runs. A job definition is the set of
instructions that are in effect for a particular job run.
To successfully execute a job, you need multiple levels of authorization. First, your
role must be authorized to read and execute a particular category of job, such as
Deploy Jobs or Component Discovery Jobs. Then, your role must have permission to
read and execute a particular job. Finally, you must have permission to act on a
target resource. For example, you must be able to read the server or component
where you are running a job. If a job modifies a target resource, you must have
appropriate permission for that. For more information about defining permissions,
see Access management on page 165. If you attempt to run a job on a server for
which your role is not authorized, the job will not run and the status of the job on
that server is set to NOT_ATTEMPTED.
All jobs execute in the background, allowing you to execute multiple jobs
simultaneously. You can even execute the same job simultaneously under the
following circumstances:
Batch Job
Each instance of the job cannot target any of the same servers.
To keep track of the progress of any specific job across its multiple job runs, you can
create an Execution Task for the job. The Execution Task concentrates information
about the relevant job runs as they progress towards the successful completion of the
job on all target servers. You can also use Execution Tasks to define separate job
schedules for different target servers and to coordinate job schedules with upcoming
maintenance windows on the various servers. In addition, you can use an Execution
Task to override job properties without modifying the original job.
Job defining tasks are mostly covered in the various sections that focus on individual
job types. Additional tasks for the creation and definition stage that are described in
the following sections include organizing jobs and assigning properties to jobs.
After jobs have been defined, BMC Server Automation provides various ways to
access the jobs. For jobs in progress, you can use the Tasks in Progress view to obtain
information about and to cancel jobs in progress. For scheduled jobs, you can use the
Job Schedules view.
The most important point of access is the Jobs folder. From the Jobs folder you can
execute jobs and view job definitions, job results, job history, and job logs. While
browsing a specific server through the Servers folder, you can view job activity for
jobs that have already executed on the server, and you can also access full job results
for Snapshot Jobs and Audit Jobs that have run on the server.
BMC Server Automation provides procedures that can help you avoid or resolve
issues that may occur when a job encounters an unresponsive or unlicensed server.
These include defining time-outs for jobs and updating server status before running
a job.
BMC Server Automation lets you export most types of jobs so they can be saved in
an external file system, and then import those jobs back into BMC Server
Automation.
BMC Server Automation includes a retention policy utility that allows you to mark
old job runs for deletion from the database. For more information, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Marking+data+for
+deletion.
Job types
The following types of jobs are available in BMC Server Automation:
ACL Push Jobs Convert the permissions for servers into entries in access control lists and
then copies those lists to agents.
Application Discovery Jobs Discover the components of Java EE application servers. This type of
discovery job is available only if you have installed the BMC Application
Automation solution. For more information, see the BMC Application
AutomationEnterprise Edition Getting Started Guide.
Agent Installer Jobs Install multiple agents on agentless devices.
Atrium Import Jobs Transfer business service data from a BMC Atrium CMDB to the BMC
Server Automation database. For more information, see the BMC Server
AutomationAtrium Integration Implementation Guide.
Audit Jobs Determine whether server configurations comply with a standard
configuration.
Batch Jobs Run a concatenated series of other jobs on remote servers.
Compliance Jobs Determine whether components satisfy compliance rules established for a
component template.
Component Discovery Jobs Associate components with servers that match conditions that you define
for each component template.
Deregister Configuration Remove implementation files for custom server objects from servers.
Objects Jobs
Distribute Configuration Distribute implementation files for custom server objects to servers where
Objects Jobs you want to use these objects.
File Deploy Jobs Copy files and directories from a managed server to multiple locations.
Network Shell Script Jobs Deploy and execute Network Shell scripts on remote servers.
Patching Jobs Manage patch configurations on servers running any operating system by
comparing the patches on those servers to standard configurations or to
collections of patches that you specify.
Provision Jobs Perform unattended installations of operating systems on new machines
(bare metal machines) or re-provision existing machines.
Publish Product Catalog Jobs Publish component template property values to the Product Catalog in
Atrium CMDB. For more information, see the BMC Server
AutomationAtrium Integration Implementation Guide.
SCAP Compliance Jobs Analyzes selected servers for compliance with rules and checklists in a
selected SCAP benchmark.
Software and BLPackage Deploy BLPackages and software installables to remote servers without
Deploy Jobs user interaction.
Snapshot Jobs Record the configuration of a group of server objects at a point in time.
Update Server Properties Jobs Obtain the most recent property settings from agents and update them in
the BMC Server Automation console.
Upgrade Model Objects Jobs Upgrade policy-based objectsthat is, component templates, BLPackages,
and server object-based Snapshot and Audit Jobsso they reference the
most recent version of a server object.
Virtual Guest Jobs Deploy new VMware virtual machines on the VMware vCenter server
(which must be a BMC Server Automation managed server).
Virtual Guest Template Automatically discover operating system templates on VMware and Citrix
Enrollment Jobs XenServer systems, and create Virtual Guest Packages for the discovered
templates.
Virtual Infrastructure Provide a view of the virtual machine inventory, without having to
Discovery Jobs manually find and register each virtual machine.
Workflow Jobs Manage BMC Atrium Orchestrator workflow processes from any BMC
Atrium Orchestrator run book module through the BMC Server
Automation Console.
Organization of jobs
In the Jobs folder, you can perform any of the following procedures to organize jobs:
Create folders and smart groups. (A smart job group is a group for which you
define membership conditions based on job properties.)
Note
When you copy and paste a job, all scheduling information is removed from the job
that is pasted.
BMC Server Automation provides a master list of all properties called the Property
Dictionary. You can use the Property Dictionary to create and edit properties that
you can later add to jobs.
You can assign one of any of the following priorities: Critical, High, Normal, Low,
and Lowest. By default, all job types have a priority of Normal. Note that these
priority levels are meaningful only in relation to each other.
Tip
For a list of the permissions and authorizations required to modify Job Priority, see
Authorizations for changing job priority on page 253.
System resources are assigned on a dynamic basis to jobs with higher priorities to
enable them to complete faster or in a more timely manner. To achieve more efficient
use of system resources, you can change the priority of scheduled jobs, or even jobs
that are currently executing.
Note
A high priority level does not guarantee a faster job completion time, which is
dependent on many factors, such as each jobs type, the work involved, the
responsiveness of the target nodes, and so on.
You can assign and modify priorities globally for all jobs, for each job type, for
individual jobs, and at the individual job schedule level. The following table lists the
various places in the BMC Server Automation Console where you can see the job
priority level.
View the assigned priority level in the Job Priority column of the Job
Results view.
Click Show Log to see the Job Priority field in the Job Run Details
window.
Open a job
Execute a job
Note
Through the Servers folder, these actions are available only for Snapshot Jobs and
Audit Job that have already executed on any specific server.
Through these folders you can also copy, cut, paste, and delete jobs as follows:
Cut, copy, and paste jobs between folders in the Jobs folder. (You cannot copy,
cut, or paste jobs through the Servers folder.) When you copy and paste a job, all
scheduling information is removed from the job that is pasted.
Delete jobs through the Jobs folder or the Servers folder. When deleting through
the Servers folder, the job is also deleted from the Jobs folder.
Note
There is a BMC Maintenance folder that is created by default in the Jobs folder. This
folder is created automatically, and contains a recommended database cleanup job.
See the http://docs.bmc.com/docs/display/bsa82/Managing+BMC+Server
+Automation+data topic on the BMC Server Automation wiki for more information.
Opening a job
You open an existing job so that you can view and modify its definitions.
To open a job
Using the Servers folder, right-click a server and select Browse. Then select the
Audit Results or Snapshot Results tab to navigate to a job.
2 Right-click the job and select Open from the pop-up menu.
The job appears in a tabbed window, where you can view and edit job properties.
Executing a job
After you define a job and it is stored in the relevant folders, you can execute the job
at any time. After the job is executed, you can monitor the progress of the job in the
Tasks in Progress view.
Ensure that you have, at minimum, Read and Execute authorizations for the job.
For example, to execute an Audit Job, you must have, at minimum, AuditJob.Read
and AuditJob.Execute.
To execute a job
Using the Servers folder, right-click a server and select Browse. Then select the
Audit Results or Snapshot Results tab to navigate to a job.
Using the Servers folder, right-click a server and select Browse. Then select the
Audit Results or Snapshot Results tab to navigate to a job.
2 Right-click the job and select Execute Against from the pop-up menu.
Alternatively, drag the job and drop it on a target server, or drag a target server
and drop it on the job.
3 In the Execute Job Now window, use the following steps to select target servers.
If you dragged and dropped a job or target server, your target server already
appears in the list of selected targets, and you can select additional target servers.
a From Available Servers, specify the operating system of the servers you want
to select. To display servers running any operating system, select All.
b Select servers from a tree or sortable list by doing one of the following:
Click By Group at the bottom of the window. The left panel displays servers
in a hierarchical list arranged by server group. Choose servers by doing one
of the following:
Click
a server group to select all servers within the group.
Click
one or more servers, if necessary expanding server groups.
Click By Name at the bottom of the window. The left panel lists servers by
name in a Group Explorer view. Sort servers in ascending or descending
order by clicking on any column header. Click one or more servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
c Click the right arrow to move your selections to the right panel.
To remove a server from the list on the right, select it and click the left arrow.
To remove all servers from the list on the right, click the double left arrow.
To further facilitate this iterative process, you can request the creation of an
Execution Task, which concentrates all information about the relevant job runs as
they progress towards the successful completion of the job on all target servers.
If you perform this procedure on a Deploy Job that failed on some target servers, the
entire job will run again on those servers. All phases of the job will repeat, even
those that previously succeeded. Similarly, performing this procedure on a Batch Job
that failed runs the whole Batch Job again, including all member jobs that previously
succeeded.
Note
Executing against failed targets is not relevant and cannot be performed for the
following types of jobs: Atrium Import Job, Provision Job, Upgrade Model Objects
Job, and Virtual Guest Job. Advanced Deploy Jobs are also not supported for
executing against failed targets.
Ensure that you have, at minimum, Read and Execute authorizations for the job.
For example, to execute an Audit Job, you must have, at minimum, AuditJob.Read
and AuditJob.Execute.
To repeat this procedure through an Execution Task, you must also have, at
minimum, the ExecutionTask.Read and ExecutionTask.Execute authorizations.
Using the Jobs folder, navigate to a job, right-click it, and select Show Results.
Using the Servers folder, right-click a server and select Browse. Then select the
Audit Results or Snapshot Results tab to navigate to a job.
2 Right-click a failed job run and select Execute Against Failed Targets.
Note
As a preferred alternative to these first steps and if you are repeating this
procedure after having already created an Execution Task during a previous
execution against failed targets (see Step 4 on page 615), navigate to the
Execution Task in the Jobs folder (instead of navigating to the job). Then do one
of the following:
Right-click the Execution Task and select Execute Against Failed Targets.
Right-click the Execution Task and select Show Results. Then right-click a
failed job run under the Execution Task and select Execute Against Failed
Targets.
A window shows the targets where this job has ended with warnings or errors.
All FailuresRuns the job on all servers where errors or warnings have occurred.
All WarningsRuns the job on all servers where warnings have occurred.
All ErrorsRuns the job on all servers where errors have occurred.
For each option, a list of the relevant servers (up to 100 servers) is displayed.
4 If you want an Execution Task created for this job as soon as the job starts
executing, select the Create Execution Task check box.
An Execution Task enables you to continue keeping track of subsequent job runs
until the job executes successfully on all target servers. For more information
about Execution Tasks, see Execution Tasks for managing job runs on page
624.
Note
To create an Execution Task, you must have, at minimum, the
ExecutionTask.Create authorization.
The Create Execution Task check box is not available if you accessed this window
from an Execution Task (rather than a job).
5 Click OK to execute the job immediately on the group of servers that you
selected.
A new job run is created for the job. This job run can be viewed under the job or
under its associated Execution Task (if you created one in Step 4 on page 615).
If there remain target servers on which the job failed, you can repeat this
procedure through the newly created job run, preferably from where it appears
under the Execution Task, or through the Execution Task itself.
For example, suppose you set up a Network Shell Script Job, and the script includes
certain commands. You do not want to grant permission to other users to perform
these commands. Under normal circumstances, those other users cannot successfully
execute the Network Shell Script Job because they would not have permission to run
those commands. With an execution override, however, you can set up your own
role and user as the override, and other role:user combinations can execute the job as
if your role and user had scheduled the job.
The override capability is particularly valuable when a user executes a job against
failed or specific targets. Those actions do not modify a jobs definition. One
role:user combination can set up an execution override, while another role:user
combination can run the job using these special approaches to job execution. Jobs run
in this way will execute using the role:user combination set up in the override.
When you set up an execution override, two job properties, EXECUTION_ROLE and
EXECUTION_USER, are set so they equal your current role and user. (Note that you
cannot manually edit the value of these properties.) If you remove an execution
override, these two properties no longer display a value, but they are set by default
to equal the role and user who scheduled the job.
1 On the Job Options panel of the Batch Job wizard or the General panel of any
other job wizard, do one of the following:
To define an execution override so that the job executes as the current role:user
combination, click Set Execution Override.
The job definition shows the role:user combination under which the job will
execute.
For information about configuring the connection to BMC Atrium Orchestrator and
BMC Remedy ITSM, see BMC technical documentation at https://docs.bmc.com/
docs/display/bsa82/Enabling+BMC+Remedy+ITSM+integration+for+job
+approval.
You can specify an approval type when you execute a job or when you schedule a
job. In addition to specifying the approval type, you must specify values for several
approval parameters that determine the values of the corresponding BMC Remedy
ITSM change ticket parameters that are created when the job definition is completed.
Note
If multiple users are executing the same job, each user must acquire approval by
submitting a separate approval request. Approval requests are associated with the
job schedule and are not associated with the job. Associating an approval request
with the job would mean that all users would be able to use the same approval reply.
1 Access the appropriate dialog box box or panel for specifying approval type. This
happens in the following scenarios:
When defining a schedule for a job, either through a wizard for creation of a
new job or while editing an existing job, if BMC Remedy ITSM approval is
required, the Approval Information tab is displayed.
2 On the Enter approval information dialog box or the Approval Information tab,
choose the Approval type from the list of pre-defined options, as described in the
table below.
Note
Approval types are available to you based on your role. For example, the
BLOperator role might be configured with authorization for manual approval,
while the BLAdmins role might be authorized for all approval types.
Manual approval Use this option for jobs that require a BMC Remedy ITSM administrator to
review the job details and impact level prior to approving execution.
By default, this option generates a change request with a Change Timing value
of Normal and an Urgency value of Medium.
Note: Approving a job may take some time. The administrator that approves
the job may not be available for some time (on manual approval), so submit the
approval request as early as possible.
Automatic approval Use this option for change requests that use an Approval Process
Configuration form to automatically approve the request.
By default, this option generates a change request with a Change Timing value
of No impact and an Urgency value of Medium.
Emergency approval Use this option for jobs that need immediate attention and must be run
immediately.
By default, this option generates a change request with a Change Timing value
of Emergency and an Urgency value of High.
No approval If you select No approval, you are not required to enter the additional BMC
Remedy ITSM parameters.
If a job type requires approval and you select No approval, the approval
mechanism is bypassed and the job executes either immediately (Execute now)
or as scheduled. This option enables users with the authorization to select No
approval to bypass the approval process for special circumstances.
The Job Approval type defines what values must be populated in the change
request by the BMC Remedy ITSM user.
Field Enter
Change type Enter the type of change being requested. The default value is Change.
Comments Enter any additional comments that would be helpful to the BMC
Remedy ITSM user approving the request.
Impact Enter the impact level of the requested change. For example, is the job
targeted for one server, or for a large number of servers? The default
value is Minor/Localized.
Select Use existing Change Ticket, and enter the IDs for the existing change
request and task in BMC Remedy ITSM. In this case BMC Server Automation
does not create a new change request, but rather updates the specified change
request and task.
Note
When using an existing change ID, the change ID can be from:
5 Click OK.
Note
If the job requires BMC Remedy ITSM approval (Automatic, Manual or
Emergency) then you are not allowed to configure a recurring schedule on the
Schedule tab.
You may now want to check whether the interaction between the job and the change
management system was successful, as described in Verifying a job with BMC
Remedy ITSM approval on page 620.
You can check to see if the interaction with the change management system was
successful by reviewing the job schedule log, which is displayed under the job until
the job starts running.
You can also check the job schedule log through the Schedule tab within job definitions.
if the attempt to schedule the job has failed (for example, failed to create or
update the change ticket)
Note
After the job starts executing after approval, the information in the job schedule
log is rolled into the job log.
If any of the following conditions exist, then the job schedule is terminated and an
error message is logged in the BMC Server Automation job log file:
Status of the change request or task in BMC Remedy ITSM is set to Closed or
Completed
The information provided in the Tasks Progress view for each task in progress is
described inInformation in the Task in Progress view on page 623.
When jobs are executing in the background, you can close the BMC Server
Automation console and the jobs will continue to run. When you open the console, if
jobs are currently running in the background, the Tasks in Progress view displays
information about them.
To cancel any job, a role must be granted both Read and Cancel permissions for that
type of job. For example, to cancel a Deploy Job, your role must be granted
DeployJob.Cancel and DeployJob.Read.
1 Select one or more jobs listed in the Tasks in Progress view. Use Shift-click or
Control-click to select multiple tasks.
2 Click Cancel .
The Cancel option sends out requests to cancel tasks and allows time for threads
to shut down. The Abort option triggers a more forceful and immediate
termination of tasks.
Note
For a Batch job, the Cancel option waits for child jobs to be cancelled and only
then cancels the parent job, while the Abort option terminates the parent job first
and then also terminates the child jobs.
When you cancel or abort an executing Workflow Job, a request to cancel the
associated workflow process is sent to BMC Atrium Orchestrator, and process
termination messages (with a status of either CANCELLED or COMPENSATED)
are returned to the Workflow Job run log. A child job cannot be cancelled if it has
already started executing.
You can pause a running job, or group of jobs, to enable resources to be used by
more critical jobs, or to modify the runtime execution priority of a job. For example,
consider the following scenario. The default priority for Deploy Jobs in your
environment is Normal, yet you have a Deploy Job which needs to be executing
immediately. There are a lot of other jobs running at this time, so to ensure that your
Deploy Job is executed as efficiently and quickly as possible, you do the following:
pause your Deploy Job and change the runtime priority to HIGH
Note
To pause and resume any job, a role must be granted both Read and
PauseResumeExecution permissions for that type of job. For example, to pause and
resume a Deploy Job, your role must be granted DeployJob.PauseResumeExecution
and DeployJob.Read.
1 Select one or more jobs listed in the Tasks in Progress view. Use Shift-click or
Control-click to select multiple tasks.
2 Click Pause .
1 Choose Close on the tab or right-click the Task in Progress view tab and
choose Close.
If a job begins when the Tasks in Progress view is hidden, a dialog informs you
that the job has started running in the background.
Table 5 on page 623 presents the information provided in the Tasks in Progress
view for each task in progress.
Column Description
Progress Progress bar shows how much of the job or task has executed.
Activity Status of the job or task. This column provides values such as Running,
Cancel Pending, Completed Successfully, Completed With Errors, and
Completed With Warnings.
Start Time Time when the job began.
Name Name of the job that is executing.
Type Type of job.
User User who executed the job.
Role Name of the role of the user who executed the job.
Priority Job execution priority level (available priority levels are Critical, High,
Normal, Low, and Lowest).
MAC Address (Provision Job only) Media Access Control address (MAC address) is a
unique identifier assigned to most network adapters or network interface
cards by the manufacturer.
Waiting for approval When you submit a job that requires BMC Remedy ITSM approval, the job is
blocked until approval notification is received from BMC Remedy ITSM. The
job displays a status of Waiting for Approval.
Additional statuses are possible if BMC Server Automation is configured to
integrate with BMC Remedy ITSM.
Host Name (Provision Job only) Name of the host on which the job is executing.
Column Description
Device Type (Provision Job only) The provisioning technology being used to provision the
serverPXE, JumpStart, or NIM.
Device Description (Provision Job only) Description of the device being provisioned.
keep track of job runs while you iteratively execute the job on failed targets until
the successful completion of the job on all target servers
define separate job schedules for different target servers and coordinate job
schedules with upcoming maintenance windows on the various servers
override certain job properties with different values, without having to change the
properties of the original job
Note
Execution Tasks are not relevant and are not available for the following types of jobs:
Atrium Import Job, Upgrade Model Objects Job, and Virtual Infrastructure
Discovery Job. Advanced Deploy Jobs are also not supported by Execution Tasks.
You can create an Execution Task manually or you can request the creation of the
Execution Task while executing a job against failed targets. After the Execution Task
is created, you can execute the associated job and view job run information through
the Execution Task.
Note
To create an Execution Task, you must have, at minimum, the ExecutionTask.Create
authorization.
The Execution Task is added to the Jobs tree alongside the job with which it was
associated. Its name is formed automatically by appending the date and time to the
name of the original job. At this point, the Execution Task contains only two job runs
the selected original job run and the newly created job run that ran against the
specified subset of target servers (that is, servers that returned errors, servers that
returned warnings, or both).
If you need to repeat the execution of the job against failed targets after the
Execution Task has been created, you can do so through the Execution Task, where
all information necessary for tracking job progress towards full success is
concentrated. Alternatively, you can modify the Execution Task and add recurring
schedules for the job, so that it will continue to progress towards successful
completion on all targets.
Right-click the job folder in which you want to store the Execution Task and
select New => Execution Task.
Right-click the job with which you want to associate the Execution Task and
select Create Execution Task.
Note
If the Execution Task is associated with a Workflow Job, a Virtual Guest Job, a
Provision Job, or a UCS Provision Job, target selection is not relevant and the
Targets panel is not displayed.
3 When you have finished defining all Execution Task settings, click Finish.
The Execution Task is added to the Jobs tree under the job with which it was
associated.
Field Definitions
Name
Identifying name.
Description
Save in
Job Selection
If you accessed the Create New Execution Task wizard through a specific job,
that job already appears as the associated job.
Select Use job targets for the Execution Task to run against the same target
servers that were defined for the associated job.
Select Use the following targets (the default option) to specify targets for the
Execution Task. Then transfer any number of target servers from the list of
available servers to the list of selected servers using the right arrow.
For certain types of jobs, you have a choice of selecting target servers from either a
tree on the By Group tab (where you can also select server groups or smart server
groups) or from a sortable list on the By Name tab.
For certain types of jobs, you can also select target components through the
Targets panel, as relevant for the specific job type.
Set property
Through this field, select the relevant job property, and then enter a new
value to be used by the Execution Task for the property.
The list of available properties that you can override includes a wide range of
job properties of various data types. Custom properties of the following
complex data types are not included: any ACE or ACE Mask type and the
List [String] type.
To override the value of another job property, click the + (plus) icon and
again select a property and set a value.
To remove a property from your list of job properties to override, click the
(minus) icon.
Example
You have associated a trouble ticket number with your job through a custom
property, but you do not want to have to modify the value of this property every
time you run the job. Instead, you base an Execution Task on the job whenever you
have a new ticket number to associate with the job.
Note
After running the Execution Task, you can access the definitions of a job through the
results of any specific job run and see the new values that you defined for overriding
job properties. For more information, see Viewing the job definition of a job run on
page 641.
With the Schedule Till Completion option on the Schedule tab, you can use a
recurring schedule to execute the job repeatedly on targets where it failed until its
successful completion on all targets (limited to a certain number of retries).
Note
Automatic creation of schedules based on maintenance windows and the use of
recurring schedules until successful completion are not available if you chose the
Use job targets option in the Targets panel or if the Execution Task is associated
with a Workflow Job, a Virtual Guest Job, a Provision Job, or a UCS Provision Job.
Once
The On date field contains the date for the one-time schedule, in yyyy/mm/
dd format. The At field contains the schedule time, in 24-hour clock format
(00:00 to 23:59).
Daily
Recurring daily schedule, for the job to run at a set time once a day. The time
goes in the At field, in 24-hour clock format (00:00 to 23:59).
Weekly
Enter a weekly interval in the Every field (for example, enter 3 if the job
should occur every three weeks), and the execution time in the At field.
For On the following days, select the days of the week when the job should
execute. You can select multiple days.
Monthly
Recurring schedule based on a day of the month. Enter the day of the month
and the time of day for job execution.
Interval
For Start At, enter the date and time when the job should first occur. For
Repeat Every, enter the interval (number of days + hours + minutes) for
subsequent occurrences.
Repeatedly execute the job that the Execution Task controls, based on the
defined recurring schedule, only on the targets where it failed in the previous
job run (or, for the first scheduled job run, on all targets where it did not yet
run) and only until successful completion of the job on all targets (but limited
to a defined maximum number of times or length of time).
Set a limit for the number of recurring job runs, after which the Execution
Task gives up on the failed targets that still remaineither set the maximum
number of retries or set an end date and time after which the job will no
longer run. Job execution might stop earlier, if the job completes successfully
before reaching the limit number of retries or date that you set.
If you want to run the job according to the recurring schedule not only on
targets that ended in error status, but also on targets that ended in warning
status, select the Include servers with warnings check box.
If you want to include target servers where the job has not yet run (after the
first scheduled job run, when such servers are the default targets), select the
Include servers in Not Run status check box.
Note
The number of times that the job has already executed according to your
recurring schedule appears beside the Schedule Till Completion check box.
The Schedule Till Completion option is not available if you chose the Use
job targets option on the Targets panel or if the Execution Task is associated
with a Workflow Job, a Virtual Guest Job, a Provision Job, or a UCS Provision
Job.
Time zone
if you schedule a job that should run weekly at 06:00 Eastern Standard Time,
the job always runs at 06:00 Eastern Time, no matter whether standard or
daylight savings time is in effect.
Note
All component machines in a BMC Server Automation system should have
their clocks synchronized.
Priority
Select an execution priority level from the drop-down list (available priority
levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum
runtime level that is set for your role, which is indicated next to the drop-
down list.
Execution Tasks Scheduled Job Notifications
The Scheduled Job Notifications tab lets you send notifications upon completion of
the scheduled job that the Execution Task controls.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
You can select any number of target servers for the job schedule from either a tree on
the By Group tab (where you can also select server groups or smart server groups)
or from a sortable list on the By Name tab, and transfer them from the list of
available servers to the list of selected servers using the right arrow.
For any property that has a check in the Editable column, select the property and
click in the Value column.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
1 Open the Jobs folder and navigate to an existing Execution Task. Then do any of
the following:
Note
You cannot change the job with which the Execution Task is associated.
To select target servers in the Targets panel, you must first click Add Servers
.
You cannot switch between the Use job targets and Use the following targets
options on the Targets panel.
If the Execution Task is associated with a Workflow Job, a Virtual Guest Job, a
Provision Job, or a UCS Provision Job, target selection is not relevant and the
Targets panel is not displayed.
Ensure that you have, at minimum, Read and Execute authorizations not only for the
job (for example, AuditJob.Read and AuditJob.Execute), but also for the Execution
Task (ExecutionTask.Read and ExecutionTask.Execute).
To execute the job against all target servers defined in the Execution Task, even
those targets where the job already completed successfully, perform one of the
following procedures:
Navigate to the Execution Task in the Jobs folder, right-click it, and select
Execute.
Right-click the Execution Task and select Show Results. Then right-click the
Execution Task in the root node and select Execute.
To execute the job only against target servers where previous job runs have not
completed successfully, perform one of the following procedures:
Navigate to the Execution Task in the Jobs folder, right-click it, and select
Execute Against Failed Targets.
Right-click the Execution Task and select Show Results. Then right-click a
failed job run under the Execution Task and select Execute Against Failed
Targets.
To view information for the Execution Task and all its job runs
The expanded Execution Task shows all the job runs that have run under the
Execution Task. This information appears in tabular form on the right, with a row
for each target server.
2 Select a job run to display basic information about the job run (as displayed for
job runs under expanded jobs).
This information appears in tabular form at right, with a row for each target server.
Note
The maximum number of job runs that are displayed under the expanded
Execution Task is controlled by the Page Size setting in the Preferences dialog
box, with a default value of 50. If more job runs exist, you can page through the
results, as described in Paging through job results on page 75.
3 Select the Execution Task in the root node to display a tabular matrix of
information that tracks the progress of the job on all target servers currently
associated with the Execution Task.
For each target server, the following columns of data are available:
Next ScheduleNext date and time that the Execution Task is scheduled to
run the job at this target server
specific job run (multiple columns)Execution status at the target server at the
end of a specific job run, with one column for each job run identified by date
and time
Note
The matrix of information about job progress on target servers is not relevant if
you chose the Use job targets option on the Targets panel or if the Execution Task
is associated with a Workflow Job, a Virtual Guest Job, a Provision Job, or a UCS
Provision Job. Instead, basic information is displayed for all job runs.
The maximum number of target servers that are displayed in the matrix is
controlled by the Execution Task Matrix Page Size setting in the Preferences
dialog box, with a default value of 100. If more target servers are associated with
the Execution Task, you can page through the results.
1 Right-click the job run under the Execution Task, and select Remove from
Execution Task.
The job run is removed permanently from display in the Execution Task. The
summary matrix of information provided through the Execution Task root node is
adjusted to not include information from target servers that are no longer relevant.
The original job with which the Execution Task was associated is not affected, and
the same job run continues to appear within the display of the relevant job.
Note
If you prefer to completely delete the job run from the job, right-click the job run and
select Delete.
Using the Jobs folder, navigate to a job, right-click it, and select Show Results.
Using the Servers folder, right-click a server and select Browse. Then select the
Audit Results or Snapshot Results tab to navigate to Snapshot or Audit Jobs
that have run on this server.
All runs of the job and their outcome display beneath the job.
1 Using the Servers folder, right-click a server and select Browse. Then select the
Activity tab.
Job runs that occurred for the selected server are listed based on default filters.
2 Change the filter for job information by choosing a combination of the following
criteria:
From Activity for, select the time period for which you want job activity.
From By Activity Type, select All to show activity information for all types of
jobs. Select a particular type of job, such as Deploy or Audit, to show activity
for only that type of job.
The Activity tab displays job runs that satisfy the criteria you specify. For
example, if you select Last 7 days and Audit, the Activity tab shows all Audit Job
runs that executed during the last seven days on the selected server.
2 Navigate to a job.
3 Right-click the job and select Show Results to display its job runs.
The status of the job is indicated by the color-coded symbol to the left of the job
instance.
GreenCompleted Successfully
For information about additional status types that apply to jobs configured for
BMC Remedy ITSM approval, see Status types for change management approval
jobs on page 640.
If a problem occurs
Job run results include a status code that provides additional details at both the
target (for servers and components) and the run level for the job run results. The
codes categorize the results into groups of known error conditions, providing a clear
indication for job failure or an explanation of a specific status. For example, status
codes are generated for known common errors such as access denied, out of
memory, database error, and so on.
Under the Job Results view, right-click the job run and select Show Log. The log
results are organized by progress status, followed by the error codes, then finally by
the targets under each error code. The message text for the error code is presented in
the results pane, under the Message column.
Note
The Job Priority column in the Job Results view indicates the execution priority
(Critical, Normal, or Low) that is associated with a job run. For more information,
see About job priorities on page 609.
The following list indicates the status codes you may encounter when viewing the
job log for a specific job type.
Aborted
Access Denied
Already Running
Canceled
Connection Refused
Database Error
Host Unreachable
No Agent
Out of Memory
Server Offline
Unlicensed Agent
Unknown Host
Note
Not all status codes are available for every job type.
When you display job results for such a job, an approved schedule is shown with the
yellow Completed with Warnings icon. Failed schedules are displayed with the red
Completed with Errors icon.
The following table lists the status types that apply to jobs configured for BMC
Remedy ITSM approval.
Status Description
Waiting for approval The job has been submitted for approval in BMC Remedy ITSM, and
execution is blocked pending approval notification.
Request approved - Waiting for The change request has been approved in BMC Remedy ITSM, and job
schedule execution is pending according to the job schedule.
Request approved - Executed Shows the job run instance with a status of success or failed.
(success or failure)
Possible reasons for the red failure icon for jobs submitted for BMC Remedy ITSM
approval are:
The job failed to create the BMC Remedy ITSM change ticket when the schedule
was created and saved.
After the job execution is complete, the BMC Remedy ITSM change ticket is closed
and the ticket workinfo note is updated with the BMC Server Automation job
completion status (success, failed, cancelled or aborted).
Note
If the change request in BMC Remedy ITSM is rejected or canceled, then the
corresponding BMC Server Automation job schedule remains in the Waiting for
approval state (shown in the Tasks in Progress view). The change request may be re-
opened and moved into pre-approved state later. If the change request remains in a
Rejected or Canceled state after the job schedule expires, the job does not execute
and the change request is closed.
When a job that requires approval in Waiting for Approval status is canceled (for
example, the job is canceled due to time-out), the BMC Remedy ITSM change request
is automatically closed.
Example
An operator in the IT operations organization is using BMC Server Automation to
implement changes on the data center servers. The operator selects the Execute Now
option for a job and specifies that the change should be approved in BMC Remedy
ITSM by selecting an appropriate approval type.
After completing the job definition in the job wizard, the job execution is blocked
and displays Waiting for approval status in the Tasks in Progress view. As soon as
the corresponding change request in BMC Remedy ITSM has been approved and
BMC Server Automation has been notified, the job is executed.
Using the Servers folder, right-click a server and select Browse. Then select the
Audit Results or Snapshot Results tab to navigate to a Snapshot or Audit Job.
Expand the job to display the job runs.
Using the Servers folder, right-click a server and select Browse. Then select the
Activity tab to display the job runs.
Open the Jobs folder, navigate to a job or Execution Task, right-click the job or
Execution Task and select Show Results to display its job runs.
2 Select a run of a job, right-click, and select Show Job from the pop-up menu.
A window displays the job definition that was used to generate the job run.
For example, you can see the values of job properties on the Properties tab.
Note
To obtain data about jobs based on a specific job property value, you can also use
the exportJobDataByPropertyValue BLCLI command. For more information
about this command, see the BLCLI help.
You can:
View all messages generated for an entire run of a job or only those messages
pertaining to a specific server.
See the servers on which a job ran and whether the job succeeded on those servers.
Export the log generated by a job. Logs are exported in CSV format so you can
easily import their contents into spreadsheets and databases.
Using the Servers folder, right-click a server and select Browse. Then select the
Activity tab to display the job runs.
Using the Servers folder, right-click a server and select Browse. Then select the
Audit Results or Snapshot Results tab to navigate to a job. Expand the job to
display the job runs.
Open the Jobs folder, navigate to a job or Execution Task, right-click the job or
Execution Task and select Show Results to display its job runs.
3 To filter messages so the job log only shows servers with specific job results, use
the Run Details drop-down to select Errors, Warnings, Success, or All.
4 To display messages pertaining to a specific server, select that server in the list at
left.
The list of messages on the right displays only messages related to the selected
server.
5 To display messages in a dialog box that allows you to scroll through messages one-
by-one, double-click on a message. The Log Item Details dialog box opens. Click
the Up arrow or the Down arrow to scroll through messages one-by-one. Click
Close to close the dialog box.
Using the Servers folder, right-click a server and select Browse. Then select the
Activity tab to display the job runs.
Using the Servers folder, right-click a server and select Browse. Then select the
Audit Results or Snapshot Results tab to navigate to a job. Expand the job to
display the job runs.
Open the Jobs folder, navigate to a job or Execution Task, right-click the job or
Execution Task and select Show Results to display its job runs.
3 Specify the location where you want to store the exported results.
5 From Object Type, select the default CSV format for the exported log file.
6 From File encoding, select the type of character encoding used for the exported file.
7 Click Save.
A list of scheduled jobs is displayed, containing all currently scheduled jobs that
you have permission to see. For each job, the following information is displayed:
Job name
Job type
Schedule
You define a time-out period for a job by assigning a value to a jobs JOB_TIMEOUT
property that specifies a maximum period of time, in minutes, for the job to
complete. If the job exceeds this maximum, the system automatically cancels the job.
You define a time-out period for a job part by assigning a value to a jobs
JOB_PART_TIMEOUT property that specifies a maximum period of time, in
minutes, for each job part to complete. If completion of a job part exceeds this
maximum, the system automatically cancels that job part along with all other job
parts running on the same server. The rest of the job continues.
Canceling all job parts on the same server prevents situations where multiple job
parts must time out serially on the same unresponsive server. If necessary, you can
override this capability on a global basis so only a single job part times out while all
other job parts continue to execute. You can also set a value for how long the
canceling of a job part should take.
To determine an appropriate value for job-level and job part time-outs, you must
consider many factors, such as the load on a machine and the contents of each job
part. You may want to test by performing multiple iterations on a job to determine
appropriate time-out values. For example, if you perform some tests and determine
that the processing of a job part never requires more than two minutes, you might
set the job part time-out to be five minutes.
In the Jobs folder, navigate to a job, right-click the job and select Show Results.
Using the Servers folder, right-click a server and select Browse. Then select the
Audit Results or Snapshot Results tab to navigate to a Snapshot or Audit Job.
The job appears in a tabbed window, in whioch you can view and edit the job
properties.
To add a job-level time-out, click the cell in the Value column for the
JOB_TIMEOUT property. Enter a maximum period of time to elapse before
the job is automatically canceled.
Note
When applying job-level time-outs, be aware of the following:
Job-level time-outs apply only to job types for which job scheduling is possible.
For Batch Jobs, only the Batch Job can be scheduled. Therefore, BMC Server
Automation ignores job-level time-outs set for member jobs that make up a
Batch Job.
To add a job part time-out, click the cell in the Value column for the
JOB_PART_TIMEOUT property. Enter a maximum period of time (in
minutes) that should elapse before a job part is canceled.
Note
By default, all other job parts acting on the same server are also canceled when
one job part times out. This prevents situations where multiple job parts must
time out serially on the same unresponsive server. However, you can override
this behavior by setting the PropagateWorkItemTimeout property through the
Application Server Administration console (the blasadmin utility).
If cancellation of a job part exceeds the maximum period of time defined, the
entire job is canceled. This prevents situations where cancellation of a job is not
performing as expected and the act of canceling the job is actually hanging a
job. To specify a maximum amount of time for canceling a job part, modify the
MaxTimeForCancelToFinish property through the Application Server
Administration console (the blasadmin utility)
For more information about configuring the Application Server, see BMC
technical documentation at https://docs.bmc.com/docs/display/bsa82/
Configuring+the+Application+Server.
Individually for a job instance (for example, when creating a job, creating a job
schedule, editing an existing schedule, or pausing a running job and changing the
runtime job property)
Tip
For a list of the permissions and authorizations required to modify job priority, see
Authorizations for changing job priority on page 253.
1 Select Configuration => Property Dictionary View. The Property Dictionary opens.
3 Navigate to the job type for which you want to set the job priority.
5 On the Modify Property dialog box, click Use the default value and then select a
priority level. Available priority levels are Critical, High, Normal, Low, and Lowest.
6 Click OK.
1 You can set the priority for a specific job or job instance in any of the following ways.
Setting the priority at the schedule level provides great flexibility, as you can
schedule the same job at different times with different priorities.
1 From the Schedule tab, you can select an execution priority level from the drop-
down list.
You cannot select a priority level higher than the maximum runtime level that is
set for your role, which is indicated next to the drop-down list.
Right-click the job and select Set Property. The Set Job Properties window is
displayed. Select PRIORITY* from the Name drop-down list.
In the Properties tab, select PRIORITY* from the Extended Properties list.
3 Select a priority level from the drop-down list (available priority levels are
Critical, High, Normal, Low, and Lowest).
4 Click OK.
You can pause a running job from the Progress Status panel (provided you have the
appropriate authorization), update the priority of a critical job so that resources can
be dedicated to that job, and then resume the paused job.
Pausing a running job places all waiting work items on hold until the job is resumed.
If all of the work items for a running job have already begun processing, then
pausing the running job has no functional impact.
After pausing the job, you can run the job with a higher or lower priority.
1 Select one or more jobs listed in the Tasks in Progress view. To select multiple
tasks, use Shift-click or Control-click .
2 Click Pause .
3 To change the execution priority for a job, click Modify Runtime Priority .
Snapshot overview
Snapshots record the configuration of a group of server objects at a point in time.
Snapshots are particularly useful for capturing standard configurations that can be
used when performing audits. To take a snapshot, you must run a Snapshot Job.
When you define a Snapshot Job, you can take a snapshot of components or live
server objects.
Snapshot Jobs include a feature called change tracking that lets you view the changes
that occur between the first time you take the snapshot, which functions as the
baseline, and the next snapshot at the current moment in time. Change tracking lets
you view the changes in an easy to interpret table and, at the part level, in side-by-
side comparisons.
Differentiate between BMC Server Automation and external changes and back out
the changes. When performing this differentiation, you can display the Deploy
Jobs that may have produced the BMC Server Automation changes.
Snapshot Jobs are stored in the Jobs folder. Snapshot Jobs which have run at least
once are also accessible from the Snapshot Results nodes for the associated server in
the Servers folder.
Snapshots and audits of virtual servers can include configuration information for
any of the virtual machines contained within the host server. In addition, if a virtual
server is licensed and managed by BMC Server Automation, that server appears in
the Servers folder. You can snapshot and audit the contents of a virtual server just as
you would any other managed server. For more information see Running Snapshot,
Audit, and Compliance Jobs on virtual infrastructure on page 894.
All component machines in a BMC Server Automation system should have their
clocks synchronized.
If you choose to perform a snapshot or audit on a symbolic link, the system traverses
that link and takes a snapshot or audits the file or directory to which the symbolic
link points.
BMC Server Automation does not support symbolic links at lower levels of the file
system. If you are taking a snapshot or performing an audit of a file system that
includes a symbolic link deeper in the file system structure, the system does not
traverse the link. In this way, BMC Server Automation ensures that you do not
inadvertently audit or snapshot portions of a file system, which in some situations
could result in very large snapshots or audit results.
Snapshot storage
When you take a snapshot of a server objects, information may be stored in two
possible locations.
When you take a snapshot of most types of server objects, only attribute information
is saved, such as the name of a patch, its version, and the date of installation.
Attribute information is saved in the database. Snapshots of file system content are
stored on the file server.
While a Snapshot Job is running, the system temporarily generates files on your local
machine. These files are removed when the job run completes. Your local machine
should have sufficient disk space to accommodate temporary files. The amount of
space required varies depending on the complexity of the objects included in a
snapshot. In most cases, the amount of space BMC recommends for a BMC Server
Automation Console is sufficient. (See BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/System+requirements.) However, if the
Application Servers default configuration has been modified to process more work
items simultaneously, your local machine may require additional disk space for
processing snapshots. Contact http://www.bmc.com/support for recommendations
on disk space requirements.
Snapshot baselines
A Snapshot Job consists of two categories of information:
Both types of information are stored in the BMC Server Automation system database.
The first time you run a Snapshot Job, it collects attribute information for all server
objects specified in the component template or the server-object based job definition.
This initial set of data is known as a baseline. If no changes are made to either the job
definition or the component template associated with the job, subsequent runs of the
job only collect server object attributes that have changed since the last time the job
was run.
The BMC Server Automation system maintains Snapshot Jobs and their associated
component templates as versioned objects. If you make a change to either of these
objects between runs of a Snapshot Job, the versions increment and the next run of
the Snapshot Job stores new values in the database for each server object collected by
the job, regardless of whether the values have changed since the last job run. This is
known as rebaselining the snapshot.
Any change to a Snapshot Job or its associated component template triggers rebaselining. For
example, any changes to the jobs description, schedule, or list of target servers
causes rebaselining. If you modify a server object-based Snapshot Job definition by
adding, removing, or modifying parts, rebaselining occurs. Similarly, if you modify a
component template associated with a Snapshot Job in any way, rebaselining occurs.
In short, any change to a Snapshot Job definition or a related component template triggers
rebaselining.
Open the Server folder. Select a server, right-click and select Browse. Select any
asset from the list, right-click the asset, and choose Snapshot.
Open the Jobs folder and select a job folder. Right-click and select New =>
Snapshot Job.
Open the Server folder. Select a server, right-click and select Browse. Select any
asset from the list, right-click the asset, and choose Snapshot from the pop-up
menu.
Open the Jobs folder and select a job folder. Right-click and select New =>
Snapshot Job from the pop-up menu.
Field definitions
Name
Identifying name.
Description
Save in
Snapshot server objectsThe job records server objects that you select
from live servers.
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Any components based on that template that are discovered on target servers can be
included in the snapshot.
The Component Templates for Filtering panel is only available when you are basing
a snapshot on components.
To define a Snapshot Job based on server objects, you must first select a master and
then select one or more server objects on that master. Following that, you can refine
those selections using includes or excludes and audit options.
Server objects: Specifies the server objects to be audited. For more information,
see Selecting server objects on page 655.
The Server Objects list lets you select any version of a custom configuration object,
even though that version of the object may not be included in your Configuration
Object Dictionary.
1 Using the Server Objects list, perform one of the following actions:
Modify an existing server object by selecting the object and clicking Update
.
Delete an existing server object by selecting the object and clicking Delete .
The selected object is removed from the Server Objects list.
If you select Add or Update, the Select Server Objects window opens.
2 Using the Select Server Objects window, perform one of the following actions:
Using the server tree on the left, select one or more server objects. Click the
right arrow.
To add a server object without searching through the tree on the left, click Add
New . The New Server Object dialog box opens. Use the dialog box to
specify a server object by browsing or entering its path. For more information,
see Rules for entering paths on page 56.
3 Click OK.
The server objects you have defined appear in the Server Objects list.
4 If you are adding hierarchical server objects such as directories, and you want
those server objects to include all subfolders, select those server objects. Then
check Recurse subfolders at the bottom of the Includes/Excludes list.
Selecting this option instructs the system to include all objects subordinate to the
server object you have selected in the Server Objects list.
Note
On target IBM AIX servers of version 5.3 with certain Technology Levels (TL) and
Service Packs (SP), do not recurse the /proc directory. For more information, refer
to IBM documentation for APAR IZ45882 and APAR IZ45883.
For example, you might want to exclude all log files or backup files in a directory.
For more information, see Includes and Excludes on page 365.
1 Select a server object in the Server Objects list and take one of the following
actions:
Click Add New Include/Exclude . A dialog box appears. For Name, enter a
path to the server object you want to include or exclude, relative to the object
you selected in the Server Objects list. Include a leading slash when specifying
the server object to be included or excluded. For example, enter /autoconf
instead of autoconf. If necessary, use wildcards in the path.
Click Add New Include/Exclude . A dialog box appears. In the list at left,
select the server objects you want to include or exclude. You can select software
or hierarchical server objects. Then click the right-arrow to move your
selections to the Selected Parts list. When you select a server object in the
Selected Parts list, its name appears in the Name field. If necessary, use the
Name field to edit the path to the server object to include or exclude, relative to
the object you selected in the first step. The path can include wildcards. The
path can also include parameters, which you can type or enter by clicking
Select Property .
3 Click OK.
For many server objects included in a snapshot, you can use the Snapshot/Audit
Options section to specify object attributes you want to store. Some attributes only
apply to certain platforms, and those platforms are listed within parentheses in the
Name column. A non-editable check mark in the Snapshot column shows attributes
that are always collected during a snapshot. You can choose other attributes that you
optionally want to collect.
2 Using the Snapshot/Audit Options list, select attributes in the Snapshot column.
Select all attributes by clicking Select All; clear all by clicking Unselect All. If an
attribute is dimmed, selecting or deselecting all has no effect.
For more information about individual options, see Snapshot options on page
658.
Snapshot options
The Snapshot/Audit Options section of the Server Objects panel lets you specify
information associated with server objects that should be collected during a snapshot.
The following list describes user-selectable attributes for built-in server objects. This
list describes some of the more important attributes as well as attributes with names
that may not completely describe their function. There are many additional
attributes that you can select.
ACL Owner
Auditing ACL
Store access control entries in the System Access Control List (SACL) for a file
or registry key. SACL entries are used to audit actions so they are recorded in
a security log. Each access control entry specifies what circumstances trigger
an audit, identifies a group or user to monitor, and lists operations to audit.
Checksum
Calculate and store a unique key based on all the data in each file. By storing
full MD5 checksums, you can compare entire files and detect changes that
occur anywhere in a file. Note that computing full checksums requires
significant processing.
Contents
Store a copy of the physical file on the file server when taking a snapshot. If a
snapshot includes a symbolic link to a file, the link must point to a valid file
or the snapshot will fail. If you are planning to use a snapshot as the basis of
an audit and then synchronize files using the results of that audit, you must
check this option.
Store the setting for a flag that determines whether an object inherits access
control entries in the System Access Control List (SACL) from its parent object.
Store the setting for a flag that determines whether an object inherits access
control entries in the Discretionary Access Control List (DACL) from its
parent object.
Light Checksum
Calculate and store a unique key based on the first 512 bytes of each file (a
light MD5 checksum). Light checksums are useful for binary files; they are
not recommended for text files.
Permission ACL
Store access control entries in the Discretionary Access Control List (DACL)
for a file or registry key. Each DACL access control entry specifies whether
access is granted, identifies a group or user granted or denied access, and
lists actions permitted or denied.
Select a component group, the Snapshot Job runs on all the components in the
component group that are based on the specified component templates at the
time the job executes.
Select a server, the Snapshot Job runs on all components on that server that are
based on the specified component templates at the time the job executes.
Leave the Selected Targets list empty, the Snapshot Job runs on all discovered
components that are based on the specified component templates at the time
the job executes.
Server objectsThe job takes a snapshot of the specified server objects on the
target servers you select. If you target a server group, the Snapshot Job runs on all
servers assigned to that group at the time the job executes.
If you have set up notifications for a particular scheduled job, those notifications are
generated instead of default notifications. Default notifications can also provide
information about Snapshot Job results.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
The Default Notifications panel also lets you define email messages and SNMP traps
when any change to a snapshot occurs. The Default Notifications panel also lets you
send email messages and generate SNMP traps when any change to a snapshot
occurs. This capability provides a simple mechanism for tracking configuration
changes. Note that the first time a Snapshot Job runs, no changes are detected
because the first run establishes a baseline against which future changes are tracked.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Limits the size of email that is generated by appending audit results. Enter
the maximum size, in kilobytes, in the text box.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Snapshot Job Scheduling on page 663.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Snapshot Job Scheduled
Job Notifications on page 661.
The Scheduled Job Notifications tab also lets you send email messages and generate
SNMP traps when any change to a snapshot occurs. This capability provides a
simple mechanism for tracking configuration changes. Note that the first time a
Snapshot Job runs, no changes are detected because the first run establishes a
baseline against which future changes are tracked.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Send email to
Limits the size of email that is generated by appending audit results. Enter
the maximum size, in kilobytes, in the text box.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing Snapshot Job, open the Jobs folder and
navigate to an existing job. Right-click the job and select Open. The content
editor displays a series of tabs, which are described in the following sections:
Snapshot Job General on page 653
Snapshot Job Components Templates for Filtering on page 654 (for jobs based
on components)
Snapshot Job Server Objects on page 655 (for jobs based on server objects)
Snapshot Job Targets on page 659
Snapshot Job Default Notifications on page 659
Snapshot Job Schedules on page 661
These tabs correspond to panels in the New Snapshot Job wizard. Use them to
modify the job definition.
If you open a server object-based Snapshot Job that includes a custom
configuration object and a more recent version of that object exists, a tab called
Version Warnings appears when the Snapshot Job cannot be automatically
upgraded to refer to the new object. In cases where the Snapshot Job is
automatically upgraded to the new version, the console displays a message
informing you of that fact. When you save the Snapshot Job, the upgrade to the
new version of the custom configuration object is finalized.
Change Tracking occurs automatically as part of the Snapshot Job. The first snapshot
contains baseline information about the server object which is displayed on the
Snapshot tab. Each sequential snapshot provides you with information about the
delta or changes that may occur between snapshots. The system displays the
changes on the Change Tracking tab and the snapshot results on the Snapshot tab.
Object Views
At the object view level, Change Tracking displays the template names, total number
of targets, the number of servers with external changes, the number of failed targets,
the number of targets where the changes were not attempted, and the total number
of changes, including the number of items added, the number of items modified, and
the number of items deleted by server object.
At the object view template node level, Change Tracking displays the template part
names, the total number of targets, the number of targets on which the changes
failed or were not attempted, and the total number of changes, including the number
of items added, the number of items modified, and the number of items deleted by
server object.
At the object view template part node level, Change Tracking displays the target server
names and the total number of changes, including the number of items added, the
number of items modified, and the number of items deleted by server object.
Server Views
Server view
Component names.
External changes.
Server view component parts / Delta information Detailed delta information. If no changes are
detected, an informational message to that effect
appears on the Change Tracking tab. You can see the
added, modified, and deleted asset delta from the
previous snapshot to the current snapshot.
Items in:
BlueIndicate that assets found under the selected server object exist either in the
previous snapshot or in the current snapshot. The presence of a blue item in the
left snapshot indicates that the found item only exists in the previous snapshot.
The presence of a blue item in the right snapshot indicates that the found item
only exists in the current snapshot.
RedIndicate that the assets found under the selected server object exist in both
the previous and current snapshots but that a change was detected between them.
If BMC Server Automation and external activities occur in the period between
snapshots, you can look further into the change to see if it is caused by the job (see
Showing deploy-related job activity on page 670) and if it is an approved change. If
the change is caused by the job run, you can determine if it is an approved change by
checking for a trouble ticket.
After you have displayed snapshot and change tracking results, you can use them to
perform the following tasks:
Back out undesired changes. (See Backing out changes on page 670.)
Show the Deploy Jobs that can cause the change. (See Showing deploy-related job
activity on page 670.)
Export some or all of the results of a snapshot, audit, or change tracking into
HTML or CSV format. (See Exporting results of an audit or snapshot on page
675.)
View file properties and ACL information for files on servers using Windows
NTFS by double-clicking the file. (See Viewing server objects on page 344.)
Select a Snapshot Job in the Jobs folder, right-click, and then select Show
Results.
A new tab with a hierarchy of the jobs on the left opens in the content editor.
Select a server in the Servers folder, right-click, and then select Browse.
A new tab for the selected server opens in the content editor. Click the
Snapshot Results tab on the bottom.
2 In the hierarchical tree on the left of the tab, expand a run of a Snapshot Job.
3 Expand the Server View or Object View node. Then expand the contents of
either node until you can click the server object type for which you want to see
details.
4 Click the Change Tracking tab to view the total number of changes, including the
number of items added, the number of items modified, and the number of items
deleted.
5 Click the Snapshot tab to view the server object name, type, and, if available, a
description of the Snapshot Job.
The table on the right side of the tab shows the contents of the selected server
object that are included in the snapshot. When viewing hierarchical server objects,
such as directories or metabase objects in the Server Node, you can click folders or
items within folders.
Typically, you back out changes when you recognize that a specific change has a
negative impact on performance or it has been deployed at an inappropriate time.
At the server level, right-click the server and select Back Out All Changes or
Back Out All External Changes.
At the component node level, right-click the part and select Back Out All
Changes.
At the component part node level, right-click the part and select Back Out
Changes.
At the delta asset level, right-click the changed item and select Back Out
Changes or Package Snapshot Delta.
The changes that occur between snapshots may be caused by BMC Server
Automation or external activity. If no File Deploy, Network Shell Script, or Deploy
Job activity occurred since the last snapshot, you know that the change was an
external change.
1 Select the Server view, Server view component, Server view component part, or
delta asset level.
When a snapshot contains multiple server object types, you can choose the contents
you want to bundle by selecting individual server objects, a node representing a
server object type, or multiple nodes.
1 Use the Jobs folder to display the results of a snapshot, as described in Snapshot
and change tracking results on page 666.
Bundle the contents of a server object type by selecting the node representing
that type of server object. Then, right-click and select Add to Depot as =>
BLPackage. A wizard for bundling snapshot results appears. Proceed to Step 4
on page 672.
Select individual server objects by expanding the node for a server object type
and selecting individual server objects in the table on the right. Then, right-
click and select Add to Depot as => BLPackage. A wizard for bundling
snapshot results appears. Proceed to Step 4 on page 672.
Bundle the contents in a snapshot for an entire server by selecting the node
representing that server. Then, right-click and select Add to Depot as =>
BLPackage. The Create BLPackage wizard opens. Use it to create a BLPackage
based on the server objects included in the snapshot. See Adding a BLPackage
to the Depot on page 509.
4 If the package includes software that does not match software stored in the depot,
the Select Matching Software window appears. Use it to match software in the
depot with software in the package you are bundling. See Matching software
with depot items on page 507.
Field Definitions
Package name
Save in
The Depot Asset Options section may be dimmed, depending on how you accessed
this panel.
If this section is available, check Soft linked to gather the contents of the BLPackage
at the time of deployment rather than the time of package creation. When you finish
defining the job, clear Soft linked to gather the contents of the BLPackage.
By soft linking the contents of a BLPackage, you can change the software, patches, or
server objects referenced by the BLPackage without updating the BLPackage
definition.
Soft linking is only available for assets stored in the Depot. When creating
BLPackages based on depot software, you can create multiple soft links to the same
software package.
Note
When you copy a BLPackage to a repeater and the Soft linked option is selected, the
contents of a BLPackage are copied to the repeater and stored there. Afterwards,
other BLPackages can use those same objects without copying them to the repeater.
If the Soft linked option is not selected, the contents of the BLPackage are always
copied into the BLPackage. While the BLPackage can be cached on a repeater, its
contents cannot reference objects that may already be stored in the repeaters cache.
File Options
Record the attributes of files and directories, such as their date of creation,
size, and permissions, so that information can be replicated when the
BLPackage is created.
Collect permission and log information for files. This option is only
applicable if the servers or snapshots being compared use Windows NT File
System (NTFS).
Registry Options
Component Options
Keep pre-existing property valueKeeps the value for the first property
encountered and discards values for all other properties that have the
same name. If there are multiple properties with the same name but they
are different property types, an error is generated.
1 Use the Jobs folder to display the results of a snapshot, as described in Snapshot
and change tracking results on page 666.
3 Expand the Server View node and select a node representing a type of software
package, such as hotfixes or patches.
4 In the table on the right, select one or more individual software packages, right-
click, select Add To Depot As, and then select the type of software package you
have selected.
5 To add software to the Depot, use the Add Depot Software window .
See Adding a hotfix to the Depot on page 496 and Adding software to the
Depot on page 482
HTML format, which is suitable for printing or viewing with a web browser
If you export audit results, the information that is exported is formatted and
packaged with some additional information to make it more understandable.
When you export results, you can use the Servers view to export from any level of
the results tree for snapshot or audit results. For example, if you choose to export
from the top level of the audit results tree, all the results of the audit are exported. If
you select a server object, such as Registry, all server objects of that type are
exported. If you select a particular server object, such as a file directory or a registry
hive, the contents of that server object are exported.
2 From the audit or snapshot results tree displayed in the left pane, select the
branch of the results you want to export. When viewing audit results, you must
view results by server.
4 On the dialog box, for Object Name, provide a file name and location where you
want to store the exported results. For Object Type, select one of the following
file formats:
5 From File encoding, select the type of character encoding to be used for the
exported data, such as UTF8 or UTF16.
After running an Audit Job, you can view its results and quickly identify
discrepancies between component configurations. When you identify discrepancies,
you can bundle changes into a BLPackage and deploy the changes to a server so its
configuration matches the standard configuration. Audits can also perform a
security function by quickly identifying unauthorized changes to server
configurations.
Audit Jobs require you to identify a masterthat is, a server with a standard
configuration that is used as the basis of comparison. The procedure for identifying a
master depends on how you define an Audit Job. If you define an Audit Job by
selecting live server objects, you must select a server or a snapshot as the master
server. If you define an Audit Job by selecting one or more component templates,
you must select one or more components or snapshots that act as a master.
Open the Servers folder and select a server. Right-click and select Audit from
the pop-up menu.
Open the Jobs folder, right-click a job folder, and select New => Audit Job
from the pop-up menu.
3 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
Open the Servers folder and select a server. Right-click and select Audit from
the pop-up menu.
Open the Jobs folder, right-click a job folder, and select New => Audit Job
from the pop-up menu.
3 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
Field Definitions
Name
Identifying name.
Description
Save in
Job type
Audit components: The job audits all components that are based on the
component template you have specified.
Audit server objects: The job audits live server objects that you select.
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Any components based on templates that are discovered on target servers can be
included in the audit.
The Component Templates for Filtering panel is only available when you are basing
an audit on components.
Note
If you select component templates and you also decide to use a snapshot as either a
master or target of the Audit Job, BMC recommends that you not modify these
component templates in the future. The Audit Job cannot retrieve new information
for a snapshot and the snapshot may not accurately reflect changes you make to the
component template. If you must modify a component template, take new snapshots
based on the most recent component template and use those snapshots in the Audit
Job.
The masters panel is only available when you are basing an audit on components.
Selecting a master
Select a component template and click Update .
The Select Master dialog box opens. It lists all components that have been discovered
for the selected component template. Expanding an entry for a component shows
any snapshots that have been taken of that component.
Click OK. The Master Entries list shows the master you have selected for a particular
component template.
The Server Objects panel is only available when you are basing an audit on live
server objects.
To define an Audit Job based on server objects, you must first select a master and
then select one or more server objects on that master. Then, you can refine the
selections using includes or excludes and audit options.
Master server
Identifies live server or snapshot on which you are basing the audit. For more
information, see Selecting master and server objects on page 682.
Server objects
Specifies the server objects that should be audited. For more information, see
Selecting master and server objects on page 682.
Snapshot/Audit options
You can only select server objects when the master is a live server. When using a
snapshot as a master, you cannot add or delete server objects.
The Server Objects list lets you select any version of a custom configuration object,
even though that version of the object may not be included in your Configuration
Object Dictionary.
1 For Master, click Browse . The Select Master dialog box opens. Use it to select a
live server or snapshot on which you want to base an audit.
2 Using the Server Objects list, perform one of the following actions:
Modify an existing server object by selecting the object and clicking Update .
Delete an existing server object by selecting the object and clicking Delete .
The selected object is removed from the Server Objects list.
If you select Add or Update, the Select Server Objects window opens.
3 Using the Select Server Objects window, perform one of the following actions:
Using the server tree on the left, select one or more server objects. Click the
right arrow.
To add a server object without searching through the tree on the left, click Add
New . The New Server Object dialog box opens. Use the dialog box to
specify a server object by browsing or entering its path.
4 Click OK.
The server objects you have defined appear in the Server Objects list.
5 If you are adding hierarchical server objects such as directories and you want
those server objects to include all subfolders, select those server objects. Then
check Recurse subfolders at the bottom of the Includes/Excludes list.
Selecting this option instructs the system to include all objects subordinate to the
server object you have selected in the Server Objects list.
For example, you might want to exclude all log files or backup files in a directory.
For more information, see Includes and Excludes on page 365.
1 Select a server object in the Server Objects list and take one of the following
actions:
Click Add New Include/Exclude . A dialog box appears. For Name, enter a
path to the server object you want to include or exclude, relative to the object
you selected in the Server Objects list. Include a leading slash when specifying
the server object to be included or excluded. For example, enter /autoconf
instead of autoconf. If necessary, use wildcards in the path.
Click Add New Include/Exclude . A dialog box appears. In the list at left,
select the server objects you want to include or exclude. You can select software
or hierarchical server objects. Then click the right-arrow to move your
selections to the Selected Parts list. When you select a server object in the
Selected Parts list, its name appears in the Name field. If necessary, use the
Name field to edit the path to the server object to include or exclude, relative to
the object you selected in the first step. The path can include wildcards. The
path can also include parameters, which you can type or enter by clicking
Select Property .
3 Click OK.
2 Using the Snapshot/Audit Options list, select attributes in the Audit column that
should have snapshot or audit functionality enabled.
Select all attributes by clicking Select All; de-select all by clicking Unselect All. If
an attribute is dimmed, selecting or de-selecting all has no effect.
For more information about individual audit options, see Audit Options on
page 684.
Audit Options
The Snapshot/Audit Options section of the Server Objects panel lets you specify
information associated with a server object that should be compared during an audit.
For many server objects included in the audit, you can use the Snapshot/Audit
Options section to specify object attributes you want to compare. Some attributes
only apply to certain platforms, and those platforms are listed within parentheses in
the Name column. A non-editable check mark in the Audit column shows attributes
that are always compared during an audit. You can choose other attributes that you
optionally want to compare.
The following list describes user-selectable attributes for built-in server objects. This
list describes some of the more important attributes as well as attributes with names
that may not completely describe a function. Many additional attributes can be
selected besides the attributes listed below.
Account Disabled
ACL Owner
Auditing ACL
Compare access control entries in the System Access Control List (SACL) for
a file or registry key. SACL entries are used to audit actions so they are
recorded in a security log. Each access control entry specifies what
circumstances trigger an audit, identifies a group or user to monitor, and lists
operations to audit.
Checksum
Calculate a unique key (an MD5 checksum) based on all the data in a file and
use that key to compare entire files and detect changes that occur anywhere
in a file. Computing full checksums requires significant processing.
Code Page
Contents
Full Name
Group members
Group owner
Home Path
Light Checksum
Calculate a unique key based on the first 512 bytes of a file (a light MD5
checksum) and then use the light checksum to compare header information
in files without expending the processing necessary for calculating full
checksums. Light checksums are useful for binary files; they are not
recommended for text files.
Login Script
Logon Server
Max Size
Member of
Permission ACL
Permissions
Privilege Level
Profile Path
Retention
Size
User members
User owner
Version
Compare file version information for DLL, EXE, and other types of files.
Select a component group, the Audit Job runs on all the components in the
component group that are based on the specified component templates at the
time the job executes.
Select a server, the Audit Job runs on all components on that server that are
based on the specified component templates at the time the job executes.
Leave the Selected Targets list empty, the Audit Job runs on all discovered
components that are based on the specified component templates at the time
the job executes.
Server objectsThe job audits the specified server objects on the target servers or
snapshots you select. If you target a server group, the Audit Job runs on all
servers assigned to that group at the time the job executes.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
The Default Notifications panel also lets you define email messages and SNMP traps
that are generated based on the results of an Audit Job. You can send notifications
when targets have consistent configurations, inconsistent configurations, or both.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Limits the size of email that is generated by appending audit results. Enter
the maximum size, in kilobytes, in the text box.
Provides name or IP address of the server to notify about audit results. After
entering server information, check the statuses that cause an SNMP trap to be
generated.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at an interval. For more information, see
Audit Job Scheduling on page 691.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Audit Job Scheduled Job
Notifications on page 690.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Limits the size of email that is generated by appending audit results. Enter
the maximum size, in kilobytes, in the text box.
Provides name or IP address of the server to notify about audit results. After
entering server information, check the statuses that cause an SNMP trap to be
generated.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing Audit Job, open the Jobs folder and
navigate to an existing job. Right-click the job and select Open from the pop-up
menu. The content editor displays a series of tabs, which are described in the
following sections:
Audit Job General on page 679
Audit Job Component Templates for Filtering on page 680
Audit Job Masters on page 681
Audit Job Server Objects on page 681
Audit Job Targets on page 687
Audit Job Default Notifications on page 688
Audit Job Schedules on page 689
Audit Job Properties on page 692
Audit Job Permissions on page 693
These tabs correspond to panels in the New Audit Job wizard. Use them to
modify the job definition.
If you open a server object-based Audit Job that includes a custom
configuration object and a more recent version of that object exists, a tab called
Version Warnings appears when the Audit Job cannot be automatically
upgraded to refer to the new object. In cases where the Audit Job is
automatically upgraded to the new version, the console displays a message
informing you of that fact. When you save the Audit Job, the upgrade to the
new version of the custom configuration object is finalized.
Object ViewThe left pane shows a list of server object types included in the
audit. Those shown in bold have one or more inconsistent servers. Select a server
object type, and the right pane shows which servers are consistent or inconsistent
with the master server.
Server ViewThe left pane shows a hierarchical list of server and server objects
included in the audit. Listings in bold indicate the presence of an inconsistency.
Select a server object and the right pane shows side-by-side panels displaying the
following:
Objects on the master server that are not present on the target server.
Objects on the target server that are not present on the master server.
Objects that appear on both the master and target servers but have different
characteristics, such as file sizes or dates of creation.
The area below the side-by-side panels provides detailed information about the
differences for a selected object. If you are auditing ACLs for registry entries or you
are auditing servers using the Windows NT File System (NTFS) and you choose to
audit ACLs for files, the pane at the bottom right provides detailed ACL information.
Synchronize a server so its configuration matches the master server. (See Using
audit results to synchronize servers on page 702.)
This procedure uses audit results to create a BLPackage and a Deploy Job to
deploy the BLPackage to the server being audited. The BLPackage includes an
XML instruction file specifying which server objects need to be added, replaced,
or deleted on the target server so its configuration matches the master. The
BLPackage also includes all server objects needed for the deployment. The Deploy
Job contains instructions for deploying the BLPackage to the target server.
Group servers with configurations that do you match the master. (See Grouping
noncompliant servers on page 709.)
Export some or all of the results of the audit. (See Exporting results of an audit or
snapshot on page 675.)
When auditing Windows Security Settings, the system displays the policy names
used by Windows 2003 and 2008. For some policies Windows 2000 uses a different
name than Windows 2003 and Windows 2008 use for the same policy. See
Windows security settings list on page 1455 for a complete list of Security
Settings with policy names that differ between operating systems.
For example, you can select the Services server object and see which servers have
Windows services configured inconsistently with the master server.
1 In the Jobs folder, select an Audit Job, right-click, and select Show Results.
A new tab opens in content editor. It shows the Audit Job results.
2 In the hierarchical tree on the left of the tab, expand a run of an Audit Job and
click the Object View node.
The right panel shows summary results for the audit, as described in the table below.
Servers and server objects listed under the Server View node appear in a bold font
if they are inconsistent.
Column Description
Column Description
3 To view object-by-object summaries, expand the tree under Object View and
select a component.
The right panel shows summary results for the component, as described in the
following table.
Column Description
# of Not Attempted Targets Total number of servers for which no attempt was
made to evaluate the consistency of this object.
The right panel lists all the targets for the job and indicates whether they are
consistent.
For example, you can select a directory to see files in the directory that are
inconsistent with the master server.
1 In the Jobs folder, select an Audit Job, right-click, and select Show Results.
A new tab opens in content editor showing the Audit Job results.
2 In the hierarchical tree on the left of the tab, expand a run of an Audit Job and
click the Server View node.
Servers and server objects listed under the Server View node appear in a bold font
if they are inconsistent.
The right panel shows summary results for the audit, as described in the
following table.
Column Description
3 To view a server-by-server summary of the audit result, expand the tree under
Server View and select a master.
The right panel shows summary results for the audit, as described in the
following table.
Column Description
Column Description
4 To view a server-by-server summary, expand the tree under Server View and
select a master.
The right panel shows a listing of all objects, with columns showing server-level
summaries, as described in the following table.
Column Description
5 To view how a server object on a particular server differs from the configuration
of the master host, expand the tree under Server View and select a server object.
The right pane shows two lists. The list on the left shows the contents of the
master server. The list on the right shows the contents of the target server.
If an item appears on one server but not the other, it is listed in a blue font. If an
item appears on both servers but has different characteristics on each (for
example, the file size or date of creation is different), the item appears in a red
font in both lists. Identical items are not listed.
6 To view information about the differences between an item, select the item.
The detail pane at bottom shows discrepancies between the selected item and the
master server. Bold red denotes characteristics that differ between the selected
item and the master server.
7 Depending on the type of server objects you are auditing, you may be able to do
any of the following:
If you are comparing files on machines that both use Windows NT File System
(NTFS) or registry keys, you can compare access control list information by
selecting the file or registry key and then clicking the General tab on the Detail
pane. The tab shows summary information about the ACLs audited.
The ACL Diffs tab provides more detailed information about master and host
ACL settings. You can also view ACL information about the master and target
hosts by clicking the Master ACL and Host ACL tabs. For more information
about ACLs, see Viewing security information for files and registry keys on
page 345.
For example, you can select a directory to see if files in that directory are inconsistent
with the master server.
To perform this procedure, you must have previously defined the Audit Job by
selecting the Contents option in the Snapshot/Audit Options section of the Server
Objects panel.
1 In the Jobs folder, select an Audit Job, right-click, and select Show Results.
2 Using the Server View, navigate to a node that consists of a file where there are
differences.
3 In the audit results pane, right-click the file and select Compare.
The Audit Compare window opens. The left panel shows the contents of the file
on the master and the right shows the content of the same file on the target.
Differences between the files are highlighted. The colors used for highlighting are
determined by setting user preferences.
A line in the target server indicates if a line was deleted. The master server
shows deleted content.
A highlighted area in the master and the target shows the location of a change.
4 Using the buttons on the Audit Compare window, display the first, last, next, or
previous difference detected between files.
For example, during an audit of httpd.conf files, the system considers each of the
following name/value pairs to be a separate entry:
ServerRoot xxx
ServerRoot yyy
ServerRoot zzz
Consequently, when an audit discovers a group of name/value pairs with the same
name on multiple servers, the audit results may not list each entry as being the same
object but with different characteristics. Instead, the audit results may list each entry
as a distinct item.
Depending on how you initiate the procedure, you can generate one BLPackage and
one Deploy Job to synchronize one server, or you can synchronize multiple servers
simultaneously. When you synchronize multiple servers, BMC Server Automation
analyzes the material required to synchronize each server and optimizes by creating
only one BLPackage or software package for each server requiring a unique
collection of files or applications.
For more information, see Viewing audit results by server on page 698.
Synchronize all target servers by right-clicking the master server and selecting
Sync all targets with master.
Synchronize one or more specific server object audit results by selecting the
objects in the contents pane, right-clicking, and selecting Sync with master.
Note
If you are synchronizing hotfixes, be aware of the following:
When selecting specific hotfixes, you can only select Sync with master when
the table on the right of the tab shows the same hotfix on both the master and
target and the hotfix has a Status of Installed or EffectivelyInstalled on one
machine and a status of Missing on the other. If the selected hotfix does not
meet all of these criteria, the Sync with master option is disabled.
If you select Sync with master for audit results that include service packs, the
BLPackage that is created does not include those service packs. It only includes
patches. Service packs should not be installed at the same time as patches.
For more information, see Matching software with depot items on page 507.
If you are synchronizing one server or the system has created one BLPackage or
software package that synchronizes multiple servers, a New Deploy Job wizard
appears.
Field Definitions
Sync name
Enter a name for the synchronization job. If the job generates a Batch Job, this
name is assigned to the Batch Job.
Save package in
Click Browse and navigate to the depot group where you want to store the
BLPackages generated by this procedure.
Click Browse and navigate to the job group where you want to store the
Deploy Jobs and the Batch Job generated by this procedure.
If this section is available, check Soft linked to gather the contents of the BLPackage
at the time of deployment rather than the time of package creation. When you finish
defining the job, clear Soft linked to gather the contents of the BLPackage.
By soft linking the contents of a BLPackage, you can change the software, patches, or
server objects referenced by the BLPackage without updating the BLPackage
definition.
Soft linking is only available for assets stored in the Depot. When creating
BLPackages based on depot software, you can create multiple soft links to the same
software package.
Note
When you copy a BLPackage to a repeater and the Soft linked option is selected, the
contents of a BLPackage are copied to the repeater and stored there. Afterwards,
other BLPackages can use those same objects without copying them to the repeater.
If the Soft linked option is not selected, the contents of the BLPackage are always
copied into the BLPackage. While the BLPackage can be cached on a repeater, its
contents cannot reference objects that may already be stored in the repeaters cache.
File Options
Collect file/directory attributes
Record the attributes of files and directories, such as their date of creation,
size, and permissions, so that information can be replicated when the
BLPackage is created.
Collect permission and log information for files. This option is only
applicable if the servers or snapshots being compared use Windows NT File
System (NTFS).
Registry Options
Collect access control list (ACL) attributes
Component Options
Local Property Name Conflicts
Keep pre-existing property valueKeeps the value for the first property
encountered and discards values for all other properties that have the
same name. If there are multiple properties with the same name but they
are different property types, an error is generated.
For more information, see Viewing audit results by server on page 698.
2 Using the Server View, select the server or server for which you want to package
differences. Right-click and select Package Delta.
Note
If you are packaging hotfixes, be aware of the following:
When selecting specific hotfixes, you can only select Package Delta when the
table on the right of the tab shows different versions of the same hotfix on both
the master and target. If a hotfix only exists on the master or target, the
Package Delta option is disabled.
When selecting specific hotfixes, you can only select Package Delta when the
table on the right of the tab shows the same hotfix on both the master and
target and the hotfix has a Status of Installed or EffectivelyInstalled on one
machine and a status of Missing on the other. If the selected hotfix does not
meet all of these criteria, the Package Delta option is disabled.
Field Definitions
Package name
Save in
If this section is available, check Soft linked to gather the contents of the BLPackage
at the time of deployment rather than the time of package creation. When you finish
defining the job, clear Soft linked to gather the contents of the BLPackage.
By soft linking the contents of a BLPackage, you can change the software, patches, or
server objects referenced by the BLPackage without updating the BLPackage
definition.
Soft linking is only available for assets stored in the Depot. When creating
BLPackages based on depot software, you can create multiple soft links to the same
software package.
Note
When you copy a BLPackage to a repeater and the Soft linked option is selected, the
contents of a BLPackage are copied to the repeater and stored there. Afterwards,
other BLPackages can use those same objects without copying them to the repeater.
If the Soft linked option is not selected, the contents of the BLPackage are always
copied into the BLPackage. While the BLPackage can be cached on a repeater, its
contents cannot reference objects that may already be stored in the repeaters cache.
File Options
Collect file/directory attributes
Record the attributes of files and directories, such as their date of creation,
size, and permissions, so that information can be replicated when the
BLPackage is created.
Collect permission and log information for files. This option is only
applicable if the servers or snapshots being compared use Windows NT File
System (NTFS).
Registry Options
Collect access control list (ACL) attributes
Component Options
Local Property Name Conflicts
Keep pre-existing property valueKeeps the value for the first property
encountered and discards values for all other properties that have the
same name. If there are multiple properties with the same name but they
are different property types, an error is generated.
After grouping noncompliant servers, you can easily create a server group and then
run jobs on that server group. For example, you can perform additional audits on the
group or deploy server objects to all servers in the group.
For more information, see Viewing audit results by object on page 697.
2 Under the Object View, select a server object included in the audit.
The table on the right shows servers with configurations that are not consistent
with the selected server object.
3 Select the servers you want to group. Then, right-click and select Group servers
from the pop-up menu.
The Add Servers to Group dialog box opens. It shows the servers you selected in
the bottom pane.
4 In the top half of the dialog box, select the server group to which you want to add
servers. If necessary, you can click Create new server group to create a new
server group.
5 Click OK.
The servers shown in the bottom half of the dialog box are grouped in the
specified server group.
HTML format, which is suitable for printing or viewing with a web browser
If you export audit results, the information that is exported is formatted and
packaged with some additional information to make it more understandable.
When you export results, you can use the Servers view to export from any level of
the results tree for snapshot or audit results. For example, if you choose to export
from the top level of the audit results tree, all the results of the audit are exported. If
you select a server object, such as Registry, all server objects of that type are
exported. If you select a particular server object, such as a file directory or a registry
hive, the contents of that server object are exported.
2 From the audit or snapshot results tree displayed in the left pane, select the
branch of the results you want to export. When viewing audit results, you must
view results by server.
4 On the dialog box, for Object Name, provide a file name and location where you
want to store the exported results. For Object Type, select one of the following
file formats:
5 From File encoding, select the type of character encoding to be used for the
exported data, such as UTF8 or UTF16.
Both software packages and BLPackages are executable packages that can be
deployed unattended. For more information about both types of package, see
Creating packages and other depot objects on page 477.
To deploy files or directories, you can optionally use a File Deploy Job rather than a
BLPackage Deploy Job. However, bundling files and directories as BLPackages and
using a BLPackage Deploy Job to deploy them gives you considerably more control
over a job, including the ability to simulate its deployment, automatically roll the job
back if a failure occurs, and manually undo the job.
Simulate phase
The Simulate phase performs a test run of a deployment without deploying the
package. The test run verifies the XML instructions that define the BLPackage and
performs tests to ensure the validity of those instructions. For example, if the
BLPackage is deleting a file, the test run ensures that the file exists. A test run also
checks environmental requirements. For example, it determines if you have the
appropriate access level and if the target is running in multi-user mode, which is
necessary when a job is defined to use agent mounting when deploying files.
The Simulate phase is optional, and it is only available when deploying BLPackages.
Staging phase
The actions that a Deploy Job performs during the Staging phase depend on whether
you are deploying assets stored in the Depot or network-based assets.
Depot assets
If assets being deployed are stored in the Depot, a Deploy Job copies the contents of
the packaging directory to a staging directory on a target server or repeater. If the
target is a component, the staging directory can be located on the server associated
with the target component.
For a BLPackage: an XML instruction file; all server objects being added, replaced,
or deleted; and grammar files, if applicable.
For a software package: an XML instruction file; installation files; support files (if
any); and grammar files, if applicable.
The packaging directory is created when you add a software package or BLPackage
to the Depot. If the contents of a BLPackage are soft-linked, the software or server
objects referenced by the BLPackage are not added to the packaging directory.
Instead, they are copied to a staging directory on a target server or repeater when the
Deploy Job runs.
Network-based assets
If the assets being deployed are network-based, the Deploy Job copies the XML
instruction file and any applicable grammar files to a staging directory on the target
server. (If the target is a component, the staging directory can be located on the
server associated with the target component.) The Deploy Job then uses one of the
following approaches to access all other required assets:
The Application Server mounts (for UNIX) or maps (for Windows) a network host
and copies all assets from that host to a staging directory on the target server or
repeater. From there, the source files are deployed to the target server.
The agent on the target server mounts or maps a network server and deploys the
assets directly from that network location to a target server. For UNIX target
servers, the job creates symbolic links in a staging directory. The links point to the
actual files being deployed, which exist on the mounted/mapped server. Creating
links lets the deploy process act on those files as if they reside in the staging
directory. For Windows, the job uses the full paths to all network-based assets so
the job does not have to perform further actions in this phase. Note that only
target servers can mount or map network hosts; repeaters cannot.
To mount a UNIX server, the agent uses the NFS protocol, and you must have root
permission on the network server. To map a Windows server, the agent uses SMB
and you must provide all necessary connection information (domain, user name, and
password) in the URL of the server to be mapped.
Commit phase
The Deploy Job applies the package to the target component or server by running an
install command (for a software package) or the appropriate add, replace, and delete
commands (for a BLPackage).
If the Deploy Job definition calls for rollback, the job creates a subdirectory in the
following location:
agentInstallDirectory/Transactions/rollback
Files in the Transactions directory can become large. BMC Server Automation
provides a mechanism for storing most transaction information in an alternate
location for a particular target server. For details on this procedure, see Configuring
the location of the transactions directory on page 770.
Finally, to clean up, the Deploy Job removes the staging directory, including any
links it contains. Note that a Deploy Job gives you the option of keeping the contents
of the staging directory if the job fails. If a job does not fail, the staging directory is
always removed. Also, after a job completes, all mounts and maps to other servers
are undone unless they are in use by another Deploy Job.
IncompleteThe job has executed but has failed to apply on at least one target
server or component. No processes are running that relate to the job. When a job
is incomplete, no other users can execute the job until it is reset. Only the most
recent run of a Deploy Job can be in an Incomplete state. When an incomplete job
executes, the job resumes from where it previously stopped.
FailedThe job failed due to unusual circumstances, such as a server crash. A job
in a Failed state can be re-executed or reset.
The system manages AMOs through other servers that are equipped with a custom
configuration object that can communicate with the agentless device. This
documentation refers to those other servers as AMO proxies.
You can deploy BLPackages to agentless devices, and you can roll back those
deployments. The AMO proxy stores rollback information. If you change the AMO
proxy for an agentless device, when you perform an undo, the system will attempt
to use the original AMO proxy for the rollback.
To run Deploy Jobs on agentless devices, the AMO proxy must be equipped with an
RSCD agent running version 8.1 or later. Also, the custom configuration object used
for communicating with the agentless device must be consistent with version 8.1 or
later.
Deploy Jobs support single-job mode for agentless devices. However, the single-
job mode setting affects all agentless devices managed from an AMO proxy. If an
AMO proxy is set up to manage multiple agentless devices and the Deploy Job is
running on more than one of those devices, the job would be processed on one
agentless device before it can run on the next agentless device.
While a Deploy Job targets an AMO, it can only operate on custom configuration
object-based assets. The job will fail if it tries to operate against any other type of
object. When a job is not targeting an AMO, it can operate on other server objects.
However, not all server objects have an ActionOnFailure defined for them. When
a job fails to deploy an object that does not have an ActionOnFailure defined, the
entire job fails. This behavior differs from assets based on custom configuration
objects. For those, the definition of ActionOnFailure dictates how the job behaves
if a deployment fails.
To prevent an AMO proxy from being overloaded with too many targets, the
Deploy Job includes properties that allow you to set the maximum number of
parallel targets during different phases of the Deploy Job. For more information,
see Controls for the number of simultaneous processes on page 751.
The basic approach defines the job so it is automatically reset should it fail. (All
Software Deploy Jobs use the basic approach.) This allows you to immediately
execute the job again. When defining a basic BLPackage Deploy Job, you cannot use
some advanced options for managing the flow and scheduling of the job. Basic
Deploy Jobs are recommended if you are including the Deploy Job in a Batch Job.
Advanced BLPackage Deploy Jobs provide greater flexibility. They let you schedule
phases individually, control the flow of the job by server or phase, and manage the
jobs state after it executes by retrying or undoing the job.
Before you can deploy a BLPackage, you must store the package in the Depot. For
information about bundling the assets of a BLPackage and storing it in the Depot, see
Adding a BLPackage to the Depot on page 509. You should also review the list of
caveats applicable to BLPackage deployments, as described in Caveats for
deploying BLPackages on page 721.
Before you can deploy a software package you must store the package in the Depot.
For information about adding Windows patches and service packs to the Depot, see
Adding a hotfix to the Depot on page 496. For information about adding all other
types of software packages to the Depot, see Adding software to the Depot on
page 482.
Open the Depot folder and navigate to the BLPackage you want to deploy. Right-
click the package and select Deploy from the pop-up menu. The New Deploy
Job wizard opens.
Open the Jobs folder and navigate to a job folder. Right-click the job folder and
select New => BLPackage Deploy Job from the pop-up menu. The New
Deploy Job wizard opens.
menu. Launching a Deploy Job in this way lets you deploy a BLPackage that
uses the selected components as targets for the deployment.
2 Provide information for the BLPackage Deploy Job as described in the following
sections:
After running a BLPackage Deploy Job, you can use the job results to retry, undo,
or reset an entire BLPackage Job or phases of the job on specific servers. For more
information, see Deploy Job results on page 764.
To deploy software, BMC recommends that you have administrator privileges on the
remote server to which you are deploying. To accomplish this, there are two
approaches:
For Windows target servers, you can use an automation principal to set up
Windows user mapping. This mechanism allows you to map a role to a local or
domain user on a target server who has administrator privileges. For more
information about Windows user mapping, see Creating automation principals
on page 195.
For UNIX target servers and Windows servers on which you do not want to use
automation principals, you must map your machine or user name to a local user
on the remote server. That local user should have administrator privileges. You
must also perform this type of mapping on repeaters when you are copying files
to them for indirect deployments, even if you are ultimately deploying files to
Windows target servers using Windows user mapping. For more information
about configuration files and mapping users, see BMC technical documentation at
https://docs.bmc.com/docs/display/bsa82/Setting+up+configuration+files.
Open the Depot folder and navigate to the software package you want to
deploy. Right-click the package and select Deploy from the pop-up menu. The
New Deploy Job wizard opens.
Open the Jobs folder and navigate to a job folder. Right-click the job folder and
select New => Software Deploy Job from the pop-up menu. The New Deploy
Job wizard opens.
Using the Servers folder, right-click a server and select Browse from the pop-
up menu. In the content editor, expand the Live node for the selected server,
and navigate to the software that you want to deploy. Right-click the software
and select Deploy from the pop-up menu. The New Deploy Job wizard opens.
If software must first be added to the Depot, the Select Matching Software
dialog box opens.
3 Provide information for the Deploy Job, as described in the following sections:
To monitor the results of a Deploy Job, see Deploy Job results on page 764.
Using those results you can retry, undo, or reset an entire Deploy Job or phases of
the job on specific servers.
For Windows target servers, you can use an automation principal to set up
Windows user mapping. This mechanism allows you to map a role to a local or
domain user on a target server who has administrator privileges. For more
information about Windows user mapping, see Creating automation
principals on page 195.
For UNIX target servers and Windows servers where you do not want to use
automation principals, you must map your machine or user name to a local
user on the remote server. That local user should have administrator privileges.
You must also perform this type of mapping on repeaters when you are
copying files to them for indirect deployments, even if you are ultimately
deploying files to Windows target servers using Windows user mapping. For
more information about configuration files and mapping users, see BMC
technical documentation at https://docs.bmc.com/docs/display/bsa82/Setting
+up+configuration+files.
new server object (such as a new UNIX object) is introduced after the agents most
recent software update. If you attempt to deploy a package that includes a server
object not already installed on a target server, the system will skip the unknown
server object and the job can still complete successfully.
When you are deploying a BLPackage, a Deploy Job cannot accommodate any
user interaction (other than canceling the job). Any deployment that requires user
input will fail.
When a BLPackage includes a resource pool that contains virtual machines, you
cannot deploy that package to another host server that is hosting virtual
machines. Also, be aware that if a BLPackage changes the number of virtual
processors on a running virtual machine, the system may become unstable.
Field Definitions
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
1 UserA creates a Deploy Job with an execution override. In other words, the job
should always run as UserA.
2 UserB runs the Commit phase of the job using the job's override settings (that is,
the job executes as UserA).
4 UserB attempts to run an undo of the job. The job fails because there is no
override set. The job attempted to run as UserB.
If the phases of a Deploy Job are run consecutively, changing override settings are
not a problem. Thus, the issue is not a concern when you run:
Basic Deploy Jobs. You cannot schedule phases separately for Basic Deploy Jobs.
Advanced Deploy Jobs, if you have selected the Execute selected phases
sequentially option (see Phase scheduling/Execution on page 733 for
information on that option).
Using the Install Software list you can change the order in which software packages
are deployed. To change order, select a package in the Install Software list and click
Move Up or Move Down .
If you want to select parts of a software package to be deployed, select the software
package in the Install Software list. Then, in the Selected Software Parts list below,
check the software parts you want to install. To check all parts, click Select All Parts
. To clear all parts, select Deselect All Parts .
If you are deploying a BLPackage with local properties to target components, you
may need to specify property values that are applicable to each target component.
The Properties list on this panel differs from other Properties lists throughout the
BMC Server Automation system. On this panel the list includes two columns labeled
Assignment Type and Value/Name. The Assignment Type column gives you the
following options:
for each component. Those, in turn, are used to replace the value of local
BLPackage property.
If you map a BLPackage property to a component property, the mapping is
ignored when you deploy the package to a target server rather than a target
component.
The Package panel also lets you choose between a basic or advanced deploy. The
two approaches to defining BLPackage Deploy Jobs have the following characteristics:
BasicDefines the job so if it fails, it is automatically reset, which means you can
immediately run the job again. Also, basic BLPackage Deploy Jobs are defined to
flow by server rather then by phase. Basic BLPackage Deploy Jobs are
recommended if you are including the job in a Batch Job. When you choose the
Basic option, other panels in the BLPackage Deploy Job wizard do not show some
of the more complex options for managing the flow and scheduling of the job.
Field definitions
Package
Properties
To set a value that always applies for a property when deploying the
package to a server, do both of the following:
If any property in the list requires a value, you must provide the value before
you can complete the panel.
Some organizations install multiple versions of the same application on one server.
For example, an organization might install different versions of Oracle for
Development, QA, and Production on the same server. Each version resides in a
different location on that server.
D:\app1
D:\app2
D:\app3
b In the component template, create a local property that can be used to define
the path to each instance of the application.
c For that local property, create three property instances. For one, define the
TPL_APP_PATH property so it equals app1. For another, it should equal app2.
The third should equal app3.
For more information about local properties for component templates and
property instances, see Local properties for a component template on page
412.
d On the Parts panel of the Component Template wizard, add the configuration
file you want to deploy by clicking Add Part . The Select Parts dialog box
opens. On that dialog box, click Add New , which opens the New
Component Template Part dialog box. On that dialog box, for Type, select File.
Then enter the path to the configuration file. For the portion of that path that
varies for each application, insert a parameter referencing the TPL_APP_PATH
property.
e Create a signature for the component template. The only requirement for the
signature is that the configuration file you added in step D must exist.
For more on creating signatures, see Discover tab for a component template
on page 375.
2 Run a Component Discovery Job on the server on which the three instances of the
application are installed.
Using the criteria in the component template, the job should discover three
components that match the signature.
For more information, see Creating Component Discovery Jobs on page 416.
c Create a local property for the BLPackage called PKG_APP_PATH. Make sure
that the type of property is the same as the type of the local property you
created for the component template.
For example, if that property was a String type, then this property should also
be a String type.
d Edit the path indicating where the configuration file added in step A should be
deployed. Replace the root directory for the application with a parameter
referencing the PKG_APP_PATH property.
For example, if you wanted to deploy the file to D:\app1\config, you would
enter a path like D:\??PKG_APP_PATH??\config.
c For the PKG_APP_PATH local property, specify that you want to set a value
for a component property name by setting the Assignment Type column to
Component Property Name. Then, for the Name/Value column, set the value
to TPL_APP_PATH.
d When specifying targets, choose the components to which you want to deploy.
When you deploy, the value of TPL_APP_PATH that was defined for each
component and was in turn derived from the value of the local property
instances you created in step 1 replaces the value of PKG_APP_PATH. For
example, TPL_APP_PATH resolves to D:\app1 for the first instance of the
application. That replaces the value of PKG_APP_PATH, which allows the
configuration file to be successfully deployed to a path of D:\app1\config.
When first defining and saving a Deploy Job, you do not have to specify targets. You
can specify targets at a later time.
In the Available Targets list, select servers, server groups, smart server groups,
components, component groups, or smart component groups. Then click the right
arrow to move your selections to the right panel.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
The Phases and Schedules panel prompts you for the following categories of
information:
If you are defining a Software Deploy Job, you can only schedule the job as a whole.
If you are defining an advanced BLPackage Deploy Job, you can schedule individual
phases.
Using the Phases and Schedules panel, you can choose to stage a deployment by
delivering a package directly to a target or by staging indirectly, meaning the
package is copied to a server designated as a repeater, and the repeater pushes the
package to multiple targets. There are several reasons to stage indirectly. If you stage
directly, you may be copying packages to a large number of hosts, which can
saturate a network with data. By staging indirectly, you can segment your network
and help spread the load over multiple hosts and sub-nets. If you are staging
through a thin pipe, for example a Wide Area Network (WAN) like the Internet, you
may have throughput issues. Staging to repeaters can shift the bulk of a deployment
to a much faster local area network.
Optionally, you can identify a network location for a staging directory by assigning a
network location to the STAGING_DIR property. Using a network staging location
means a package only needs to be pushed once to the staging directory. When the
Commit phase of a Deploy Job runs, the job pulls the package from the network
location and applies it to the target.
If you are staging indirectly, you must specify the repeater that each target server
uses. Each target servers REPEATER_NAME property identifies the repeater
relaying data to that server.
Objects being deployed are stored on a repeater after the Deploy Job completes.
Subsequent Deploy Jobs can use the same objects without copying them to the
repeater. When you run an indirect Deploy Job, BMC Server Automation searches
the cache on the repeater to find the objects being deployed. If an object exists, the
system compares the objects MD5 checksum to confirm that it is the same as the
object being deployed. If the object does not exist or it is not the same, a new object is
copied to the repeater.
Note
BLPackages that include virtual disk files can be largeoften measured in gigabytes.
When deploying such large files, BMC does not recommend using repeaters. Instead,
you should deploy the file directly to a host server.
When choosing to set up an indirect deployment, you should also consider whether
your source files are network-based. If you are using a network-based deployment,
you can instruct the agent on a target server to mount the server where the source
files are located. From there the agent can deploy the files directly to the target
server. In a deployment like this, using a repeater may not provide any benefit.
The appearance of the Phases and Schedules panel varies depending on whether you
are defining a Software Deploy Job or a basic or advanced BLPackage Deploy Job.
Phase selection
The Phase Selection options let you choose the phases of a Deploy Job you want to
run. You can also choose how to stage the deployment.
Staging refers to how packages are delivered to targets without actually applying
them to those servers. (A package does not necessarily include source files if you are
using a network-based deployment.) You can stage packages directly by pushing the
packages to targets, or you can stage indirectly. When staging indirectly, packages
are pushed to servers designated as repeaters, and then the repeaters push packages
to multiple target servers simultaneously.
Simulate
Commit
If you select Commit, you can choose how to stage deployment by selecting
one of the following:
Stage direct
Stage indirect
Deliver the package to a repeater. During the Commit phase, the package is
applied to targets.
Note
If you are staging indirectly, you must first define a property that identifies a
repeater for each target server. For information, see Configuring servers to
use repeaters during deployments on page 675.
Phase scheduling/Execution
The Phase Scheduling/Execution options let you schedule the execution of a job.
The options available vary depending on whether you are defining a Software
Deploy Job or a basic or advanced BLPackage Deploy Job. If you are defining a
Software Deploy Job or a basic BLPackage Deploy Job, you can only schedule the
overall job. If you are defining an advanced BLPackage Deploy Job, you can
schedule the overall job or schedule individual phases. Many organizations prefer to
schedule individual phases so that they can stage a job during business hours and
then commit the job during a maintenance window.
Instructs the job to execute immediately when you finish defining the job.
This option is not available if you are modifying an existing job or if your
system has been configured to require approval for this type of job.
This option is only available when your system has been configured to
require approval for this type of job.
Do not execute
After you define a Deploy Job, you can always select the job and execute it
interactively.
Indicate the entire job runs sequentially. To schedule the job, enter a date and
time using a format of yyyy/mm/dd hh:mm or click Browse, which displays
the Schedule Dialog. The dialog box contains two tabs, Schedule and
Schedule Job Notifications. Use them to define a schedule for the job.
See Deploy Job Scheduling on page 735 and Deploy Job Scheduled
Job Notifications on page 736.
If your system has been configured to require approval for this type of job,
you must also provide approval information. See Deploy Job Execute on
approval and Approval type settings on page 737.
Allows you to schedule individual phases of the job using the options
described below.
This option is only available if you are defining an advanced Deploy Job.
Simulate time
If you checked Simulate under Phase Selection, do one of the following for
Simulate time:
If you want to schedule this phase, select Start simulating at. Then, to
schedule the phase, enter a date and time using a format of mm/dd/yyyy
hh:mm, or click browse, which displays the Add New Schedule Dialog.
The dialog box contains two tabs, Schedule and Schedule Job
Notifications. Use them to define a schedule for the job.
See Deploy Job Scheduling on page 735 and Deploy Job Scheduled
Job Notifications on page 736.
Stage time
If you checked Commit under Phase Selection, do one of the following for
Stage time:
If you do not want to schedule the staging phase, select Not scheduled.
If you want to schedule the staging phase, select Start staging at. Then, to
schedule the phase, enter a date and time using a format of mm/dd/yyyy
hh:mm, or click Browse, which displays the Add New Schedule Dialog.
The dialog box contains two tabs, Schedule and Schedule Job
Notifications. Use them to define a schedule for the job.
See Deploy Job Scheduling on page 735 and Deploy Job Scheduled
Job Notifications on page 736.
Commit time
If you checked Commit under Phase Selection, do one of the following for
Commit time:
If you do not want to schedule the Commit phase, select Not scheduled.
If you want the Commit phase to follow staging, select Start immediately
after staging is complete. If approvals are required for this type of Deploy
Job, this option is called Start after staging is complete (on Approval) and
the option lets you click Browse to open an approval information window.
If you want to schedule the Commit phase, select Start commit at. Then, to
schedule the phase, enter a date and time using a format of mm/dd/yyyy
hh:mm, or click Browse, which displays the Add New Schedule Dialog.
The dialog box contains two tabs, Schedule and Schedule Job
Notifications. Use them to define a schedule for the job. The dialog box
contains a third tab if approvals are required.
For more information about scheduling the job, see Deploy Job
Scheduling on page 735 and Deploy Job Scheduled Job Notifications
on page 736. For more information about using the approval information
window, see Deploy Job Execute on approval and Approval type settings
on page 737.
Deploy Job Scheduling
The Schedule tab on a Deploy Job lets you schedule a job or a phase of a job so it can
run once.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job will always execute at the time you have specified. BMC
Server Automation automatically accounts for differences in time zones and changes
in daylight savings time. For example, if you schedule a job that should run weekly
at 06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
1 Using the Schedules tab, specify the date and time when the job or phase of a job
should run.
2 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
3 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
Deploy Job Scheduled Job Notifications
The Scheduled Job Notifications tab lets you send notifications when a scheduled job
completes.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Deploy Job Execute on approval and Approval type settings
The Approval information tab lets you select an approval type and enter approval
parameters when you configure the schedule.
The Approval information tab only appears when the BMC Server Automation
administrator has specified that this job type requires BMC Remedy ITSM approval
prior to execution. When approval is required, you must use this tab to select the
approval type and enter the approval parameters.
To specify an approval type, select the Execute on Approval option, and then select
an Approval type. Optionally, you can select to use an existing change ticket for
approval. The Execute on Approval field appears when you:
For more information, see Executing a job with BMC Remedy ITSM approval on
page 617.
There are many interactions to consider when specifying job options. For a
description of the procedure necessary to define job options, see Specifying job
options on page 738.
If you are defining an advanced BLPackage Deploy Job, you can use this panel to
control the flow of the job. You can specify whether a job should proceed as far as it
can for each server or complete the same phase for all servers before proceeding to
the next phase. You can also specify whether failed jobs are automatically reset so
they can be immediately re-executed.
If you are defining any type of Deploy Job, you can use the Job Options panel to do
any of the following:
Specify whether the job can execute in parallel on a target with other Deploy Jobs.
In some situations you may want a job to execute in single-job mode, meaning no
other Deploy Jobs can be processed while this job is executing.
Note that when a job starts, it may be placed in a queue of jobs waiting to execute.
The job leaves the queue when execution begins. Jobs defined to run in parallel
can execute while other parallel jobs are also executing. A job defined to run in
single-job mode must wait until the jobs ahead of it complete. Any jobs further
back in the queue wait until the job running in single-job mode completes.
Specify how long the job can wait in an agents queue of jobs to be processed
before the job itself is processed.
Specify how long the job can lose its connection to a target before the job fails.
Typically a Deploy Job loses a connection to a target because the network has a
experienced a failure, a target server is in the process of rebooting or shutting
down, or the server has rebooted into single-user mode.
Specify that the job uses single-user mode while processing the entire job or while
processing individual items. Single-user mode is a minimal UNIX environment
typically used when installing or removing software. When a server is in single-
user mode, BMC Server Automation cannot communicate with the agent on that
server. Single-user mode is available for all UNIX based systems. Windows
systems ignore all single-mode instructions.
Specify that a server reboot after an object in the package is deployed if the
definition for that object calls for a reboot. If necessary, you can specify that a
server reboot at the end of the job or that the server not reboot. You can also
specify that the job consolidate all reboots until the end of the job.
Specify for Solaris servers that a reconfiguration reboot occurs at the end of the
job. You can also specify whether a Solaris server should perform a
reconfiguration reboot after an object in the package is deployed if the definition
for that object calls for a reconfiguration reboot.
1 To set the logging level for the job, select one of the following from Logging
Level:
Errors and warningsErrors and warnings are displayed and output to a log.
By serverThe job proceeds as far as it can for each server. When one server
fails, the job continues on other servers. When the job completes a phase on
one server, the job continues to the next phase on that server. This option is
useful when you want the job to complete on as many servers as possible. A
failure on one server does not impede the job on other servers.
b If you selected By phase in the previous step, you can optionally check All
hosts must pass commit, which instructs the job to undo the Commit phase to
all targets if any targets do not successfully complete the Commit phase.
If you check this option and a job fails, the system undoes the staging phase of
the Deploy Job.
c Check Reset job on failure to allow this job to be run again even though the
job failed at least one phase on at least one server.
Checking this option places failed jobs into a Reset state. Unless you check this
option, a job cannot be run again until it completes successfully.
Select Enable single-job mode if this Deploy Job should not run in parallel on a
target with any other Deploy Jobs.
A job in single-job mode can only run when the target server is not currently
processing other Deploy Jobs. If another Deploy Job is running, this Deploy Job
waits until the other job is complete. While this job is being processed on a target
server, no other Deploy Job can run.
If you are deploying a package that includes an item that requires single-user
mode or a reboot, the job must be processed in single-job mode. In this situation,
the Enable single-job mode option is automatically checked and you cannot clear
it.
WARNING
If you choose to run Deploy Jobs in parallel on Windows systems, be aware that
many Windows installations change system files common to multiple
applications. For example, Windows installations often change COM+, metabase,
and security settings. Running multiple Windows installations simultaneously
can change system files almost simultaneously and leave an operating system in
an unstable state.
Note
Be aware of the following:
When deploying a software package that includes an object that requires an out-
of-band reboot, you must define that object within a BLPackage as requiring an
out-of-band reboot (see Setting a reboot for an object on page 525). This
automatically selects the Enable single-job mode option in this step. It also
ensures that rollback information is created for that object, assuming rollback
is enabled.
If you have not defined item-level reboots in the BLPackage and you are
deploying a package to a Windows server that should reboot automatically if a
reboot is required, you must set the Deploy Job to run in single-job mode. Also,
the Deploy Job must be defined to either reboot at the end of the job or to use
item-defined reboots. (See Step 6 on page 189 below for information about
defining reboots.)
Select Fail job if waiting in Agent deploy queue... and then enter a maximum
wait in minutes in the field to the right.
Agents queue Deploy Jobs that are waiting to process. If this Deploy Job does not
run before the specified period of time has elapsed, the job fails. If you do not
check this option or you do check this option and enter a 0 as a maximum wait
time, the job waits to run indefinitely.
4 If the Deploy Job fails when the Application Server loses contact with a target
server, check Fail job if any Agent connection loss exceeds... (This option
appears under Agent Connection Timeout.) Then, in the field to the right, enter a
maximum period of time in minutes that the job can wait to regain contact with
the agent before the job fails. If you do not check this option or you do check this
option and enter a 0 as a maximum wait time, the job waits to run indefinitely.
Note
When using this option, be aware of the following:
BMC recommends that you not use this option unless you are certain of the
length of time a target server can be disconnected from the Application Server.
For example, if a server is rebooting, you should know how long that process
takes. If you are installing software on a server in single-user mode (an agent
cannot be contacted when a server is in single-user mode), be certain of the
length of time it takes the software to install.
Losing a network connection to a target server will make a job appear to fail
even though the job may continue successfully on the target server.
If the duration of a connection loss exceeds the time specified in this step,
logging information is not available for the target server.
5 Under User Mode Options (UNIX Only), select one of the following from the drop-
down list:
When processing each object being deployed, this Deploy Job uses the user
mode setting (single- or multi-user) defined for that object.
This Deploy Job is processed on a target server using single-user mode. The
job switches into single-user mode without first rebooting or shutting down.
This Deploy Job reboots or shuts down a target server so the server enters
single user mode. The job is then processed using single-user mode.
6 Under Reboot Options, select one of the following from the drop-down list:
Causes a target to reboot after each object in the BLPackage is processed if the
instructions for that object call for a reboot. In addition, at the end of the job a
final reboot occurs if the last item in the job is not defined to reboot. If the last
item is defined to reboot, only one final reboot occurs at the end of the job.
Prevents a server from rebooting unless the item being deployed includes an
out-of-band reboot (that is, a reboot that is built into the object and is not part
of the BLPackage instructions). If any job items are defined to reboot after
deployment, those reboots are consolidated into one reboot at the end of the
job. If no job items require a reboot, no reboot occurs at the end of job. If a
deployment to Solaris target servers includes items that require a
reconfiguration reboot, those reboot requests are consolidated and the reboot
at the end of the job is a reconfiguration reboot.
Note
If a Deploy Job includes a reboot, the job must be executed in single-job mode.
This prevents the reboot from interfering with other Deploy Jobs.
7 For Solaris target servers, specify how the job should handle reconfiguration
reboots by doing the following:
a If any end-of-job reboots are specified in the previous step, indicate whether
those reboots should be reconfiguration reboots by checking Use
configuration reboot for reboot at end of job...
b Specify how the Deploy Job should manage item-level reconfiguration reboots
by selecting one of the following:
Instructs the Deploy Job to use the reconfiguration reboot settings defined for
objects being deployed. These reboots will occur in addition to the end-of-job
reconfiguration reboot setting specified in step a.
Instructs the Deploy Job to ignore any reconfiguration reboot settings defined
for objects being deployed, regardless of whether you specified an end-of-job
reconfiguration reboot in step a. If you choose this option, only the
reconfiguration aspect of the reboot is ignored. If an item definition calls for a
reconfiguration reboot, a reboot still occurs but it is not a reconfiguration reboot.
You can potentially define reboot settings for individual items in a BLPackage and
for the Deploy Job itself. You can also specify whether reboots should be
reconfiguration reboots. The table below details all possible combinations of reboot
settings.
The table does not include reboots on UNIX platforms that bring a server into single-
job mode (or exit single-job mode, in the case of Solaris 10). A reboot into or out of
single-job mode satisfies a requirement for a reboot so another reboot at the end of a
job or item deployment is not necessary. A reboot into or out of single-user mode can
be a reconfiguration reboot if a reconfiguration reboot is necessary.
Yes or No Use item defined (Not applicable) Use item defined The job reboots for each
reboot setting reconfigure item that requires a reboot.
setting If any items require a
reconfiguration reboot,
those reconfiguration
reboots occur.
Yes or No Use item defined (Not applicable) Ignore item The job reboots for each
reboot setting defined item that requires a reboot.
reconfigure All reboots are normal
setting reboots.
Yes or No Ignore item (Not applicable) Use item defined No reboots occur.
defined reboot reconfigure
setting setting
Yes or Not Ignore item (Not applicable) Ignore item No reboots occur
defined reboot defined
setting reconfigure
setting
Yes or No Use item defined No Use item defined The job reboots for each
reboot setting and reconfigure item that requires a reboot.
reboot at end of job setting In addition, a normal
reboot occurs at the end of
job unless the last item
installed also performs a
reboot.
Yes or No Use item defined No Ignore item The job reboots for each
reboot setting and defined item that requires a reboot.
reboot at end of job reconfigure Any reconfiguration
setting reboots are replaced with
standard reboots. In
addition, a normal reboot
occurs at the end of the job
unless the last item
installed also performs a
reboot.
Yes or No Use item defined Yes Use item defined The job performs all item-
reboot setting and reconfigure level reboots, including
reboot at end of job setting any reconfiguration
reboots. The final reboot at
the end of the job is a
reconfiguration reboot.
Yes or No Use item defined Yes Ignore item The job performs all item-
reboot setting and defined level reboots but none of
reboot at end of job reconfigure those reboots are
setting reconfiguration reboots.
The final reboot at the end
of the job is a
reconfiguration reboot.
Yes or No Ignore item No Use item defined The job ignores all item-
defined reboot reconfigure level reboots and performs
setting and reboot setting a normal reboot at the end
at end of job of the job.
Yes or No Ignore item No Ignore item The job ignores all item-
defined reboot defined level reboots and performs
setting and reboot reconfigure a normal reboot at the end
at end of job setting of the job.
Yes or No Ignore item Yes Use item defined The job ignores all item-
defined reboot reconfigure level reboots and performs
setting and reboot setting a reconfiguration reboot at
at end of job the end of the job.
Yes or No Ignore item Yes Ignore item The job ignores all item-
defined reboot defined level reboots and performs
setting and reboot reconfigure a reconfiguration reboot at
at end of job setting the end of the job.
Yes Consolidate any Yes or No Use item defined The job delays all item-
After item reconfigure level reboots until a final
deployment setting reboot at the end of the job.
reboots until end If any item-level reboots
of job are reconfiguration
reboots, the final reboot is
a reconfiguration reboot.
Yes Consolidate any No Ignore item The job delays all item-
After item defined level reboots until a final,
deployment reconfigure normal reboot at the end of
reboots until end setting the job.
of job
Yes Consolidate any Yes Ignore item The job delays all item-
After item defined level reboots until a final
deployment reconfigure reconfiguration reboot at
reboots until end setting the end of the job.
of job
No Consolidate any Yes or No Use item defined No reboots occur.
After item reconfigure
deployment setting
reboots until end
of job
No Consolidate any Yes or No Ignore item No reboots occur.
After item defined
deployment reconfigure
reboots until end setting
of job
The Phase Options panel also lets you assign pre- and postcommands for the Deploy
Job and the undoing of the Deploy Job.
To complete the Phase Options panel, you may have to perform the following
procedures:
1 To test for disk space on the target, check Test for sufficient staging directory
space... If you clear this option, no testing is done to determine if sufficient disk
space exists on a target server.
StageA check is made to determine if there is sufficient disk space for the
staging phase of the Deploy Job. By default Deploy Jobs are configured to test if
sufficient disk space exists for the Stage phase of the job.
SimulateA check is made to determine if sufficient disk space exists for the
simulation phase of the Deploy Job.
1 Check Auto rollback to leave the destination host unchanged should the Commit
phase fail.
When you check this option and the Commit phase fails for any reason, the
Deploy Job is automatically rolled back, leaving the destination host
unchanged. If you do not check this option and the Commit phase fails, the
deployment aborts and does not roll back any transactions that are part of the
deployment.
Note
Using the BLPackage editor, you can customize the behavior of a deployment
so individual commands in the deployment can fail but the overall deployment
continues (see Adding an external command to a BLPackage on page 539).
2 Check Allow rollback to leave rollback files on the target server so they can
potentially be used later to undo a deployment. In some situations, the rollback
files left on the target server can be large.
WARNING
Each run of a Deploy Job generates a unique set of rollback files. Because these
files can be large, if you are running multiple Deploy Jobs and you choose to store
rollback files by selecting this option, you may be generating extremely large
amounts of data. In a situation like this, you should set up a prudent retention
policy for both storing job runs and executing your data retention policy. Job run
data should only be stored as long as you need it. For example, if you run a
Deploy Job daily, you may only want to store job run data for one or two days.
See BMC technical documentation at https://docs.bmc.com/docs/display/bsa82/
Managing+BMC+Server+Automation+data for more information about data
retention.
3 Check Preserve staging area on failure if you want to keep the data copied to a
staging area for the BLPackage even though this Deploy Job fails.
By default a Deploy Job deletes the staging directory on a target server when a
failure occurs during any phase of the job. Preserving a staging area can
potentially leave large files on a target directory after a job failure.
5 If you are deploying to Windows machines, check any of the following under
Windows-only Options:
Instructs a server to begin the Commit phase even though a server requires a
reboot to copy over existing locked files. Clearing this option means the
Commit phase does not begin if locked files requiring a reboot exist.
Instructs a server to create copy on boot files when locked files are
encountered during the Commit phase. These are files that are copied and
then overwritten after a reboot. Note that a Deploy Job only creates copy on
boot versions of read-only files if the Overwrite read-only files option (see
above) is checked.
Clearing this option means the job repeatedly attempts to copy the files being
modified. The job will attempt to copy the files 25 times, with a two-second
wait between each attempt. If files are still not successfully copied, the job
generates an error and fails.
Commit Phase
Undo Phase
Registers COM objects during the Undo phase. If the Commit phase of a
job run removes a file, the file is restored when that job run is undone. If
the file has an extension of DLL, EXE, or OCX, the job determines if the file
is a COM object. If it is, and this option was selected during the Commit
phase of the job run being undone, the file being restored is registered.
Commit Phase
Undo Phase
Unregisters COM objects during the Undo phase. If the Commit phase of a
job run adds a file, the file is removed when that job run is undone. If the
file has an extension of DLL, EXE, or OCX, the job determines whether the
file is a COM object. If it is and this option was selected during the
Commit phase of the job run being undone, the file being removed is
unregistered.
You can create pre- and postcommands by entering commands in the text box or
importing text from a file on any managed server.
3 For Deployment path, enter the path where pre- and postcommands, in script
form, are written during deployment so they can be run on an agent.
The path can include a parameter. Enter the parameter manually or click Select
Property , which appears when you click in the Value column. (For more
information about using this tool, see Inserting a parameter on page 163.)
For Pre-command, enter the command that you want to execute before the
deployment begins. To import the text of the command, click Browse and
navigate to the file containing that text.
If a precommand must execute successfully for the deployment to complete,
check Must have 0 exit status.
For Post-command, enter the command that you want to execute after the
deployment ends. Postcommands are executed in the target directory. To
import the text of the command, click Browse and navigate to the file
containing that text.
If a postcommand must execute successfully for the deployment to complete,
check Post command should have 0 exit status.
If necessary, click Zoom to open a dialog box that gives you a larger text box
to edit pre- and postcommands. When you finish editing the command, click OK.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
To define time-outs, enter values for one or both of the following Deploy Job properties:
The Deploy Job properties listed below let you control how many Deploy Job
processes and connections run on a target at one time. Typically, these properties are
used to limit the number of AMOs that are processed simultaneously on an AMO
proxy. For example, you could limit the total number of Simulate and Commit
phases running on an AMO proxy. However, these properties are not limited to
AMOs. They can also be used to limit the number of processes running on agent-
based targets.
Property Description
SIMULATE_MAX_PARALLET_TARGETS Maximum number of targets running the Simulate
phase of the Deploy Job
Property Description
STAGING_MAX_PARALLEL_TARGETS Maximum number of targets running the Staging
phase of the Deploy Job
COMMIT_MAX_PARALLEL_TARGETS Maximum number of targets running the Commit
phase of the Deploy Job
UNDO_MAX_PARALLEL_TARGETS Maximum number of targets running an undo of the
Deploy Job
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
The factors influencing BMC Server Automation behavior include the target servers
operating system (for example Windows 2000 or Windows 2003), the servers
workgroup or stand-alone status, the presence of a domain, domain-level settings,
and the refresh rate for those settings. These factors are important because the
system relies on an underlying Windows utility called secedit to deploy and browse
local security settings.
When a BLPackage is deployed, all security settings are applied at once. If the
secedit utility returns a failure during the deployment, the Deploy Job is marked as a
failure. The Deploy Job cannot provide any information about the cause of the
failure because secedit does not provide that information. If secedit returns a success,
the Deploy Job is marked a success. If a security setting does not apply to a targets
operating system, however, inconsistent behavior may occur. For example, if you
create a BLPackage containing security settings for a Windows 2003 machine, and
you create the BLPackage on a Windows 2000 machine, deploying that BLPackage to
a Windows 2000 machine appears to succeed. In fact, no change actually occurs on
that server. On the other hand, if you create the same package on a Windows 2003
machine and deploy it to a Windows 2000 machine, the deployment fails. Error
messages do not explain the cause of the failure.
If you use a Deploy Job to change security settings in the Security Options category
(a sub-category of Local Policies), changes are made to the registry. If you browse the
changes you have made to security settings, those changes may not display
immediately.
If a security setting is defined at the domain level, the next refresh overwrites its
corresponding local setting.
To modify the definition of an existing Deploy Job, open the Jobs folder and
navigate to an existing job. Right-click the job and select Open from the pop-up
menu. The content editor displays a series of tabs, which are described in the
following sections:
Deploy Job General on page 722
Deploy Job Software on page 724 (for Software Deploy Jobs)
Deploy Job Package on page 724 (for BLPackage Deploy Jobs)
Deploy Job Targets on page 729
Deploy Job Default Notifications on page 729
Deploy Job Phases and Schedules on page 730
Deploy Job Job Options on page 737
Deploy Job Phase Options on page 746
These tabs correspond to panels in the New Deploy Job wizard. Use them to
modify the job definition.
Select the Properties, Permissions, or Audit Trail tab group to see or modify
any of properties, permissions, or audit trail information that apply to this job.
For more information, see Properties, Permissions, and Audit Trail tab group
on page 98.
To set default values for the many options in a Deploy Job, use the DeployOptions
property class in the Property Dictionary. Assign new default values for any
properties where the current default value is not appropriate. When you create a
new Deploy Job, the system uses those default values to set options in the job. Be
aware that modifying the DeployOptions property class does not change settings for
any existing Deploy Jobs.
3 Select DeployOptions.
4 In the Properties tab, select properties and define their values according to your
needs. These values control the settings for any newly created Deploy Jobs. For
more information about these properties, see DeployOptions properties for
controlling Deploy Job behavior on page 446.
For more about setting these options, see Assigning default values for Deploy Jobs
on page 754.
AGENT_CONNECTION Integer Enter a maximum period of time in minutes that the Deploy Job
_TIMEOUT can wait after the Application Server loses contact with the target
server. If the specified period of time elapses, the job fails.
If you do not enter any value or you enter 0, the job waits
indefinitely.
AGENT_QUEUE_WAIT Integer Enter a maximum period of time in minutes that the Deploy Job
_TIMEOUT can wait for the agent on the target server to process this Deploy
Job. Waits typically occur when agents have queued Deploy Jobs.
If the specified period of time elapses, the job fails.
If you do not enter any value or you enter 0, the job waits
indefinitely.
BY_PHASE_ALL_HOST Boolean Enter True to instruct the job to undo the Commit phase for all
_MUST_PASS_COMMIT target servers if any servers do not successfully complete the
Commit phase. By default this option is set to False. This option is
only applicable when the FLOW_CONTROL option is set to
ByPhase.
COPY_LOCKED_FILES Boolean Enter True to instruct a target server to create copy on boot files
when locked files are encountered during the Commit phase of a
Deploy Job.
Entering False means the job generates an error and fails if it
encounters locked files.
Note that a Deploy Job only creates copy on boot versions of read-
only files if the OVERWRITE_READONLY_FILES option is set to
True.
DEPLOY_JOB_TYPE Enumerated Specify the Deploy Job type:
ENABLE_SINGLE_JOB_ Boolean Enter True to instruct the Deploy Job to run in single-job mode
MODE that is, it cannot run in parallel on a target server with any other
Deploy Jobs.
A job in single-job mode can only run when no other Deploy Job
is currently being processed on the same target server. If other
Deploy Jobs are processing, this Deploy Job waits until they are
complete. While this job is being processed on a target server, no
other Deploy Job can run.
FLOW_CONTROL Enumerated Specify how you want to control the flow of a job by choosing one
of the following:
FOLLOW_SYMLINKS_ Boolean Enter True if a Deploy Job should copy the target of a symbolic
ON_URL link included in a URL; enter False if a Deploy Job should copy
only the symbolic link itself. This option only applies when you
are using the Copy to Agent at staging option to provide a URL
that identifies source files for a patch or software package.
IGNORE_COPY_ON_BO Boolean Enter True to instruct a server to begin the Commit phase of the
OT_FILES Deploy Job even though a server requires a reboot to copy over
existing locked files.
Entering False means the Commit phase does not begin if locked
files requiring a reboot exist.
IS_ALLOW_ROLLBACK Boolean Enter True to instruct the Deploy Job to leave rollback files on the
target server so they can potentially be used later. In some
situations the rollback files left on the target server can be very large.
IS_AUTO_ROLLBACK Boolean Enter True to instruct the Deploy Job to leave the destination host
unchanged should the Commit phase fail.
When you set this option to True and the Commit phase fails for
any reason, the Deploy Job is automatically rolled back, leaving
the destination host unchanged. If you set this option to False and
the Commit phase fails, the deployment aborts and does not roll
back any transactions that are part of the deployment.
IS_COMMIT_ENABLED Boolean Enter True to enable the Commit phase of the Deploy Job. During
the Commit phase, packages are applied to target servers.
IS_RECONFIGURE_REB Boolean Enter True if any end-of-job reboots specified in
OOT REBOOT_OPTIONS should be Solaris reconfiguration reboots.
IS_SIMULATE_ENABLE Boolean Enter True to enable the Simulate phase of the Deploy Job. The
D Simulate phase performs a dry run of a deployment without
actually deploying a package. A dry run lets you review job
results, see the server objects that are changed during
deployment, and determine what actions, if any, are causing the
deployment to fail (that is, to generate a non-zero return code).
IS_STAGING_INDIREC Boolean Enter True to enable indirect staging, which means the Deploy
T Job delivers the package to a repeater. During the Commit phase,
the package is applied to the target server.
Entering False means the job delivers the package directly to a
target server.
Note: If you are staging indirectly, you must define a property
that identifies a repeater for each target server.
ITEM_RECONFIGURE_ Enumerated Specify how the Deploy Job should handle item-level
REBOOT_OPTIONS reconfiguration reboots by selecting one of the following:
LOGGING_LEVEL Enumerated Specify the amount of logging information that the Deploy Job
generates by choosing one of the following:
OVERWRITE_READON Boolean Enter True to instruct a server to overwrite read-only files when
LY_FILES read-only files are encountered during the Commit phase.
PRESERVE_STAGING_ Boolean Enter True to retain data copied to a staging area on a target
DIR_ON_FAILURE server even though the Deploy Job fails.
By default a Deploy Job deletes the staging directory on a target
server when a failure occurs during any phase of the job.
Preserving a staging area can potentially leave large files on a
target directory after a job failure.
REGISTER_COM_COMP Boolean Enter True to register COM objects during the Commit phase.
ONENTS When a deployment adds a file with an extension of DLL, EXE, or
OCX, the job determines whether the file is a COM object. If it is,
the deployment registers the new object during the Commit phase.
REGISTER_COM_COMP Boolean Enter True to register COM objects during the Undo phase.
ONENTS_FOR_UNDO If the Commit phase of a job run removes a file, the file is restored
when that job run is undone. If the file has an extension of DLL,
EXE, or OCX, the job determines whether the file is a COM object.
If it is and this option was set to True during the Commit phase of
the job run being undone, the file being restored is registered.
RESET_JOB_ON_FAILU Boolean Setting this option to True allows a job to be run again even
RE though the job failed at least one phase on at least one server. By
default this option is set to False.
If you set this option to True, failed jobs are placed into a Reset
state. If you do not set this option to True, a job cannot be run
again until it completes successfully
UNREGISTER_COM_C Boolean Enter True to unregister COM objects during the Commit phase.
OMPONENTS_FOR_CO When a deployment removes a file with an extension of DLL,
MMIT EXE, or OCX, the job determines whether the file is a COM object.
If it is, the deployment unregisters the object during the Commit
phase.
UNREGISTER_COM_C Boolean Enter True to unregister COM objects during the Undo phase.
OMPONENTS_FOR_UN If the Commit phase of a job run adds a file, the file is removed
DO when that job run is undone. If the file has an extension of DLL,
EXE, or OCX, the job determines whether the file is a COM object.
If it is and this option was set to True during the Commit phase of
the job run being undone, the file being removed is unregistered.
USER_MODE_OPTIONS Enumerated Specify user mode behavior (only applicable to UNIX target
_UNIX_ONLY systems) by choosing one of the following:
Uninstalling software
To uninstall software, use a Software Deploy Job to push a software package to
servers where the uninstall should occur. The system runs an uninstall command
rather than an install command, which is the normal behavior of a Software Deploy
Job.
You can control the phases of an uninstall job just as you would a Deploy job (see
Deploy Job results on page 764). Because the process of defining an uninstall job
is almost identical to defining a Deploy Job, this procedure primarily references the
Deploy Job procedure.
Note
Be aware of the following:
To run an uninstall job, you must have administrator privileges on the remote
server where you are uninstalling. That means your machine or user name should
be mapped to a local user on the remote server, and that local user should have
administrator privileges. For more information about configuration files and
mapping users, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Setting+up+configuration+files.
You cannot uninstall AIX patches. When BMC Server Automation installs an AIX
patch, it automatically commits to the installation. After committing, an AIX
patch cannot be uninstalled.
To uninstall a hotfix, you must enable the Allow service to interact with desktop
option for the RSCD agent service running on that target server. This is the
default configuration for Windows 2003 servers.
Before you can run an uninstall job, you must store the software packages being
uninstalled in the Depot. Note that a software package stored in the Depot does not
necessarily include source files if you are using a network-based deployment. For
information about adding Windows patches and service packs to the Depot, see
Adding a hotfix to the Depot on page 496. For information about adding all other
types of software packages to the Depot, see Adding software to the Depot on
page 482.
To uninstall software
Open the Depot folder and navigate to the software package you want to
uninstall. Right-click the package and select Uninstall from the pop-up menu.
The New Uninstall Job wizard opens.
Open the Servers folder, expand the Live node for a server, and navigate to the
software you want to uninstall. Right-click the software and select Uninstall
from the pop-up menu.
The New Uninstall Job wizard opens. If software must first be added to the
Depot, the Select Matching Software dialog box opens.
For more information, see Matching software with depot items on page 507.
3 Provide information for the uninstall job, as described in the following sections:
To monitor the results of an uninstall job, see Deploy Job results on page 764.
This process lets you retry, undo, or reset an entire uninstall job or phases of the
job on specific servers.
The complete results of a Deploy Job, including the jobs history, can be accessed
from the Jobs folder. Deploy Job results that pertain to a specific server also appear
in the Activity tab for all servers in the Servers folder. The job results show a listing
for each run of the job, including the date and time the job ran.
When examining results for a Deploy Job, the content editor displays a tab with two
main sections. The left section shows the history of the job. The right section displays
two tabs for a selected job run: Log Messages and Deploy Status.
The Log Messages tab show messages generated for the job run.
The Deploy Status tab provides a table that shows targets servers and components
and the status of their job phases. You can click the headers in each table column to
sort Deploy Job results. Clicking the header for the row listing server or component
names sorts results alphabetically name. Clicking the Simulate, Stage, or Commit
header sorts results according to the contents of that column. Results are sorted into
the following job statuses:
Completed successfully
Note
The ActionOnFailure command in a BLPackage can be set so a job continues even
though a command within the job may have failed. If a command is set to Ignore and
the command fails, the job appears to have completed successfully. (You can
examine the job log to determine where any failures occurred.) If a command is set
to Continue and the command fails, the job completes with errors. If a job includes a
mixture of commands set to both Ignore and Continue and those commands fail, the
job appears to have completed with errors because the Continue command takes
precedence over the Ignore command.
See Phases of a Deploy Job on page 714 and Deploy Job states on page 716 for
more information about job phases and states.
Using the results of a Deploy Job, you can perform any of the following procedures:
You can also take action on a particular run of a job. For more information, see
Performing actions on a server or phase on page 767.
1 In the Jobs folder, right-click a Deploy Job and do any of the following:
Select Open from the pop-up menu. A tab for the Deploy Job opens in the
content editor. Use the subtabs at the bottom of the tab to redefine the job.
Select Execute from the pop-up menu. The job executes. In some situations
where the job has previously failed, the job will resume on any targets where
failures occurred. For more information, see Resuming a failed Deploy Job on
page 766.
Select Reset from the pop-up menu. This option is only available when a job is
in the incomplete state. Selecting Reset sets the jobs state to Reset. After a job
has been reset, it can be run again.
The icon appears when the phases of an advanced Deploy Job are scheduled at
different times, and the job is waiting to resume the next scheduled phase. This icon
also appears if an advanced Deploy Job has failed, and the job is not defined to reset
automatically on failure. The following is a sample of this icon.
In the case of a failed advanced Deploy Job, you can resume the job from the point of
failure on any targets. How the job proceeds from the point of failure depends on
how you control the flow of a job. If you are controlling:
By serverThe job proceeds on all failed servers, moving to the next phase for
each server when the job completes its current phase.
By phaseThe job proceeds on all failed servers. When they all complete the
current phase, the job moves to the next phase for all target servers.
When you resume a failed job, you can click Show details on the Deploy Status tab
to display all job attempts on all target servers. If no work occurs on a server for a
particular job attempt, nothing appears in the cell that corresponds to that phase on
that server.
1 To resume a failed job that is in a paused state, right-click a Deploy Job and select
Execute from the pop-up menu.
To take action on a job as a whole, see Performing actions on a job on page 765.
1 In the Jobs folder, select a Deploy Job. Right-click and select Show Results from
the pop-up menu. A tab opens showing results for the Deploy Job.
2 Select a run of a job and a section on the right side of the current tab shows two
tabs: Deploy Status and Log Messages.
Remove a target from this job by selecting a target where the job is incomplete,
right-clicking, and selecting Remove.
Retry the job on a target by selecting a target where the job is incomplete, right-
clicking, and selecting Retry.
The job immediately runs the phase of the job that did not complete previously.
Retry the job for multiple targets and phases by selecting the cells where the job
is incomplete. Right-click and select Retry from the pop-up menu.
The job immediately runs the phases of the job that previously did not
complete on the selected targets.
Show the current status of all targets by clicking Show Summary on the
Deploy Status tab. Show the history of all job attempts by clicking Show
Details on the Deploy Status tab.
When you are showing summary information, the Show Details button
appears. When you are showing history information, the Show Summary
button appears.
4 To show messages generated for the entire job run that is currently selected, click
the Log Messages (run level) tab.
When you perform this procedure on a job in an Incomplete state, the job remains in
an Incomplete state. If you perform it on a job in a Failed or Succeeded state, the job
remains in a Failed or Succeeded state.
When you uninstall a software package, you are running a Deploy Job that deploys a
software package and then uninstalls the software package rather than install it. If
you undo a Deploy Job used for uninstalling software, you are undoing the
uninstall. In effect, you are installing the software package.
Note
BMC Server Automation does not support undo when you are deploying AIX or Red
Hat patches.
1 Display job results by selecting a job, right-clicking, and selecting Show Results
from the pop-up menu.
To undo all committed packages, select the most recent job run and select Undo
from the pop-up menu.
To undo committed packages for selected servers, click the Deploy Status tab if
it is not already selected. Select cells in the Commit column for those servers
where you want to undo packages. Use Shift-click or Control-click to select
multiple cells. Right-click and select Undo from the pop-up menu.
A confirmation dialog box shows the BLPackage or the software packages that
are being rolled back and lists the servers on which you are undoing the
Deploy Job.
4 To confirm the undo, click OK. A dialog box announces that the undo is in
process and allows you to cancel the undo if necessary.
After undoing a Deploy Job, you can display the Deploy Status panel again. It
displays a column called Rollback, which shows the status of the undo.
Selecting a cell under the Rollback column displays messages for the undo on
that server.
Rebooting servers
Using Deploy Job results, you can reboot a Windows server when deployment of a
software package requires a reboot.
Servers should reboot automatically if the object being deployed requires a reboot
(see Setting a reboot for an object on page 525) and the Job Options panel of the
Deploy Job allows reboots (see Deploy Job Job Options on page 737).
Servers requiring a reboot are flagged with a different icon on the Deploy Status tab.
In addition, the log messages generated for the Commit phase of the job include a
warning that a reboot is required.
A Deploy Job can be defined so that a target Windows server reboots automatically
at the end of the job. To accomplish this, the Deploy Job must run in single-job mode
and the job must be defined to either reboot automatically at the end of the job or to
use item-defined reboots. For details on these requirements, see Deploy Job Job
Options on page 737.
To reboot servers
1 In the Deploy Status tab for a Deploy Job, right-click the server requiring a reboot
or right-click the cell representing the Commit phase on the server requiring a
reboot. Then select Reboot from the pop-up menu. A dialog box prompts you to
confirm the reboot.
Using NFS to mount a location while running single-user mode on page 771
This procedure gives you the capability to set up a maintenance window for one or
more servers. Generally, the IS_DEPLOYABLE property can be set to False, so
nothing can be deployed to the server. When a maintenance window opens, you can
set the property on the server to True. At that point you can deploy patches and
make other changes to the server. To change the value of the IS_DEPLOYABLE
property for multiple servers, use an Update Server Properties Job.
For details on how to define a property value, see Setting values for system
object properties on page 161.
The logging and rollback files that are stored in the Transactions directory can get
very large. This procedure allows you to specify an alternate location for each target
server. This procedure requires you to set a value for the TRANSACTIONS_DIR
server property.
The location you specify using this procedure must already exist. If the alternate
location is on a UNIX server, the Deploy Job must have appropriate permissions to
create sub-directories in that location.
When you perform this procedure, BMC Server Automation will continue to use the
default Transactions directory for some files, which are small and typically transient.
When you use the clean-up utility to remove unwanted files on target servers, the clean-
up utility uses the current location of the Transactions directory. Clean-up does not
affect any previous locations for the Transactions directory.
For details on how to define a property value, see Setting values for system
object properties on page 161.
A UNIX agent may need to mount a source location if a patch or software package
being deployed is defined to use the Agent mounts source for direct use at
deployment option, as described in Adding software on page 485.
Most servers are not configured to use NFS while running in single-user mode.
Enabling NFS in this context usually requires special configuration. Before running a
Deploy Job on a server with DEPLOY_ALLOW_NFS_DURING_SUM set to True,
you must configure the server to use NFS in single-user mode. Otherwise the agent
will not be able to successfully mount a source location.
For details on how to define a property value, see Setting values for system
object properties on page 161.
The time stamp shown in the Deployment Time column reflects the local time for the
server.
1 Using the Servers folder, select a server, right-click, and select Browse.
The right side of the tab shows the history of BLPackage deployments on this server.
3 While displaying information about BLPackages, you can remove entries from the
list by doing any of the following:
To remove all entries in the list, select BLPackages, right-click, and select
Remove All Entries.
To remove all entries deployed before a certain date, select BLBLPackages, right-
click, and select Remove All Entries Older Than. A dialog appears, asking you
to specify a date.
To remove a specific BLPackage entry, select that entry, right click, and select
Remove Entry.
File Deploy Jobs allow you to choose the files and directories you want to deploy
from servers. In other words, you can select files and directories that are available
under the Live node for a server in the Servers folder. If you want to deploy files
stored in the Depot, you must bundle the files as a BLPackage (see Adding a
BLPackage to the Depot on page 509) and then use a BLPackage Deploy Job to
deploy them (see Creating a Deploy Job on page 718). Deploying files as
BLPackages provides far more control over a job, including the ability to simulate its
deployment, automatically roll the job back when a failure occurs, and manually
undo the job.
Note
Be aware of the following:
To deploy files and directories, BMC Server Automation recommends that you
have administrator privileges on the remote server to which you are deploying.
To accomplish this, there are two approaches:
For Windows target servers, you can use an automation principal to set up
Windows user mapping. This mechanism allows you to map a role to a local or
domain user on a target server who has administrator privileges. For more
information about Windows user mapping, see Creating automation
principals on page 195.
For UNIX target servers and Windows servers where you do not want to use
automation principals, you must map your machine or user name to a local
user on the remote server. That local user should have administrator
privileges. You must also perform this type of mapping on repeaters when you
are copying files to them for indirect deployments, even if you are ultimately
deploying files to Windows target servers using Windows user mapping. For
more information about configuration files and mapping users, see BMC
technical documentation at https://docs.bmc.com/docs/display/bsa82/
Setting+up+configuration+files.
Using the Servers folder, right-click a server and select Browse from the pop-
up menu. In the content editor, expand the Live => File System node for a
server, and then select the files and directories you want to deploy. Right-click
and select Deploy Files from the pop-up menu. The New File Deploy Job
wizard opens.
Open the Jobs folder and navigate to the job folder where you want to create a
File Deploy job. Right-click the job folder and select New => File Deploy Job
from the pop-up menu. The New File Deploy Job wizard opens.
2 Provide information for the File Deploy job, as described in the following
sections:
Field Definitions
Name
Identifying name.
Description
Save in
Source
Use the Source list to identify the files and directories you want to deploy. To
specify additional files and directories, do any of the following:
Click Browse and use the Select Source Files dialog box to select a file or
directory.
Click Add and use the Add Source File dialog box to provide a path to
a file or directory.
The files and directories you specify appear in the Source list.
To delete an entry from the list of files or directories being deployed, select
the entry and click Delete . Use Control-click or Shift-click to select
multiple entries.
Checking this option means that each file or directory you are deploying will
have the same relative path on the destination machine as it has on the source
machine. For example, when you are copying the file /etc/hosts, the hosts file
is copied to the path /etc/hosts rather than being copied to a directory that
you specify. Preserving source file paths is an easy way to synchronize file
systems, especially when you are moving multiple files that need to reside in
various locations.
Destination
For Destination, enter the path of the location to which you want to copy
files or directories. You can type a path or click Browse to select a destination.
Note: If you checked Preserve source file paths in the previous step, you
should probably enter / for Destination. Specifying a destination other than /
means that the system preserves the paths of the files and directories you are
deploying and recreates those paths relative to the destination directory you
specify. For example, if you are copying /etc/hosts and your destination
directory is /tmp, the hosts file is copied to /tmp/etc/hosts.
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Field definitions
Available Servers
Specify the operating system of the servers you want to select. To display
servers running any operating system, select All.
By Group, By Name
Select servers from a tree or sortable list by doing one of the following:
Click the By Group tab at the bottom of the window. The left panel
displays servers in a hierarchical list arranged by server group. Choose
servers by doing one of the following:
To select all servers within the group, click a server group.
Click one or more servers, if necessary, to expand server groups.
Click the By Name tab at the bottom of the window. The left panel lists
servers by name in a Group Explorer view. Sort servers in ascending or
descending order by clicking on any column header. Click one or more
servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
Click the right arrow to move your selections to the right panel.
Sync Push
Using a File Deploy Job, you can copy files and directories to target servers and
overwrite the corresponding files on those machines. Alternatively, you can copy
only those files and directories that meet criteria you specify, a process called a
synchronized push.
If the files and directories on a target server satisfy your criteria, the push replaces
those files. When you perform a synchronized push, you can also specify some other
characteristics of the push.
Field definitions
Sync Push
Check Sync Push to copy source files and directories conditionally based on
criteria you specify.
Clearing Sync Push copies source files and directories to each target server
regardless of the state of the corresponding files on each of the targets.
Essentially, this option overwrites existing destination files on the target host.
By default, files are not copied conditionally. That is, by default, target files
are overwritten.
File Size
Copies a source file if its size differs from the size of the target file.
MD5 checksum
Copies a source file if its MD5 checksum differs from that of the target. This
option is typically used when File Size and Last Modified do not adequately
differentiate files. Selecting this option adds overhead to the push.
Last modified
Copies a source file if its time and date of last modification differs from the
time and date when the target file was last modified.
Permissions
Synchronizes file permissions if the source and target file permissions differ.
In this case only file permissions are copied; the file itself is not copied. This
option is not recommended when the source or target machines are Windows
systems.
Ownerships
Synchronizes file ownership if there are different owners for the source and
target files. In this case only file ownership information is copied; the file
itself is not copied. This option is not recommended when the source or
target machines are Windows systems.
Prune
Recursively deletes files and directories that exist in the target directory but
not in the source directory. This option ensures consistency across remote
systems.
There are several reasons to perform an indirect rather than a direct push. Copying
to a large number of hosts can saturate a network with data. Using an indirect push,
you can segment your network and help spread the load over multiple hosts and sub-
nets. If you are pushing through a thin pipe, for example a Wide Area Network
(WAN) like the Internet, you may have throughput issues. Pushing to a single
remote server that acts as the repeater can shift the bulk of a push to a much faster
Local Area Network (LAN).
Note
If you are staging indirectly, you must set up target servers so they use repeaters. For
more information, see Configuring servers to use repeaters during deployments
on page 989.
Field definitions
Staging directory
Check to remove all staging files from the repeater host after the copy is
complete. Clear to leave all staging files on the repeater host so they can be
used in future synchronized pushes, as described in the next option.
Check to copy only modified files to the repeater host. Unmodified files are
not copied. Checking this option means that all files are copied to repeater hosts.
Parallel pushes
Backup Options
When deploying a file or directory, you can take precautions to back up the files that
are overwritten.
Field definitions
Backup Options
When you select this option, all files that would be overwritten during a copy
are renamed with the suffix you have defined. The suffix is appended to the
end of the file. For example, foo gets saved as foo.bak. Then, if you need to
roll back a File Deploy Job, a custom script can look for all files in the
destination directory with a particular suffix and rename them by removing
that suffix. For example, foo.bak gets restored as foo.
Note: When rolling back a File Deploy Job, all files with names ending in a
designated suffix will have that suffix removed even though those files may
not have been created during previous deployments.
Suffix
Backup
When you select this option, the system makes a copy of the files that would
be overwritten by copying the destination file or directory of the first host
listed when you identify target hosts in the next step of the wizard. For
example, if the first target host you identify is eastwin2k1, the system copies
everything in the destination directory in eastwin2k1 and stores those files in
the local backup you have specified.
When you provide the location for a backup, you can specify a network
location, such as //eastwin2k2. If you do not specify a network location, the
backup occurs on your local host.
When you specify a backup location, by default the destinations host name
and a time stamp are used to create subdirectories to store the backup files.
For example, if the destination host is eastwin2k1, and you specify a
Backup
The directory where a backup of the target file or directory can be stored.
This directory defaults to /backup. If the local host is running UNIX and the
backup directory does not already exist, then you must have root permission
to create this directory. If you are not root, an error occurs. If the /backup
directory already exists, you must have read and write permission for that
directory.
Name
It is not efficient to copy large files that contain only a small number of changes. The
Global Deploy Options section lets you perform block-level updates of large files by
comparing, block by block, the MD5 checksums of the source and destination files
and updating only those blocks where the MD5 checksums differ.
You can specify a minimum amount of available disk space on the partition
containing the destination directory. If the partition does not meet this minimum,
deployment to that host is aborted.
Note
Entering a value of 0 for any option in the Global Deploy Options section instructs
the system to ignore that option.
Field definitions
To specify block level updates, fill in both this field and Update block size.
Enter the minimum size (in kb) for a file that should invoke large file
handling. Files smaller than this value are copied in full.
To specify block level updates, fill in both this field and Min. file size.
Enter the block size (in kb) that should be used for comparison and update
purposes.
AllPreserves all source file characteristics after the file is copied to the
target location. Source file characteristics include the file's time stamp,
permissions, UID, and GID for UNIX targets. For Windows targets, source
file characteristics include time stamp and permissions. However,
Windows repeaters can only preserve the file's time stamp. No other
source file characteristics are preserved if you are deploying files via a
Windows repeater.
Timestamp onlyPreserves only the time stamp of the source file when it
is copied to the target location.
If a file being deployed exists on target servers, the file is deleted before the
job deploys a new copy of the file.
If you select this option and you select the Timestamp only option or you use
a Windows repeater to deploy files, the files that are copied to the target are
not assigned the permissions of the source file. Instead, they are assigned the
permissions of the user that the agent is impersonating. For UNIX targets, the
user is determined through a call to the setuid command. For Windows
targets, the user is determined either by Windows user mapping or user
privilege mapping. For more information on how agents impersonate users,
see BMC technical documentation at https://docs.bmc.com/docs/display/
bsa82/Impersonation+and+privilege+mapping.
After you define pre- and post-commands, they are saved to the file server as script
files. When a job runs, it uses the nexec -e command to execute the pre- and post-
commands. When you execute a pre-command, the target directory is first created (if
it does not already exist) and then the pre-command is executed in the target
directory. Post-commands are executed in the target directory.
You can create pre- and post-commands by entering commands in the text box or
importing text from a file on any managed server.
If necessary, click Zoom to open a dialog box that gives you a larger text box to
edit pre- and post-commands. When you finish editing the command, click OK.
Field definitions
Pre-command
Enter the command that you want to execute before the job begins. To import
the text of the command, click Browse and navigate to the file containing
that text.
Post-command
Enter the command that you want to execute after the job ends.
Postcommands are executed in the target directory. To import the text of the
command, click Browse and navigate to the file containing that text.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
If your system has been configured to require approval information for this
job type, select Execute on Approval and then click Browse to display the
Enter Approval Information dialog box. For more information, see File
Deploy Job Execute on approval and Approval type settings on page 788.
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see File Deploy Job Scheduling on page 787.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Snapshot Job Scheduled
Job Notifications on page 661.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
that integrate traps into your trap collection system. The MIB is located at
installDirectory/Share/BladeLogic.mib.
Indicates email notifications should list all servers on which a job has failed.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
The Approval information tab only appears when the BMC Server Automation
administrator has specified that this job type requires BMC Remedy ITSM approval
prior to execution. When approval is required, you must use this tab to select the
approval type and enter the approval parameters.
To specify an approval type, select the Execute on Approval option, and then select
an Approval type. Optionally, you can select to use an existing change ticket for
approval. The Execute on Approval field appears when you:
For more information, see Executing a job with BMC Remedy ITSM approval on
page 617.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing File Deploy Job, open the Jobs folder
and navigate to an existing job. Right-click the job and select Open from the pop-
up menu. The content editor displays a series of tabs, which are described in
the following sections:
File Deploy Job General on page 775
File Deploy Job Targets on page 777
File Deploy Job Options on page 777
File Deploy Job Advanced Options on page 783
File Deploy Job Default Notifications on page 784
File Deploy Job Schedules on page 785
These tabs correspond to panels in the New File Deploy Job wizard. Use them
to modify the job definition.
To create a Network Shell Script Job you must first add a script to the Depot. See
Adding a Network Shell script on page 549.
If a Network Shell Script Job runs a local script (that is, the script is copied to one or
more remote servers and then executed locally on those servers), you must identify a
staging directory that holds the script on each target server. To accomplish this, you
must assign a value to the STAGING_DIR property on all target servers. Only a local
script requires a staging directory. For more information see Setting values for
system object properties on page 161 and Changing property values for one or
more system objects on page 161.
Note
If a Network Shell Script Job includes BLCLI commands that read or write to a local
path (a path on the machine where the BLCLI is running), the user must have read or
write access to the path at the operating system level. Otherwise the command fails.
The "user" in this context is the operating system user, not the BMC Server
Automation user. Typically, on Windows the operating system user should have the
necessary read and write privileges.
For example, consider a Network Shell Script Job that invokes a BLCLI command
that exports an object to a specified directory. In a typical Linux setup, the BLCLI
process runs as the user bladmin. If bladmin does not have write access to the
specified directory, the command fails.
Using the Depot folder, navigate to a script that you want to deploy. Right-
click the script and select NSH Script Job from the pop-up menu.
Open the Jobs folder and navigate to the job folder where you want to create a
new Network Shell Script Job. Right-click the job folder and select New =>
NSH Script Job from the pop-up menu.
2 Provide information for the Network Shell Script Job, as described in the
following sections:
Field definitions
Name
Identifying name.
Description
Save in
NSH Script
Click Browse and navigate to the script that is the basis of this Network
Shell Script Job.
If you selected a script to begin this procedure, this field is already complete.
An information line beneath the NSH Script text box identifies the type of
script you have selected.
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Execute Asynchronously
However, note that this option is not recommended for scripts that generate
medium to large amounts of output to stdout/stderr.
Field definitions
Available Servers
Specify the operating system of the servers you want to select. To display
servers running any operating system, select All.
By Group, By Name
Select servers from a tree or sortable list by doing one of the following:
Click the By Group tab at the bottom of the window. The left panel
displays servers in a hierarchical list arranged by server group. Choose
servers by doing one of the following:
To select all servers within the group, click a server group.
Click one or more servers, if necessary, to expand server groups.
Click the By Name tab at the bottom of the window. The left panel lists
servers by name in a Group Explorer view. Sort servers in ascending or
descending order by clicking on any column header. Click one or more
servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
Click the right arrow to move your selections to the right panel.
Any values you enter on the Parameters panel override the default values that were
defined for parameters when the script was added to the Depot. This panel also lets
you choose whether parameter flags and values should be used when the job runs.
When entering a string value for a parameter, you can parameterize the string by
inserting a variable that represents a property value. When the job runs, the property
references are resolved using values defined for target servers. You can only insert
property references in this way when the script is defined to use either the
runscript or the copy and execute command (that is, you chose the first or third
script types when defining the Network Shell script). Property references cannot be
used when Network Shell scripts execute centrally against target servers because the
property references cannot be resolved for each target server.
To specify whether the job should use a flag for this parameter, click in the Flag
runtime usage column. A drop-down list appears. Select one of the following:
If the Network Shell script is defined so the job requires a flag for this parameter,
this cell is set to Required and you cannot modify the setting.
To modify the value of the parameter, double-click in the Value column for that
parameter and enter a new value.
You can only modify parameters that are defined to be editable when the
Network Shell script was created.
If you want to include a reference to a property in the parameter, enter a variable
for that property in the Value column, bracketed with double question marks
(such as ??WINDIR??/rsc). Alternatively, you can click Select Property to
find and enter the appropriate property.
To specify whether the job should use a value for this parameter, click in the
Value runtime usage column. A drop-down list appears. Select one of the following:
If the Network Shell script is defined so the job requires a value for this
parameter, this cell is set to Required and you cannot modify the setting.
If the parameter is defined so it does not accept a value, and the parameter has
never had a value associated with it, this cell is set to N/A and you cannot modify
the setting.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
If your system has been configured to require approval information for this
job type, select Execute on Approval and then click Browse to display the
Enter Approval Information dialog box. For more information, see Network
Shell Script Job Execute on approval and Approval type settings on page
799.
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Network Shell Script Job Scheduling on page 798.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Network Shell Script Job
Scheduled Job Notifications on page 797.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
The Approval information tab only appears when the BMC Server Automation
administrator has specified that this job type requires BMC Remedy ITSM approval
prior to execution. When approval is required, you must use this tab to select the
approval type and enter the approval parameters.
To specify an approval type, select the Execute on Approval option, and then select
an Approval type. Optionally, you can select to use an existing change ticket for
approval. The Execute on Approval field appears when you:
For more information, see Executing a job with BMC Remedy ITSM approval on
page 617.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing Network Shell Script Job, open the Jobs
folder and navigate to an existing job. Right-click the job and select Open from
the pop-up menu. The content editor displays a series of tabs, which are
described in the following sections:
Network Shell Script Job General on page 792
Network Shell Script Job Targets on page 794
Network Shell Script Job Parameters on page 794
Network Shell Script Job Default Notifications on page 796
Network Shell Script Job Schedules on page 796
These tabs correspond to panels in the New Network Shell Script Job wizard.
Use them to modify the job definition.
You can include any type of job in a Batch Job. You can even include other Batch
Jobs, in effect nesting Batch Jobs.
A typical Batch Job might execute the jobs necessary to provision a server with
applications and application infrastructure. Or, a Batch Job might deploy a series of
BLPackages to update a distributed application that consists of components running
on database, application, and web servers.
1 Select a job folder in the Jobs folder, right-click, and select New => Batch Job
from the pop-up menu.
The New Batch Job window and the Select Jobs to Add to Batch Job dialog box open.
2 Select the jobs to add to the Batch Job from the tree displayed in the Select Jobs to
Add to Batch Job dialog box. Click OK.
The job you added to the Batch Job appears in a list on the left of the New Batch
Job window.
Note
Selecting a Virtual Infrastructure Discovery Job as part of a Batch Job is not
supported.
To modify the definition of an individual job that is included in the batch, select
the job in the left-hand tree and use the tabs on the right to access the
information you want to change.
For information about modifying a particular job type, refer to the
documentation for that job type.
WARNING
When you modify settings for an individual job and save the Batch Job, the
settings for that individual job are also saved.
To reposition a job in the list, select the job and click Move Up or Move
Down .
To add a job to the list of jobs included in the batch, click Add Jobs . The
Select Jobs to Add to Batch Job dialog box opens. Use the dialog box to select
one or more jobs that should be included in the Batch Job and then click OK.
The jobs you select are added to the list on the left.
You cannot add, delete, or reposition jobs included in a nested Batch Job unless
you modify the definition of that nested Batch Job.
1 Select the top entry in the tree on the left. Before naming the Batch Job, the
entry is entitled New Batch Job. After naming the Batch Job, the entry is the
name of the Batch Job.
2 Using the tabs on the right, provide information for the Batch Job, as
described in the following sections:
Batch Job Options on page 805
Batch Job Default Notifications on page 807
Batch Job Schedules on page 808
Batch Job Properties on page 811
Batch Job Permissions on page 811
specify whether the Batch Job should stop if it encounters errors in one of the
individual jobs included in the batch
specify whether you want the individual jobs in the batch to execute sequentially,
in parallel, or by server
specify whether you want to enable a rolling execution of the Batch Job divided
across multiple job runs, so that each time the Batch Job runs, it executes against a
certain (user-defined) maximum number of servers
The Batch Job Options panel also lets you specify target servers. Each of the
individual jobs included in the batch can run on the target servers specified in the
definition of that job, or all of the individual jobs can run on the same set of target
servers that you specify for the entire Batch Job. When first defining and saving a
Batch Job, you do not have to specify target servers. You can specify target servers at
a later time.
If you define a Batch Job that includes other nested Batch Jobs, the settings you
define for the current Batch Job only apply to the jobs it contains. A Batch Jobs
settings do not apply to any jobs contained within nested Batch Jobs unless you
specify target servers on this panel. In that case, the specified target servers apply to
all jobs nested within the Batch Job.
Field definitions
Name
Identifying name.
Description
Save in
Continue executing batch when individual jobs return non-zero exit code
The Batch Job should continue despite individual jobs that might return an
exit code other than zero.
This option is particularly useful when you are using a Network Shell script
job to reboot a Windows server. That process typically generates errors until
the server successfully reboots.
Each individual job in the Batch Job runs against all specified targets before
moving on to the next individual job listed in the jobs list.
All the individual jobs in the Batch Job run against all targets simultaneously.
Execute by server
All the individual jobs in the Batch Job run against each target sequentially
but the Batch Job processes all targets in parallel. This option is identical to
running multiple Batch Jobs simultaneously, with each Batch Job configured
to have only one target and to execute individual jobs sequentially.
The Batch Job runs against a limited number of serversa subset consisting
of no more than the number that you specify herebefore moving on to the
next subset of servers.
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Servers/Server Groups
If all the jobs included in the batch should execute on the servers specified
in the definition of each job, select Use servers from individual jobs. This
option is not available if you chose the Execute by server option, described
above. When you select this option, you do not have to specify any servers
where the job executes.
If all the jobs should execute on the servers that you specify, select Use the
following servers for all jobs. If you select this option, click Add Servers
. The Select Servers/Groups window opens. Use it to specify the servers
or server groups where the Batch Job, including all jobs that are part of
any nested Batch Jobs, should execute.
Note
When running Batch Jobs, the system ignores job-level time-out properties set for
member jobs in the batch. Job-level time-outs only apply to a scheduled job, which
means the Batch Job itself.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
If your system has been configured to require approval information for this
job type, select Execute on Approval and then click Browse to display the
Enter Approval Information dialog box.
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job will always execute at the time you have specified. BMC
Server Automation automatically accounts for differences in time zones and changes
in daylight savings time. For example, if you schedule a job that should run weekly
at 06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
The Approval information tab only appears when the BMC Server Automation
administrator has specified that this job type requires BMC Remedy ITSM approval
prior to execution. When approval is required, you must use this tab to select the
approval type and enter the approval parameters.
To specify an approval type, select the Execute on Approval option, and then select
an Approval type. Optionally, you can select to use an existing change ticket for
approval. The Execute on Approval field appears when you:
For more information, see Executing a job with BMC Remedy ITSM approval on
page 617.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing Batch Job, open the Jobs folder and
navigate to an existing job. Right-click the job and select Open. The content
editor displays a series of tabs, which are described in the following sections:
Batch Job Options on page 805
Batch Job Default Notifications on page 807
Batch Job Schedules on page 808
These tabs correspond to panels in the New Batch Job wizard. Use them to
modify the job definition.
To modify the definition of an individual job that is included in the batch, select
the job in the left-hand tree and use the tabs on the right to access the
information you want to change.
For information about modifying a particular job type, refer to the
documentation for that job type.
WARNING
When you modify settings for an individual job and save the Batch Job, the
settings for that individual job are also saved.
To reposition a job in the list, select the job and click Move Up or Move
Down .
To add a job to the list of jobs included in the batch, click the Add Jobs.
The Select Jobs to Add to Batch Job dialog box opens. Use the dialog box to
select one or more jobs that should be included in the Batch Job and then
click OK. The jobs you select are added to the list on the left.
You cannot add, delete, or reposition jobs included in a nested Batch Job unless
you modify the definition of that nested Batch Job.
1 In the Jobs folder, navigate to the relevant Batch Job, right-click it, and select
Show Results.
The Batch Job is displayed as the root node in a hierarchical tree. All runs of the
Batch Job and their outcomes are displayed beneath the root node. Additional
nodes present the job runs for the jobs contained within the Batch Job.
2 Select the root job node or any of the job run nodes to display basic information in
tabular form on the right.
Table 6 on page 815 summarizes the effects of these settings (as defined on the
Batch Job Options panel) on the display of Batch Job results.
Mode of execution of child jobs Description of display without rolling Description of display with rolling
execution execution
Sequentially One set of child job runs directly Several nested Batch Job runs
under the Batch Job run. under the main Batch Job run.
Within the set of child jobs, times Each nested Batch Job run
of execution are unique and connects to a set of child job runs.
progressively later. Times of execution of child jobs
When you click a child job, you are unique and progressively later,
can see that the job executed both within and between child job
against all servers (in the table on sets.
the right). When you click a child job, you
can see that the job executed
against a subset of servers
(consisting of no more than the
number of servers that you
specified on the Batch Job Options
panel).
In parallel One set of child job runs directly Several nested Batch Job runs
under the Batch Job run. under the main Batch Job run.
Within the set of child jobs, times Each nested Batch Job run
of execution are all the same. connects to a set of child job runs.
When you click a child job, you Times of execution of child jobs
can see that the job executed are all the same within each set,
against all servers (in the table on but progressively later between sets.
the right). When you click a child job, you
can see that the job executed
against a subset of servers
(consisting of no more than the
number of servers that you
specified on the Batch Job Options
panel).
By server Multiple Batch Job runs nested Multiple Batch Job runs nested
under the main Batch Job run, one under the main Batch Job run, one
for each target server. Each nested for each target server. Each nested
Batch Job run connects to a set of Batch Job run connects to a set of
child job runs. child job runs.
The time of execution of the first Times of execution reveal that the
child job is the same in all sets. nested Batch Jobs are grouped
Subsequent jobs execute one after together based on the number of
the other within each set, but times maximum servers specified on the
of execution may differ between Batch Job Options panel. For an
sets. For an example, see Figure 2 example, see Figure 1 on page
on page 817. 816.
When you click a child job, you When you click a child job, you
can see that the job executed can see that the job executed
against a single server. against a single server.
Figure 1 on page 816 and Figure 2 on page 817 present examples of results for a
Batch Job running by server with and without rolling execution enabled. In this
example, the Batch Job has 5 child jobs and runs against 4 servers, and rolling
execution (if enabled) is set to 2 servers.
Run a BMC Atrium Orchestrator process remotely through the BMC Server
Automation Console as a BMC Server Automation job.
Take advantage of BMC Server Automation job features and capabilities, such as
powerful access control, flexible job scheduling, and job-related notifications.
Keep a log with details about the execution of the Workflow Job and its
underlying BMC Atrium Orchestrator process.
View a full history and results for all job runs based on the BMC Atrium
Orchestrator process, including results of any secondary BMC Server Automation
jobs called by the Workflow Job.
For more information about the integration of BMC Server Automation with BMC
Atrium Orchestrator and the creation and import of modules and processes for use
by BMC Server Automation jobs, see the BMC Atrium Orchestrator Application
Adapter for BMC BladeLogic Server Automation User Guide and the BMC Continuous
Compliance for Server Automation solution Getting Started Guide. For more information
about designing and managing workflows in BMC Atrium Orchestrator, see the
BMC Atrium Orchestrator Development Studio User Guide.
Within BMC Atrium Orchestrator, you have activated the relevant modules that
contain the processes that you plan to use in Workflow Jobs and have enabled all
the relevant adapters.
To enable the execution of another BMC Server Automation job (a child job) by the
Workflow Job, ensure that you have installed and configured the BMC Atrium
Orchestrator adapter for BMC Server Automation. For child jobs to execute
successfully, ensure that the BMC Server Automation user defined for this
adapter (typically BLAdmin) has permissions to execute any type of BMC Server
Automation job that you want executed by the Workflow Job.
You might need to further edit existing processes in BMC Atrium Orchestrator in
preparation for using them in BMC Server Automation Workflow Jobs, as
described in the following sections:
Configure the connection between BMC Server Automation and BMC Atrium
Orchestrator, as described in Setting up the connection to BMC Atrium
Orchestrator on page 838.
Perform an initial selection of the BMC Atrium Orchestrator modules that contain
the processes that you plan to use in Workflow Jobs, as described in Choosing
modules for Workflow Jobs on page 841.
Job. By default, such input parameters are passed on to the Workflow Job as string-
type input parameters.
To enable the use of the full range of BMC Server Automation input types in the
Workflow Job, as well as to organize the input parameters on Workflow Job panels,
you must modify the original process in BMC Atrium Orchestrator.
Introduce a special block of XML code into the process properties (see Defining
input parameter information through XML code on page 826).
Note
To help you choose the best method for you, note the following strengths and
weaknesses of each method for configuration of input parameters:
The method of including metadata in input parameter names is simpler and does
not require XML knowledge. However, this method affects parameter names,
which can become long and hard to read. In addition, this method does not grant
you full control over the order in which parameters are displayed on Workflow
Job panels.
specify allowed job types for limiting Job or List_Job parameter values.
During the transfer of input parameters from the BMC Atrium Orchestrator process
to the BMC Server Automation Workflow Job, the XML option takes precedence
over the parameter naming option.
they include metadata that can be used by the Workflow Job. Use the naming
guidelines described here also for any subsequent input parameters that you may
decide to add to the process.
2 For each input parameter that you want to modify, double-click in the Input
Parameter Name column and modify the name of the input parameter in the
following manner:
b Add the data type before the existing parameter name and connect it with an
underscore character. For a list of data types, see Data types for input
parameters of a Workflow Job on page 834.
c Add any of the optional elements described in Table 7 on page 822 after the
parameter name. Connect all elements with the underscore character. If the
optional element requires a value (this is true for all elements except required),
separate the value from the name of the element with a space.
group The name of a box on the Workflow The following two parametersUser Name and
Job panel in which to include the Passwordare displayed in the Login Info box
parameter. on the Workflow Job panel:
page The name of the Workflow Job The following parameters are divided across two
panel on which to include the pagesfive parameters in two boxes (groups) on
parameter. one page, and two parameters on another page:
By defining pages, you can split the
single Workflow Input Parameters string_Name_group Login Info_page AR Info
panel (displayed during creation of
a Workflow Job) or tab (displayed password_Password_group Login Info_page
when editing a Workflow Job) into AR Info
multiple panels or tabs. However,
the relative order of these pages xml_Change_group Change Info_page AR
cannot be guaranteed. Info
a If you specify an invalid default value for a Boolean type parameter, a value of false is used instead.
Similarly, if you specify an invalid default value for a numeric parameter, a value of 0 is used instead.
If you specify an invalid default target server, the corresponding field on the Workflow Job panel
displays invalid default value (and you should choose a different value during job configuration).
3 When you have finished modifying the names of all relevant input parameters,
click OK to save the input parameters.
Note
Any input parameters that you do not modify will continue to be passed on to the
BMC Server Automation Workflow Job as a string-type input parameters, with no
control over their order or relative location on the Workflow Job panels. This is
true also for any parameters for which your modifications do not properly follow
the rules for adding metadata.
Figure 3 on page 824 displays the defined parameters in the BMC Atrium
Orchestrator Development Studio, and Figure 4 on page 825 presents the resulting
panels in the Workflow Job wizard.
1 Use any text editor to create XML code that contains the definitions of all process
input parameters and how they are to be organized on panels during the creation
of the Workflow Job (or on tabs during the editing of the Workflow Job) in BMC
Server Automation.
If you want to validate your XML code against its schema after you have finished
authoring it, you can find a copy of the WorkflowDefinition.xsd in Copy of
WorkflowDefinition.xsd for XML validation on page 832.
For full details about this XML code, see XML code for workflow definitions on
page 827.
3 Paste your XML text into the Description field (replacing any text that might
already be there), and then click OK.
This XML code must adhere to the WorkflowDefinition.xsd XML schema, of which
a copy is provided here in Copy of WorkflowDefinition.xsd for XML validation on
page 832.
Note
Your XML code must include all input parameters that have already been defined
through the Start activity of the BMC Atrium Orchestrator process. If you leave out
any defined input parameter, misspell the name of an input parameter, or if the XML
code is invalid for any other reason, the XML code will not be implemented, and the
input parameters will be passed on to the BMC Server Automation Workflow Job as
string-type input parameters (in accordance with the default).
Basic elements
You define your workflow using a single workflow root element. Within the
workflow, you can define one or more of each of the basic elements described in
Table 8 on page 827:
page Panel in the wizard for creating the Workflow Job or tab for editing the
Workflow Job
group Box that groups parameters on the panel or tab
parameter Input parameter field, either grouped in a box or standing on its own on the
panel or tab
All defined elements are created according to the order in which they appear in your
XML code.
The following example XML code highlights the basic elements (with all other
subordinate nodes collapsed). This example presents one page with two parameters
enclosed within a group and a third parameter standing on its own.
<workflow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="./WorkflowDefinition.xsd">
<page name="pageName1">
<group name="groupName1">
<parameter name="parameterName1"...>
</parameter>
<parameter name="parameterName2"...>
</parameter>
</group>
<parameter name="parameterName3"...>
</parameter>
</page>
</workflow>
Note
The XSD definition within the <workflow> tag is necessary only for the validation of
the XML code after you finish authoring it.
Table 9 on page 828 lists the parameter attributes that you can include for each
parameter that you define in your XML code.
name The name of the parameter. The label of the input parameter
field, if no prompt attribute was
defined.
description An optional description for the Text in the tooltip displayed when
parameter. you hover over the parameter field.
prompt An optional alias for the The label of the input parameter
parameter name. field (overriding the name
attribute).
isRequired An indication of whether input for If input for the parameter is
the parameter is required or required, the label for the input
optional (either true or false). parameter field appears in bold
The default (if you do not include characters and you cannot leave
this attribute) is false (that is, the panel until you enter a value.
parameter input not required).
type The type of data accepted by the The data type determines the type
parameter. of field displayed for the
parameter and the allowed input
that you can enter.
For a list of data types, see Data
types for input parameters of a
Workflow Job on page 834.
defaultValue element with An optional element for specifying The default value that appears
value attribute the default value of the parameter. within the input parameter field.
a
For list-type parameters, multiple
value attributes can be used.
Do not use this element with the
job, list_job, or serverGroup
data type.
possibleValues element with A required element for Values in the closed list displayed
value attribute enumeration-type parameters. in the input parameter field for
One or more value attributes enumeration-type data.
within this element specify the
values in the closed list.
allowedJobTypes element with An optional element for job or Filters the jobs displayed when
jobType attribute list_job parameters, that limits you browse existing jobs.
the range of job types. One or
more jobType attributes within
this element specify the allowed
job types.
a If you specify an invalid default value for a Boolean type parameter, a value of false is used instead.
Similarly, if you specify an invalid default value for a numeric parameter, a value of 0 is used instead.
If you specify an invalid default target server, the corresponding field on the Workflow Job panel
displays invalid default value (and you should choose a different value during job configuration).
The first page, named AR System info, contains two groups of parameters, Login
info and Change info, as well as another stand-alone parameter. The second page,
named BladeLogic Job info, contains a job parameter and a list_target parameter.
Figure 3 on page 824 and Figure 4 on page 825 display the resulting panels displayed
during configuration of the Workflow Job.
<workflow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="./WorkflowDefinition.xsd">
<page name="AR System info">
<group name="Login info">
<parameter name="Username" type="string" isRequired="true">
<defaultValue>
<value>ARAdmin</value>
</defaultValue>
</parameter>
<parameter name="Password" type="password" isRequired="true"/>
</group>
<group name="Change info">
<parameter name="chgDesc" description="Describe, in a few words,
the function of the Bladelogic Job you want to execute" prompt="Description
of Change" type="xml"/>
<parameter name="Impact" type="enum">
<possibleValues>
<value>Low</value>
<value>Medium</value>
<value>High</value>
</possibleValues>
<defaultValue>
<value>Medium</value>
</defaultValue>
</parameter>
<parameter name="Risk level" type="numeric">
<defaultValue>
<value>1</value>
</defaultValue>
</parameter>
<parameter name="Urgency" type="enum">
<possibleValues>
<value>Low</value>
<value>Medium</value>
<value>High</value>
</possibleValues>
<defaultValue>
<value>Medium</value>
</defaultValue>
</parameter>
</group>
<parameter name="Approval type" type="enum" isRequired="true">
<possibleValues>
<value>Manual</value>
<value>Automatic</value>
<value>Emergency</value>
</possibleValues>
<defaultValue>
<value>Manual</value>
</defaultValue>
</parameter>
</page>
<page name="Bladelogic Job info">
<parameter name="Job to execute" type="job" isRequired="true">
<allowedJobTypes>
<jobType>Audit Job</jobType>
<jobType>Snapshot Job</jobType>
</allowedJobTypes>
</parameter>
<parameter name="Target servers" type="list_target" isRequired="true"/
>
<parameter description="internal parameter for transfer of Workflow
Job ID to the child job" type="job_run_id"/>
</page>
</workflow>
<xs:complexType name="parameter">
<xs:all>
<xs:element name="defaultValue" type="defaultValue"
maxOccurs="1" />
<xs:simpleType name="dataType">
<xs:restriction base="xs:string">
<xs:enumeration value="string" />
<xs:enumeration value="numeric" />
<xs:enumeration value="boolean" />
<xs:enumeration value="datetime" />
<xs:enumeration value="password" />
<xs:enumeration value="file" />
<xs:enumeration value="directory" />
<xs:enumeration value="job" />
<xs:enumeration value="target" />
<xs:enumeration value="serverGroup" />
<xs:enumeration value="enum" />
<xs:enumeration value="xml" />
<xs:enumeration value="jobRunId" />
<xs:enumeration value="list_string" />
<xs:enumeration value="list_numeric" />
<xs:enumeration value="list_boolean" />
<xs:simpleType name="jobType">
<xs:restriction base="xs:string">
<xs:enumeration value="ACL Push Job" />
<xs:enumeration value="Audit Job" />
<xs:enumeration value="Batch Job" />
<xs:enumeration value="BL Package Deploy Job" />
<xs:enumeration value="Compliance Job" />
<xs:enumeration value="Component Discovery Job" />
<xs:enumeration value="Deregister Configuration Objects Job" />
<xs:enumeration value="Distribute Configuration Objects Job" />
<xs:enumeration value="File Deploy Job" />
<xs:enumeration value="NSH Script Job" />
<xs:enumeration value="Solaris Patching Job" />
<xs:enumeration value="AIX Patching Job" />
<xs:enumeration value="Windows Patching Job" />
<xs:enumeration value="RedHat Linux Patching Job" />
<xs:enumeration value="Oracle Enterprise Linux Patching Job" />
<xs:enumeration value="SuSE Linux Patching Job" />
<xs:enumeration value="Provision Job" />
<xs:enumeration value="UCS Provision Job" />
<xs:enumeration value="Snapshot Job" />
<xs:enumeration value="Software Deploy Job" />
<xs:enumeration value="Update Server Properties Job" />
<xs:enumeration value="Upgrade Model Objects Job" />
<xs:enumeration value="VSM Discovery Job" />
<xs:enumeration value="Virtual Guest Job" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="defaultValue">
<xs:all>
<xs:element name="value" type="xs:string" minOccurs="1" />
</xs:all>
</xs:complexType>
<xs:complexType name="allowedJobTypes">
<xs:all>
<xs:element name="jobType" type="jobType" minOccurs="1" />
</xs:all>
</xs:complexType>
</xs:complexType>
</xs:complexType>
</xs:schema>
Table 10 on page 834 lists the available data types. Figure 3 on page 824 and Figure
8 on page 837 show the fields that are displayed in the Workflow Job wizard
panels to represent these data types.
a
Data type for a single value Data type for multiple values Description of value
a
Data type for a single value Data type for multiple values Description of value
a
Data type for a single value Data type for multiple values Description of value
a List types are returned to the BMC Atrium Orchestrator process with commas separating between values.
For example, inclusion of any of the following BLCLI commands in the original BMC
Atrium Orchestrator process will affect the execution results of your Workflow Job:
For more information about Workflow Job results and how these BLCLI commands
affect them, see Viewing Workflow Job results and logs on page 851.
For a full list of the BLCLI commands that are related to Workflow Jobs and details
about the required arguments for each command, see the BLCLI help.
To fully enable the integration, you must set up the connection with BMC Atrium
Orchestrator through the BMC Server Automation Console. If you want secure data
communication between the products, you must also enable an HTTPS connection
on both products.
Ensure that your role is granted the AOConfig.* and the AutomationPrincipal.*
authorizations.
Parameter Description
Host The IP address or fully-qualified host name of the BMC Atrium Orchestrator CDP
server.
Port The port number used to connect to the BMC Atrium Orchestrator CDP.
Grid Name The name defined for the BMC Atrium Orchestrator grid.
Specify the name of a grid only if this is the first defined CDP connection. For any
additional CDP connection (see Step 4 on page 839), this field is read-only, as all
defined connections must be on the same grid.
User Name The name of the BMC Atrium Orchestrator user used to log on to the CDP. This
user must be associated with the ADMIN role in BMC Atrium Orchestrator.
Password The BMC Atrium Orchestrator password used to log on to the CDP.
Time-out The amount of time, in seconds, before a BMC Server Automation job that connects
to BMC Atrium Orchestrator times out. The default is 300 seconds (five minutes).
SSL enabled? Whether the connection to the CDP is SSL enabled and based on an HTTPS
connection (as described in Enabling HTTPS support for the AO connection on
page 840).
If you want to test whether or not you can connect to the CDP with the host, port,
grid name, user name, and password details that you specified, click Check
Connection.
If you define multiple BMC Atrium Orchestrator CDP instances, ensure that only
one of your CDPs is set as the primary instance (using the Primary AO check box).
1 On the system where the BMC Atrium Orchestrator CDP is installed, create the
keystore file by entering a command such as the following example:
keytool -genkey -alias w2k3-sp-vm5 -dname "cn=w2k3-sp-vm5" -keyalg RSA
-keystore C:\.keystore -storepass changeit
The value entered for the -dname option must match the host name where the
BMC Atrium Orchestrator CDP is installed. In this example, the value is w2k3-sp-
vm5.
The keystoreFile attribute points to the location where the keystore file
resides and the truststoreFile attribute points to the CA issued certs in the
JDK installation location.
2 On the system where the BMC Server Automation Application Server is installed,
export the public certificate from the keystore file which was generated for BMC
Atrium Orchestrator to a temporary file by entering a command such as the
following example:
keytool -export -alias w2k3-sp-vm5 -file C:\cert.csr
-keystore C:\.keystore -storepass changeit
file is the name and location of the certificate file that is going to be created from
this command.
keystore is the keystore file name and location that you created for BMC Atrium
Orchestrator.
3 Add the public certificate from the temporary file to the trusted certificate file by
entering a command such as the following example:
keytool -import -alias w2k3-sp-vm5 -file C:\cert.csr
-keystore "C:\Program Files\BMC Software\BladeLogic\NSH\jre\lib\security
\cacerts"
-keypass changeit
4 Enter the following command to check whether the certificate was added to the
cacerts file:
keytool -list
-keystore C:\Program Files\BMC Software\BladeLogic\NSH\jre\lib\security
\cacerts
This filtering task limits your subsequent choice of BMC Atrium Orchestrator
processes during the creation of Workflow Jobs to the relevant processes that are
contained within the selected BMC Atrium Orchestrator modules.
For best performance during this procedure, keep the BMC Atrium Orchestrator
processes that you expect to use in Workflow Jobs grouped in a minimum number
of BMC Atrium Orchestrator modules (ideally one or two).
2 From the list of active BMC Atrium Orchestrator modules on the Workflow Job
Configuration dialog box, select the modules that contain processes that you want
available for selection in Workflow Jobs.
Note
If the list is empty or you do not see certain modules that you are interested in,
activate the relevant modules through BMC Atrium Orchestrator.
3 Click OK.
For information about managing and organizing jobs, as well as performing other
actions such as deleting jobs, see Managing jobs on page 605.
Ensure that your role is granted, at the minimum, the WorkflowJob.Read and
WorkflowJob.Create authorizations.
1 In the Jobs folder, right-click a job folder and select New => Workflow Job.
2 Define the Workflow Job through the wizard panels, as described in the following
sections:
Note
The Workflow Input Parameters panel is not displayed if no input parameters
have been defined in the associated BMC Atrium Orchestrator process.
Name
Description
Save in
Identify the job folder where you want to store this job. Click Browse , and
then select a folder in the Select Folder dialog box and click OK. If necessary,
you can create a new folder during this process by clicking Create New
Folder .
Note
The additional AO Process Name field appears when modifying an existing
Workflow Job. This field is read-only, as you cannot change the BMC Atrium
Orchestrator process associated with an existing job.
Navigate the hierarchical tree of modules. Expand the relevant module and
(possibly) the relevant directory, and select the process on which you want to base
your Workflow Job.
Note
If you cannot find the module that you are interested in, ensure that you have
selected the module as described in Choosing modules for Workflow Jobs on page
841.
For each parameter, enter or select (as relevant for the specific parameter type) a
value for the parameter.
For a list-type parameter, use the Add and Delete icons to create a list of
multiple parameter values, and the Move Up and Move Down icons to
organize the values in the list.
Note
For the value of an XML parameter, you are limited to 2000 characters of XML code.
If an invalid default value was defined for a field that requires you to specify a target
server, the field displays invalid default value instead of the default value. Simply
specify a valid target server. To correct the issue for future configuration of the job,
define a valid default value for the field as described in Configuring input
parameters in a process on page 820.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
When scheduling a job, you can perform any of the following tasks:
If your system has been configured to require approval information for this
job type, select Execute on Approval and then click Browse to display the
Enter Appoval Information dialog. For more information, see Workflow Job
Execute on approval and Approval type settings on page 847.
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Workflow Job Scheduling on page 847.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Workflow Job Scheduled
Job Notifications on page 846.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
that integrate traps into your trap collection system. The MIB is located at
installDirectory/Share/BladeLogic.mib.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
The Approval information tab only appears when the BMC Server Automation
administrator has specified that this job type requires BMC Remedy ITSM approval
prior to execution. When approval is required, you must use this tab to select the
approval type and enter the approval parameters.
To specify an approval type, select the Execute on Approval option, and then select
an Approval type. Optionally, you can select to use an existing change ticket for
approval. The Execute on Approval field appears when you:
For more information, see Executing a job with BMC Remedy ITSM approval on
page 617.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing Workflow Job, open the Jobs folder and
navigate to an existing job. Right-click the job and select Open from the pop-up
menu. The content editor displays a series of tabs, which are described in the
following sections:
These tabs correspond to panels in the New Workflow Job wizard. Use them to
modify the job definition.
Note
You cannot change the associated BMC Atrium Orchestrator process. A read-
only field on the General tab displays the name of the process with which the
job is associated.
An existing Workflow Job does not get updated automatically if its associated
process is modified in BMC Atrium Orchestrator. In such a case, you will have
to create a new Workflow Job for the modified process.
Multiple Workflow Input Parameters tabs may exist, and they may have
different names, as specified within the properties of the original BMC Atrium
Orchestrator process. For more information, see Configuring input parameters
in a process on page 820.
Warning messages about invalid input parameter values are displayed when
you open the Workflow Job if values that you defined during the creation of
the job for targets, server groups, or jobs have since become obsolete.
1 In the Jobs folder, navigate to the relevant Workflow job, right-click it, and select
Show Results.
All runs of the job and their outcome are displayed beneath the job.
If the Workflow Job invoked the execution of a child job using the
executeWorkflowChildJob or executeWorkflowChildJobId BLCLI command, an
additional job run node for the child job is displayed below (and hierarchically
subordinate to) each Workflow Job run. Additional information displayed for the
child job depends on its job type. For more information about the inclusion of
these BLCLI commands in BMC Atrium Orchestrator processes, see BLCLI
commands for inclusion in a process on page 837.
2 Select the root job node or any of the job run nodes to display basic information in
tabular form on the right.
1 Select a job run in the display of Workflow Job results, right-click, and select
Show Log.
Note
Besides the log messages issued by the BMC Server Automation Workflow Job,
the log may include messages issued by the BMC Atrium Orchestrator process if
you included the updateWorkflowJobRunLog BLCLI command in the associated
BMC Atrium Orchestrator process. For more information about the inclusion of
this BLCLI command in BMC Atrium Orchestrator processes, see BLCLI
commands for inclusion in a process on page 837.
Other messages may be returned from BMC Atrium Orchestrator to the
Workflow Job run log. These may include, for example, messages about process
termination due to unexpected issues or after you cancel or abort an executing
Workflow Job through the Tasks in Progress view.
BMC Server Automation provides IT Operators with essential tools for the
management of the virtual environment and on-demand deployment of virtual
assets. With BMC Server Automation, you have the ability to:
quickly replicate and deploy new virtual systems using an existing virtual system
as a template, or using a repeatable process (using the Virtual Guest Package and
Virtual Guest Job).
See Deploying assets to the virtual infrastructure on page 861.
discover and register what is in the virtual infrastructure (using the with Virtual
Infrastructure Discovery Job).
See Discovering and registering assets in a virtual environment on page 895.
perform ad hoc management tasks (turn virtual systems/ host servers on or off,
and so on) from the BMC Server Automation console.
See Managing virtual environments on page 901.
manage virtualization sprawl (ability to discover Virtual Machines that are not
registered in the vCenter and move those unregistered virtual machines to a
vCenter server that you specify).
See Managing virtualization sprawl on page 928.
Note
The BMC Server Automation administrator must install and configure the virtual
environment. For more information, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Home.
Table 11 on page 854 lists the types of BMC Server Automation console
management tasks you can perform in each supported virtual environment.
VMware vSphere
Live Browse a virtual node inventory (vCenter, virtual host, and virtual
machine)
Solaris Zones
Live Browse a virtual node inventory (nonglobal zone, projects and resource
pools)
IBM PowerVM
Live Browse a virtual node inventory (LPARs, VIO servers, pools)
Hyper-V
Live Browse for virtual node inventory (clusters, host, and virtual machine)
Red Hat Enterprise BMC Server Automation supports both Red Hat Enterprise Virtualization
Virtualization platforms, Red Hat KVM and Red Hat Enterprise Virtualization Manager for
Servers (RHEV Manager).
Deploy for RHEV virtual guest configurations (modify memory, CPU, add
new disk or NIC to a virtual machine)
Citrix XenServer
Live Browse a virtual node inventory (hosts, virtual machines, custom
templates, XenServer templates, pools, storage repositories)
Note
The BMC Server Automation administrator must install and configure the virtual
environment. For more information, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Home.
Note
To live browse a virtual node inventory, you must log on as a user whose role has
the following additional authorizations:
PropertyInstance.Read authorization
Connection PropertyInstance.Read
Clusters: Shows all the clusters in the vCenter and lists the
resource pools and hosts under each cluster.This view includes
configuration information about the clusters created in the
vCenter server, server properties, and status.
Hosts: Shows all hosts in the vCenter and under each host shows
virtual machines, resource pools present, and the host
configuration of each ESX host.
LPAR List: Lists all the LPARs in the frame, with an indication of
each LPARs state. You can browse each LPAR to view
information about its hardware, options, profiles, and settings.
VIO Servers: Lists all the VIO servers in the frame, with an
indication of each VIO servers state. You can browse each VIO
server to view information about its adapter mapping, hardware,
options, profiles, and settings.
Hosts: Shows all the hosts configured under the VMM, and their
Properties.
Red Hat BMC Server Automation supports both Red Hat Enterprise Virtualization platforms, Red
Enterprise Hat KVM and Red Hat Enterprise Virtualization Manager for Servers (RHEV Manager).
Virtualization
RHEL KVM
Networks: Lists each network connected to the host server.
Storage Pools: Lists all of the storage pools available to this host.
RHEV Manager
Clusters: Shows all the clusters in the RHEV Manager. This
includes configuration information about the clusters created in
the RHEV Manager. The Clusters node also includes:
Hosts: Shows all the hosts configured under the RHEV Manager,
and their Properties.
However, using a BLPackage and Deploy Job, or Virtual Guest Package (VGP) and
Virtual Guest Job (VGJ) provides a repeatable process for creating new virtual
systems according to a specific configuration that you define or from a template.
As a virtual infrastructure administrator, you may have requests for new virtual
machines. Depending on the request, you can create the new virtual machine and
add it to the host server in any of the following ways:
Base the new machine on the characteristics of an existing virtual machine. See
Deploying virtual systems based on existing virtual systems on page 863.
Create a VGP that describes the new virtual machine you want to add. For
example, you can base the VGP on a VMware vCenter template, or create the VGP
using values of your own, if you do not have an existing machine or template on
which to base the configuration. See Deploying virtual systems using a Virtual
Guest Package on page 868.
After you have built the new virtual machine, you can apply compliance checks to it
to ensure that it was built according to policy.
The VGP and VGJ are available for the following virtualization environments:
This approach is useful when you have an existing VM that represents the standard
configuration for a specific use, such as the typical system for a developer, and you
want to clone that system for future use. This system may be a high-end system with
four CPU and 8 GB RAM, for example. You would create a BLPackage based on this
system, and could deploy it whenever a new developer was hired.
1 In the Servers folder, navigate to a host server (for vCenter server, Solaris global
zone, or RedHat KVM host server) or agentless managed object (for IBM and
Citrix XenServer) and expand the Live node.
Expand the VMware vCenter Server server object type and then expand the
Virtual Machines node.
Expand the IBM Configuration server object type and then expand the LPARs
node.
Expand the Global Zone server object type and then expand the non-global
zones node.
Expand the RHEV Manager server object type and then expand the Virtual
Machines node.
Expand the RHEL KVM server object type and then expand the Domains node.
Expand the Citrix XenServer server object type and then browse to the host
node on which the virtual machine is located.
Expand the Microsoft VMM server object type and then browse to the host
node on which the virtual machine is located.
In the case of Citrix XenServer, you can clone only those VMs which are in the
Halted state.
Panel Selection
Select Server Objects Click the name of the virtual system on which you are basing the BLPackage.
For more information about filling out the wizard panels, see Adding a
BLPackage to the Depot on page 509.
5 Edit the BLPackage to describe the new virtual system you want to create:
a In the Depot folder, navigate to the depot folder holding the BLPackage you
just created.
b On the Objects tab of the contents pane, right-click the BLPackage you want to
edit and select Open. A new tab with the name of the selected BLPackage
appears.
c Edit the BLPackage to describe the new virtual system. For example, for
VMware, you can specify other machine characteristics, such as Virtual
Ethernet Adapter Type.
a Open the Depot folder and navigate to the BLPackage you just edited. Right-
click the package and select Deploy from the pop-up menu. The New Deploy
Job wizard opens.
b Fill out the wizard panels as described in Creating a Deploy Job on page 718.
In addition to whatever other Deploy Job options you choose, make sure you
select a host server (vCenter server, IBM frame, Solaris global zone, Citrix
XenServer, Microsoft VMM host, or RedHat KVM host) as the target on the
Targets panel.
Note
The IBM frame and the Citrix XenServer are represented by an agentless
managed object. Note that the Single-User Mode deploy options (Single-user
mode without reboot/shutdown and Reboot/shutdown into single-user
mode) of an BLPackage are not supported for agentless managed objects.
Targets must match the environment where you first created the BLPackage
that defines the new virtual system. For example, if you started by basing a
BLPackage on a virtual machine that resided on a vCenter server, then your
target must be a vCenter server.
7 When the Deploy Job run completes, return to the Servers folder, navigate to the
host server and expand the Live node.
8 Expand the top-level server object type (for example, the VMware vCenter server
object type) and then expand the appropriate child node for your virtual
environment. You should see the new virtual system you just added.
VMware vSphere In addition to whatever other BLPackage options you choose, make sure to
include the following selections:
Options > General: Set the value of each of the following options
according to a new, unique name for the new Virtual Machine.
Name
Configuration file
Snapshot directory
Log Directory
Suspended directory
Resources > ResourcePool: If you do not want to put this new machine
into any resource pool, set the (case sensitive) value to: Root Pool
If you want to put this new machine into a resource pool, for example
RP2, set the (case sensitive) value to: Root Pool/RP2
Server Properties:
You must specify the location of the new virtual system in the virtual
infrastructure hierarchy. To do this, provide values for the following
properties:
ParentCluster (if applicable)
ParentDatacenter
ParentHost
Make sure these values are correctyou may want to look them up (for
example, using LiveBrowse of the server) before setting them here.
IBM PowerVM If there are two or more adapters (physical or virtual) in the profile, you can
delete an adapter from the list using a BLPackage Deploy Job. However, if
there is only one adapter shown in the list, you cannot delete it.
Note that the Single-User Mode deploy options (Single-user mode without
reboot/shutdown and Reboot/shutdown into single-user mode) of an
BLPackage are not supported for agentless managed objects.
Solaris Zones In addition to whatever other BLPackage options you choose, make sure to
set the Zone Path value to a new, unique name for the new non-global zone.
Red Hat Enterprise You can perform the following operations on a virtual guest using a BLPackage:
Virtualization
Modify CPU
Modify RAM
Add disk (to modify a disk, you must first delete the disk and then add
the modification as a new disk)
Add NIC (to modify a disk, you must first delete the NIC and then add
the modification as a new NIC)
Citrix XenServer Note the following considerations when creating a BLPackage that is based
on an existing virtual machine:
Microsoft Hyper-V You can perform the following operations on a virtual machine using a
BLPackage:
Modify CPU
Modify RAM
Modify the power state (power state modification is supported only for
VMs in the Running and Stopped states)
Note
Deploying virtual assets using a BLpackage is supported only for the virtual
assets in the list below. If you attempt to deploy any other node or asset (where
the root node is not one of the assets listed below), the job will fail, and the
following message is written to the job log: PreCondition check failed.
VMware vSphere: Virtual machine and all its child nodes, ESX host memory,
networking, advanced settings, DNS and routing, and security profiles
IBM PowerVM:
VIO and all its child nodes, except the adapter mappings and physical IO
child nodes
HyperV: Virtual Machine asset (for Power Status), Virtual Machine CPU, and
Virtual Machine Memory, disk, and NIC
Red Hat Enterprise Virtualization: RHEL virtual machine and all its child
nodes, except the display node
This list is for assets that are deployable using a BLpackage. Deploy for some
other virtual assets are supported using a Virtual Guest Package and a Virtual
Guest Job.
For example, you can base the VGP on an existing VMware vCenter template, or
create the VGP using values of your own, if you do not have an existing machine or
template on which to base the configuration. Having a base package from which to
deploy new Virtual Machines helps enforce consistency and standards, such as
including Antivirus and management software on any new virtual machine.
Automation supports on all operating systems. This capability allows you to create
multiple VGPs, each designed and tailored for a specific use. For example, you can
create one VGP that defines a VM for an development SQL server, while another can
be tailored for use by QA as a web server.
For VMware, Microsoft Hyper-V, IBM, Solaris, Citrix XenServer, and Red Hat
Enterprise Virtualization environments, you can create the VGP manually, as
described in To create the Virtual Guest Package manually on page 869.
Best practice
If you are creating a VGP that includes VMware virtual disk files, note that these
files can be extremely largeoften measured in gigabytes. Make certain your file
server has sufficient disk space. Take care not to create unnecessary copies of
these VGPs. Packaging a virtual machine or any of its storage information will not
include the associated disk files in the package. Only the storage configuration
information will be included in the VGP.
1 From the Depot folder, right-click the depot folder where you want to add the
VGP. From the pop-up menu, select New > Virtual Guest Package and then the
virtualization platform type for the package (VMware, Microsoft Hyper-V, IBM,
Solaris, Red Hat KVM, Citrix XenServer, RHEV).
Field Description
Field Description
Member of Browse to the folder in the Depot where you want the VGP to be created.
Field Description
3 Select the template from the displayed list, and click OK.
For IBM, choose the partition type for which to configure the
package and create the new partition. Choose AIX or Linux
Partition to create an LPAR or VIOS Partition to create a VIO
server partition, used for I/O resource sharing for the frame.
For Solaris, choose Non Global Zone to configure the package and
create a non-global zone.
For Red Hat KVM, choose RedHat KVM Domain to configure the
package and create a new domain.
Field Description
VMware VC Template Browse to the location of a template on which this VGP will be based.
(VMware only)
Template Name (RHEV/ HyperV Browse to the location of a template on which this VGP will be based.
only)
3 Click Next.
The Permissions panel is an access control list granting roles access to this VGP.
Access to all objects, including the sharing of objects between roles, is controlled
through ACLs. See Virtual Guest Package permissions on page 872 to ensure
that your role has the required permissions to create a VGP for a specific platform.
A dialog box appears, indicating that the package is being saved to the Depot.
After the VGP is saved, you may want to use the Virtual Guest Package editor to
modify the VGP. See Editing a Virtual Guest Package on page 876.
The following table lists the permissions required to create a VGP for each of the
supported platforms.
The Virtual Guest Template Enrollment Job discovers all OS templates on the virtual
entity managers that you specify, creates Virtual Guest Package for the discovered
templates, and stores them in the Depot folder that you specify.
This job creates a VGP for any new template that it finds on the target. It does not
update or delete any existing VGPs based on changes in the template on the target.
The job creates one VGP for each unique template name, even if that template
exists on multiple targets. The job uses the template name to create the name of
the VGP (not applicable for Microsoft Hyper-V environments).
To create a VGP manually, see Deploying virtual systems using a Virtual Guest
Package on page 868.
Can configure OS level default values for the VGPs, such as license keys, domains,
administrator passwords, and so on. The values are then used when the job
creates the VGPs.
Ensure that you have created the Depot folders in which you want to store the VGPs.
1 From the Jobs folder, right-click the folder where you want to add the VGP. From
the pop-up menu, select New > Virtual Guest Template Enrollment Job.
2 Define the parameters for the Virtual Guest Template Enrollment Job, as
described in the following sections:
3 Optionally, click Next to display the following panels and specify options.
5 After the job has completed, right-click the job and select Show Results.
The job lists the results of the template discovery by target. It provides warnings
if it finds templates that have the same name but are different OS types, to warn
you about configuration errors in the setup.
The job displays a filtered list of targets for which template-based provisioning is
applicable.
After the VGP is created, you may want to use the Virtual Guest Package editor to
modify the VGP. See Editing a Virtual Guest Package on page 876.
Creating default configuration settings for Virtual Guest Packages
For VMware, Microsoft Hyper-V, Citrix XenServer, and RHEV Manager platforms,
you can set operating system defaults that will be used for the Virtual Guest
Packages that are created by the Virtual Guest Template Enrollment Job.
For example, you might create a default Windows Server 2003 configuration to set
license keys for the VGPs that are created for templates that are discovered on
Windows Server 2003 systems.
This procedure applies to VMware, Microsoft Hyper-V, Citrix XenServer, and RHEV
Manager environments.
2 Click Add .
3 Under Operating System Type, click the operating system for this default
configuration.
4 Provide information for the fields on the window. (Fields displayed in the
window depend on the operating system type you selected.) For information, see
Add Customization Information window on page 875.
Required fields
User Name - Enter the user name for the virtual machine.
License Key - Enter the key to the OS license you are using, including all
hyphens in the key.
Optional fields
Workgroup - Enter the name of the workgroup to which you want to add
the virtual machine.
Windows Server Domain - Enter the name of the domain to which you
want to add the virtual machine.
Domain User Name - Enter the name of the user account for the domain.
Password and Confirm Password - Enter the users password, and then
enter it again in the Confirm Password field
Time Zone - Select the time zone for the virtual machine from the drop-
down list.
Locale - Select the locale for the virtual machine from the drop-down list.
Depending on the Virtual Guest Type, you will see different configuration panels in
the package editor.
2 In the content editor, navigate to any of the tabs, based on the virtualization
platforms, and review or edit the settings. These settings enable you to use the
VGP as base, and then customize the options to suit your needs for the new
virtual system.
The settings on the tabs are very similar to the options you specify when
completing the Virtual Guest Job for a specific environment. For information
about these options, see:
The Virtual Guest Package Job Creation Wizard performs a validation check for the
target server. If the agent is not properly configured with the correct configuration
objects, then the job does not execute.
You can create a Virtual Guest Job for any of the following virtualization platforms:
VMware
IBM AIX
Solaris zones
Citrix XenServer
Microsoft Hyper-V
Note
To deploy new virtual systems, BMC Server Automation recommends that you have
administrator privileges on the host server to which you are deploying the virtual
system.
Right-click the Job folder and select New > Virtual Guest Job from the pop-up
menu.
Right-click the Virtual Guest Package from the Depot and select Deploy
Virtual Guest from the pop-up menu.
2 Define the Virtual Guest Job appropriate for your virtualization environment, as
described in the following sections:
Creating a Virtual Guest Job for RedHat KVM environments on page 881
Creating a Virtual Guest Job for Citrix XenServer environments on page 884
3 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
You can create a Virtual Guest Job to deploy a virtual guest machine to a target
vCenter server.
WARNING
To deploy virtual machines, BMC Server Automation recommends that you have
administrator privileges on the vCenter server to which you are deploying the new
virtual machine.
Right-click the Job folder and select New > Virtual Guest Job from the pop-up
menu.
Right-click the VGP from the Depot and select Deploy Virtual Guest from the
pop-up menu.
2 Define the description of the Virtual Guest Job and select the appropriate VGP, as
described in the following sections:
If you have chosen to customize the operating system for the new virtual guest,
the following panels are also displayed:
4 Optionally, click Next to display the following panels and specify options.
5 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
Right-click the Job folder and select New > Virtual Guest Job from the pop-up
menu.
Right-click the VGP from the Depot and select Deploy Virtual Guest from the
pop-up menu.
2 Define the description of the Virtual Guest Job and select the appropriate VGP, as
described in the following sections:
4 Optionally, click Next to display the following panels and specify options.
5 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
Right-click the Job folder and select New > Virtual Guest Job from the pop-up
menu.
Right-click the VGP from the Depot and select Deploy Virtual Guest from the
pop-up menu.
2 Define the description of the Virtual Guest Job and select the appropriate VGP, as
described in the following sections:
4 Optionally, click Next to display the following panels and specify options.
5 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
Note
To deploy domains, BMC Server Automation recommends that you have the
appropriate privileges on the host server to which you are deploying the new domain.
To deploy a domain
Right-click the Job folder and select New > Virtual Guest Job from the pop-up
menu.
Right-click the VGP from the Depot and select Deploy Virtual Guest from the
pop-up menu.
2 Define the description of the Virtual Guest Job and select the appropriate VGP, as
described in the following sections:
4 Optionally, click Next to display the following panels and specify options.
5 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
Right-click the Job folder and select New > Virtual Guest Job from the pop-up
menu.
Right-click the VGP from the Depot and select Deploy Virtual Guest from the
pop-up menu.
2 Define the description of the Virtual Guest Job and select the appropriate VGP, as
described in the following sections:
If you have chosen to customize the operating system for the new virtual guest,
the following panels are also displayed:
4 Optionally, click Next to display the following panels and specify options.
5 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
For virtual machines deployed on a Citrix XenServer, you can only provision
Operating Systems on virtual machines created from the following template types:
Windows templates
Note
Linux templates on Citrix XenServer do not support PXE booting and therefore are
not supported.
When creating VMs on a Citrix XenServer, ensure that the customized template does
not contain the following files:
The presence of these log files in the template may cause the VGJ to fail.
Right-click the Job folder and select New => Virtual Guest Job from the pop-
up menu.
Right-click the VGP from the Depot and select Deploy Virtual Guest from the
pop-up menu.
2 Enter a description of the Virtual Guest Job and select the appropriate VGP, as
described in the following sections:
If you have chosen to customize the operating system for the new virtual guest,
the following panels are also displayed:
4 Optionally, click Next to display the following panels and specify options.
5 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
Right-click the Job folder and select New Virtual Guest Job from the pop-up
menu.
Right-click the VGP from the Depot and select Deploy Virtual Guest from the
pop-up menu.
2 Define the description of the Virtual Guest Job and select the appropriate VGP, as
described in the following sections:
5 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
2 Right-click the Job folder and select Open from the pop-up menu.
3 In the content editor, navigate to any of the following tabs and review or edit the
settings:
2 Right-click the Job folder and select Open from the pop-up menu.
3 In the content editor, navigate to any of the following tabs and review or edit the
settings:
2 Right-click the Job folder and select Open from the pop-up menu.
3 In the content editor, navigate to any of the following tabs and review or edit the
settings:
2 Right-click the Job folder and select Open from the pop-up menu.
3 In the content editor, navigate to any of the following tabs and review or edit the
settings:
RedHat
KVM - General Settings on page 954
RedHat
KVM - Storage/Network Settings on page 954
Red
Hat Enterprise Virtualization - Basic on page 956
Red
Hat Enterprise Virtualization - Storage on page 957
Red
Hat Enterprise Virtualization - Network on page 957
Red
Hat Enterprise Virtualization - Advanced on page 958
2 Right-click the Job folder and select Open from the pop-up menu.
3 In the content editor, navigate to any of the following tabs and review or edit the
settings:
2 Right-click the Job folder and select Open from the pop-up menu.
3 In the content editor, navigate to any of the following tabs and review or edit the
settings:
You cannot rollback or undo a Citrix Xenserver virtual machine or disk that you
deleted using BLDeploy. While the Undo action for a deleted disk using
BLDeploy might create a new disk, it will not recover the data from the disk that
was deleted.
The rollback feature is not supported if you have renamed a virtual machine
using a BLPackage (this applies to all virtualization platforms).
The rollback feature is not supported for Virtual Guest Jobs (all platforms).
1 From the Jobs folder, navigate to the Deploy Job you used to deploy the BLPackage.
All runs of the job and their outcome display beneath the job.
4 Right-click the job run you want to rollback and select Undo.
The server auditing and compliance capabilities in BMC Server Automation involve:
The following table describes the capabilities in BMC Server Automation that are
useful in managing, controlling, and enforcing configuration changes to your server
and application environments, regardless of whether the environment is virtual or
physical.
Task Description
Base-lining the environment Use a Snapshot Job to establish a baseline of the virtual environment
(for example, a host, virtual machine, LPAR, and so on), so that you can
then track audit discrepancies or compliance violations using an Audit
or Compliance Job.
The results of the Snapshot Job provide a view of your virtual assets at
a point in time, which can then be used as a reference point, against
which you can run Audit Jobs, for example.
Auditing the environment To ensure that there are no unauthorized changes in server
configuration, the BMC Server Automation operator can run an Audit
Job periodically to compare each virtual asset configuration with one or
more baseline configurations. Any detected differences in the
configurations are treated as audit discrepancies in BMC Server
Automation and can be rectified by running a remediation job
(automatically or manually) to synchronize the virtual assets (servers,
virtual systems, and so on).
Ensuring compliance to standards To prevent unauthorized or unwanted changes in the virtual
infrastructure, the BMC Server Automation operator can run a
Compliance job periodically that compares the configuration of each
virtual asset against certain rules and policies (for example, operational
or regulatory policies).
For example, you may want to ensure that all Microsoft Windows
virtual machines have 2 GB of storage.
The Compliance Job produces a list of consistent and inconsistent
servers and guests. Remediation instructions are then generated and
packaged, and can be either automatically or manually deployed.
Remediating issues in the You can create a remediation package for a virtual asset that has failed
environment an Audit or Compliance Job. You create a BLPackage that consolidates
all remediation actions specified in the audit or compliance rules that
the target component has failed.
The remediation package can then be triggered automatically to rectify
issues with inconsistent or non-compliant assets.
Note
The BMC Server Automation administrator must install and configure the virtual
environment. For more information, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Home.
For example, you could run a Snapshot Job on a vCenter servers Inventory node to
check to see if any virtual machines have been added to, or removed from, a given
data center. To see what virtual environments are supported, see Working with
virtual environments on page 853.
Note
Snapshot Jobs and Audit Jobs are not supported at the root level, for Citrix XenServer.
You can then remediate the virtual assets that fail audit or are found to be non-
compliant, using a remediation job.
For example, suppose you run a Compliance Job and discover that a virtual
machines memory settings are non-compliant. You can run a Deploy Job to deploy a
BLPackage with the proper configuration settings that remediates the problem on
the virtual machine.
You can use the general principles from the following example to perform snapshot
and audit operations on nodes in a virtual environment.
2 In addition to whatever other Snapshot Job options you choose, make sure to
select Select Snapshot Job Type => Snapshot server objects on the Snapshot
Job - General panel.
3 When the Snapshot Job run completes, browse to the Snapshot Results node in
the Servers folder. Expand the Snapshot Job run, then expand the results node for
this Job run.
4 Right-click the results node for the Snapshot Job run, and select Audit.
The New Audit Job wizard opens. Fill out the wizard panels as described in
Creating Audit Jobs on page 677.
In addition to whatever other Audit Job options you choose, make sure to choose
the Select server objects option for Select Audit Job Type on the General panel.
5 When the Audit Job run completes, browse to the Audit Results node in the
Servers folder.
For information about how to view audit results, see Viewing audit results by
object on page 697 or Viewing audit results by server on page 698.
Creating and executing a Virtual Infrastructure Discovery Job ensures that all virtual
assets in the environment are known to BMC Server Automation, which results in
the following benefits:
For details on creating the job, see Creating the Virtual Infrastructure Discovery Job
on page 898.
Running the Virtual Infrastructure Discovery Job enables you to see what the virtual
inventory looks like, without having to manually find and register each virtual asset.
Being able to manage this inventory effectively enables you to control resource waste
and optimize the use of the available hardware.
Use the Virtual Infrastructure Discovery Job to perform the following tasks:
Environment Task
VMware Discover and register virtual machines, nonglobal zones, or LPARs that are
Solaris available on the selected targets.
IBM Imports four properties for virtual machines, non-global zones, and LPARs
(Entity ID, Entity Manager, Entity Container and Entity Type).
Updates all the properties of all discovered virtual machines, nonglobal zones,
or LPARs (if you selected the update virtual infrastructure option).
VMware environments Discover unregistered virtual machines on the datastores of the selected targets.
only Retrieves all the virtual machines registered in the vCenter and then retrieves
all the virtual machines from the datastores attached to the data centers. The
difference between these two lists reveals the virtual machines which are not
registered with any ESX host on that vCenter.
Discover unregistered templates on the datastores of the selected targets.
Auto-remediate option - registers the discovered unregistered virtual machines
in the vCenter; upon successfully registering the virtual machines in the
vCenter, automatically registers the virtual machines in BMC Server
Automation.
Import lifecycle properties - imports three lifecyle properties for virtual
machines (OWNER, EXPIRY_DATE, LOCATION)
The Virtual Infrastructure Discovery Job is supported for VMware, IBM, and
Solaris platforms only.
The initial running of the job across the virtual infrastructure will take longer than
subsequent executions of the job. For additional information, contact BMC
Software Customer Support.
2 Right-click the Job folder and select New => Virtual Infrastructure Discovery
Job from the pop-up menu. The Virtual Sprawl Discovery Job wizard opens.
WARNING
For VMware platforms, if an ESX host is in the disconnected state and has not
been removed from VMware vCenter, the options in the Virtual Infrastructure
Discovery Job are not supported against the vCenter server which manages the
disconnected ESX host.
4 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
In the Schedules panel, define any number of schedules for the Virtual Infrastructure
Discovery Job in the list of schedules, and then click Next. You can use any of the
following options:
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
Missing Servers
This view shows servers that are present in BMC Server Automation inventory but
not in virtual environment. This view shows the following information:
Entity Type - Shows the type of virtual asset for the server. For example, VMware
Virtual Machine, IBM LPAR, and so on.
Entity Manager - Shows the server name of the host server, on which the virtual
system is running.
You can then select one or more servers from the table, right-click and select
Decommission Server (s) to remove the servers from the BMC Server Automation
inventory.
Note
The Missing Servers node is available only if you selected the Run Virtual
Infrastructure Update job option.
Unregistered Servers
This view displays any unregistered Virtual Machines discovered by the Virtual
Infrastructure Discovery Job. Review the systems and register those which you want
to manage.
Note
The unregistered server node is available only if you selected the Discovered
Unregistered Virtual Systems job option.
Unregistered Templates
Note
The unregistered server node is available only if you selected the Discovered
Unregistered Virtual System Templates job option.
2 Right-click the Job you want to modify and select Open from the pop-up menu.
management tasks you can perform in a virtual environment, and describes the
administration tasks for each supported virtualization platform.
You can also perform ad-hoc management tasks (turn virtual systems/ host servers
on or off, and so on) from the BMC Server Automation console, for each of the
following virtualization platforms:
Note
All management tasks for VMware hosts and virtual machines are performed
through the vCenter.
Prior to browsing VMware virtual assets, you must have distributed the vCenter
configuration object on the vCenter server, as described in BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Home.
Note
To live browse a virtual node inventory, you must log on as a user whose role has
the following additional authorizations:
PropertyInstance.Read authorization
Connection PropertyInstance.Read
3 In the Live Browse tab or the content editor, expand the Live node.
4 Expand the VMware vCenter Server server object type to display the nodes.
View Description
Inventory Shows the dynamic tree under a vCenter (this is the equivalent of the VMware
Infrastructure clients Hosts & Clusters view). This tree view provides an easy
way to see the hierarchical organization of the vCenter.
Hosts Shows configuration and software information about each ESX host in the vCenter.
The Hosts view includes all VMware hosts belonging to all clusters as well as those
that do not belong to a cluster.
Under each host, the view lists all the virtual machines for that host as well as the
following information:
configuration of the host, such as the hardware characteristics of the server (for
example: storage, memory, and processor information) and various software-
related settings (for example: memory shares, CPU shares)
resource utilization, such as memory usage, CPU usage, and number of logical
processors
server properties, such as parent datacenter, parent cluster, entity ID and entity
type
View Description
Clusters Shows all the clusters in the vCenter. This view includes:
Templates Lists the available vCenter templates. A virtual machine template is a reusable
image created from an existing virtual machine. This view lists each available
template and provides key configuration information for the template, such as:
template options, such as guest operating system type, location and name of the
configuration file, power off options, logging enablement, and so on
Virtual Machines Lists all the virtual machines in the vCenter, in alphabetical order and the power
status for each. The virtual machine view is a quick way to browse the virtual
machines in the environment without having to navigate to each VMware host.
For each virtual machine, you can view:
virtual machine options, such as guest operating system type, location and name
of the configuration file, power off options, logging enablement, and so on
guest information, which shows the state of the virtual machine, the datastore
name, and the VMware tools status
resource utilization statistics, such as CPU usage and host memory usage
server properties, such as parent datacenter, parent cluster, entity ID and entity
type
Configuration Lists various configuration information related to the vCenter server, such as
underlying operating system details, vCenter server name, and version.
1 In the Servers folder, navigate to a VMware vCenter server and expand the Live
node.
2 Expand the VMware vCenter Server server object type and then expand the
Virtual Machines node.
The Virtual Machines node shows all virtual machines configured within the
VMware vCenter server. The icon for the virtual machine indicates the current
status.
Task Description
Running
Stopped
Disabled
Orphaned
A virtual machine is considered orphaned (or unregistered) if it exists
in the vCenter database but is no longer present on the ESX Server host.
A virtual machine could also be orphaned if it exists on a different ESX
host than the one expected by the vCenter.
3 Right-click a virtual machine. From the pop-up menu, select any of the
management tasks described in the following table.
Task Description
Start Start a virtual machine and run any scripts that are configured to run
when the machine starts.
Stop Run any power-down scripts and then stop a virtual machine.
Task Description
Reset Stop and restart a virtual machine. This procedure runs any power-
down scripts before the virtual machine stops, and it runs any power-
on scripts after the virtual machine restarts.
You can use VMwares Virtual Infrastructure Client to view the snapshot. The
snapshot is stored in the following location:
1 In the Servers folder, navigate to a vCenter server and expand the Live node.
2 Expand the VMware vCenter Server object type and then expand the Virtual
Machines node.
The Virtual Machines node shows all virtual machines configured within the
vCenter server.
3 Right-click a virtual machine. From the pop-up menu, select SnapshotVM. The
Enter Action Parameters dialog displays.
4 For Name, enter an identifying name for the virtual machine state snapshot. For
Description, you can optionally provide descriptive text.
5 If the snapshot should include the virtual machine's memory, select Yes for the
snapmemory option.
6 Click OK.
1 In the Servers folder, navigate to a vCenter server and expand the Live node.
4 In the content editor, review the Server Properties for the virtual machine or ESX
host by scrolling to the right.
For example, to determine the location of virtual machines and ESX hosts in the
vCenter hierarchy, review the following properties:
Virtual machine
Parent Host
Parent Datacenter
ESX host
Parent Datacenter
For more information, see Browsing Solaris zones on page 908 and Executing
management tasks on Solaris zones on page 909.
Prior to browsing Solaris virtual assets, you must have distributed the Solaris
configuration object to the global zone running the Solaris agent, as described in
BMC technical documentation at https://docs.bmc.com/docs/display/bsa82/
Home.
3 In the Live Browse tab or the content editor, expand the Live node.
4 Expand the Global Zones server object type to display the nodes.
The following table describes the structure of the global zones server object type.
View Description
Non-global Zones This view displays all nonglobal zones. For each nonglobal zone, the content editor
displays:
Zone Options: Displays zone attributes, inherited packages, and Zone resource
controls.
Zone Storage: Displays information about zone datasets and Zone file systems.
Zone General: Displays general information about the zone, such as zone path,
auto boot value, privileges and zone type.
View Description
Resource Pools Displays resource pool information such as processor set data (pset name, system
ID, maximum and minimum CPU settings) and pool information.
1 In the Servers folder, navigate to a Solaris global zone server and expand the Live
node.
2 Expand the Global Zone server object type and then expand the Non-global
Zones node.
This node shows all nonglobal zones configured within the global zone. The icons
indicate the status of the nonglobal zones.
Task Description
Running
Configured
Ready
Installed
Incomplete
3 Right-click a nonglobal zone. From the pop-up menu, select any of the
management tasks described in the following table.
Task Description
Task Description
Boot Places the zone in the running state. A zone can be booted from the
ready state or from the installed state. Note that you must perform the
internal zone configuration when you log on to the zone after booting it
for the first time. This action should be performed using the zlogin -C
command.
Ready Prepares a nonglobal zone for running applications but does not start
any user processes in the nonglobal zone.
For information about configuring the proxy server and adding the IBM frame object
in BMC Server Automation, see BMC technical documentation at http://
docs.bmc.com/docs/display/bsa82/Setting+up+an+IBM+PowerVM+environment.
For more information about managing the environment, see Browsing IBM
PowerVM Virtual Assets on page 911 and Executing management tasks on IBM
virtual assets on page 913.
Prior to browsing IBM virtual assets, you must have distributed the IBM PowerVM
configuration object to the AIX server configured as the agentless managed object, as
described in BMC technical documentation at https://docs.bmc.com/docs/display/
bsa82/Home.
3 In the Live Browse tab or the content editor, expand the Live node.
4 Expand the IBM Configuration server object type to display the nodes.
The following table describes the structure of the IBM Configuration server object
type.
View Description
Hardware: Displays the key hardware information for the frame, such as CPU
configuration, memory statistics, list of physical adapters, list of profiles in use,
and virtual network management type.
Software: Displays various software parameters configured for the frame, such
as memory sharing, micro-partitioning, page size, and power-on type.
Workload Groups: Displays information about any workload groups set up for
the frame, including workload group name, processors, and memory.
General: Displays basic information about the frame such as serial number,
model type, and state.
Server Properties: Displays the HMC name associated with the frame.
View Description
LPAR List Lists all the LPARs in the frame, with an indication of each LPARs state. You can
browse each LPAR to view information about its hardware, options, profiles, and
settings.
For each LPAR, you can view hardware configuration, which includes CPU,
MEMORY, RESOURCE RESERVATION and those displayed below.
Options: Displays information such as LPAR name and ID, server state, system
name, and OS version.
Profiles: Displays information about the LPARs profile, such as processor mode,
memory settings, and shared processor pool information.
Settings: Displays information such as boot settings and LPAR service and
support settings.
Hardware: Displays various hardware information for the LPAR, such as CPU,
memory, and physical IO.
Pools Lists information about the frame's IO pools, shared processor pools, and shared
memory pool.
IO pools: Displays the pool name, pool ID, LPAR name, and LPAR ID.
Shared Memory Pools: Displays the pool name, Device Used by (LPAR name),
and Device Used by (LPAR ID), Paging VIOS Name, Paging VIOS ID, Size (in
MB), Type (logical or physical), State (active or inactive), Physical Location,
Redundant Device, Redundant Device Name, Redundant VIOS Name, and
Redundant Device State.
Shared Processor Pools: Displays the object name, Pool Name, Pool ID,
Reserved Processing Units, and Maximum Processing Units.
View Description
VIO Servers: Lists all the VIO servers in the frame, with an indication of each VIO servers state.
You can browse each VIO server to view information about:
Options: Displays general information such as LPAR name and ID, server state,
resource configuration, system name, current profile, and OS version.
Profiles: Displays information about the VIO servers profile, such as:
Profile settings: profile boot settings, service and support settings (such as
Redundant Error Path reporting), and profile power controls.
Settings: Displays information such as boot settings and LPAR service and
support settings (such as Redundant Error Path reporting).
1 In the Servers folder, navigate to an IBM frame server and expand the Live node.
2 Expand the IBM Configuration server object type and then expand the LPAR
List node.
The LPAR List node shows all the logical partitions in the frame.The status icons
indicate the status of the LPAR.
Task Description
Running
Not activated
Error
Open Firmware
3 Right-click an LPAR. From the pop-up menu, select any of the management tasks
described in the following table.
Task Description
Start Start an LPAR from the HMC and run any scripts that are configured
to run when the partition starts.
Restart Stop the LPAR from the HMC and then start it again.
Stop Run any power-down scripts from the HMC and then stop the LPAR.
For more information, see Browsing Hyper-V virtual machines on page 915 and
Executing management tasks on Microsoft virtual machines on page 916.
Prior to browsing Hyper-V virtual assets, you must have distributed the Hyperv
configuration object to the VMM server running the Windows x64 agent, as
described in BMC technical documentation at https://docs.bmc.com/docs/display/
bsa82/Home.
3 In the Live Browse tab or the content editor, expand the Live node.
4 Expand the Microsoft VMM server object type to display the nodes.
The following table describes the structure of the Microsoft VMM server object type.
View Description
Clusters Shows all the clusters configured under the Microsoft VMM, and their configuration
information (name, domain, host group, number of hosts, and available storage).
Under each cluster, the view lists all the hosts associated with that cluster and their
status.
Hosts Shows all the hosts belonging to all clusters as well as those that do not belong to a
cluster. It shows the status of each host in the Microsoft VMM. Under each host, the
view lists the following:
Storages: This item shows configuration information for all storage available to
the host, such as storage name, total size, available size, if the storage is in use,
and if the storage is clustered.
View Description
Virtual Machines Lists all the virtual machines in the Microsoft VMM, in alphabetical order, and the
status for each. The virtual machine view is a quick way to browse the virtual
machines in the environment without having to navigate to each host.
For each virtual machine, you can view:
Network: Details for each network, such as network name, MAC address,
network adapter type, location, and VLAN ID.
Storage: Details for each storage allocated to the virtual machine, such as storage
name, maximum disk size, if the storage is thin provisioned, device path, disk
type, bus type, bus, and logical unit number (LUN).
CPU: Lists the CPU information for the virtual machine, such as CPU type,
number of virtual CPUs, and CPU priority.
Memory: Lists the memory size allocated for the virtual machine.
1 In the Servers folder, navigate to a VMM server and expand the Live node.
2 Expand the Microsoft VMM server object type and then expand the Virtual
Machines node.
The Virtual Machines node shows all virtual machines configured within the
VMM server. The icons indicate the status of the virtual machine.
Task Description
Running
Stopped
Paused
3 Right-click a virtual machine. From the pop-up menu, select any of the
management tasks described in the following table.
Task Description
Guest Shutdown Run any power-down scripts and then stop a virtual machine.
BMC Server Automation supports both Red Hat Enterprise Virtualization platforms,
Red Hat KVM and Red Hat Enterprise Virtualization Manager for Servers (RHEV
Manager).
Browsing Red Hat KVM server and RHEV Manager servers on page 918
3 In the Live Browse tab or the content editor, expand the Live node.
4 Expand the RHEL KVM server object type to display the nodes.
The following table describes the structure of the RHEL KVM server object type.
View Description
Networks Lists all the networks connected to the Red Hat KVM host server. For each host
server, you can view:
View Description
Domains Lists all the domains on the Red Hat KVM host server, in alphabetical order, and the
status for each. For each domain, you can view:
OS Options: Domain options, such as operating system type, path, start and
stop actions, OS Machine, OS Architecture, Boot Device, and so on.
Storage Pools Lists all the storage pools associated with the RHEL KVM server. For each storage
pool, you can view the name, volume name, key, capacity (MB), allocation (MB),
and target path.
3 In the Live Browse tab or the content editor, expand the Live node.
4 Expand the RHEV Manager server object type to display the nodes.
The following table describes the structure of the RHEV Manager server object type.
View Description
Clusters Shows all the clusters on the RHEV Manager. This view includes:
Configuration information about the clusters associated with the RHEV Manager
server, such as total hosts, CPU model, and total CPU
Specific server properties of the cluster, such as parent datacenter for the cluster
Below each cluster, the networks and storage associated with the cluster
View Description
Data Centers Shows all the data centers to which the RHEV Manager server belongs. This view
includes:
Configuration information about the data center, such as storage type and
compatibility version
Hosts Shows configuration and software information about each host in the RHEV
Manager. The Hosts view includes all RHEL hosts belonging to all clusters as well
as those that do not belong to a cluster.
For each host, the view lists includes:
Server properties, such as host name, parent datacenter, parent cluster, and path
Hardware configuration, which includes total CPU, CPU speed, CPU model,
address, and so on
Templates Lists the available RHEV Manager templates. A virtual machine template is a
reusable image created from an existing virtual machine. This view lists each
available template and provides key configuration information for the template,
such as:
Template hardware, including the number of cores, number of sockets, cores per
socket, and virtual machine memory
Template properties, such as the template name, guest operating system, parent
datacenter, and cluster
View Description
Virtual Machines Lists all the virtual machines in the RHEV Manager, in alphabetical order and the
power status for each. The virtual machine view is a quick way to browse the virtual
machines in the environment without having to navigate to each RHEL host.
For each virtual machine, you can view:
Storage: Displays information about all of the storage devices that are available
to the virtual machine
CPU: Displays the number of cores, number of sockets, and cores per socket
the number of cores, number of sockets, cores per socket, and virtual machine
memory
BMC Server Automation supports both Red Hat Enterprise Virtualization platforms,
Red Hat KVM and Red Hat Enterprise Virtualization Manager for Servers (RHEV
Manager).
1 In the Servers folder, navigate to the server running Red Hat KVM and expand
the Live node.
2 Expand the RHEL KVM server object type and then expand the Domains node.
This node shows all domains configured within the Red Hat KVM server. The
icons indicate the status of the domain.
Task Description
Running
Stopped
Paused
3 Right-click a domain. From the pop-up menu, select any of the management tasks
described in the following table.
Task Description
Shut down Run any power-down scripts and then stop a domain.
1 In the Servers folder, navigate to the server running RHEV Manager and expand
the Live node.
2 Expand the RHEV Manager server object type and then expand the Virtual
Machines node.
This node shows all virtual machines configured within the RHEV Manager
server. The icons indicate the status of the virtual machine.
Task Description
Running
Stopped
Paused
3 Right-click a virtual machine. From the pop-up menu, select any of the
management tasks described in the following table.
Task Description
Snapshot and Audit See Running Snapshot, Audit, and Compliance Jobs on virtual
infrastructure on page 894.
Guest Shutdown Run any power-down scripts and then stop a virtual machine.
For information about configuring the proxy server and adding the Citrix XenServer
host agentless managed object in BMC Server Automation, see BMC technical
documentation at http://docs.bmc.com/docs/display/bsa82/Setting+up+a+Citrix
+XenServer+environment. For more information about managing the environment,
see:
Prior to browsing Citrix XenServer virtual assets, you must have distributed the
Citrix XenServer configuration object to the Linux server configured as the agentless
managed object, as described in BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Home.
1 In the Servers folder, navigate to the Citrix XenServer agentless managed object.
3 In the Live Browse tab or the content editor, expand the Live node.
4 Expand the Citrix XenServer server object type to display the nodes.
5 Expand a host. The following table describes the structure of the host server.
View Description
View Description
Host Configuration Shows the properties of the host server. For each host, you can view the following:
General - Displays general properties for the XenServer host, such as memory
configuration, version information, license information, number of CPUs and
management information.
Storage - Displays a high level view of all removable storage, local storage, and
DVD drives for the host.
NICs - Displays information about the network interface cards on the host.
Host Storage Displays a high level view of DVD drives, local drives, and removable storage for
the host. You can then drill down to see the virtual disks within each of these
storage repositories.
List of all virtual Lists all the Virtual Machines on the XenServer, in alphabetical order, and the status
machines for each. For each Virtual Machine, you can view:
General: Displays general properties for the Virtual Machine such as memory,
VCPUs, boot parameters, and so on.
Storage: Displays information for the virtual disks attached to the Virtual Machine.
Network: Displays information for the virtual network interface cards attached
to the Virtual Machine.
This view lists the XenServer-provided templates available on the selected host or
Pool. For each template, you can view the associated network settings, the name
and description of the template, and configuration information, such as memory
and virtual CPUs.
View Description
Pool Configuration Shows information about the following characteristics of the Pool:
Pool Storage: Displays information about all of the removable storage, local
storage, and DVD drives that are available under the pool.
Pool WLB: Displays configuration of the workload balancing features that are
configured on the Pool (if the license providing this feature is applied to the hosts).
Pool Storages Displays all DVD drives, local drives, and removable storage allocated to the pool.
You can then drill down to see the virtual disks within each of these storage
repositories.
List of all Hosts Lists all the Hosts in the Resource Pool, in alphabetical order, and the status for each.
List of Custom Templates: Displays the list of custom templates that are not
bound to any particular host.
List of storages: Displays the list of storage repositories attached to the resource
pool..
List of virtual machines: Displays the list of Virtual Machines that are not bound
to any particular host.
1 In the Servers folder, navigate to a XenServer host server object and expand the
Live node.
2 Expand the Citrix XenServer server object type and then expand the list of hosts.
All virtual machines configured within the host are displayed. The icon for the
virtual machine indicates the current status.
Task Description
Running
Halted
Suspended
Rebooted
Snapshot
3 Right-click a virtual machine. From the pop-up menu, select any of the
management tasks described in the following table.
Task Description
Shutdown Shuts down theoperating system on the virtual machine (if present),
and then powers off the virtual machine.
Reboot Restart the operating system (if present) on the virtual machine. If an
operating system is not present, it powers off and then powers on the
virtual machine.
Force reboot Halts and then boots the virtual machine without gracefully restarting
the operating system (if present) on the virtual machine.
Take snapshot See Running Snapshot, Audit, and Compliance Jobs on virtual
infrastructure on page 894.
Task Description
Rename Renames the virtual machine. You cannot rename a virtual machine by
deploying a BLPackage. You must use the Rename ad-hoc action.
4 When you right-click a XenServer Custom Template, you can select the Delete
Template option.
You can run a Virtual Infrastructure Discovery Job to query the virtual environment
for existing virtual machines. If the discovered virtual assets are not already enrolled
in the inventory, you can choose to auto-enroll them by selecting an option in the Job
configuration.
Running the Virtual Infrastructure Discovery Job enables you to see what the virtual
inventory looks like, without having to manually find and register each virtual asset.
Being able to manage this inventory effectively enables you to control resource waste
and optimize the use of the available hardware.
See About the Virtual Infrastructure Discovery Job on page 896 for pre-
requisites and best practices for running the job.
See Creating the Virtual Infrastructure Discovery Job on page 898 for detailed
instructions for creating the job.
See Reviewing the results of the Job on page 900 for information about
evaluating the Missing Servers View and the Unregistered Templates View.
The mapping file contains a list of mappings for the targets and VMware vCenter
servers against which the Virtual Infrastructure Discovery Job is run.
Note
Lifecycle Properties will not be imported for ESX Hosts.
You must store the file in a depot folder so that it is accessible across application
server instances.
The Import Lifecycle Properties option on the Virtual Infrastructure Discovery Job
imports only the three supported lifecycle properties (OWNER, EXPIRY_DATE,
LOCATION) for all registered virtual machines.
To create a properties mapping file for the Import Lifecycle Properties option
1 Create an XML file with the format shown in Figure 9 on page 929.
Figure 9: Format of server lifecycle properties mapping file
<?xml version="1.0"?>
<CustomPropertyMapping>
<VirtualEntityManagerList>
<VirtualEntityManager>
<name>hostname_1</name>
<type>VMware vCenter</type>
<property name="location"
defaultValue="Boston" isMap="false" customProperty="" />
<property name="owner" defaultValue="BMC"
isMap="false" customProperty="" />
<property name="expiry date" defaultValue="2009-08-21
14:07:20" isMap="false" customProperty="" />
</VirtualEntityManager>
<VirtualEntityManager>
<name>hostname_2</name>
<type>VMware vCenter</type>
<property name="location" defaultValue="" isMap="true"
customProperty="VM location" />
<property name="owner" defaultValue="" isMap="true"
customProperty="VM owner" />
<property name="expiry date" defaultValue="" isMap="true"
customProperty="VM expiry date"/>
</VirtualEntityManager>
</VirtualEntityManagerList>
</CustomPropertyMapping>
where hostname is the fully qualified VMware vCenter server name or IP address.
Specify that the lifecycle property values be imported from the default values
specified in the mapping file. The example shown for hostname_1 in Figure 9
on page 929 shows how you would enter the default values in the mapping file.
Specify that the lifecycle property values be retrieved from the virtual entity
manager (for example, the vCenter server) by mapping custom properties on
the virtual entity manager to each of the supported properties. The example
shown for hostname_2 in Figure 9 on page 929 shows how you would retrieve
properties from the virtual entity manager using the isMap attribute.
If the isMap attribute for a property in the mapping file is set to false then the
default value specified for the property is used, as shown for hostname_1 in
Figure 9 on page 929.
If the isMap attribute for a property in the mapping file is set to true, then the
specified customProperty must match the name of the custom property defined
in the virtual entity manager whose value is to be imported for this property.
For example: if the isMap attribute for the location property is set to true and
the custom property defined on the virtual entity manager (VMware vCenter in
this example) is VM location, then the customProperty attribute in the
mapping file must also be VM location.
4 Save the file in a depot folder so that it is accessible across application server
instances.
The imported lifecycle properties are listed under the Lifecycle property set
instance for each virtual machine under the vCenter. If the update all servers
properties option is selected then the three lifecycle properties of the servers
existing in BMC Server Automation will also be updated.
Note
Although lifecycle properties are not retrieved from the virtual entity manager in
a Solaris zones or IBM LPAR environment, the default values specified in the
mapping file for the properties will be imported, and the Lifecycle property set
instance will be created for non-global zones or IBM LPAR.
Full instructions for generating and using reports are available in the BMC BladeLogic
Decision Support for Server Automation User Guide.
1 Access the Virtualization reports through the Virtualization folder on the Public
Folders tab in the BMC BladeLogic Decision Support for Server Automation
portal.
2 Review the various Extended server properties that are used to populate the BMC
BladeLogic Decision Support for Server Automation reports, shown in the
following table.
Table 38: Extended server properties used for BMC BladeLogic Decision Support for Server
Automation reports
CREATION_SERVICE_ Creation Service The service request identifier associated with the
REQUEST_ID Request server creation.
CREATION_CHANGE_ Change Service The change request identifier associated with the
REQUEST_ID Request server creation.
CREATION_TASK_ID Creation Task The task identifier associated with the server creation.
EXPIRY_DATE Expiry Date The date when the server is supposed to expire (or
the date when the lease lapses).
For more information about the Virtual Guest Job, see Deploying virtual systems
using a Virtual Guest Package on page 868.
Field definitions
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
2 Browse to the host server (vCenter, global zone, IBM frame, Citrix XenServer,
RedHat KVM server, RHEV Manager server, or Microsoft VMM server) that will
be the target for the new virtual guest.
Note
The IBM frame and the Citrix XenServer are represented by an agentless
managed object.
3 Expand the host server node, and drill down until you find your target for the
Virtual Guest Job.
Note the following considerations for selecting a target, based on platform:
Platform Notes
VMware Select the target as Host server/Resource Pool/Cluster for the new Virtual
Machine.
You can select only one host, cluster, or resource pool from the VMware vCenter
as the target for the Virtual Guest Job.
Solaris You can select only one global zone as the target for the Virtual Guest Job.
IBM You can select only one frame as the target for the new IBM AIX or Linux
partition or VIOS partition.
RedHat KVM You can select only one virtual host as the target for the domain.
RHEV You can select a RHEV Manager host or a Cluster as the target for the Virtual
Guest Job.
Citrix XenServer If you are deploying the virtual machine to a Citrix XenServer Pool, all disks
belonging to the virtual machine must reside on shared storage for the pool.
You can select only one Host as the target for the virtual machine.
Hyper-V You can select only one VMM server as the target for the Virtual Guest Job.
4 Click OK.
5 Click Next.
Note
You can select only one host, cluster, or resource pool from the VMware
vCenter as the target for the Virtual Guest Job.
VMware - Config
Both the Config Wizard panel in the Virtual Guest Job wizard and the VM Config
Type Settings panel in the Virtual Guest Package lets you select the virtual guest
configuration and OS settings appropriate for the new virtual guest. If the package is
based on a template, this panel is read-only, with the exception of Virtual Machine
Name.
Enter a name for the virtual machine, and then specify any of the following settings.
If you are creating the virtual machine from a template or virtual machine, the
template or virtual machine name is shown in the Created from VM/Template field.
Typical - Select this option to choose basic settings for the virtual machine
configuration.
Custom - Select this option to be able to set advanced configuration options for
the virtual machine.
Under VM Config file Datastore location, choose the location for the VMX file,
which is the primary configuration file for the virtual machine. This file will
contain all of the options you select when you set up this virtual machine.
OS Type - select the operating system type from the drop-down list.
OS Version - select the operating system version from the drop-down list
Select the Customize OS check box if you want to specify settings for the virtual
machine operating system. You specify the settings on two subsequent wizard
panels: the Basic Config panel and the Computer Settings panel.
VMware - Settings
Both the Settings panel in the Virtual Guest Job wizard and the VM Processor\Memory
\Disk Settings panel in the Virtual Guest Package lets you select the virtual
processor, memory, and disk settings appropriate for the new virtual guest.
Increase or decrease the number of virtual processors, using the Virtual Processor
and Memory Configuration field. Specify the number of virtual processors and
the amount of memory that will be allocated to the virtual machine.
Add new virtual disks and modify the data stores for the ones that are part of the
template, in the Virtual Disk Configuration section.
Memory for this virtual machine - Use the slide bar to set the amount of
dedicated memory for this virtual machine.
Disk Format
Select one of the following format options from the drop-down list.
Same format as source - Use this option if you want to use the same storage
format as the source template or VM, if you are cloning a template or VM.
Thick format - Use this option if you want the entire defined space allocated
on physical disk. For example, if you are planning to allocate 50 GB disk
space to a new virtual machine, the entire 50 GB will be consumed on the
physical drives.
Create a new virtual disk - After selecting this option, click Add ( ) to
display the Add virtual disk dialog box, where you can specify the storage
adapter type, the amount of storage, and the location of the datastore. You
can also select the Thin Disk Provisioning option to specify that the new
virtual disk use thin disk provisioning (described above). Note that a user-
added disk can be deleted or modified, however, you cannot change the size
or delete the disks provided from the template.
DNS Configuration
In the DNS suffixes field, enter any Domain Name System (DNS) suffixes in
comma-seperated format. The DNS suffix is used in DNS name registration
and DNS name resolution.
Network Connections
You can add new virtual NICs to the virtual machine, and also modify the
template-defined NICs. Any user-added NICs can be deleted, but you cannot
delete the NICs provided with the template. You can also specify the IP
settings for any NICs that you add.
Note
BMC Server Automation supports the use of VMware Distributed Virtual
Switch (DVS) port groups.
IP Address
Subnet mask
Default gateway
1 In the Virtual Guest Package editor, select the Run Once Script tab.
4 Click OK.
The RunOnce commands you specify run after the guest operating system starts,
which is in logged on mode with Administrator credentials. If you do not want the
virtual machine logged on automatically, then add a reboot command to the end of
the run once command list (for example, shutdown /r).
Note
You can specify only OS commands on the Run Once Script panel; there is no
support for executing multi-line scripts.
IBM - Storage (automatic management) on page 943 (this panel displays if you
selected the Automatically manage storage virtual server adapters option in the
Virtual Guest Package wizard)
Field definitions
General settings
Specify identification information for the LPAR. The Partition ID and the
Profile Name are automatically generated if you leave those fields blank. You
can also specify the level of resources that will be assigned to the new partition.
Partition Name
Partition ID
Profile Name
Use all resources in system - Select this option for the partition to have
access to all resources in the system.
Auto Boot - Select True to automatically boot the LPAR. Select False if
you do not want the LPAR booted automatically. Default value: False.
Processor Settings
Processor Type:
Select the processor type (Shared or Dedicated), and then choose the
following settings. Select Shared to have the partition share CPUs. with other
partitions in the shared processor pool. Select Dedicated to assign CPUs for
use only by this partition.
Processing Units:
Use the following settings to set the range of processors available to the
partition.
Minimum processors
Desired processors
Maximum processors
If you selected a Processor Type of Shared, enter the name of the shared
processor pool. In a shared processor pool, processor resources are allocated
as sub-units of processing power, known as a processing unit (PU) that can
span multiple physical CPUs. This enables the physical CPUs to act as a
shared pool of CPUs. Default value: DefaultPool (0)
Capped/Uncapped Weight:
Memory Settings
Use the following settings to set the amount of memory available to the
partition.
Minimum memory
Desired memory
Maximum memory
IBM - Storage
The Storage panel lets you select the virtual adapter settings appropriate for the new
LPAR.
If you chose to manage the storage manually, then the following fields are displayed:
Virtual SCSI Adapters On the Create Virtual SCSI Adapter dialog, specify:
Remote adapter ID - Enter the virtual slot ID for the remote partition.
Virtual Fiber Channel Adapters On the Create Virtual Fiber Channel Adapter dialog, specify:
Remote adapter ID - Enter the virtual slot ID for the remote partition.
Virtual Serial Adapters On the Create Virtual Serial Adapter dialog, specify:
Remote adapter ID - Enter the virtual slot ID for the remote partition.
If you chose to automatically manage storage virtual server adapters, you will see a
single storage table on the Storage panel, from which you can add storage for the
LPAR. You can:
Click Add ( . A dialog box is displayed where you can choose the type of storage
you want to add. The following table describes the available choices.
IBM - Network
The Network panel lets you select the virtual adapter settings appropriate for the
new LPAR.
Virtual switch - Select the virtual switch from the drop-down list of
available switches. A virtual switch enables partitions on a managed
system to communicate internally and to connect to external networks.
Default value: Ethernet0
Click Add to add one or more LHEAs. On the Select Logical Host Ethernet
Adapter dialog box, specify:
Port Group - Enter the port group to which the physical port belongs. A
port group is a group of logical ports that share one or two physical ports.
A port group can support up to 16 logical ports.
Logical Port - Enter a logical port from the port group that you want to
allocate to the LPAR.
Allow all VLAN IDs - Check this box to enable the logical port to accept
packets with any VLAN ID.
Allowed VLAN IDs - If you want the logical port to accept only packets
with specific VLAN IDs, clear the Allow all VLAN IDs check box and
enter each VLAN ID into this field. You allow up to 20 VLAN IDs to be
accepted on this logical port.
Field definitions
Under Physical IO, click Add ( ) to add one or more physical devices.
IO Pool ID
Optionally, specify the I/O pool if you want to assign the physical I/O slot to
an I/O pool.
Choose how to add the I/O device to the partition profile. A partition profile
is a record on the HMC that specifies a configuration for a logical partition.
Add as required - select this option if you want to specify that the I/O
device is dedicated to the partition.
Add as desired - select this option if you want to specify that an I/O
device is shared. Selecting this option means that either the I/O device is
meant to be shared with other logical partitions, or that the I/O device is
optional.
IBM - Advanced
The Advanced panel lets you specify optional settings for the LPAR.
Field definitions
Specify the Active Memory Expansion (AME) factor. AME enables the LPAR
to compress in-memory data, which allows more data to be placed into
memory. The AME factor specifies a target effective memory capacity for the
LPAR. For example, if you specify an AME factor of 3.0 and a memory size of
20 GB, then the expanded memory size for the LPAR is 60. GB
Memory Settings
Click Use Shared Memory to specify any of the following shared memory
settings (the following fields are not displayed unless you select the Use
Shared Memory option:
number, the higher priority the partition has for obtaining shared
memory. For example, a partition with a weight of 128 would get a greater
percentage of the available memory than a partition with a weight of 64.
Custom Entitled Memory - Set the desired amount of memory (in MB)
that will always be available to the LPAR.
Other Settings
Solaris - Basic
The Basic panel lets you specify identification information, processor settings, and
memory settings for the zone.
General Settings
Specify the Zone Name and the Zone Path (must start with a forward slash /
), and then any of the following settings:
Resource Pool - Click Browse ( )to associate the zone with a resource
pool that is available on the system. Default value: Not applicable.
Auto Boot - Select True to automatically boot the zone when the global
zone is booted. Select False if you do not want the zone booted
automatically. Default value: False.
Processor Settings
Capped sets a limit on the amount of CPU resources that can be used by
the zone while it is running. Enter a positive integer or positive decimal
(with two digits to the right of the decimal) in the Number of CPUs or
Range field to represent the CPU cap.
Memory Settings
Use these settings to provide limits for the physical, swap, and locked
memory usage of the zone. For example, you could specify a maximum swap
memory of 256 MB for the zone.
Note: You must specify at least one of the memory settings when capping
memory for the zone.
Physical
Locked
Maximum Swap
Field definitions
Network Settings
Choose the IP type (Shared or Exclusive) and then click Add ( ) to specify
a network address on the Select Network Address panel.
For a Shared IP zone, specify both the IP address and the physical device.
Optionally, you can also set the default router. For example, Physical = hme0,
Address=192.168.0.1, Default Router=10.0.0.1
For an Exclusive IP zone, specify only the physical device. For example,
Physical = bge32001
File Systems
Adding a file system is optional. Click Add to specify additional file systems
on the File Systems/Data Sets/ Devices Settings Dialog panel. Use the
following options to specify how and where to mount file systems:
Dir: Specify the mount point for the file system. For example, Dir=/mnt
Special: Enter the block special device name or directory to mount from
the global zone. For example, Special=/dev/dsk/c0t0d0s2
Raw: Enter the raw device on which to run the file system consistency
check command (fsck) before mounting the file system. For example,
Raw= /dev/rdsk/c0t0d0s2
Type: Enter the file system type. For example, Type = ufs
Options: Enter additional mount options similar to those used with the
mount command. For example, Options = nodevices.logging
Click Add to specify additional Data Sets on the File Systems/Data Sets/
Devices Settings Dialog panel. Adding a ZFS data set resource enables
storage administration to be delegated to a nonglobal zone.
Specify the name of the data set, but do not include a leading slash (/) or
spaces in the data set name. For example, enter ZFSPool/testzfs
Inherited Pkg-Dirs
Select Sparse Root to create a zone that contains a read/write copy of only
a portion of the file system existing on the global zone. The other file
systems are mounted from the global zone as read-only loop-back virtual
file systems. When the zone is created, the global administrator selects
which file systems to share with the sparse root zone, By default, the
following directories are shared as read-only file systems: /usr, /lib, /
sbin, and /platform. These directories are shown in the Inherited Pkg-Dirs
section.
Select Whole Root to create a zone that contains a read/write copy of the
file system that exists on the global zone. When this type of zone is
created, all of the packages installed on the global zone are available to the
zone. The whole root zone has dedicated use of the package database that
is created and copied onto the zone.
Solaris - Advanced
The Advanced panel lets you specify additional settings for the Zone.
Advanced Settings
Boot Args - Enter any boot arguments you want applied to the zone. For
example, enter -m debug to set the boot behavior of SMF to write
messages at the debug level. Default value: Not applicable.
Scheduling Class - Select a scheduling class you want applied to the zone.
The scheduling class controls the allocation of available CPU resources
among zones, based on their importance. Select from the following options:
TS (Time Shared)
IA (Inter Active)
FX (Fixed Priority)
SYS (System)
RT (Real Time)
Devices
Resource Controls
Value: priv=privileged,limit=100,action=deny
Custom Attributes
Field definitions
General settings
Number of VCPUs
Auto Start - Automatically starts the new virtual machine as soon as the
host is booted.
Field definitions
Disks
Click Add ( ) to open the Disk Settings dialog box, where you can add any
of the following:
Disk Name
Disk Description
Size (MB)
Select Server - Select a server from the drop-down list. The selection
populates the list of disks at the bottom of the dialog box.
Location - Displays the path for the storage location of the disk you selected.
Networks
Click Add to open the Virtual Interface Settings dialog box and add any of
the following:
Network Name - Select from the networks attached to the selected server.
MAC Address - You can either enter a MAC address, or choose to have
the address generated automatically.
Field definitions
General
Number of VCPUs
CPU Architecture
Boot Automatically
Field definitions
Storage Details:
Click Add ( ) to open the Storage Details dialog box, where you can add
any of the following:
Note
If you select Block Partition, the Use Existing Storage Pools, Server, Pool
Name, Size, and Allocate Now options are disabled.
Use Existing Storage Pool - If you selected File Image and check this
option, the Server and Pool Name drop-down lists are enabled. Select a
server, and then select from the pools available on that server.
Base Location - if you selected File Image, enter the path to the file
(without the file name, as the name is automatically generated), starting
with a forward slash ( / ).
Location - if you selected Block Partition, enter the path to the partition,
starting with a forward slash ( / ).
Size (MB) - set the desired disk space size and check Allocate Now.
Note
For a Target Device Type of CDROM and Floppy, the Target Device Bus must
be IDE.
Click Add to open the Network Details dialog box and add any of the following:
Server
Network Type
Network Name
Note
In the Virtual Guest Package and the Virtual Guest Job wizard, you must add at
least one bridge network to provision a RHEV KVM domain using PXE.
Device Model
The following panels are specific to the Red Hat Enterprise Virtualization environment:
General Settings
Virtual Guest Storage - Use the Browse button to select storage for the
virtual machine.
Guest Operating System - Select an operating system for the bare metal
virtual guest from the drop-down list. For template-based the operating
system field is read-only.
Memory (MB)
Customize OS - Select this option if you want to specify settings for the
virtual guest operating system. You specify these settings on two
subsequent panels: the Basic Config panel and the Computer Settings panel.
Virtual Disk
Click Add ( ) to display the Select Storage dialog box, select a server from
the drop-down list and specify the following::
Note
The Storage option is required only if you want to place the disk in another
storage location (not in the VM storage).
Click Add ( ) to display the Virtual Network Interface Settings dialog box,
where you can specify any of the following:
Network Name - Choose from the networks attached to the selected server.
MAC Address - You can either enter a MAC address, or have one
generated automatically.
IP address
Subnet mask
Default gateway
Advanced Settings
Disk Interface Type - Select the interface type for the guest virtual disk.
Network Adapter Type - Select the adapter type for the guest virtual
network.
The following panels are specific the the Microsoft Hyper-V environment:
Virtual Guest Storage - Browse to select storage to allocate to the virtual machine.
Source Template - This read-only field is displayed only if you have selected a
template as the base for the virtual machine.
Virtual Guest Operating System - Select an operating system for the virtual guest
from the drop-down list. This field is read-only if you have selected a template as
the base for the virtual machine.
Number of CPU Sockets - Select the number of physical CPUs that will be
available to the virtual machine.
Cores Per Socket - Select the number of processors within the physical CPU chip
that will be available to the virtual machine.
Total Cores - This read-only field displays the total number of CPU sockets and
cores per socket. For example, if you selected two CPU sockets and two cores per
socket, then this field displays a value of 4.
Memory (MB) - Select the amount of memory that will be available for the virtual
machine.
Auto boot on host reboot - Automatically starts the virtual machine if the host
server is rebooted.
Customize OS - Select this check box if you want to specify settings for the virtual
machine operating system. This field is displayed only if you have selected a
template as the base for the virtual machine. You specify the settings on two
subsequent wizard panels: the Basic Config panel for VM Basic Config -
Microsoft Windows on page 961 and the VM Computer Settings on page
962 panel.
Note
Linux template customization is not supported for Hyper-V (Microsoft VMM).
Under Virtual Disk, click Add to display the Virtual Disk Settings dialog box, select a
server from the drop-down list and specify the following:
Note
The Storage option is required only if you want to place the disk in another
storage location (not in the VM storage).
Thin Provisioning- Use this option if you want to dynamically allocate storage
using VMware vStorage Thin Provisioning. In this format, the system
dynamically consumes the space for the physical disk; space is allocated and
expanded on demand whenever the guest OS requests space. For example, if you
create an 80 GB disk but only use 20 GB of that disk, the actual disk consumption
on the physical drives is 20 GB.
Interface Type - Select the interface type from the drop-down list.
Under Virtual Network Interfaces, click Add to display the Virtual Network
Interface Settings dialog box, select a server from the drop-down list and specify the
following:
Network Name - Choose from the networks attached to the selected server.
MAC Address - You can either enter a MAC address, or have one generated
automatically.
The fields you see on this panel depend on the operating system type chosen for the
virtual machine.
Windows Server Domain - enter the domain name to which you want
to add the virtual machine. To create a domain account, click Create a
computer account in the domain, and fill in the User name, Password,
and Confirm Password fields.
This panel appears only if the Virtual Guest Package is based on a Linux template.
Note
Linux template customization is not supported for Hyper-V (Microsoft VMM).
Under Host name, enter the host name for the new virtual machine. Host names
can be any combination of alphanumeric characters and can include hyphens (-).
However, special characters are not allowed. The host name field is a required field.
Under Domain, you can optionally add the new virtual machine to a specific
domain.
Note
The fields you see on this panel depend on the operating system type chosen for the
virtual machine. The VM Basic Config panel for VM Basic Config - Microsoft
Windows on page 961 operating systems has different fields.
VM Computer Settings
The VM Computer Settings panel lets you specify the guest OS computer settings
information such as user, organization, licensing information, and time zone locale
settings for VMware, Citrix XenServer, Microsoft Hyper-V, and RedHat Enterprise
Virtualization platforms.
This panel is present only if the Virtual Guest Package was based on a template.
Name - Enter a name for the primary user of the virtual machine.
Under License Setup, enter the following license information for the virtual
machine:
License key - Enter the license key in the format shown on the panel.
Per server/Per seat - Specify the type of license for this virtual machine.
Under Localization, choose the time zone and locale for the virtual machine.
Time zone - Select the time zone from the drop-down list, or enter a custom
time zone.
Locale - Select the locale for the virtual machine from the drop-down list, or
enter a custom locale.
On the Schedule panel, choose Execute Job Now or click Add ( ) to define a
schedule for this Virtual Guest Job.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run once, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Scheduling jobs on page 1098.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Scheduled Job
Notifications on page 1099.
On the Notifications panel, optionally specify email or trap notifications for the Job.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
The Permissions list is an access control list (ACL) granting roles access to this
Virtual Guest Job. ACLs control access to all objects, including the sharing of objects
between roles.
Review the permissions for the Virtual Guest Job. The VirtualGuestPackageJob
ACL, by default, has all of the permissions associated with the VirtualGuestPackage
authorization category.
The Permissions list is an access control list (ACL) granting roles access to this
Virtual Guest Job. ACLs control access to all objects, including the sharing of objects
between roles.
For example, if the Location property appeared on this panel, you could modify
the property to Boston to show the location of the virtual machine being created.
This capability enables you to set up a template for Virtual Guest Jobs, using specific
properties as parameters. You would then need to specify values before each job run
in just one panel.
This panel lets you override (add/edit/remove) the property definitions that the
Virtual Guest Job inherits from the Virtual Guest Package. For example, if you
wanted to create a default value for the amount of memory for virtual machines, you
could do that here.
The Virtual Infrastructure Discovery Job wizard consists of the following panels:
For general information about the Job, see About the Virtual Infrastructure
Discovery Job on page 896.
Field definitions
Name
Identifying name.
Description
Save in
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
Job Settings
General options
Selecting this option imports only the three supported lifecycle properties
(OWNER, EXPIRY_DATE, LOCATION) for all registered virtual machines
(lifecycle properties are not imported for ESX Hosts).
Note: The life cycle properties can be imported in one of the following scenarios:
On the Targets panel, choose the targets for virtual guest discovery, or select All
Servers. Click Next.
Select the remediation target for any unregistered Virtual Machines by doing the
following:
4 Select the target as either Host, Resource Pool or DRS enabled Cluster.
Note
The Virtual Infrastructure Discovery Job does not support selecting objects
from the vApp tree as remediation targets.
5 Click Next.
Note
You must have created a server lifecycle properties mapping file and stored it in the
Depot. See Creating the server lifecycle properties mapping file on page 929.
Do the following:
3 Click OK.
4 Click Next.
On the Notifications panel, optionally specify and email or trap notifications for the
Job.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
On the Schedule panel, choose Execute Job Now or click the Add icon to define a
schedule for the Job.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run once, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Scheduling jobs on page 1098.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Scheduled Job
Notifications on page 1099.
On the Properties panel, review the properties associated with the virtual host server.
Tip
If you want the Virtual Infrastructure Discovery Job to update all the discovered and
registered servers with the entity properties, you must ensure that the Run Virtual
Infrastructure Update and Auto-register discovered ESX Hosts/Virtual Systems
option were selected on the General panel.
If you also select the Import Lifecycle Properties option on the General panel, the
lifecycle properties of discovered and registered servers are also updated.
Using the Permissions panel, you can add individual permissions to a job. You can
also set permissions by adding ACL templates or ACL policies.
Review the permissions for the Virtual Infrastructure Discovery Job. The
VSMDiscoveryJob ACL, by default, has all of the permissions required.
The Virtual Guest Template Enrollment Job wizard consists of the following panels:
New Virtual Guest Template Enrollment Job - Notifications panel on page 974
For more information about the Virtual Guest Template Enrollment Job, see
Automatically creating a Virtual Guest Package on page 873.
For VMware, Microsoft Hyper-V, RHEV Manager, and Citrix Xenserver platforms,
you can use a Virtual Guest Template Enrollment Job to automatically discover
operating system templates on those systems, and create Virtual Guest Packages for
the discovered templates.
The Virtual Guest Template Enrollment Job discovers all OS templates on the virtual
entity managers that you specify, creates Virtual Guest Package for the discovered
templates, and stores them in the Depot folder that you specify.
Field definitions
Name
Identifying name.
Description
Save in
Save VGPs in
Depot folder where you want to store the Virtual Guest Packages that the job
creates.
Limited: Specifies the maximum number of targets on which the job can
run simultaneously. If you set this value to 1, the job processes each target
serially. Limiting the number of targets is useful when a job might
temporarily disrupt the functionality of a target server, and you want to
limit that disruption to a small fraction of your managed servers.
2 Click the right arrow to move your selections to the right panel.
Note
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
3 Click Next.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
On the Schedule panel, choose Execute Job Now or click Add ( ) to define a
schedule for this New Virtual Guest Template Enrollment Job.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
Click Add ( ) to open the Schedule Panel. The Schedule tab lets you
schedule a job so it can run once, recur hourly, daily, weekly, or monthly, or
recur at some arbitrary interval. For more information, see Scheduling jobs
on page 1098.
Click Add ( ) to open the Schedule Panel. The Scheduled Job Notifications
tab lets you set up notifications that are generated when a scheduled job
runs. For more information, see Scheduled Job Notifications on page 1099.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
Tool Description
Custom commands Custom commands allow you to perform many functions from within
the BMC Server Automation Console that might otherwise require you
to launch a command line interface like Network Shell or other external
applications. See Custom commands on page 977.
Repeater servers When you deploy a BLPackage or software package, the objects being
deployed are copied to a staging directory on target servers. Often this
involves copying large files to many target servers. In some situations,
copying these objects to a repeater server can reduce network traffic.
See Configuring servers to use repeaters during deployments on
page 989.
Routing rules You can create routing rules to determine which Application Servers to
use for job execution. See Creating rules to determine Application
Servers used for job execution on page 997.
Infrastructure Management The Infrastructure Management window provides a way to view and
window manage Application Servers and other servers that support BMC
Server Automation operations. See About the Infrastructure
Management window on page 1001.
Custom commands
Custom commands allow you to perform many functions from within the BMC
Server Automation console that might otherwise require you to launch a command
line interface like Network Shell or other external applications.
You can define a custom command to perform any of the following actions:
The Custom Command Administration window lets you perform any of the
following procedures:
Use this procedure to create or modify a custom command. After creating a custom
command, you can use the Servers folder to execute the command on a remote
server or the local host.
To modify an existing custom command, select the command and click Open
Custom Command. The Custom Command Editor opens. Proceed to Step 4 on
page 979.
To create a new custom command, click New Custom Command . The Add
Custom Command wizard opens and displays the Custom Command
Template Selection panel. This panel lists and describes each type of custom
command you can create.
3 Select the row describing the type of custom command you want to create and
click Next. The Custom Command Editor panel appears. The options available on
this panel vary, depending on the type of command you are creating.
BMC Server Automation provides the following macros that can be used in
conjunction with custom commands. When you create a custom command that
includes a macro, the macro represents information that you provide when you
actually run the custom command.
%p The full path to the selected files or directories on which the command should run.
This path does not include the server name. For example, a path might read /c/
winnt rather than //host1/c/winnt.
%f Selected files or directories on which the command should run, excluding the path
to those files or directories. For example, winnt rather than /c/winnt.
For example, you can use the %h macro to automatically apply a command to one
or more servers. The command telnet %h starts a telnet session on any server
you designate when you execute the command. Using the %h macro, you can also
execute commands against multiple servers from the command line. For example,
agentinfo %h generates agent information for every server that you specify
when you execute the command.
Using Command Options (described below), you can run the command once
against many servers or run the command repeatedly, once for each specified server.
Note
When running a Network Shell script as a custom command, always explicitly
launch Network Shell using syntax such as nsh <scriptname>. If you do not, the
script may execute using a local shell, such as the Windows cmd.exe shell, rather
than Network Shell.
6 Under Command Associations, specify what the custom command can run
against. You can select Server Groups, Servers, Directories, Files, or any
combination of those choices.
If the operating system you select in the next step is Unknown, you will not be
able to browse directories or files. In that context, selecting Directories or Files in
this step will have no effect.
Select All Operating Systems if the custom command should apply to all
operating systems. Selecting this option includes unknown operating systems.
Select Selected Operating Systems and check the operating systems for which
this command is appropriate.
Checking Unknown (no agent installed) lets you run this custom command on a
server that does not have an RSCD agent installed. The Unknown check box is
only available if you have selected a command type of Local, Local GUI, or Local
tabular.
8 For tabular output only: Under Format Options, choose any of the following
formatting options:
Check Use table headers if the first row of output should be treated as sortable
table headers. If you clear this option, columns will use enumerated headers
(that is, 1, 2, 3, and so forth).
For Separator, select the character used to separate data fields in the
command's output.
The following is a sample row of command output that uses " as a string delimiter
and a comma as a separator:
"text1",1,2,"text2"
Note that only string values are enclosed in the string delimiter, which allows the
output table to do numerical sorting on numeric fields and text sorting on string
fields. The string delimiter is not displayed in the output table.
Output using the string delimiter can contain the separator character. For
example, if a comma is the separator and a field value is Hello, Dolly, that value
is broken into two fields unless the entire field is enclosed with string delimiters
("Hello, Dolly").
9 Under Command Options, check any of the options that are appropriate. The
available command options vary depending on the type of program, script, or
application you are defining.
10 Click Next or click the Permissions tab. The Permissions panel appears.
The Permissions panel is an access control list granting roles access to this custom
command. Access to all objects, including the sharing of objects between roles, is
controlled through ACLs.
11 Define an ACL for the custom command. For more information about defining an
ACL, see Defining permissions for a system object on page 231.
2 Select the commands you want to delete and click Delete Custom Command .
A dialog prompts you to confirm the deletion.
1 Develop a policy for routing to the remote servers by identifying the following:
A way to categorize remote servers so that you can set up rules for routing to
them. This categorization can be based on a single (new) server property or a
combination of several server properties.
Using a Network Shell proxy server prevents issues that can occur when any type
of action causes files to be copied from a server behind one SOCKS proxy to a
server behind another SOCKS proxy. For information on Network Shell proxy
servers, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Setting+up+a+Network+Shell+proxy+server.
3 Create the proxy server objects and add them to the BMC Server Automation
infrastructure. See Creating SOCKS proxy server objects on page 983.
4 Use the Network Routing wizard to create a network routing policy and rules for
routing communications to servers. See Creating rules for routing to remote
servers on page 984.
5 Add the remote servers you want to manage. See Adding remote servers on page
988.
3 On the General panel, enter the following information for the SOCKS proxy
server:
Name Name of the proxy server. This name can be any name. The BMC Server
Automation system uses it for identification and display within the
system.
User name and Password User name and password for logging on to the SOCKS proxy. If the
SOCKS proxy does not require these credentials, leave these text boxes
blank.
Resolve host name Specifies whether or not the proxy server resolves DNS host names. Set
to True to allow the SOCKS proxy server to resolve host names. Set to
False to use the DNS server in the local network.
This setting is important in networks where target servers do not
necessarily have unique IP addresses. In those networks, a proxy server
can use a DNS server different from that of the Application Server.
Setting Resolve host name to True lets you have two target servers that
have the same IP address but still have unique identities, each through a
different DNS server.
4 Click Finish. The Infrastructure Management window lists the proxy server
object you created.
You can edit the properties of a proxy server, delete proxy server objects, and
check to see if the proxy server is operational. For information, see Managing
SOCKS proxy servers on page 1005.
To create the SOCKS Proxy Server routing policy, the Network Routing wizard
modifies the default network routing policy. Modifying the routing policy affects
the entire BMC Server Automation system. Information you enter in the wizard
should be in keeping with your teams strategy for routing to remote servers.
To create, modify, or delete routing rules, your role must be granted the
RoutingPolicy.Modify and the BL_Administration.Read authorizations.
4 When you have finished creating rules for routing to remote servers, click Finish.
The Network Routing wizard sets the default network routing policy to route
through SOCKS proxy servers according to the rules you created. The
Infrastructure Management window lists the rules in the Network Routing Rules
folder.
Note
The system detects communication requests to localhost and to IP address
127.0.01 (as in the case when the File Server resides on the same host as the
Application Server) and does not evaluate routing rules for these requests.
To create more of these simple routing rules, run the Network Routing Wizard
again.
To create network routing rules based on existing server properties (for example,
host name or operating system), or to create complex routing rules based on a
combination of several server properties, use the New Rule wizard to create
routing rules manually. For information about using the New Rule wizard, see
Creating complex routing rules on page 1016.
Note
If you plan to provision a remote server that will be accessed through a SOCKS
proxy server, you must define the routing rule for the server before
provisioning it.
If you create complex routing rules manually with the New Rules wizard and
then run the Network Routing Wizard again, the Network Routing Wizard
overwrites the existing routing policy and rules. However, if you have not
created complex rules manually, running the Network Routing wizard again
preserves the routing policy and rules.
If you setup routing rules based on instrinsic Properties such as HOST, the rule
will no longer work if the property gets updated.
Field definitions
Name
Enter a name for the new server property on which routing rules will be
based. The name cannot be the same as an existing built-in server property.
For example, suppose you want your network routing rules to be based on a
target servers location. In that case, you might choose Location as the name
for the server property.
Note
Choose a name with care. The Network Routing wizard uses the name to
create a custom property class, an instance of that class, and a server
property. These items affect the entire BMC Server Automation system and
once created, cannot easily be modified.
Description
New Rule TargetsThe Targets panel lets you select servers for the rule.
3 When you have finished selecting proxy servers for the rule, click Finish.
To create another rule based on the same server property, click Add Rule and
repeat the process.
To modify a rule, click Edit Selected Condition .
New Rule General (network routing)
The General panel lets you provide information that defines a network routing rule.
Field definitions
Name
Enter a name for the network routing rule you want to create. The Network
Routing wizard uses the name not only as the rule name but also as the value
of the server property in the rules condition. For example, if the new server
property is Location, you might enter New York for the rule name. The
Network Routing wizard names the rule and sets its condition such that the
rule applies when the Location value is New York.
Description
2 In the first text box on the left, enter a property name or click Select Property to
choose a property from a list.
If you click the Select Property icon, you can view hierarchical properties by
clicking the right arrow that appears next to some properties. This displays a
subordinate list of properties.
4 Use the next field to the right to specify a property value or range of values.
5 Click OK.
The Rule Definition panel shows the condition. To edit the condition, select it and
click Edit Selected Condition. To add further conditions, click Add Property
Condition again.
The order of the conditions determines the order in which the system uses them to
determine the proxy server. To re-position a condition, select the condition and
use the Move Up, Move Down, Move to Top, and Move to Bottom icons.
6 On the Rule Definition panel, click Next to display the Proxies panel.
New Rule Proxies (network routing)
The Proxies panel lets you choose one or more SOCKS proxy servers through which
communication to remote servers should be routed.
Under Select proxies for this rule, select one or more proxy servers that the
matching targets should be routed through. Click the right arrow, which moves your
selections to the list on the right.
When you first define a rule, you do not have to specify SOCKS proxy servers; you
can specify these servers at a later time. (For information, see Assigning SOCKS
proxy servers to a routing rule on page 1006.)
To add multiple servers to a server hierarchy, you can specify a text file that contains
a list of server names and properties assigned to each server. For information, see
Server import file format on page 266.
2 Right-click the Servers node (the top node in the Servers folder). Then select Add
Server form the pop-up menu. The Add New Server wizard opens.
3 For Name/IP Address, enter a host name or IP address that can be resolved by
either the Application Server or the SOCKS proxy server.
4 Under Properties, select the server property you added with the Network
Routing wizard, for example, Location.
5 Click in the Value column of the selected property. Then click Select a value .
The Choose Property Class Instance panel opens. (This panel opens because the
Network Routing wizard created a custom property class and instances when it
created the server property for you.)
6 On the Choose Property Class Instance panel, select the routing rule you want as
the value of the server property. For example, if you select New York, it sets the
Location property value to New York.
7 Click OK. The instance (rule name) appears in the Value column for the server
property.
8 Click Next.The Permissions panel shows the Access Control List and permissions
for the server.
If the Add New Server wizard displays the warning that an agent could not be
detected on the server and asks if an agent is installed, click Yes. You can resolve
this problem at the end of this procedure.
9 On the Permissions panel, you can add to the Access Control list or edit the
existing permissions. To accept the permissions as defined, click Finish.
10 Repeat Step 2 on page 988 to Step 9 on page 989 for each remote server.
11 To view the servers you added, define a smart group based on the server
property you created with the Network Routing Wizard. Any server with that
property is automatically added to the group.
Note
Defining a smart group using IP Addresses does not work if the Application
Server cannot resolve the IP address; this is the case where communication to
remote servers takes place through SOCKS proxy servers. However, you can use
conditions such as Name or an added property such as Location to define a smart
group.
For example, if your routing rules are based on the server property named
Location, you would use the Location property as the condition for
membership in the smart group of all remote servers.
12 Click Finish.The Servers folder shows the smart group you defined.
13 Optionally, update each servers properties. (Perform this step only if the Add
New Server wizard displayed the warning Agent could not be detected on the
server in Step 8 on page 226.)
The cause for the Agent could not be detected warning may be that the remote
server was added before the routing rules were properly set up or that the SOCKS
proxy server is not ready. To solve this problem, check the definitions of the
routing rules and the configuration of each SOCKS proxy server. Then update
each remote servers properties.
Often this involves copying large files to many target servers. In some situations,
copying these objects to a repeater can reduce network traffic.
From the repeater, objects are copied to target servers staging directories and used
during the Commit phase of a Deploy Job.
Note
If you are using repeaters with File Deploy jobs then you must also have Network
Shell installed on the repeater server.
This approach, called indirect staging, is particularly beneficial if you are deploying
through a WAN or you have segmented your network so traffic can be distributed
between sub-nets.
Note
If the BMC BladeLogic Advanced Repeater is installed on a server, you can configure
the server as an advanced repeater server.
An advanced repeater server uses BMC BladeLogic Advanced Repeater technology
with Deploy Jobs to enable file servers and repeater servers to store and share
deploy data more efficiently.
For information about configuring advanced file servers and advanced repeater
servers, see BMC technical documentation at https://docs.bmc.com/docs/display/
bsa82/Configuring+advanced+file+servers+and+Advanced+Repeater+servers.
2 Use the Repeater Routing wizard to create a policy and rules for determining the
repeater to use for target servers. See Creating rules to determine the repeater
used for target servers on page 992.
3 On each target server, set a property whose value is a rule you created with the
Repeater Routing wizard. See Assigning repeaters to target servers on page 996.
Note
To access, create and manage repeater server objects, your role must be granted
these authorizations in RBAC:
Authorization Description
2 Right-click Repeater Servers and select New Repeater Server from the pop-up
menu. The New Repeater Server wizard opens.
3 On the General panel, enter the following information for the repeater server:
Name (Required) The name of the repeater server. This name can be any name.
The BMC Server Automation system uses it for identification and
display within the system.
To have the system use the host name as the name of the repeater
server, select a host machine before filling in the Name field.
Host (Required) The name of the host machine for the repeater server.
Note: If you are using repeaters with File Deploy jobs then you must
also have Network Shell installed on the repeater server.
Click the browse button (three dots) and select a server. (The host must
be a managed server in order for you to select it.) Then click OK.
Staging directory (Required) The path to the staging directory on the repeater server. The
path must contain a drive and a directory path, for example: /c/tmp/
stage.
Enable Advanced Repeater If the BMC Server Automation Advanced Repeater is installed on this
server, this option is visible. To configure the server as an advanced
repeater server, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Configuring+advanced+file
+servers+and+Advanced+Repeater+servers.
Maximum cache size (Required) The maximum size (in KB) of the cache on the repeater (that
is, the sum of the sizes of all the files cached on the repeater).
Specify an integer greater than or equal to 0.
If you set this option to 0, the system assumes that there is no limit to
the cache size and never removes objects from the cache. You must
manage space on the repeater yourself.
If caching a new object will cause the cache size to exceed this
maximum, the system removes from the cache the stored object that was
accessed longest ago. BMC Server Automation then continues to
remove the oldest objects from the cache until enough room has been
cleared for the new object to be stored without exceeding the maximum
cache size. If the object being deployed exceeds the maximum cache
size, the deployment fails.
4 Click Finish. The Infrastructure Management window lists the repeater server
object you created.
You can edit the properties of a repeater server, delete server objects, and verify
that the server is operational and the staging directory exists.
Note
To create, modify or delete repeater routing rules, your role must be granted the
RoutingPolicy.Modify and the BL_Administration.Read authorizations.
4 Click Finish. The Rules panel opens and displays the rule you created. For
example, the result for a rule named New York (which uses the server property
Location) would have this condition: ??TARGET.Location?? = New York.
To create another rule based on the same server property, click Add Rule and
repeat the process.
5 When you have finished creating rules that use the new server property, click
Finish.
The Repeater Routing Wizard sets the default routing policy to determine
repeaters for target servers according to the rules you created. The Infrastructure
Management window lists the rules under the Repeater Routing Rules node.
To create more of these simple routing rules, run the Repeater Routing Wizard
again.
To create routing rules based on existing server properties (for example, host
name or operating system), or to create complex routing rules based on a
combination of server properties, use the New Rule wizard to create rules
manually. For information about using the New Rule wizard, see Creating
complex routing rules on page 1016.
Note
If you create complex routing rules manually with the New Rule wizard and then
run the Repeater Routing Wizard again, the Wizard overwrites the existing
routing policy and rules. However, if you have not created complex rules
manually, running the Repeater Routing Wizard again preserves the routing
policy and rules.
Field definitions
Name
Enter a name for the new server property on which rules will be based. The
name cannot be the same as an existing built-in server property.
Note
Choose a name with care. The Routing Wizard uses the name to create a
custom property class, an instance of that class, and a server property. These
items affect the entire BMC Server Automation system and once created,
cannot easily be modified.
For example, suppose you want a target servers location to determine which
repeater to use for indirect staging. In that case, you might choose Location
as the name of the property.
Description
3 When you have finished selecting the repeater server for the rule, click Finish.
To create another rule based on the same server property, click Add Rule and
repeat the process.
To modify a rule, click Edit Selected Condition .
New Rule - General (repeater routing)
The General panel lets you provide information that defines a routing rule that
determines the repeater used for indirect staging to a target server.
Field definitions
Name
Enter a name for the repeater routing rule you want to create. The Repeater
Routing Wizard uses the name not only as the rule name but also as the value
of the server property in the rules condition. For example, if the new server
property is Location, you might enter New York for the rule name. The
Repeater Routing Wizard names the rule and sets its condition such that the
rule applies when the Location value is New York.
Description
2 In the first text box on the left, enter a property name or click Select Property to
choose a property from a list.
If you click the Select Property icon, you can view hierarchical properties by
clicking the right arrow that appears next to some properties. This displays a
subordinate list of properties.
4 Use the next field to the right to specify a property value or range of values.
5 Click OK.
The Rule Definition panel shows the condition. To edit the condition, select it and
click Edit Selected Condition. To add further conditions, click Add Property
Condition again.
The order of the conditions determines the order in which the system uses them to
determine the repeater server. To re-position a condition, select the condition and
use the Move Up, Move Down, Move to Top, and Move to Bottom icons.
6 On the Rule Definition panel, click Next to display the Repeaters panel.
New Rule Repeaters (repeater routing)
The Targets panel lets you choose the repeater server to use for indirect staging to
target servers. You can select only one repeater for the rule.
Under Select repeater for this rule, select the repeater server to use for indirect
staging to target servers. Then click the right arrow to move the servers to the
selected list (on the right). You can select only one repeater for the rule.
To remove a repeater from the selected list, select the server name and click the left
arrow.
When you first define a rule, you do not have to specify a repeater server; you can
specify the server at a later time. (For information, see Assigning a repeater server
to a repeater routing rule on page 1009.)
Click Finish.
2 Right-click the server and select Set Property. The Set Server Property dialog
opens.
3 Under Name, select the server property you added with the Repeater Routing
Wizard, for example, Location.
4 Click in the Value column of the selected property. Then click Select a value .
The Choose Property Class Instance panel opens. (This panel opens because the
Repeater Routing Wizard created a custom property class and instances when it
created the server property for you.)
5 On the Choose Property Class Instance panel, select the routing rule you want as
the value of the server property. For example, if you select New York, the system
sets the Location property value to New York.
6 Click OK. The instance (rule) name appears in the Value column for the server
property.
7 Click OK. BMC Server Automation sets the property to the rule. During a Deploy
Job, the system uses the rule to determine the repeater for indirect staging to the
server.
To determine which server to use for interaction with a target server, the system
evaluates each request against the list of routing rules. (For information about
displaying this list and managing rules, see Managing routing rules on page 1013.)
For information about job execution routing rules and how to create them see:
Note
To create, modify or delete job execution rules, your role must be granted the
RoutingPolicy.Modify and the BL_Administration.Read authorizations.
2 In the left pane of the Infrastructure Management window, right-click the Job
Execution Rules node and select New Rule. The New Rule wizard opens.
Field definitions
Name
Description
1 Click Add Property Condition . The Add Property Condition window opens.
2 In the first text box on the left, enter a property name or click Select Property to
choose a property from a list.
If you click the Select Property icon, you can view hierarchical properties by
clicking the right arrow that appears next to some properties. This displays a
subordinate list of properties.
4 Use the next field to the right to specify a property value or range of values.
5 Click OK. The Rule Definition panel shows the condition. To edit the condition,
select it and click Edit Selected Condition. To add further conditions, click Add
Property Condition again.
A typical job execution rule condition might be:
(??JOB.NAME?? starts with QA) OR (??JOB.NAME?? starts with DEV)
The order of the conditions determines the order in which the system uses them to
determine Application Servers for the job execution. To re-position a condition,
select the condition and use the Move Up, Move Down, Move to Top, and Move
to Bottom icons.
6 On the Rule Definition panel, click Next to display the Targets panel.
Under Select targets for this rule, select one or more Application Servers to use for
job execution. Click the right arrow, which moves your selections to the list on the
right.
Note
Selecting only one Application Server as the target disables work item thread
sharing. To avoid this situation, select more than one target Application Server. For
more information about work item threads and job distribution, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Understanding+the
+Application+Server.
Do not select an Application Server that is configured with an Application Server
Type of Configuration Server as a target for the routing rule. Ensure that the
Application Server you select as a target is configured as a Job Server, which
includes any of the following Application Server Types:
JOB
CONFIGURATION, JOB
ALL
2 To enable or disable job execution rule evaluation, use the following command:
Where:
true Turns on job rule evaluation. The system evaluates job routing rules to
determine the Application Server to use for job execution. This is the default setting.
3 Restart all applicable Application Servers (for example, all Application Servers
that are job servers).
Node Description
Application Servers Displays information about Application Servers configured on the host
and status information about the services they run. For information, see
Getting information about Application Servers on page 1002.
Application Server Launchers Lets you configure, control, and manage multiple Application Servers
on the same host. (Your role must be granted authorization to view and
manage Application Servers on this node.) For information, see BMC
technical documentation at https://docs.bmc.com/docs/display/
bsa82/Configuring+the+Application+Server.
Node Description
Pxe Servers Displays information about the PXE servers used for provisioning
Windows and Linux servers in a BMC Server Automation environment.
For information, see Getting information about PXE servers on page
1004.
Database Config Info Displays database connection information. For information, see Getting
information about the database on page 1005.
Proxy Servers Lets you create and manage SOCKS proxy servers used to communicate
with remote target servers. See Managing SOCKS proxy servers on page
1005.
Network Routing Rules Lets you create and manage rules for routing communications to remote
servers through a SOCKS proxy server. See Setting up communications
with remote servers on page 982.
File Servers Lets you manage pre-defined file servers used to store the contents of
files included in snapshots, Network Shell scripts, BLPackages, software
packages, and other types of information that is not easily stored in the
database.
Repeater Servers Lets you create and manage repeater servers used for indirect staging to
target servers during deployment. See Managing repeater servers on
page 1007.
Repeater Routing Rules Lets you create and manage rules for determining the repeater used for
indirect staging to target servers. See Configuring servers to use
repeaters during deployments on page 989.
Job Execution Rules Lets you create and manage rules for determining the Application
Server used for job execution. See Creating rules to determine
Application Servers used for job execution on page 997.
2 In the left pane, expand the hierarchy of the Application Servers node. Then click
the Application Server you want to see.
General information about an Click the Application Servers name in the left pane.
Application Server The right pane shows:
Software version
A list of the services that an Expand the hierarchy of an Application Server. (The number and type
Application Server provides of services vary according to the Application Servers type.)
Status information about an Expand the hierarchy of the Application Server. Click the service name.
Application Server service
General information for each Application Server configured on the host machine
(and using the same database) and detailed status information about each
Application Servers services.
General information for each PXE server connected to the database and detailed
status information about each PXE Servers services.
3 On the Export AppServer Details Report dialog, from the pull-down menu, select
a directory where the report should be stored. Optionally, select a subdirectory by
double-clicking its name in the panel.
c For File Encoding, select the type of character encoding that should be used
for the exported data, such as UTF8 or Western (windows-1252).
5 Click Save.
2 In the left pane of the Infrastructure Management window, expand the hierarchy
of the PXE Servers node. The hierarchy lists all PXE Servers configured to use the
database.
To display general information about a PXE Server, click the servers name.
To display information about the services that the PXE Server provides, expand
the hierarchy of the PXE Server. Then click the name of the service. The right
pane shows information about the status of the service.
You can also export a report of the status information for all PXE servers. See
Reporting Application Server information on page 1003.
2 In the left pane of the Infrastructure Management window, expand the hierarchy
of the Database Configuration Info node. Then click the name of the database.
You can also export a report of the database configuration information. See
Reporting Application Server information on page 1003.
After you create proxy server objects, you can manage those objects through the
Infrastructure Management window of the BMC Server Automation console. You
can view and edit a proxy servers properties, delete the proxy server object, or check
to see if the actual proxy server is functioning.
For information about creating proxy server objects, see Creating SOCKS proxy
server objects on page 983.
3 To edit the properties, right-click the name of the proxy server and select
Properties from the pop-up menu.
4 On the Modify Proxy Server panel, make the changes you want and click OK. The
right pane of the Infrastructure Management window shows the properties with
changes.
3 Right-click the proxy server and select Delete Proxy Server from the pop-up
menu.
3 Right-click the name of the proxy server you want to check. Then select Update
Proxy Server Status from the pop-up menu.
The Application Server pings the SOCKS proxy server and displays a return
status message in the right pane of the Infrastructure Management window. If the
proxy server is not running, its name shows a red X icon ( ).
3 Right-click the rule to which you want to assign proxy servers and select Assign
Targets for Rule. The Targets panel opens.
4 In the list under Select proxies for the rule, select one or more SOCKS proxy
servers through which communication to remote servers should be routed. Then
click the right arrow to move the servers to the selected list (on the right).
To remove a server from the selected list, select the server name and click the left
arrow.
5 Click Finish.
Note
If a routing rule has multiple SOCKS proxy servers associated with it, the
Application Server chooses one proxy server to use for routing to the target
server. However, if that proxy server is not running, the connection to the target
server fails. The connection does not fail over to another proxy server associated
with the rule.
You can use the Infrastructure management window to perform the following
management tasks:
For information about creating repeater server objects, see Creating repeater server
objects on page 991.
2 In the left pane of the Infrastructure Management window, expand the Repeater
Servers hierarchy and select the repeater whose properties you want to view. The
right pane of the window displays the properties.
3 Right-click the repeater server and select Properties from the pop-up menu.
4 On the Modify Repeater Server panel, make the changes you want and click OK.
The right pane of the Infrastructure Management window shows the properties
with changes.
2 In the left pane of the Infrastructure Management window, expand the Repeater
Servers hierarchy.
3 Under the Repeater Servers node, right-click the repeater server and select Delete
Repeater Server from the pop-up menu.
3 Right-click the rule to which you want to assign a repeater server and select
Assign Targets for Rule. The Targets panel opens.
4 In the list under Select repeater for this rule, select the repeater server to use for
indirect staging to target servers. Then click the right arrow to move the server to
the selected list (on the right). You can select only one repeater for the rule.
To remove a server from the selected list, select the server name and click the left
arrow.
5 Click OK.
Where:
true Turns on repeater rule evaluation. The system evaluates repeater routing
rules to determine the repeater to use for indirect staging. This is the default setting.
false Turns off repeater rule evaluation. The system uses the value for the
REPEATER_NAME property on the target server to determine the repeaters to use.
3 Restart all applicable Application Servers (for example, all Application Servers
that are job servers).
2 In the left pane of the Infrastructure Management window, expand the Repeater
Servers node.
3 Right-click the repeater server and choose from the following options:
Option Description
Update Repeater Server Status Contacts the repeater server to determine current status. The
Infrastructure Management window displays such information as
name, host, and staging directory. If the staging directory exists, the
window also displays information about its disk usage.
If the repeater server is not running, its name shows a red X icon ( ).
In addition to the commands available for a standard repeater server, servers configured as advanced
repeaters have the following additional commands:
Clear Advanced Repeater Cache Clears the cache on an advanced repeater server.
Verify Advanced Repeater Cache Verifies that the cache on an advanced repeater server is operational.
Repair Advanced Repeater Cache Repairs a corrupted cache on an advanced repeater server.
A remote host authentication defines the mechanism and the user credential needed
to access an agentless device. A remote host authentication rule matches remote host
authentications with agentless devices.
You can use the Infrastructure management window to perform the following
management tasks:
Provide information needed to access the remote hosts on which agents should be
installed. See Specifying or modifying information for remote host
authentication on page 288.
Define rules that determine the information used to access a remote host during
installation. See Creating or modifying rules for remote host authentication on
page 293.
You can also use the Infrastructure Management window to perform the following
management tasks for remote host authentication and remote host authentication
rules.
Version of the RSCD agent on the PsExec server matches what is listed in its
server properties
For remote host authentication based on SSH, confirms the presence of the
designated automation principal.
2 In the left pane of the Infrastructure Management window, expand the Remote
Host Authentications node.
The information at right updates. The Status says "Success" if the update
completes successfully.
2 In the left pane of the Infrastructure Management window, expand the Remote
Host Authentications node.
2 In the left pane of the Infrastructure Management window, expand the Remote
Host Authentication Routing Rules node.
3 Right-click a rule and select Assign Remote Host Authentications for Rule.
4 Under Select the remote host authentications for this rule, select one or more
remote host authentication definitions that should be used to authenticate to
servers that match the criteria specified in this rule. Click the right arrow, which
moves your selections to the list on the right.
2 In the left pane of the Infrastructure Management window, expand the Remote
Host Authentication Routing Rules node.
Repeater routing wizardCreating rules to determine the repeater used for target
servers on page 992.
2 In the left pane of the Infrastructure Management window, right-click the node
for the routing rules you want to edit; for example, Repeater Routing Rules. Then
select Rules Management from the pop-up menu.
The Rules Management panel opens and shows each rules name, description,
and definition.
3 In the Rules Management panel, select the name of the rule that you want to view
in more detail or to edit. Then click Edit Selected Rule . The Modify Rule
dialog box opens to the General tab.
4 In the Modify Rule dialog box, click a tab to view or edit its information.
5 Click OK.
The order of the rules on the list determines the order in which the system evaluates
them against a request. When the conditions of a rule match those of the request, no
further evaluations are performed.
For example, suppose the Repeater Server policy has three rules for determining the
repeater to use for indirect staging to target servers. The routing policy lists the rules
in the following order: New York, NYC Office 1, and NYC Office 2. When a
BLPackage is deployed, the system evaluates the request against each routing rule,
in the order listed. If the conditions of the first rule on the list (New York) match the
request, the other rules are not evaluated.
Tip
You can view and change the order of routing rules. See Changing the order of rule
evaluation on page 1015.
If a rule assigns a server and the server is not running, the job or connection fails. For
example:
If a job execution rule assigns an Application Server to execute a job and that
Application Server is down, the job fails. It is not reassigned.
If a routing rule has multiple SOCKS proxy servers associated with it, the
Application Server chooses one proxy server to use for routing to the target
server. However, if that proxy server is not running, the connection to the target
server fails. The connection does not fail over to another proxy server associated
with the rule.
For job execution rules, when a routing rule assigns an Application Server to execute
a Batch Job, that Application Server executes all of the Child Jobs as well.
The order of rules on the list determines the order of evaluation. You can change the
order of rules in the Rules Management window.
2 In the left pane of the Infrastructure Management window, right-click the node
for the routing rules you want to reorder; for example, Repeater Routing Rules.
Then select Rules Management from the pop-up menu.
3 On the Rules tab, select the rule you want to re-position and use the Move Up
, Move Down , Move to Top , and Move to Bottom icons. (The rule
at the top of the list is evaluated first.)
4 Click OK.
2 In the left pane of the Infrastructure Management window, right-click the node
for the routing rules you want to delete; for example, Repeater Routing Rules.
Then select Rules Management from the pop-up menu.
3 In the Rules Management panel, select the rule you want to delete and click
Delete Rule .
For example, you might create a routing rule based on a target server host name and
customer name properties.You would use the New Rule wizard only when you
want to create complex routing rules.
Note
If you use the New Rule wizard to add complex routing rules and then run the
Routing Wizard again, the Routing Wizard overwrites any existing routing policy
and all rules.
2 In the left pane of the Infrastructure Management window, right-click the node
for the routing rules you want to manage; for example, Repeater Routing Rules.
Then select Rules Management from the pop-up menu.
3 In the Rules Management panel, click Add Rule . The New Rule wizard opens
and shows the General panel.
4 Complete the information about the following wizard panels, depending on the
type of routing rule you are creating.
Support Data Generation Lets you generate data about Applications Servers
and other components in the BMC Server Automation environment and package
that data into a zip file.
Diagnostic Services Lets you run predefined tests to evaluate the status of the
BMC Server Automation environment while it is running and to identify issues.
For information about using these tools, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Collecting+diagnostics.
Microsoft Windows
Oracle Solaris
Fujitsu Solaris
IBM AIX
Oracle Linux
Note
Patch management is supported for HP-UX using an external tool called Vendor
Patch Content (VPC). VPC is included as part of BMC Server Automation.
The following steps summarize the patch management process in BMC Server
Automation:
1 Create a patch catalog, using BMC Server Automation, to manage patches stored
on the server. Patch downloads can occur either:
2 Analyze target servers to determine which patches are required on each server.
3 Package and deploy patches. BMC Server Automation creates BLPackages that
contain the missing payload and Deploy Jobs that remediate the target servers.
4 Re-analyze the servers to ensure that each is at the required patch level.
Note
Best Practice: Set up a small test group of servers and run the patch process on the
group. Then expand the process to all servers in the organization.
Online modePatches are downloaded directly from the appropriate product site.
Use Offline mode if you work in an air-gapped environment, where the BMC Server
Automation Application Server does not have external Internet access. In Offline
mode, you use the BMC offline Patch Downloader utility to download metadata and
payload information to a server with Internet access. After downloading, you can
transfer the metadata and payload information (using removable storage) to the
patch repository within the air-gapped environment.
The Patch Downloader utilities run scripts that use XML configuration files (samples
are provided) containing required information such as the repository location, as
well as filters used during downloading from the vendor website.
1 Preparatory tasks
3 Patching tasks
Task Description
Preparatory tasks
Defining role-based To create or update a catalog, you must be assigned a role that includes the
permissions necessary permissions. To facilitate division of responsibilities, you can assign
permissions to one role or divide them between several roles.
For a list of the required permissions, see Role-based permissions for patch
catalog on page 1023.
For details about assigning roles and permissions, see Managing
authorizations on page 168.
For a list of the required permissions for creating Patching Jobs and for
deploying patches, see: https://docs.bmc.com/docs/display/bsa82/RBAC
+permissions+for+patch+management.
Task Description
Configuring Global Global Configuration parameters provide basic information used during patch
Configuration catalog creation and updating, as well as for Patch and Remediation Jobs.
parameters The following parameter groups are available:
For details about the global configuration parameters, see Global Configuration
parameter list on page 1025.
Defining the location of (Windows only) To deploy Microsoft Office patches, BMC Server Automation
Microsoft Windows must have access to a network location containing installation media for
installation media for Microsoft Office. Because target servers can run different versions of Microsoft
Microsoft Office patch Office, you might need to specify a different location for each target server or
deployment Smart Group.
For details about defining locations of Microsoft Office patch media, see
Defining the location of Microsoft Windows installation media for Microsoft
Office patch deployment on page 1032.
Building an offline patch repository
(Offline mode only)
Obtaining the Patch From the BMC Software EPD site, download the appropriate utilities for building
Downloader utilities your offline repository. The utilities are platform-specific. You must know which
from BMC Software platform you plan to use to download your patches.
For details, see Downloading patch downloader utilities on page 1033.
Preparing XML Use the utilities that you downloaded from the BMC Software EPD site to
configuration files for prepare the XML configuration files for downloading the patch content.
downloading patch For details, in Offline Patch Downloader utility on page 1032.
content
Downloading patches to To download the patch content, use the utilities that you downloaded from the
the offline patch BMC Software EPD site and the XML configuration files that you prepared.
repository For details, see the appropriate section for the platform type that you want to
patch in Offline Patch Downloader utility on page 1032.
Patching
Creating and updating a For both types of repositories, online and offline, you create a patch catalog using
Patch Catalog the BMC Server Automation Console. Patches are added to the catalog as depot
objects according to filters that you define for the catalog.
To ensure that you are working with valid patch content, you must run a Catalog
Update Job before you run a Patch Job.
For details, see Creating a patch catalog on page 1076.
Task Description
Creating and running a A Patching Job has two parts:
Patching and
Remediation Job AnalysisAnalyzes the configuration of target servers and determines the
required patches.
Remediation
1 Downloads the payload from the vendor sites to the Patch Repository
You can choose to run only the Analysis part of a Patching Job, and then run
Remediation later, or you can run Remediation immediately after the Analysis.
For details about Patching Jobs, see Creating a Patching Job on page 1110. For
details about running Remediation Jobs separately, see Manually remediating
servers on page 1134.
Preparatory tasks
Before you can begin patch management-related tasks, you must perform the
following preliminary tasks:
(Microsoft Windows only) Identify the location of the installation media required by
Microsoft Windows servers.
Define Role and ACL Policy definitions using role-based access control. For more
details, see Access management on page 165.
To be able to view results of Patching Jobs created from a Patch Catalog, you must
have the DepotObject.Read permission enabled.
The Patch Global Configuration tabs are displayed at the bottom of the console.
Note
To eliminate the possibility of overwriting proxy server settings defined for the
BMC Server Automation Application Server, or having to change these
settings, these jobs do not use the same proxy server settings as the BMC Server
Automation Application Server.
Platform-specific tabs for each platform (such as the Windows tab and the
Solaris tab) -- Parameters that apply only to that specific platform type
SQUID
NTLM
NTLM-V2
User Name
Enter the user name required to log onto the proxy server. If this is defined,
the Internet connection is through the proxy server.
Password
Enter the password associated with the defined User Name required to log
onto the proxy server.
Domain
Host
Port
Enter the port number used for communication with the proxy server.
Note
The following table describes parameters that are platform-specific. You must enter
this information for every platform that you want to patch using BMC Server
Automation.
RHN Username
(Red Hat Linux only) user name for accessing the Red Hat Network
RHN Password
(Red Hat Linux only) password for accessing the Red Hat Network
Oracle Username
Oracle Password
The default batch size used for parallel processing during a Catalog Update
Job. The number of catalog objects processed by each batch. If no value is
entered, the default value is 300.
Note: Setting a lower default value speeds up catalog update but consumes
more resources on the BMC Server Automation Console; conversely, setting a
higher default value slows down catalog update but consumes less resources.
After you set this value, do not change it unless specifically required.
The default batch size used for parallel processing during a Patching Job. The
number of analysis processes handled by each batch. If no value is entered,
the default value is set at 100.
Note: Setting a lower default value speeds up analysis but consumes more
resources on the BMC Server Automation Console; conversely, setting a
higher default value slows down analysis but consumes less resources. After
you set this value, do not change it unless specifically required.
Action on Failure
The action that BMC Server Automation takes if a patch fails to deploy:
IgnoreIgnore the failure. The Deploy Job continues and the results show
the job as succeeding.
Ldom option
None (default value)This option ignores the LDoms and treats the
targets as physical installations of Solaris. Use this option if you want to
ignore the LDoms even if LDom packages are installed on your computer.
Stop Ldoms using ldm stopThis option stops the LDoms using the ldm
stop command (however, the guest LDoms are not gracefully shut down).
(Solaris Only) The location in the Depot for the file used to override single-
user mode and reboot settings for a particular patch.
(Solaris Only) The location of the file containing released information from
Oracle about clusters. Information contained in this file is used to
prepopulate the filter selection lists found in the patch catalog wizard.
(Windows Only) The location of the file containing released information from
Shavlik. Information contained in this file is used to pre-populate the filter
selection lists found in the patch catalog wizard.
(SuSE Only) The location of the file containing released information of service
packs from Novell. Information contained in this file is used to pre-populate
the filter selection lists found in the patch catalog wizard.
(Windows, Solaris, and Red Hat Linux) The number of attempts made before
reporting failure if BMC Server Automation fails to connect to a vendor site.
(Windows, Solaris, and Red Hat Linux) The length of time, in milliseconds, that
BMC Server Automation waits before making another attempt to connect to
the vendor site.
(AIX Only) The location of the file containing released information from IBM
about available Technology Levels and Service Packs. Information contained
in this file is used to prepopulate the Technology Level and Service Pack filter
selection lists found in the patch catalog wizard.
Analysis Option
Stop Analysis if any applied fileset foundSelect to stop analysis if any fileset
is found in the applied state on a target server. Analysis ends on that
server but continues on all other target servers included in the Patching
Job if the servers do not have filesets in the applied state. This option can
also be set for an individual Patching Job.
Precommit Option
NoneThe state of all currently installed filesets in the Applied state does
not change.
Deploy Option
Apply and CommitDuring deployment, all filesets for the target server are
installed in the Commit state.
Apply OnlyDuring deployment, all filesets for the target server are
installed in the Apply state.
The Deploy Job sends commands to the operating system which in turn
sends responses back to BMC Server Automation indicating that the
commands succeeded. In most cases, standard commands are used but
occasionally, the operating system uses a return code not known to BMC
Server Automation. Unknown codes entered in this field are defined to BMC
Server Automation as success return codes.
The Deploy Job sends commands to the operating system which in turn
sends responses back to BMC Server Automation indicating that the
commands failed. In most cases, standard commands are used but
occasionally, the operating system uses a return code not known to BMC
Server Automation. Unknown codes entered in this field are defined to BMC
Server Automation as failure return codes.
The Deploy Job sends commands to the operating system which in turn
sends warnings back to BMC Server Automation. In most cases, standard
warnings are used; occasionally, the operating system uses a return code not
known to BMC Server Automation. Unknown codes entered in this field are
defined to BMC Server Automation as warning return codes.
The Deploy Job sends commands to the operating system which in turn
sends back a request for reboot to BMC Server Automation. In most cases,
standard commands are used; occasionally, the operating system uses a
return code not known to BMC Server Automation. Unknown codes entered
in this field are defined to BMC Server Automation as reboot return codes.
(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the
operating system returns an exit code if the action was successful. In most
cases, standard commands are used; occasionally, the operating system uses
a return code not known to BMC Server Automation. Unknown codes
entered in this field are defined to BMC Server Automation as undeploy
success return codes.
(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the
operating system returns an exit code if the action failed. In most cases,
standard commands are used; occasionally, the operating system uses a
return code not known to BMC Server Automation. Unknown codes entered
in this field are defined to BMC Server Automation as undeploy failure
return codes.
(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the
operating system may return a warning. In most cases, standard commands
are used; occasionally, the operating system uses a return code not known to
BMC Server Automation. Unknown codes entered in this field are defined to
BMC Server Automation as undeploy warning return codes.
(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the
operating system may send back a request for reboot to BMC Server
Automation. In most cases, standard commands are used; occasionally, the
operating system uses a return code not known to BMC Server Automation.
Unknown codes entered in this field are defined to BMC Server Automation
as reboot return codes
Command Priority
(Microsoft Windows only) One of the commands that BMC Server Automation
runs on target servers during Patching Jobs consumes a large amount of CPU
power. On servers that only have a single CPU this can give the appearance
of a system hang. It may also have an effect on other processes that are
running on the target server.
If you are patching single-CPU Windows servers, you can lower the priority
for this command using the Command Priority option. This causes this
specific command to run at a lower priority, slowing down this process, and
allowing other processes to proceed normally.
Normal
Below Normal
The Shavlik URL Configuration tab provides information about the two
configuration files required by Microsoft Windows.
The following table lists the fields that are available for configuring the Shavlik files.
To edit the details, select the file and click Edit Patch Configuration File).
(Read-only) the name of the configuration file downloaded from the Shavlik
Technologies website.
URL of the Shavlik Technologies website where the PD5.cab (or PD5.xml) or
HFNetChk7b.cab (or HFNetChk7b.xml) configuration file can be
downloaded or the NSH location of the file on your servers. You can change
this to any URL that has valid copies of these files.
Download
Description
Enter a description for the URL/NSH patch you entered in the URI box.
Prepare a network location where BMC Server Automation can access the
installation media for Microsoft Office during patch deployment (SMB Share).
Set up a user name and password for access to the installation media.
Tip
BMC Server Automation recommends that you deploy missing service packs before
beginning hotfix deployment.
1 In the Servers folder, right-click the target server or smart group and select Set
Property.
Column Value
MS_OFFICE_INSTALL_ Enter the full, UNC-formatted, path to the location where the
LOCATION installation media is located.
MS_OFFICE_INSTALL_ Enter a user name that BMC Server Automation can use to access the
USERNAME installation media.
MS_OFFICE_INSTALL_ PWD Enter the password for the user name supplied in
MS_OFFICE_INSTALL_USERNAME.
3 Click OK.
If there is no Internet access to BMC Server Automation, you work in Offline Mode
using the Patch Downloader utility that is supplied by BMC to download metadata
and payload information to a server with Internet access. After downloading, you
transfer metadata and payload information, using removable storage, to the patch
repository within the air-gapped environment.
The Patch Downloader utility runs a script and uses a configuration file containing
information such as the NSH path to a network location and filters used for
download from the vendor website. The following sections describe the process of
creating the configuration file and running the Patch Downloader utility for each of
the supported platforms.
Note
For the Patch Downloader utilities to function properly, you must have Java 1.6 or
later installed.
To know which file to download, you need to determine what platform you will be
using to run the utilities.
The downloader utilities are packaged in files that are named as follows:
All-OS-Patch-Downloaders-platform-build.extension
platform is the supported platform on which you can run the utilities.
The compressed files contain utilities for downloading patches from all supported
platforms as well as sample XML files for building configuration files.
The following sections explain how to build the configuration files and how to use
the downloader utilities.
The Patch Downloader is: windows_downloader.bat. To install, extract the file and
place in a directory on the server.
This information includes definition of a proxy server (if one is used), identification
of a local, temporary directory on the server that is used by the Patch Downloader
utility during download, and filter definitions which determine the metadata and
payload that is downloaded from the Shavlik Technologies website.
Note
Ensure that the editor you are using to edit the XML file supports UTF-8 encoding.
The downloaded utility expects a configuration file with UTF-8 encoding. If the file
uses a different encoding method, the application may fail with parsing errors.
Use the following command to encrypt the password supplied to the proxy server by
the Patch Downloader utility. You must specify the resulting encrypted password in
the <password></password> parameter in the configuration XML file.
Tag Description
<protocol></protocol> The protocol for which to assign the proxy configuration. Valid
values are:
http
https
ftp
<port></port> The port used for communication with the proxy server.
<host></host> The proxy servers host name or IP address.
<username></username> The user name required for authentication to communicate with
the proxy server.
<password></password> An encrypted password for the specified user.
<domain-name></domain-name> The proxy server domain name to be used for authentication.
<proxy-type></proxy-type> The type of proxy server. Valid values are:
None
indicates that no proxy server is used
NTLM
NTLM-v2
Squid
Tag Description
<temporary-location>c:\tmp</ location where files can be stored temporarily during the
temporary-location>>
download process
<validate-payload- indicates whether the download utility checks the certificate of the
certificate>true|false</
validate-payload-certificate> patch payload before download
Valid entries are either true or false.
<payload-repository-location></ local location of the patch repository where metadata and payload
payload-repository-location>
are stored
<download-request-retries></ number of times the download utility attempts to download if the
download-request-retries>
first attempt at downloading a payload fails
Tag Description
<download-request-timeout></ number of milliseconds that the utility waits for a response before
download-request-timeout>
considering the attempt as failed
This parameter is useful if the http response is slow.
<downloader-parallel-threads></ number of downloads that can be performed in parallel
downloader-parallel-threads>
4 In the <subscription> tag, specify filters for limiting the patches that are included
in the download.
Note
The same filters entered here must also be entered during catalog creation.
For example, to create a filter that defines product category and language, use the
following syntax:
<subscription>
<products>
<include-product>
<product-category>Microsoft Windows Server 2003</product-category>
<product-category-language>English</product-category-language>
</include-product>
</products>
</subscription>
<subscription>
<products>
<include-product>
<product-category>Microsoft Windows Server 2003</product-category>
<product-category-language>English</product-category-language>
</include-product>
<include-product>
<product-category>Microsoft Office XP</product-category>
<product-category-language>English</product-category-
language>
</include-product>
</products>
</subscription>
</windows-downloader-config>
downloaderConfigurationFilePath
Enter the location of the Configuration File used by the Patch Downloader.
This information includes definition of a proxy server (if one is used), identification
of a local, temporary directory on the server that is used by the Patch Downloader
utility during download, and download filter definitions.
Use the following command to encrypt the password supplied to the proxy server by
the Patch Downloader utility. You must specify the resulting encrypted password in
the <password></password> parameter in the configuration XML file.
Tag Description
<port></port> port number used to communicate with the proxy server
<host></host> IP address or host name of the proxy server
<username></username> user name required for authentication prior to communication with the
proxy server
<password></password> encrypted password for the specified user
<domain-name></domain-name> domain name of the proxy server
<proxy-type></proxy-type> type of proxy server used
Possible values are as follows:
None
indicates that no proxy server is used
NTLM
NTLM-V2
Squid
Tag Description
<temporary-location>c:\tmp</ location where files can be stored temporarily during the
temporary-location>>
download process
<payload-repository-location></ local location of the patch repository where metadata and payload
payload-repository-location>
are stored
<download-request-retries></ number of times the download utility attempts to download if the
download-request-retries>
first attempt at downloading a payload fails
<download-request-timeout></ number of milliseconds that the utility waits for a response before
download-request-timeout>
considering the attempt as failed
This parameter is useful if the http response is slow.
<downloader-parallel-threads></ number of downloads that can be performed in parallel
downloader-parallel-threads>
4 In the <subscription> tag, specify filters for limiting the patches that are included
in the download. Use the following XML tags:
Tag Description
<cluster-name></cluster-name> filter that defines a cluster name
<cluster-path></cluster-path>
<solaris-downloader-config>
<config>
<proxy-settings>
<port>8080</port>
<host>IPAddress</host>
<username>patch</username>
<password>NWKIPRTPCWEB</password>
<domain-name></domain-name>
<proxy-type>ntlm-v2</proxy-type>
</proxy-settings>-->
<temporary-location>c:\tmp</temporary-location>
<payload-repository-location>d:\tmp\solaris</payload-repository-
location>
<metadata-override-file-path></metadata-override-file-path>
<download-request-retries>10</download-request-retries>
<download-request-timeout>180000</download-request-timeout>
<downloader-parallel-threads>10</downloader-parallel-threads>
</config>
<subscription>
<cluster-filter>
<cluster-name>Solaris 9 SPARC Sun Alert Patch Cluster</cluster-name>
<cluster-path></cluster-path>
</cluster-filter>
<cluster-filter>
<cluster-name>Java ES Required OS Solaris 10 x86</cluster-name>
<cluster-path></cluster-path>
</cluster-filter>
<os-arch-filter>
<os>9</os>
<arch>x86</arch>
</os-arch-filter>
<os-arch-filter>
<os>10</os>
<arch>sparc</arch>
</os-arch-filter>
<patch-ids-filter>
<patch-id>100287-05</patch-id>
<patch-id>100323-05</patch-id>
<patch-id>100386-01</patch-id>
<patch-id>100393-01</patch-id>
</patch-ids-filter>
</subscription>
</solaris-downloader-config>
downloaderConfigurationFilePath
oracleUserName
The user name required to log onto the Oracle website. Quotation marks are
required.
oraclePassword
The password required to log onto the Oracle website. Quotation marks are
required.
Single user mode and reboot settings override file on page 1042
For clarity, these files are given a default name which is used throughout the
chapter. However, there is no requirement to use this name. After you prepare the
files, manually add them to the Depot.
Override file
As sometimes happens, you might identify errors in the patchdiag.xref file
downloaded from the Oracle website.
Corrections are made in a separate override file, using the default name
xref_content.info, which updates the patchdiag.xref file during patch analysis. The
sample file showing the format is as follows:
138194|01|Jun/11/08| | | | |Unbundled|i386;|SUNWservicetagr:
1.0,REV=2007.05.21.20.36;SUNWservicetagu:
1.0,REV=2007.05.21.20.36;SUNWstosreg:1.0,REV=2007.05.21.20.36;|Service Tags
SunOS 5.10_x86
138215|01|Nov/11/08| | | | |10|sparc;|SUNWesu:
11.10.0,REV=2005.01.21.15.53;SUNWxcu4:11.10.0,REV=2005.01.21.15.53;|SunOS
5.10: sort patch
138216|01|Nov/11/08| | | | |10_x86|i386;|SUNWesu:
11.10.0,REV=2005.01.21.16.34;SUNWxcu4:11.10.0,REV=2005.01.21.16.34;|SunOS
5.10_x86: sort patch
Entries in the override file must be identical to the same entries contained in the
patchdiag.xref file (with corrected information inserted). Entries in the override file
supersede the corresponding entries in the patchdiag.xref file during creation and
update of a patch catalog. The following fields cannot be overridden:
Patch ID
Version Number
Release Date
All other information can be overridden. New entries, which have no corresponding
entry, are added to the patchdiag.xref file.
After you create the XML file, import it into the Depot and point the Patch Catalog to
this file.
The following sample file shows the format required for this file:
<solaris-sumreboot-info>
<patch>
<patch-id>113000-07</patch-id>
<reboot-info>rebootafter</reboot-info>
<single-user>singleuser</single-user>
</patch>
<patch>
<patch-id>138194-01</patch-id>
<reboot-info>rebootimmediate</reboot-info>
<single-user>singleusernone</single-user>
</patch>
<patch>
<patch-id>138195-01</patch-id>
<reboot-info>rebootnone</reboot-info>
<single-user>singleuser</single-user>
</patch>
<patch>
<patch-id>138215-01</patch-id>
<reboot-info>reconfigimmediate</reboot-info>
<single-user>singleusernone</single-user>
</patch>
<patch>
<patch-id>138216-01</patch-id>
<reboot-info>reconfigafter</reboot-info>
<single-user>singleuser</single-user>
</patch>
</solaris-sumreboot-info>
Either this utility must be run on an AIX platform, or the Repository Location field
in the patch catalog must be on an AIX platform. If both are not on AIX platforms,
you cannot create an AIX patch catalog.
Note
The Java Runtime Environment (JRE) for AIX is not included with BMC Server
Automation. Before running the downloader for AIX, you must download and
install a licensed copy of JRE 1.6.
This information includes definition of a proxy server (if one is used), identification
of a local, temporary directory on the server that is used by the Patch Downloader
utility during download, and download filter definitions.
Use the following command to encrypt the password supplied to the proxy server by
the Patch Downloader utility. You must specify the resulting encrypted password
within the <password></password> tag in the configuration XML file.
Tag Description
<port></port> port number used to communicate with the proxy server
Tag Description
<host></host> IP address or host name of the proxy server
<username></username> user name required for authentication prior to communication with the
proxy server
<password></password> the encrypted password for the specified user name
<domain-name></domain-name> domain name of the proxy server
<proxy-type></proxy-type> type of proxy server used
Valid values are:
None
indicates that no proxy server is used
NTLM
NTLM-V2
Squid
Tag Description
<temporary-location>c:\tmp</ location where files can be stored temporarily during the
temporary-location>>
download process
<payload-repository-location></ local location of the patch repository where metadata and payload
payload-repository-location>
are stored
<download-request-retries></ number of times the download utility attempts to download if the
download-request-retries>
first attempt at downloading a payload fails
<download-request-timeout></ number of milliseconds that the utility waits for a response before
download-request-timeout>
considering the attempt as failed
This parameter is useful if the http response is slow.
<downloader-parallel-threads></ number of downloads that can be performed in parallel
downloader-parallel-threads>
4 In the <subscription> tag, specify filters for defining the patches that are included
in the download. Use the following XML tags:
Tag Description
<level-type-filter> You can define a filter for either a Technology Level (TL) or a
<level-number></level-number>
<level_type></level_type> Service Pack (SP) but you must use the version identifier provided
</level-type-filter> by AIX FixCentral. Use the following tags:
TLTechnology Level
SPService Pack
<apar-ids-filter> APAR filters use the operating system level used by the servers
<currentoslevel></
currentoslevel> and a specific APAR identifier. Use the following tags:
<apar-id></apar-id>
</apar-ids-filter> <currentoslevel> is the operating system level used by the
servers that you want to patch.
<ptf-ids-filter> PTF filters use the operating system level used by the servers and
<currentoslevel></
currentoslevel> a specific PTF identifier. Use the following tags:
<ptf-id></ptf-id>
</ptf-ids-filter> <currentoslevel> is the operating system level used by the
servers that you want to patch.
Tag Description
<update-type-filter> Update filters use the operating system level used by the servers
<currentoslevel></
currentoslevel> that you want to patch as well as the update type. Use the
<update-type></update-type> following tags:
</update-type-filter>
<currentoslevel> is the operating system level used by the
servers that you want to patch.
security
critical
latest
</update-type-filter>
</subscription>
</aix-downloader-config>
downloaderConfigurationFilePath
downloaderConfigurationFilePath
updatesFilePath
A name and location for the Updates File. After you create the file, add it to
the depot, and then enter the information in Global Configuration, in the AIX
Updates List File box. Quotation marks around the path are required.
To populate the latest Technology Levels and Service Packs on AIX Catalog filters
1 Copy the Offline Patch Downloader, extract it, and execute the following command:
aix_downloader.sh -configFile "sample-downloader-config-files/sample-aix-
downloader-config.xml"
-generateUpdateList "updateListfileName.xml"
2 Navigate to the updateListfileName.xml file that contains the latest updates for
AIX.
Note
The updateListfileName.xml file is generated by downloading the Updates list
for AIX.
6 Add the updateListfileName.xml file to the AIX Update List file field and save it.
After you save the updateListfileName.xml file, you can see the latest
Technology Levels and Service Pack information at the AIX Catalog filters.
1 On the command line, enter the following command to show the downloader
help on the standard output:
aix_downloader.bat|sh aix_downloader.sh -help
1 On the command line, enter the following command to send the downloader
version information to the standard output:
aix_downloader.bat|sh aix_downloader.sh -version
1 On the command line, enter the following command to send a list of supported
products and languages to the standard output:
aix_downloader.bat|sh aix_downloader.sh -listProducts
Use this procedure if the patch repository was initially created using BMC
BladeLogic Vendor Patch Content.
Note
If you used AIX Data Center mode in VPC to create the repository, you will not be
able to migrate this repository.
In this procedure, you define the location where that data is stored as well as the
location where you want to create the repository used by BMC Server Automation.
-repoLocation
-srcLocation
location of the metadata and payload you downloaded from the vendor site
using the following format:
Loc1 (or Loc2 ) is a location on a server with Internet access where the
metadata and payload are stored.
You can supply more than one combination using a semi-colon (;) between
each set of information. Quotation marks are required.
-fixgetFile
-renamePayload
(Optional) If the source and the new repository are the same location, rename
older payloads with the naming conventions used in the version 8.1.00 patch
repository. If not specified, new copies of the older payloads are created.
Quotation marks around the path are required.
The Patch Downloader utility uses configuration and filter information to download
metadata and payload from the Red Hat Network website.
Starting with BMC Server Automation version 8.2, you can download metadata and
payloads for both the supported base channels and their child channels using the the
Patch Downloader utility. For more information about what constitutes base
channels and child channels, see: http://docs.redhat.com/docs/en-US/
Red_Hat_Network_Satellite/5.4/html-single/Channel_Management_Guide/
index.html#chap-Channel_Management_Guide-Introduction_to_RHN_Channels.
The server that houses the patch repository must have the createrepo and
pythonurlgrabber packages pre-installed before download begins. The required
version for the packages is as follows:
Note
The packages must be of the versions listed in the previous table. Higher versions of
the packages will work, provided the versions of createrepo and python-urlgrabber
are compatible.
This information includes definition of a proxy server (if one is used), identification
of a local, temporary directory on the server that is used by the Patch Downloader
utility during download, and download filter definitions.
Use the following command to encrypt the password supplied to the proxy server by
the Patch Downloader utility. You must specify the resulting encrypted password in
the <password></password> tag in the configuration XML file.
Tag Description
<port></port> port number used to communicate with the proxy server
<host></host> IP address or host name of the proxy server
<username></username> user name required for authentication prior to communication with the
proxy server
<password></password> encrypted password for the specified user
<domain-name></domain-name> domain name of the proxy server
<proxy-type></proxy-type> type of proxy server used
Valid values are:
None
indicates that no proxy server is used
NTLM
NTLM-V2
Squid
Tag Description
<temporary-location>c:\tmp</ location where files can be stored temporarily during the
temporary-location>>
download process
<payload-repository-location></ local location of the patch repository where metadata and payload
payload-repository-location>
are stored
<download-request-retries></ number of times the download utility attempts to download if the
download-request-retries>
first attempt at downloading a payload fails
<download-request-timeout></ number of milliseconds that the utility waits for a response before
download-request-timeout>
considering the attempt as failed
This parameter is useful if the http response is slow.
Tag Description
<downloader-parallel-threads></ number of downloads that can be performed in parallel
downloader-parallel-threads>
4 Modify filters, in the <subscription> command. These define patches that are
included in the download:
To create a filter that downloads the latest RPMs by errata type, use the
following syntax:
<errata-type-filter>
<os></os>
<arch></arch>
<channel-label></channel-label>
<errata-severity>
<critical></critical>
<high></high>
<moderate></moderate>
<low></low>
</errata-severity>
<errata-type>
<security></security>
<bugfix></bugfix>
<enhancement></enhancement>
</errata-type>
</errata-type-filter>
Parameter Description
<os></os> operating system for the channel label
<arch></arch> architecture for the channel label
<channel-label></channel-label> channel label to download
<errata-severity></errata-severity> Configure filter for metadata download of security
advisory errata patches. For each classification, enter True
to include patches of that type or False to exclude patches
of that type.
<critical>
<high>
<moderate>
<low>
Parameter Description
<errata-type></errata-type> Configure filter for metadata download of errata
according to type. For each classification, enter True to
include patches of that type or False to exclude patches of
that type.
<security></security>
<bugfix></bugfix>
<enhancement></enhancement>
To create a filter that downloads a specific errata by errata id, use the following
syntax:
<errata-ids-filter>
<os></os>
<arch></arch>
<channel-label></channel-label>
<errata-ids>
<errata-id></errata-id>
</errata-ids>
</errata-ids-filter>
Parameter Description
<os></os> operating system for the channel label
<arch></arch> architecture for the channel label
<channel-label></channel- channel label that you want to download
label>
<errata-id></errata-id> a valid Errata ID for the channel label specified in the filter
To create a filter that downloads a specific update level, use the following syntax:
<update-level-filter>
<os></os>
<arch></arch>
<channel-label></channel-label>
<update-level></update-level>
</update-level-filter>
Parameter Description
<os></os> operating system for the channel label
<arch></arch> architecture for the channel label
<channel-label></channel- channel label you want to download
label>
Parameter Description
<update-level></update- a valid update level for the channel label specified in the filter
level>
Note: The update-level filter works only on Linux computers. It does
not work on windows computers.
</subscription>
</redhat-downloader-config>
downloaderConfigurationFilePath
rhnUserName
user name required to log onto the Red Hat Network website
rhnPassword
-isoLocation "isoFilePath"
-osArch "operatingSystemArchitecture"
Note
You must execute the extractPackagesFromISO command on a Linux computer
only.
patchRepositoryFilePath
isoFilePath
operatingSystemArchitecture
For example:
redhat_downloader.bat
-extractPackagesFromISO -repoLocation "C:\redhat"
-isoLocation "\redhatDVD.iso"
-osArch "RHAS4-x86"
1 Obtain the list of supported base channels and their child channels.
2 Identify the child channels. The child channels are listed after the base
channels. To help you to distinguish between the child channels and the base
channels, the output displays a blank line after the base channels. In the
following sample output of the listChannels command, the supported child
channels start with MRG Grid v. 2 (for RHEL 6 Server x86).
2 For each child channel that you want to download, specify an <errata-type> entry
in your .XML configuration file, and provide the channel label of the child
channel within the <channel-label> parameter.
4 Run the Patch Downloader Utility for Red Hat Enterprise Linux.
x86
...
The patch repository was initially created using BMC BladeLogic Vendor Patch
Content
You used a patch download utility that was not supplied by BMC Server
Automation.
In this procedure, you define the location where that data is stored as well as the
location where you want to create the repository used by BMC Server Automation.
locationOperSysArch
location of the metadata and payload you downloaded from the vendor site,
in the following format:
Loc1 (or Loc2) is a location on a server with Internet Access where the metadata
and payload was stored.
You can supply more than one combination using a semi-colon (;) between
each set of information. Quotation marks are required.
repositoryPath
Note
The packages must be of the versions listed here. Earlier or later versions may not
function properly.
This information includes definition of a proxy server (if one is used), identification
of a local, temporary directory on the server that is used by the Patch Downloader
utility during download, and download filter definitions.
Use the following command to encrypt the password supplied both to the vendor
site and to the proxy server by the Patch Downloader utility. You must specify the
resulting encrypted password in both <password></password> tags in the
configuration XML file.
Parameter Description
<port></port> port number used to communicate with the proxy server
<host></host> IP address or host name of the proxy server
<username></username> user name required for authentication prior to communication with the
proxy server
<password></password> encrypted password for the specified user
<domain-name></domain-name> domain name of the proxy server
<proxy-type></proxy-type> type of proxy server used
Valid values are:
None
indicates that no proxy server is used
NTLM
NTLM-V2
Squid
Tag Description
<temporary-location>c:\tmp</ location where files can be stored temporarily during the
temporary-location>>
download process
<payload-repository-location></ local location of the patch repository where metadata and payload
payload-repository-location>
are stored
<download-request-retries></ number of times the download utility attempts to download if the
download-request-retries>
first attempt at downloading a payload fails
<download-request-timeout></ number of milliseconds that the utility waits for a response before
download-request-timeout>
considering the attempt as failed
This parameter is useful if the http response is slow.
<downloader-parallel-threads></ number of downloads that can be performed in parallel
downloader-parallel-threads>
4 Modify the <subscription> command to create a filter that downloads the latest
RPMs according to operating system, architecture, and channel combinations,
according to the following syntax:
Parameter Description
<os></os> operating system for the channel label
<arch></arch> architecture for the channel label
<url></url> URL for the vendor site
<username></username> Mirror credentials user name for logging on to the SUSE
Linux Enterprise website
<password></password> encrypted password for the specified password
<arch>x86</arch>
<url>https://nu.novell/repo/$RCE/SLES10-Updates/sles-10-x86/rpm/</url>
<username>abs</username>
<password>suse1234</password>
</os-arch-filter>
</subscription>
</suse-downloader-config>
The following table lists the URLs for the different Operating System and
Architecture combinations of SUSE Linux Enterprise. You can use the required URL
in the configuration file for SUSE Linux Enterprise.
Note
The Patch downloader also downloads base rpm files which are not added to the
patches in the Catalog. Hence, the offline SUSE Linux Catalog adds lesser number of
patches to the Catalog than it has downloaded.
downloaderConfigurationFilePath
Note
Quotation marks are required.
Note
You must execute the extractPackagesFromISO command on a Linux computer
only.
patchRepositoryFilePath
isoFilePath
operatingSystemArchitecture
The patch repository was initially created using BMC BladeLogic Vendor Patch
Content
You used a patch download utility that was not supplied by BMC Server
Automation.
In this procedure, you define the location where the data is stored, as well as the
location to create the repository used by BMC Server Automation.
Example
suse_downloader.sh -createRepo -srcLocation "/Source_Location1,SLES9-x86;/
Source_Location2;SLES9-x86_64" -repoLocation "/Repository_Location"
-srcLocation
The location of the metadata and payload you downloaded from the vendor
site, using the following format:
"Loc1,os-arch;Loc2,os-arch"
Loc1 (or Loc2) is a location on a server with Internet access where the metadata
and payload is stored. In the example, Source_location1 contains x86 rpms and
Source_location2 contains x86_64 rpms.
You can supply more than one combination using a semi-colon (;) between
each set of information. Quotation marks are required.
repositoryPath
The local location where the repository, used by BMC Server Automation, is
stored. Quotation marks around the path are required. In the example,
Repository_Location is the location where the new repository is created.
Creation of a patch catalog requires that the following packages are pre-installed on
the server that hosts the patch repository:
Note
The packages must be of the versions listed here. Earlier or later versions may not
function properly.
This information includes definition of a proxy server (if one is used), identification
of a local, temporary directory on the server that will be used by the Patch
Downloader utility during download, and download filter definitions.
Use the following command to encrypt the password supplied to the proxy server by
the Patch Downloader utility. You must specify the resulting encrypted password in
the <password></password> parameter in the configuration XML file.
Use the following command if you are running the downloader on Microsoft Windows:
Use the following command if you are running the downloader on UNIX:
Parameter Description
<port></port> port number used to communicate with the proxy server
<host></host> IP address or host name of the proxy server
<username></username> user name required for authentication prior to communication with the
proxy server
<password></password> encrypted password for the specified user
<domain-name></domain-name> domain name of the proxy server
<proxy-type></proxy-type> type of proxy server used
Valid values are:
NTLM
Squid
Tag Description
<temporary-location>c:\tmp</ location where files can be stored temporarily during the
temporary-location>>
download process
Tag Description
<payload-repository-location></ local location of the patch repository where metadata and payload
payload-repository-location>
are stored
<download-request-retries></ number of times the download utility attempts to download if the
download-request-retries>
first attempt at downloading a payload fails
<download-request-timeout></ number of milliseconds that the utility waits for a response before
download-request-timeout>
considering the attempt as failed
This parameter is useful if the http response is slow.
<downloader-parallel-threads></ number of downloads that can be performed in parallel
downloader-parallel-threads>
4 Modify the <subscription> command to create a filter that downloads the latest
RPMs according to operating system, architecture, and channel combinations. Use
the following XML tags:
Parameter Description
<os></os> operating system for the channel label
<arch></arch> architecture for the channel label
<channel-label></channel-label> channel label to download
downloaderConfigurationFilePath
oelUserName
The user name required to log onto the Oracle Enterprise Linux website.
Quotation marks around the path are required.
oelPassword
The password required to log onto the Oracle Enterprise Linux website.
Quotation marks are required.
Note
You must execute the extractPackagesFromISO command on a Linux computer
only.
patchRepositoryFilePath
The local location of the patch repository used by the Patch Downloader.
Quotation marks around the path are required.
isoFilePath
The location of the ISO from which RPMs are extracted. Quotation marks
around the path are required.
operatingSystemArchitecture
oelUserName
user name required to log onto the Oracle Enterprise Linux website
oelPassword
The patch repository was initially created using BMC BladeLogic Vendor Patch
Content
You used a patch download utility that was not supplied by BMC Server
Automation.
In this procedure, you define the location where the data is stored and where to
create the repository used by BMC Server Automation.
Example
oel_downloader.sh -createRepo -srcLocation /repo/oel_repo1,OEL5-x86;/
repo/oel_repo2,OEL4-x86
-repoLocation /repo/oel_new_repo
locationOperSysArch
The location of the metadata and payload you downloaded from the vendor
site, using the following format:
Loc1,os-arch;Loc2,os-arch
Loc1 (or Loc2) is a location on a server with Internet access where the metadata
and payload is stored.
You can supply more than one combination using a semi-colon (;) between
each set of information.
Note
Quotation marks are required.
repositoryPath
The local location where the repository, used by BMC Server Automation, is
stored.
Note
Quotation marks around the path are required.
For both types of repositories, online and offline, you create a patch catalog through
the BMC Server Automation Console. Patches are added to the catalog as depot
objects according to filters defined for the catalog.
Note
The deploy option for the Patch Catalog does not involve patch analysis and hence
cannot account for dependencies on other patches. This option does not check for
payload availability. BMC recommends that the deploy option must be used only by
advanced users who would want to deploy a patch without performing a patch
analysis.
(Red Hat Enterprise Linux, SUSE Linux Enterprise, and Oracle Enterprise Linux) you
must preinstall the following packages on the server that hosts the patch repository:
Note
The packages must be of the versions listed here. Earlier or later versions may not
function properly.
1 Right-click a folder in the Depot and choose New => Patch Catalog >
platformName > Catalog.
For platformName, substitute the platform such as Windows Patch Catalog, Red
Hat Patch Catalog.
2 Provide information for the patch catalog as described in the following sections:
Note
After they are created, all panes in the wizard remain available for edit and
review except General and Permissions.
Defined options include locations (such as location of the source files, the repository,
the signature file, and so on) as well as filters and whether local copies of the files are
created on the target server or downloaded directly during deployment.
For Microsoft Windows Server 2008, the windows update service must be started
prior to deploying patches.
Catalog Mode
Select one of two options:
Source from Vendor (Online Mode): Use this mode if the BMC Server
Automation Application Server is installed on a server with Internet access.
Source from Disk Repository (Offline Mode): Use this mode in a secured
environment where download occurs on a server, with Internet access, outside of
the environment.
Repository Options
Enter the following information:
Metadata files stored in this location are copied to the catalog automatically.
Payload files are not copied to the catalog.
Note
Payload files are not required to create the patch catalog.
BMC recommends that this location have ample free space. Repositories
typically contain many files, usually totaling gigabytes of data.
Agent mounts source for direct use at deployment (no local copy): A
Deploy Job instructs the agent on a target server to:
The value entered here depends on your selection in the Network URL type
for payload deployment box.
If you chose Copy to agent at staging, do not enter a value here. The value
is populated based on the repository location.
If you chose Agent mounts source for direct use at deployment (no local
copy), enter the NFS-accessible path to the location of the payload.
RBAC Policy
(Online Only) To download the payload (executables) at the same time as the
metadata, select the Download from Vendor check box.
Tip: You can also download the payload by right-clicking the catalog and
selecting Download.
Filters
Filters limit the amount of information brought into the catalog. You define a
combination of product and language (such as Microsoft Windows 2008 English).
There is no limit on the number of filters you can create but you must have at least
one. Only those hotfixes and bulletins that match the combinations you define are
added to the catalog.
If you are working in Offline Mode, the product/language combinations you define
must match those defined in the configuration file used by the download utility.
You can define filters during catalog creation or later, when editing the catalog. Click
Add Filter and enter the following:
Product
Language
Defined options include locations (such as location of the source files, the repository,
the patchdiag.xref file) as well as filters and whether local copies of the files are
created on the target server or downloaded directly during deployment.
Note
Before applying patches, make sure you are applying the correct patches. BMC
Server Automation supports undo for patches, but this rolls back the patches
without verification of the type of patches. Some types of patches, such as kernel
patches, should not be undone.
Note
BMC Server Automation can apply patches to global and local zone setups where no
lib or var is shared between the global and local zones. BMC Server Automation
does not support patching on whole-root and sparse-root zones.
BL does not stop local zones before applying patches to a global zone. Its
recommended to stop local zone before zone patching and users should try doing
this using a separate deploy command.
Catalog Mode
Select one of two options:
Source from Oracle (Online Mode): Use this mode if the BMC Server Automation
Application Server is installed on a server with Internet access.
Source from Disk Repository (Offline Mode): Use this mode in a secured
environment where download occurs on a server, with Internet access, outside of
the environment.
Oracle Credentials
If you selected Source from Oracle (Online Mode), enter the user name and
password used to access the vendor website.
Repository Options
Enter the following information:
(Offline only) location where existing metadata and payload files are stored
Note
Payload files are not required to create the patch catalog.
BMC recommends that this location have ample free space. Repositories
typically contain many files, usually totaling gigabytes of data.
For Fujitsu Solaris, contains the location created by the fj2pdx.pl script. This
script is available in the Support Files directory within All-OS-Patch-
Downloaders-platform-build.extension.
(Oracle Solaris Only) depot location of the file used to correct errors found in
the patchdiag.xref file that you added to the patch repository
depot location of the file used to override single user mode and reboot
settings for a particular patch
Agent mounts source for direct use at deployment (no local copy): A
Deploy Job instructs the agent on a target server to do the following:
Note
If you select the Agent mounts source for direct use at deployment (no local
copy) option, the Deploy Job does not copy patch payloads to a staging area
on the agent, so the job does not create any local copies of the patches on
target servers.
The value entered here depends on your selection in the Network URL type
for payload deployment box.
If you chose Copy to agent at staging, do not enter a value here. The value
is autopopulated based on the repository location.
If you chose Agent mounts source for direct use at deployment (no local
copy), enter the NFS-accessible path to the location of the payload.
Note
The Agent mounts source for direct use at deployment (no local copy)
option does not work if the patch requires the server to be rebooted into
single user mode. You must override the reboot requirement.
RBAC Policy
Select a predefined ACL policy. Permissions defined by the ACL policy are
assigned to all depot objects created in the catalog.
Filters
Filters limit the amount of information brought into the catalog.
A filter defines:
There is no upper limit to the number of filter combinations you can make but there
must be at least one. Only clusters and patches that match the combinations you
define are added to the catalog.
In Offline Mode, recreate the filters defined in the configuration file used by the
download utility.
You can define filters either when the catalog is created or later, when you edit the
catalog. Depending on the filter option you selected, provide specific details for the
To begin, click Add Filter and select one of the following options:
Os-Architecture
Patch IDs
Cluster
Identify a specific Oracle Solaris cluster. If the catalog works in offline mode,
you can enter a custom, Oracle Solaris cluster.
Note
If you create an online Oracle Solaris Catalog with filter type as cluster, the
download of patches will start automatically and the Download from Vendor
checkbox is disabled.
Catalog Mode
Select one of two options:
Source from IBM Network (Online Mode): Use this mode if the BMC Server
Automation Application Server is installed on a server with Internet access.
Credentials are not required.
Source from Disk Repository (Offline Mode): Use this mode in a secured
environment where download occurs on a server, with Internet access, outside of
the environment.
Repository Options
Enter the following information:
Metadata files stored in this location are copied to the catalog automatically.
Payload files are not copied to the catalog.
BMC recommends that this location have ample free space. Repositories
typically contain many files, usually totaling gigabytes of data.
(Offline Only)
(Online Only)
NSH path to the location where base-level payload files are stored. Base-level
payload files are not copied to the repository location.
URL of the location where base-level metadata and payload files are stored.
Specifying a value for this field is optional if you have selected the Copy to
agent at staging option for the Network URL Type For Payload Deployment
field.
Note
If the patches that you require do not contain dependencies, you need not specify
values for the Base Repository Location and Base Repository Network URL fields.
Note
For more information about how to upgrade or install AIX patches using the Base
Repository Location and the Base Repository Network URL options, see: https://
docs.bmc.com/docs/display/bsa82/Improved+patch+management+for+AIX.
Agent mounts source for direct use at deployment (no local copy): A
Deploy Job instructs the agent on a target server to either mount the
device specified in the URL or deploy patch payloads directly to the agent.
The value entered here depends on your selection in the Network URL Type
for Payload Deployment box.
If you chose Copy to agent at staging, do not enter a value here. The value
is autopopulated based on the repository location.
If you chose Agent mounts source for direct use at deployment (no local
copy), enter the NFS-accessible path to the location of the payload.
RBAC Policy
Permissions defined by the ACL Policy are assigned to all Depot objects
created in the catalog.
OS Base Version
Version of the operating system (OS) for which you want to source Technology
Levels, Service Packs, and so on
Filters
Filters limit the amount of information brought into the catalog. For an offline
catalog, re-create the filters defined in the configuration file used by the download
utility. Available filter types are as follows:
By Update Level
By Fix Type
By Fix ID
Only patches that match the combinations you define are added to the catalog. You
can define filters either when the catalog is created or later, when you edit the
catalog. To begin, click Add Filter and select from the following:
By Fix Type Select one of the following three fix types for a
particular update level All Latest Fixes, All
Security Fixes, or All Critical Fixes. Only one Fix
Type filter can be included in the patch catalog.
OS Level Fixes of a particular type are downloaded for the
Operating System Level defined here.
Catalog Mode
Select one of two options:
Source from Red Hat Network (Online Mode): Use this mode if the BMC Server
Automation Application Server is installed on a server with Internet access.
Source from Disk Repository (Offline Mode): Use this mode in a secured
environment where download occurs on a server, with Internet access, outside of
the environment.
Repository Options
Enter the following information:
Metadata files stored in this location are copied to the catalog automatically.
Payload files are not copied to the catalog.
Agent mounts source for direct use at deployment (no local copy): A
Deploy Job instructs the agent on a target server to: mount the device
specified in the URl and deploy patch payloads directly to the agent. The
Deploy Job does not copy patch payloads to a staging area on the agent, so
the job does not create any local copies of the patches on target servers.
The value entered here depends on your selection in the Network URL Type
for Payload Deployment box:
If you chose Copy to agent at staging, do not enter a value here. The value
is autopopulated based on the repository location.
If you chose Agent mounts source for direct use at deployment (no local
copy), enter the NFS-accessible path to the location of the payload.
RBAC Policy
Filters
Filters limit the amount of information brought into the catalog. Available types of
filters are:
Errata Type
Errata Advisory
Update Level
There is no upper limit to the number of filter combinations you can make but there
must be at least one. Only RPMs and Errata that match the combinations you define
(and their dependent RPMs and Errata) are added to the catalog.
Note
You cannot create multiple filters for the same combination of operating system and
architecture.
In Offline Mode, re-create the filters defined in the configuration file used by the
patch downloader utility.
You can define filters either when the catalog is created or later, when you edit the
catalog. To begin, click Add Filter and select from the following:
Channel
Select the channel from the list provided. The operating system (OS) and
architecture are supplied automatically in read-only boxes. If you want to
download child channels, select Offline Mode, and use the Patch Downloader
utility for Red Hat Enterprise Linux, as described in Downloading child
channels using the Patch Downloader utility on page 1059.
By Errata Type
Security Advisory
Critical
Important
Moderate
Low
By Errata Advisory
By Update Level
Update Level
Select an Update Level identifier; only one can be included for each filter.
Catalog Mode
Select one of two options:
Source from Vendor (Online Mode): Use this mode if the BMC Server
Automation Application Server is installed on a server with Internet access.
Source from Disk Repository (Offline Mode): Use this mode in a secured
environment where download occurs on a server, with Internet access, outside of
the environment.
Note
If you want to specify the filters for SUSE Linux Enterprise 9 and for SUSE Linux
Enterprise 10 and SUSE Linux Enterprise 11, as described in the Filters for Online
mode section, set both the Novell Credentials and the Novell Mirror Credentials.
Note
You can also specify the Novell Credentials and the Novell Mirror Credentials via
the Patch Global Configuration tab. In this case, the credentials you specify are
automatically populated in the SuSE Linux Catalog tab when you are creating a new
SUSE catalog in online mode. You can override the credentials specified via the
Patch Global Configuration tab by specifying a different set of credentials in the
SuSE Linux Catalog tab.
Repository Options
Enter the following information:
(Offline Only) Location of the XML files generated by the downloader and the
corresponding payload files
Metadata files stored in this location are copied to the catalog automatically.
Payload files are not copied to the catalog.
(Online Only)
(default) Copy to agent at staging: During the Deploy Job staging phase,
the BMC Server Automation Application Server copies patch payloads to
a staging directory on the target server.
Agent mounts source for direct use at deployment (no local copy): A
Deploy Job instructs the agent on a target server to mount the device
specified in the URL and deploy patch payloads directly to the agent.
Selecting this option means the Deploy Job does not copy patch payloads
to a staging area on the agent, so the job does not create any local copies of
the patches on target servers.
The value entered here depends on your selection in the Network URL Type
for Payload Deployment box.
If you chose Copy to agent at staging, do not enter a value here. The value
is autopopulated based on the repository location.
if you chose Agent mounts source for direct use at deployment (no local
copy), enter the NFS-accessible path to the location of the payload.
RBAC Policy
Filters
Filters limit the amount of information brought into the catalog. Use this procedure
to re-create the same filters defined in the configuration file used by the Patch
Downloader utility. You can define a filter during catalog creation or later, when
editing the catalog.
There is no upper limit to the number of filter combinations you can create, but you
must create at least one. Only those RPMs that match the combinations that you
define (and their dependent RPMs) are added to the catalog.
To begin, you click Add Filter (as shown in the following figure), and then you
provide values for the following options:
OS Flavor
Select the combination operating system and architecture from the list provided.
OS
The operating system, based on your selection in the OS Flavor box, is supplied
automatically in a readonly box.
Architecture
The architecture, based on your selected in the OS Flavor box, is supplied
automatically in a readonly box.
(Online Only)
In Online mode, the SUSE filter XML file contains the following URLs for a
combination of OS and Architecture: Online, Updates, and Pool. Depending on
which updates need to be downloaded, select one or more of the following options:
Updates: The latest updates for the specified OS level. If you select the Updates
option, you must ensure that your target is at the OS level for which you require
the updates. For example, if you select the Update option for SUSE Linux
Enterprise 10 SP1, you must upgrade your target to SUSE Linux Enterprise 10 SP1
before applying the updates.
Online: Updates from the previous OS level to the specified OS level. You must
use the Online option only when you want to bring your target from the existing
OS level to the next OS level. For example, you must use the Online option if you
want to bring your target from SUSE Linux Enterprise 10 SP2 to SUSE Linux
Enterprise 10 SP3.
Pool: All the updates until the specified OS level. For an OS-Architecture
combination, if you require the updates from an OS level to the next or the latest
OS level, you must use the Pool option. For example, you must use the Pool
option if you want to bring your target from SUSE Linux Enterprise 10 SP1 to
SUSE Linux Enterprise 10 SP4.
Note
The Pool option includes the updates provided in the Online option, so selecting the
Online option and the Pool option together is not required.
Note
On the Patch Global Configuration tab, you may also specify the SUSE override
filters list file by performing the following steps:
The drop-down list for Service Packs in the SUSE Linux Catalog tab displays only
the service packs specified in the SUSE filters list file.
Catalog Mode
The Source from Disk Repository (Offline Mode) option is already selected.
Repository Options
Enter the following information:
Enter the location of existing metadata and payload files. Metadata files
stored in this location are copied to the catalog automatically. Payload files
are not copied to the catalog.
Enter the NSH path to the location of the patch repository. This location must
be on a Linux platform (Red Hat, SUSE or Oracle Enterprise Linux). BMC
recommends that this location have ample free space. Repositories typically
contain many files, usually totaling gigabytes of data.
(default) Copy to agent at staging: During the Deploy Job staging phase,
the BMC Server Automation Application Server copies patch payloads to
a staging directory on the target server.
Agent mounts source for direct use at deployment (no local copy): A
Deploy Job instructs the agent on a target server to mount the device
specified in the URL and deploy patch payloads directly to the agent.
Selecting this option means the Deploy Job does not copy patch payloads
to a staging area on the agent, so the job does not create any local copies of
the patches on target servers.
The value entered here depends on your selection in the Network URL Type
for Payload Deployment box.
If you chose Copy to agent at staging, do not enter a value here. The value
is autopopulated based on the repository location.
if you chose Agent mounts source for direct use at deployment (no local
copy), enter the NFS-accessible path to the location of the payload.
RBAC Policy
Filters
Filters limit the amount of information brought into the catalog. Use this procedure
to re-create the same filters defined in the configuration file used by the Patch
Downloader utility. You can define a filter during catalog creation or later, when
editing the catalog.
There is no upper limit to the number of filter combinations you can make but there
must be at least one. Only RPMs that match the combinations you define (and their
dependent RPMs) are added to the catalog.
OS Flavor
Select the combination operating system and architecture from the list
provided.
OS
Architecture
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Scheduling jobs on page 1098.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Scheduled Job
Notifications on page 1099.
Scheduling jobs
The Schedule tab lets you schedule a job so it can run once, recur hourly, daily,
weekly, or monthly, or recur at some arbitrary interval.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
A tab for that catalog appears on the right side of the workspace. The content
editor displays a series of tabs, which are described in the following sections.
These criteria are used to filter content both during initial creation and later, as new
payloads are added to the catalog. A newly created patch catalog automatically has
the following, out-of-the-box, smart groups predefined:
Technology Level
Service Packs
APARs
PTFs
All patches added to your catalog appear in one of these groups. You can create
others as needed; for example, a smart group could contain all critical patches.
Smart groups appear as part of the hierarchical tree in the patch catalog. If you
expand the smart group, you can view the contents in the left pane. For any patch in
the smart group, you can right-click and select Open to view properties of a
particular patch as well as any associated patches.
Microsoft Windows Downloads and refreshes metadata files downloaded from the vendor
Solaris website as well as updating metadata for existing depot objects in the
catalog.
If the catalog is defined to permit download of payloads during an
Update Job, payloads are also downloaded for newly added patches.
Red Hat Enterprise Linux Downloads payloads only from the vendor website. There is no
patching metadata on the Red Hat website.
AIX Regenerates metadata for the depot objects in the patch catalog.
SUSE Linux Enterprise
Oracle Enterprise Linux
Tip
If you change filtering options for an existing catalog, patches that no longer match
the new filters are marked as irrelevant. Irrelevant patches are not deleted
automatically because they may be referenced in an Analysis Job or by a BLPackage.
Instead, they are moved to the Irrelevant Patches smart group. To clean up the
catalog and remove the irrelevant patches, right-click the catalog and select Remove
Irrelevant Patches.
1 On the BMC Server Automation Console, right-click the patch catalog and select
Update Catalog.
The Catalog Update Job begins, using the filter criteria you defined for the
catalog. The Tasks in Progress view shows the current status of the job. The job is
stored in the Jobs folder.
After the patch catalog is updated, you can do the following to view the results of a
Patch Catalog Update Job:
2 Click the Results tab to view the results of the job runs.
3 Right-click the job run in the Results tab and select Show Log to see the log for
this job run.
After the patches are downloaded, you can view the results of the job run. The run
date and time are displayed together with a final count of how many patches were
successfully downloaded and how many failed to download. If you expand the
results, individual patches are identified in Object View together with their final status.
1 In the Depot folder, navigate to the patch catalog for which you want to
download patches.
3 Provide information for the New Patch Download Job as described in the
following sections:
1 After the patches are downloaded, you can right-click a Download Job and select
Show Results.
Name
Description
Save in
Specify a Catalog
(Read only) Displays the hierarchical location in the Folders pane where the
patch catalog is stored.
The patches on the list are those that already have metadata in the patch catalog and
reflect the smart groups that have been previously defined.
Note
If you entered this wizard by selecting Download All Missing Patches from
Analysis Results, then this step is eliminated because all patches that have metadata,
but no payload, are automatically selected.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
If your system has been configured to require approval information for this
job type, select Execute on Approval and then click Browse to display the
Enter Approval Information dialog box.
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
3 Click Close.
1 From the patch catalog, right-click any Technology Level, Service Pack, APAR
ID, PTF, Critical Fix, Security Fix, or Latest Fix and select Deploy.
A Deploy Job is created. The Deploy Job installs all filesets in the Apply state
using the default install command identified on the AIX Container panel for the
selected Technology Level, Service Pack, APAR ID, PTF, Critical Fix, Security
Fix, or Latest Fix.
The default install command, defined on the AIX Container Panel, is as follows:
installp -a -Y -d . all
1 From the patch catalog, right-click any Technology Level, Service Pack, APAR
ID, PTF, Critical Fix, Security Fix, or Latest Fix and select Open.
4 From the patch catalog, right-click any Technology Level, Service Pack, APAR
ID, PTF, Critical Fix, Security Fix, or Latest Fix and select Deploy.
A Deploy Job is created which installs all filesets in the Commit state using the
default install command identified on the AIX Container panel for the selected
Technology Level, Service Pack, APAR ID, PTF, Critical Fix, Security Fix, or
Latest Fix.
Analysis The Patching Job checks the configuration of target servers and
determines which patches are needed.
Make sure that anyone who can view results of the Patching Job, has the
DepotObject.Read permission enabled for the Patch Catalog that is used for the
analysis.
(Solaris Only) for an agent, running on a target server in single-user mode, to mount
a source location using the NFS transmission protocol, the following must be done
prior to deployment:
For more information, see Using NFS to mount a location while running single-user
mode on page 771
1 In the Jobs folder, navigate to the folder where you want to create a Patching Job.
Right-click and select New => Patching Job > platformName Patching Job.
For example, Microsoft Windows Patching Job, Solaris Patching Job.
3 Provide information for the Patching Job as described in the following sections.
Patching Job Analysis Options for Red Hat Enterprise Linux, Oracle
Enterprise Linux, and SUSE Linux Enterprise on page 1120
Name
Description
Specify a Catalog
Unlimited
Select this to have the job to run in parallel on as many target servers as possible.
Limited
Select this to have the job to run in parallel on a specific number of target servers.
Select when the Patching Job will always execute as the user, BLAdmin, and
the role, BLAdmins.
Select when the Patching Job will always execute using the user and role that
scheduled the job.
You can select List and create an Include/Exclude list for specific patches.
Starting with BMC Server Automation version 8.2, you can specify the QNumbers
for the patches that needed to be included in or excluded from a catalog for Patch
analysis.
Note
Create a .txt file containing a list of the QNumbers for the patches you require. Each
line in the .txt file must contain one QNumber. To select the patches for the Include/
Exclude list, you must point to the location of this .txt file in the Qnumber file field.
For more information, see: https://docs.bmc.com/docs/display/bsa82/Ability+to
+specify+QNumbers+of+Windows+patches+for+Patch+Analysis.
If you do not select List, you can choose from one of the following analysis options:
Tip
If you are not sure what to do, select Group, and then select Security Patches
(Recommended) only.
Security tools
Non-security patches
(Optional) Select when you do not want to include service packs in the
analysis results.
You can select List and create an Include/Exclude list for specific patches or choose
from one of the following options:
Tip
If you choose Without Dependencies, only those patches on your Include List are
analyzed. Associated dependencies are not included.
Analyze the patches from the Include List without analyzing associated
dependencies.
Starting with BMC Server Automation version 8.2, administrators can add primary
and guest Solaris LDoms to the same Patch Analysis Job, and remediate both LDoms
simultaneously. For more information, see Patching Job Independent Solaris
LDoms can be patched simultaneously on page 1115.
Create a Master Batch Job to patch the guest LDoms before the primary LDoms
Stop and restart the guest LDoms before and after the patch deployment on the
primary LDoms
Note
You cannot use the existing Deploy Jobs or BLPackages for patching Solaris LDoms.
Note
The primary and guest LDom Deploy jobs must not be scheduled to run in parallel,
because changes to the primary LDom during execution (such as the primary LDom
being rebooted) impact the guest LDom patching. To ensure that the primary LDom
Deploy Jobs are executed after the guest LDom Deploy Jobs finish execution, execute
only the Master Batch Job. The Master Batch Job ensures that the primary and guest
LDom Deploy Jobs are correctly sequenced.
The Solaris tab on the Patch Global Configuration panel contains a new item, Ldom
option, which allows the following values:
None (default value): This option ignores the LDoms and treats the targets as
physical installations of Solaris. Use this option if you want to ignore the LDoms
even if LDom packages are installed on your computer.
Stop Ldoms using ldm stop: This option stops the LDoms using the ldm stop
command (however, the guest LDoms will not be gracefully shutdown).
Note
The guest LDoms whose status is Active must have the agent installed and must be
accessible from the BMC Server Automation Application Server by their ldm-name.
Stopping and restarting the guest LDoms before and after patch deployment
The Solaris LDom BLPackage contains a Stop LDoms ExternalCmd item, as shown
in the following figure. This ExternalCmd item ensures that the guest LDoms are
stopped before the primary LDoms are patched, and restarts the guest LDoms after
the patching of primary LDoms is completed.
Note
The Stop LDoms ExternalCmd maps to the ldom stop Patch Configuration Panel
option.
Creating a Master Batch Job to patch the guest LDoms before the primary LDoms
The Master Batch Job contains the primary and guest LDom Deploy Jobs, which are
executed in the following sequence (as shown in the following figure):
1 The guest LDom Deploy Job is executed, which deploys the patches on the guest
LDoms.
2 The primary LDom Deploy Job is executed, which deploys the patches on the
primary LDoms.
The following figure shows the Master Deploy Job, which contains the primary and
guest LDom Deploy Jobs.
The Master Deploy Job executes LDom patching in the following sequence:
2 An NSH Script Job to shutdown the guest LDoms from the Application Server
using the shutdown command is executed.
The NSH Script Job contains an associated NSH script in the Depot in the same
location as the BlPackage. When the Shutdown Ldoms using ldm-names as
hostname option is selected, the NSH Script Job and the NSH script ensure graceful
shutdown of the guest LDoms.
Selecting the Stop Ldoms using ldom stop option in the Patch Global
Configuration tab stops the guest LDoms (before patching the primary LDoms)
without gracefully shutting down the guest LDoms.
The Shutdown Ldoms using ldm-names as hostname option in the Patch Global
Configuration tab assumes that the ldm-name is the same as the hostname used
by the nexec parameter to shutdown the guest LDoms gracefully.
Add both a primary and its guest LDoms to the same Patching Analysis Job.
BMC does not recommend patching a primary LDom and its guest LDoms using
different Patching Analysis Jobs, because patching the primary and LDoms
separately might incorrectly sequence the primary and guest LDom Deploy Jobs,
leading to the problems noted in the Analyzing and deploying Solaris LDom
patches section.
Administrators will see Batch Jobs corresponding to the primary and guest LDom
Deploy Jobs on the BMC Server Automation Console, but they must not execute
those Batch Jobs manually.
You can create an Include/Exclude List for specific patch containers (PTFs or
APARs) or choose from one of the following options:
Use this option to stop analysis on any target server that has filesets in the
applied state (installed but not committed).
The Patching Job uses the settings in the Global configuration parameters.
Use this option to continue analysis on any target server that has filesets in
the applied state (installed but not committed).
Group
List
For an APAR or PTF-based catalog, you can create an Include List for specific
APAR or PTF IDs. You can also create an Exclude List for a specific fileset.
Use this option if inclusion of the fileset would lead to deployment failure,
such as if the fileset had dependency issues, whereas exclusion of the fileset
would result in successful analysis and deployment.
Note
Exclusion is the only action you can perform at the fileset level.
You can create an Include/Exclude list for specific patches, to override the default of
including the entire patch catalog in the analysis.
Analyze for missing RPMs and updates available for installed RPMs on a target
server (Install Mode)
Analyze only for updates available for installed RPMs on a target server (Update
Mode)
Note
It is not recommended to choose Install Mode if you are including all errata or all
RPMs from the catalog. Various conflicts and dependency issues between RPMs may
occur, as install mode attempts to install RPMs for which the base versions or earlier
versions are not present.
On SUSE Linux Enterprise version 10, Novell does not support moving from SP1 to
SP3 in the Online mode. If you want to move from SP1 to SP3 using Online mode,
you must move to the SP2 Online mode and install all required RPMs. After moving
to SP2, you can use the SP3 Online mode to move to SP3. This procedure ensures
that all dependent RPMs required by SP3 are installed on the system without
causing any dependency issues. You can also move from SP1 to SP3 after using the
SP3 Pool option, which takes care of all dependencies.
On SUSE Linux Enterprise version 11, only Update Mode is supported. Install Mode
is not supported on this version of SUSE Linux Enterprise, as certain dependency
patches are not available on the SUSE Linux Enterprise website (and the Patching
Job would fail if you attempt to install patches with dependencies to unavailable
patches).
Enter text that the Patching Job automatically adds to the name of all
BLPackages and Deploy Jobs created. The name of the Patching Job appears
as the default.
Enter the folder where the Remediation and Deploy Jobs created by the
Patching Job are stored. By default, the location is the same one used to store
the Patching Job.
Browse to and select the ACL policy to assign to each BLPackage, Deploy Job,
and Batch Job created by the Patching Job.
Select to open Deploy Job Options. The options defined here are the same
ones defined for any Deploy Job.
Select to open a list of Deploy Job properties. The properties defined here are
the same ones defined for any Deploy Job.
Field definitions
Available Servers
Specify the operating system of the servers you want to select. To display
servers running any operating system, select All.
By Group, By Name
Select servers from a tree or sortable list by doing one of the following:
Click the By Group tab at the bottom of the window. The left panel
displays servers in a hierarchical list arranged by server group. Choose
servers by doing one of the following:
To select all servers within the group, click a server group.
Click one or more servers, if necessary, to expand server groups.
Click the By Name tab at the bottom of the window. The left panel lists
servers by name in a Group Explorer view. Sort servers in ascending or
descending order by clicking on any column header. Click one or more
servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can
change dynamically based on their server properties. You can modify static
server groups manually by adding or removing servers.
Click the right arrow to move your selections to the right panel.
The list of properties for selection includes all complex properties of the
JobRunStatusEnumeration type. It does not include intrinsic and deprecated
properties.
Using the property that you specify here, you can create smart groups based on the
completion status of the current job at the various targets. For example, you can
create a smart group that includes all servers at which this job has not yet run or a
smart group for all servers at which this job has completed successfully.
Such smart groups can serve as the targets either in the current job or in other jobs.
When used in a separate job, the smart group targets link the execution of one job
with the outcome of a previous job. In fact, you can optionally join both jobs together
within a Batch Job.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
If your system has been configured to require approval information for this
job type, select Execute on Approval and then click Browse to display the
Enter Approval Information dialog. For more information, see Patching Job
Execute on approval and Approval type settings on page 1126.
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see Patching Job Scheduling on page 1125.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see Patching Job Scheduled
Job Notifications on page 1125.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Starting with BMC Server Automation version 8.2, the Default Notifications panel
has been enhanced. For more information, see: https://docs.bmc.com/docs/display/
bsa82/Enhanced+Default+Notifications+panel+with+the+provision+to+attach
+patch+analysis+results+in+email+notifications
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
The Approval information tab only appears when the BMC Server Automation
administrator has specified that this job type requires BMC Remedy ITSM approval
prior to execution. When approval is required, you must use this tab to select the
approval type and enter the approval parameters.
To specify an approval type, select the Execute on Approval option, and then select
an Approval type. Optionally, you can select to use an existing change ticket for
approval. The Execute on Approval field appears when you:
For more information, see Executing a job with BMC Remedy ITSM approval on
page 617.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To modify the definition of an existing Patching Job, open the Jobs folder and
navigate to an existing job. Right-click the job and select Open. The content
editor displays a series of tabs, which are described in the following sections:
These tabs correspond to panels in the New Patching Job wizard. Use them to
modify the job definition.
The name of the Patching Job, as defined during job creation, is displayed as the
root node in the hierarchical tree. All runs of the Patching Job and their results are
displayed beneath the root node.
2 Select the root job node to display additional information in column form on the
right.
Note
For a description of menu options available from the root job node, see
Managing jobs on page 605.
A list of run dates and times for the Patching Job is displayed.
Patching Job Analysis statistics are displayed on the right side in column format
including what was discovered missing, how many target servers were scanned,
and how many target servers were not scanned.
6 Expand the analysis results node to display the Object and Server views.
Object View This view lists every missing patch discovered during analysis
together with architecture, whether the patch is recommended by the vendor
site, description of the patch, and so on.
Server View Server View organizes target servers included in the job
according to two sub-categories, Failed Targets and Successful Targets. Target
servers are displayed on pages. The number of servers on each page can be
configured (Window => Preferences => Paging Options => Page Size; see
Customizing preferences on page 84 for more details), target servers are
listed individually including final status as well as the missing number of:
The name of the Patching Job, as defined during job creation, is displayed as the
root node in the hierarchical tree. All runs of the Patching Job and their results are
displayed beneath the root node.
2 Select the root job node to display additional information in column form on the
right.
The following information is displayed: date and time of each job run, the type of
job run, the final status of the job, the starting and ending date/time for the job,
and the user that ran the job.
Note
For a description of menu options available from the root job node, see
Managing jobs on page 605.
A list of run dates and times for the Patching Job is displayed.
5 Expand the remediation results node and expand the date and time that
remediation occurred.
On the Deploy Status tab, target servers are listed on separate lines. For each
target server, a green checkmark appears indicating if the patches were applied,
staged, or committed. A red X indicates failure in that stage. You can do the
following:
Place the cursor on the green checkmark or red X to see start and stop times for
the action.
Select either the green checkmark or the red X to see a list of log messages
generated during remediation.
1 In the Jobs folder, right-click the Patching Job and select Show Results.
3 In Object View, right-click one or more patches and select Deploy Selected
Patches.
BMC Server Automation opens a Remediation Job for the selected patches.
1 In the Jobs folder, right-click the Patching Job and select Show Results.
3 In Object View, right-click one or more patches and select Download Selected
Patches.
BMC Server Automation downloads payload for the selected patches that only
have metadata in the patch catalog.
1 In the Jobs folder, right-click the Patching Job and select Show Results.
BMC Server Automation opens the Depot Software Properties box with a two-
page, read-only description of the metadata for the selected patch.
1 In the Jobs folder, right-click the Patching Job and select Show Results.
BMC Server Automation opens a Remediation Job to install all missing patches on
all target servers listed in the Patching Job.
1 In the Jobs folder, right-click the Patching Job and select Show Results.
BMC Server Automation downloads payload for all patches that only have
metadata in the patch catalog.
1 In the Jobs folder, right-click the Patching Job and select Show Generated Batch
Deploy Job Results.
This links the Patching Job results to the results of the Batch Job that was used to
perform remediation.
2 Select the root job node to display additional information in tabular form on the
right.
If you select the create remediation artifacts check box during patching job
definition, the process of packaging and deploying the payload is handled
automatically according to a schedule you defined for the job.
However, when analysis results indicate that patches are missing, you can choose to
remediate the target server using the following procedure.
Note
As part of the Remediation Job, Deploy and Batch Jobs are created but those jobs are
not executed immediately. You can run Deploy Jobs according to a separate schedule
and set them to run during maintenance windows.
1 At the end of analysis, right-click the patching job and choose Show Results.
2 Expand the analysis results from the root node and under Server View, right-click
Successful targets and select Remediate All Server(s).
Name
Description
Save In
If not already displayed, enter or browse to the location where the Patch
Remediation Job is stored.
Select if the Patching Job always executes as the user, BLAdmin, and the role,
BLAdmins.
Select if the Patching Job always executes using the user and role that
scheduled the job.
Text that is added to the names of all BLPackages and Deploy Jobs created
during remediation. By default, the Remediation Job name is entered
automatically in this box.
Save package in
Enter a depot location where the BLPackages created during remediation are
stored. By default, the location where the Remediation Job is stored in the
depot is supplied.
Enter a job folder where the Batch and Deploy Jobs created by the
Remediation Job are stored.
Browse to and select the ACL Policy which assigns predefined permissions to
each BLPackage, Deploy Job, and Batch Job created by the Remediation Job.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
If your system has been configured to require approval information for this
job type, select Execute on Approval and then click Browse to display the
Enter Approval Information dialog box.
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
Starting with BMC Server Automation version 8.2, the Default Notifications panel
has been enhanced. For more information, see: https://docs.bmc.com/docs/display/
bsa82/Enhanced+Default+Notifications+panel+with+the+provision+to+attach
+patch+analysis+results+in+email+notifications
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job will always execute at the time you have specified. BMC
Server Automation automatically accounts for differences in time zones and changes
in daylight savings time. For example, if you schedule a job that should run weekly
at 06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
1 In the Jobs folder, right-click the Patching Job and select Show Results.
The run date and time for the Patching Job is displayed as the root node in a
hierarchical tree. All runs of the Patching Job and their results are displayed
beneath the root node.
2 Select the root job node to display additional information in tabular form on the
right.
Displays the date and time at which the job was run. When you select the first
line, basic information about the job is shown on the right side of the pane
including how many Deploy Jobs were generated and how many Target Servers
were included in the remediation job.
Note
For a description of menu options available from the root job node, see the
Managing Jobs chapter.
Patch Deployment
Remediation generates a number of deployment jobs which are used to apply a
specific set of missing patches to a list of target servers. For each of those jobs, BMC
Server Automation lets you control deployment behavior by defining deploy options.
Individually For each job, select the deploy options that should be used when
generating Deploy Jobs during remediation. For more information about the
options you can select, refer to the following sections describing Deploy Job
behavior:
Deploy Job Job Options on page 737
Deploy Job Phase Options on page 746
Deploy Job Phases and Schedules on page 730
By Group Specify an existing Deploy Job in the remediation options tab (in
Deploy Options dialog) in the Remediation Editor. Its options are used as a
template that is applied to all Deploy Jobs created during remediation.
Deploy Jobs are chained to the parent Patching Job, and the parent Patching Job is
marked as complete only after the Deploy Job finishes execution. The BMC Server
Automation Console displays the execution status of the Deploy Jobs and a
consolidated status summary of all the Deploy Jobs. For more information, see
Enhanced view of Patching Job status on page 1141.
WARNING
Although an undo option is available for deployed patches, BMC neither supports
nor recommends this action. The undo option, which depends on platform-specific
operating system commands, can compromise the target server.
Note
On Microsoft Windows 2008 and Microsoft Windows Vista, the Microsoft update
service must be running for patching to work.
Starting with BMC Server Automation version 8.2, Deploy Jobs are chained to the
parent Patching Job, and the parent Patching Job is marked as complete only after
the Deploy Job finishes execution. Consequently, any Jobs that are scheduled to run
after the Patching Job, will start only after the Deploy Job finishes execution.
The BMC Server Automation Console displays the corresponding Batch Job Run
status with the Batch prefix under the Remediation Run node. The Batch Job Run
lists the execution status of the Deploy Jobs, as shown in the following figure.
Live Browse Use Live Browse to look at installed patches on the server, one
server at a time. For more information about Live Browse, see Server browse
options on page 338.
Note
Live Browse on a server does not list non-security patches.
Reports For information about patch management reports, see the BMC
BladeLogic Decision Support for Server Automation.
Microsoft Windows
Linux
Oracle Solaris
IBM AIX
HP-UNIX
Citrix XenServer
For detailed information about supported operating systems and versions, see the
Product Availability and Compatibility Matrix available at http://www.bmc.com/
support/reg/bladelogic-compatibility-tables.html .
Provisioning process
BMC Server Automation provisioning performs unattended installations of
operating systems onto new machines (bare metal machines) or re-provisions
existing machines. The provisioning process can also run Batch Jobs that configure
server settings, deploy files, and install software after installing the operating system.
Designed to work in conjunction with established protocols like DHCP, TFTP, and
TCP/IP, this PXE-based approach to provisioning allows Intel computers to boot
from a PXE-compliant Network Interface Card (NIC) and retrieve their operating
system installation instructions and files over the network, instead of relying on
floppy disks and CD-ROMs.
reboot the target machine. Ensure that both the NIC and the BIOS firmware are up-
to-date.
1 Create System Package and Data Store Instance, Import Device, Run Provision Job:
Create a system package that contains all the instructions needed to install an
operating system over the network.
Create a data store instance that points to the location of a data store, which is
where you store sets of installation files that are used for provisioning
operating systems.
Register the target devices MAC address (and optional additional information)
with the BMC Server Automation system by importing the device.
The BMC Server Automation JumpStart integration lets SPARC devices boot from
the network using the BOOTP protocol and communicate with JumpStarts boot,
config, and install servers for remote provisioning. This integration works with
established protocols such as NIS, NIS+, and DHCP.
1 Prepare to provision
To prepare for SPARC provisioning, you perform the following tasks in the BMC
Server Automation Console:
Create a system package that contains all of the instructions required to install
an operating system over the network. The system package can include a
reboot script, which instructs the target machine to boot from the network. This
description assumes that the system package includes a reboot script.
Create a data store instance that points to the location of a data store containing
the required operating system installation files.
Create a Provision Job that references the system package and data store instance.
Ensure that the OpenBoot PROM and the network card on the device are up to
date.
In the BMC Server Automation Console, import (or add) the device. This action
registers the devices MAC address (and optional additional information) with
the BMC Server Automation system.
Open the Provision Job and add the device to the Job.
The BMC Server Automation JumpStart integration lets Solaris x86 devices boot
from a PXE server using DHCP and communicate with JumpStarts servers for
remote provisioning.
You must have a working Solaris x86 JumpStart environment, which includes a
PXE server. The BMC Server Automation PXE server is not compatible with the
Solaris x86 PXE boot process and the two servers might have difficulties
coexisting on the same network. If you require both Windows or Linux PXE
provisioning and Solaris x86 provisioning, BMC Software recommends that you
use separate networks.
1 Create System Package and Data Store Instance, Import Device, Run Provision Job:
Create a system package that contains all the instructions needed to install an
operating system over the network.
Create a data store instance that points to the location of a data store, which is
where you store sets of installation files that are used for provisioning
operating systems.
Register the target devices MAC address (and optional additional information)
with the BMC Server Automation system by importing the device.
When you provision a server, you can also install an RSCD agent on the server,
register it, and provide information about that server, so you can manage that server
in the future.
When you create a Provision Job to provision a server, you can also specify a Batch
Job that runs after the agent is installed on the newly provisioned server. A Batch Job
can run multiple jobs sequentially. In this way you can run jobs that perform
additional configuration on the server, deploy all necessary files, and install required
software.
Provisioning tasksChecklist
You can use these steps as a checklist for performing all of the tasks required to set
up the provisioning system and provision servers.
To enable provisioning, you must set up the provisioning system, create components
used by the provisioning process, prepare devices, and create and execute Provision
Jobs that perform the unattended installation of the operating system.
For requirements and set-up procedures for each of the supported provisioning
technologies, see BMC Server Automation technical documentation at https://
docs.bmc.com/docs/display/bsa82/Setting+up+the+provisioning+system.
Using the role-based access control (RBAC) features in BMC Server Automation:
Grant the appropriate level of access to the roles involved in the provisioning
process.
For example, expert users who design system packages might be assigned to a
role that is granted complete authorization to all provisioning capabilities.
Users who actually provision devices might be assigned to another role that is
granted limited access.
For information about RBAC, including how to configure roles, add users, and
assign authorizations, see Access management on page 165. For the specific
authorizations required for provisioning activities, see https://docs.bmc.com/
docs/display/bsa82/System+authorizations.
3 Set up the data store, which is a file system that holds the images to install on the
target servers.
For data store requirements and set-up procedures for each of the supported
operating systems, see BMC technical documentation at https://docs.bmc.com/
docs/display/bsa82/Setting+up+the+provisioning+system.
4 (Windows and Linux only) Create boot image files and copy them into the data
store.
For the PXE provisioning technology, which is used to provision Windows and
Linux operating systems, you must create the boot image files and copy them into
the data store. For the other provisioning technologies, you can copy image files
from outside sources directly into the data store.
For information, see Creating WinPE 2.0 and later boot image files on page
1160, Creating a Gentoo Linux image file on page 1179, or Using the Skip
Linux Pre-Install image option on page 1183.
This step establishes the connection to the data store and other functional
software components. For information, see Configuring provisioning on page
1184.
A system package can include a BMC Server Automation Batch Job that
configures the server and installs software after it installs the operating system.
For information, see Batch Jobs on page 803 and Including a Batch Job in a
system package on page 1213.
System packages are a consistent, logical way to provide the path names of
images and to represent the values passed to the operating system installer. You
should create a system package for each operating system that you plan to provision.
For information, see Creating a system package on page 1214 and the sections
that follow it. The subsequent sections describe the system package settings for
each operating system.
In a Provision Job, you select a system package and set job-specific information
such as properties, execution schedules, permissions, and notifications. You can
optionally override system package settings in a Provision Job. You can also select
devices if the next step (preparing devices) is complete.
9 Prepare devices.
Devices must be connected to the network and appear in the Devices folder in the
BMC Server Automation Console. For information, see Importing and managing
devices on page 1332.
You can rerun the same job many times, with new devices selected each time. For
information, see Changing or adding devices in a Provision Job on page 1366.
For information, see Viewing the results of a Provision Job on page 1368.
12 Reboot the target devices that were successfully provisioned if they are not
rebooted automatically.
For PXE provisioning, no further actions are required. The devices boot from
the network.
The type of boot image file you create depends on the types of machines you plan to
provision.
Placeholders let you specify which image file to use in provisioning a device. For
example, if you add a device, the BMC Server Automation Console displays a drop-
down menu of image files that you can associate with the device.
To view configuration settings for an image, in the BMC Server Automation Console,
select Configurations => Provisioning Configurations. Then click the Image Files
tab.
After it boots from the image, the machine can obtain instructions for installing the
operating system.
1 Prepare the machine on which you plan to create the WinPE image. See Preparing
a machine for WinPE 2.0 and later image creation on page 1161.
The image creation wizard. See Creating WinPE 2.0 and later images using the
Image Creation wizard on page 1164.
The CreateWinPE2_x.vbs script. See Creating WinPE 2.0 and later image files
using the BMC Server Automation script on page 1171.
3 Copy the image files to the appropriate location for provisioning. See Copying
image files to a location for provisioning on page 1175.
1 Download and install the following items from the Microsoft website:
To create WinPE 2.1 images, download the Automated Installation Kit (AIK)
for Microsoft Windows Vista SP1 and Microsoft Windows 2008.
To create WinPE 2.0 images, download the Automated Installation Kit (AIK).
Note
These files are very large and might take a while to download.
3 Using an image file editor (such as WinImage), open the WAIK image file.
5 Extract the appropriate msi file, depending on the architecture of the server that
you are using to create the WinPE images.
If you are using an x86 machine to create images, extract the waikx86.msi file
and use it to install WAIK.
If you are using an x86-x64 or x64 machine to create images, extract the
waikamd64.msi file and use it to install WAIK.
If you are using an Itanium machine to create images, extract the waikia64.msi
file and use it to install WAIK.
Note
For information about the unattended image types (x86, x64) that you can create
using the x86 and x64 architectures, see the Microsoft WAIK product
documentation.
This file is included when you download BMC Server Automation from the BMC
Electronic Product Distribution (EPD) website.
Copy this file to a directory on the machine where you installed WAIK. For
example, C:\BMC_BL.
Note
The directory name must not contain spaces.
7 Unzip provision-files.zip.
\provisioning\winpe
8 If you are using the image creation wizard to create boot image files, you can
begin the wizard now. See Creating WinPE 2.0 and later images using the Image
Creation wizard on page 1164.
If you are using the script to create boot image files, continue with the following
steps.
9 (Applies only to using the script to create boot image files.) Set up files for driver
injection.
Note
Although driver injection is optional for boot image creation, drivers are typically
required to create a usable provisioning boot image.
To inject drivers into the WinPE image, create a text file called Driver.txt and put
this file in the provisioning\winpe directory. For example:
C:\BMC_BL\provisioning\winpe\Driver.txt
For example:
Note
Pathnames containing spaces are not supported.
10 (Applies only to using the script to create boot image files.) Find the following
files:
CreateWinPE2_x.vbs
extractpxeboot.vbs
C:\BMC_BL\provisioning\winpe\CreateWinPE2_x.vbs
C:\BMC_BL\provisioning\winpe\extractpxeboot.vbs
11 (Applies only to using the script to create boot image files.) Copy
CreateWinPE2_x.vbs and extractpxeboot.vbs to the WAIK installation
subdirectory: \Tools\PETools
For example:
C:\Program Files\WinAIK\Tools\PETools
12 (Applies only to using the script to create boot image files.) Run the image
creation script. See Creating WinPE 2.0 and later image files using the BMC
Server Automation script on page 1171.
If you plan to create image files for booting from media local to the target server,
create a network.ini file.
2 Specify information for creating the image, as described in the following sections:
A progress dialog box informs you that the image file creation is running. When it
completes, the script execution log appears in the dialog box.
Toolkit Select
The Toolkit Select panel lets you specify the location of the image toolkit used to
create the image, the type of image to create, and where the newly created image file
should be stored.
Field Definitions
Identifies the server on which the image tool kit is located. Type the server
name or click Browse to select the server.
The image tool kit host must be a server running a licensed RSCD agent and
the user creating the image file must be logged into the server using a role
that has Write authorization.
Image Type
Specifies the method of creation and format of the WinPE 2.0 and later image
you want to create. Select one or more types.
PXE Image: Creates an image for booting the target server from the PXE
server. The image is a directory with the name bootImageName; the
directory contains the files for booting the target server from the PXE server.
UFD Image: Creates an image in UFD format for booting from USB flash
drive. The image is a directory with the name bootImageName_UFD; the
directory contains the files for booting from a USB flash drive.
Architecture
Specifies the architecture of the machine for which you are creating the
image: x86 or x64.
Specifies the full path for the Microsoft Windows Automated Installation Kit
(WAIK) directory. Type the path or click Browse to select the directory. For
example: C:\Program Files\WinAIK\Tools\PETools
Specifies the full path for the directory in which you unzipped the provision-
files.zip file. The directory should contain the CreateWinPE2_x.vbs file. For
example: C:\BMC_BL\provisioning\winpe.
Type the full path for the directory or click Browse to select the directory.
The pathname may contain spaces.
For PXE image typeIf this is the only image type you selected:
Select Use TFTP Root as base directory to specify that tftproot on the
tftp server be used as the base directory. In the text box, type the
directory under tftproot where you want the image file created.
Deselect Use TFTP Root as base directory, and in the text box, type the
full path to the directory in which you want the image file created, or
click Browse to select a location. Use NSH format for the path. For
example:
//myComputerHostname/myImageDirectory
For ISO or UFD image typesIn the text box, type the full path to the
directory in which you want the image created, or click Browse to select a
location. Use NSH format for the path. For example:
//myComputerHostname/myImageDirectory
Specifies the new boot image file name. Spaces are not supported in the boot
image name.
If you are creating the default images (for the default placeholders on the
Image Files tab of the Provisioning Configurations window), use the
following expected file names:
If you are creating additional custom images, provide a name other than
those listed above. When the boot file name is other than boot_2_0_xx, the
system creates a custom placeholders for the image on the Image Files tab
of the Provisioning Configurations window.
For USB flash drive (UFD) image types, there are no placeholders, and hence,
no expected image names.
Driver Selection
The Driver Selection panel lets you inject drivers into the WinPE image.
Most installations require a set of drivers. For example, you might need to inject
VMware drivers, such as vmware-nic.inf, vmx_svga.inf and vmxnet.inf, in the
WinPE boot image.
To provide the path names to the driver files to inject into the image:
To select an existing Driver.txt file that contains the path names to .inf driver files,
click Browse next to the Open Driver.txt file field.
The path names contained in the selected file appear in the large Driver Files
panel in the middle of the window.
To add additional drivers to the displayed list or to start building a list of drivers,
click Add . In the Select Driver Files dialog, select the root folder that contains
the drivers or subfolders with drivers. Then click OK. All drivers in the selected
folder or subfolders appear in the large Driver Files panel in the middle of the
window.
Note
The path to the Driver.txt file can contain spaces. However, the path names of
the .inf driver files can not contain spaces. Spaces are not supported.
To save a new Driver.txt file that contains all of the drivers shown in the Driver
Files panel, click Save new Driver.txt file. Then do one of the following:
Type the path to a folder where you want to save this new Driver.txt file. Use
NSH format and include the file name. For example:
//myComputerHostname/myDriversFile/Driver.txt
Click Browse to select a folder in which you want to save this new Driver.txt
file. Add the file name to the path in the edit box under Save new Driver.txt.
Custom Script
To specify an external script to run when the image is mounted, use the Custom
Script panel. This panel lets you select an existing script or type a script in the text box.
Click Browse to select the script file in the Select Custom Script dialog. Then
click OK after selecting the file.
Configuration Details
The Configuration Details window lets you specify information for an image for
booting a target server from local media (CD-ROM, DVD, USB flash drive, iLO,
DRAC). Provide information only if you creating an ISO or UFD image.
Field Definitions
Network Details
(Optional) Specifies the path to the network.ini file. This file contains the
MAC address of each target server and its network details (static IP address,
subnet mask, default gateway, WINS server, and DNS servers). Specify this
file if the provisioning environment does not contain a DHCP server.
If you select a network.ini file, the image creation process copies the file to
the root of the WinPE ISO image or UFD directory, depending on the image
types you selected.
If you do not specify a network.ini file during image creation, you can:
Manually copy the network.ini file to the root directory of the media (CD,
DVD, USB) you use for local provisioning of the server.
Provide network details during the provisioning of the target server. Use
this option if your provisioning environment does not include a DHCP
server.
When you run the Provision Job, it searches for the network.ini file at the
root of the local media. If the file is not present there, the job allows the
DHCP server to provide network details dynamically. If no DHCP server is
present, the job prompts you for those details.
Specifies the IP address of the Application Server with which the target
server communicates.
Specifies the port that the target server uses to communicate with the
Application Server.
The copy option you select becomes the value of the CONFIG_STORE
property. You can set the value of the CONFIG_STORE property in Local
Properties when you create a system package.
BMIWIN.EXE Path
Specifies the path to the bmiwin.exe file to copy the local media. For example:
D:\DataStore\bmiwin.exe. Type the path (including the file name) or click
Browse to select the file.
Specifies the path to the RSCD Agent installer files to copy to the local media.
For example: D:\DataStore\RSCD\rscd_76_x86. Type the path or click
Browse to select the directory.
OS Drivers Path
Specifies the path to the operating system driver files you want to copy to the
local media. For example: D:\DataStore\Drivers. Type the path or click
Browse to select the directory.
Tip
If you are using the DHCP server to assign IP addresses (not the network.ini file)
and if the server fails to assign the network details due to slow initialization of
network cards on the target machine, edit the BLAssignNetDetails.vbs file and
increase the ATTEMPTS and DELAY values to allow for initialization time. For
example, you might increase ATTEMPTS from 2 (the default) to 5 and DELAY from
10 (the default) to 30.
The BLAssignNetDetails.vbs file resides in the /provisioning/winpe subdirectory
you created by unzipping the provision-files.zip file.
The network.ini file provides such details as static IP address, subnet mask, default
gateway, WINS server, and DNS servers. An example of an environment where you
might use such a file is one in which you provision target servers from local media.
1 In a text editor, create a new file named network.ini. (The file must have this
name.)
2 In the file, for each target server, create a section containing its MAC address and
network details. Use the following structure and syntax:
[macAddress]
STATIC_IP=xxx.xxx.xxx.xxx
SUBNET_MASK=xxx.xxx.xxx.xxx
DEFAULT_GATEWAY=xxx.xxx.xxx.xxx
WINS_PRIMARY_SERVER=xxx.xxx.xxx.xxx
WINS_SECONDARY_SERVER=xxx.xxx.xxx.xxx
DNS_SERVER_SEARCH_ORDER=xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx
Example
The following is an example of a network.ini file.
[00-0C-29-48-EA-7E]
STATIC_IP=180.138.100.15
SUBNET_MASK=255.255.255.0
DEFAULT_GATEWAY=180.138.100.1
WINS_PRIMARY_SERVER=180.138.100.4
WINS_SECONDARY_SERVER=180.138.100.10
DNS_SERVER_SEARCH_ORDER=180.138.100.4,180.138.100.5
[00-0C-20-56-64-2C]
STATIC_IP=180.138.100.12
SUBNET_MASK=255.255.255.0
DEFAULT_GATEWAY=180.138.100.1
WINS_PRIMARY_SERVER=180.138.100.4
Guidelines:
Key names should be specified as shown; however, key names are case-
insensitive.
Each section must begin with the target servers MAC address, enclosed by
square brackets ([ ]).
Creating WinPE 2.0 and later image files using the BMC
Server Automation script
You can run the CreateWinPE2_x.vbs script to create a WinPE 2.0 and later x86 or
x64 image file.
If you plan to create image files for booting from media local to the target server,
create a network.ini file.
1 Create the input file containing image creation parameters. See Creating the input
parameters .ini file on page 1171.
2 Run the CreateWinPE_2_0.vbs script to create the image files. See Running the
CreateWinPE2_x.vbs script on page 1174.
3 Copy the image files to the TFTP server for booting from the PXE server (PXE
image type) or to the media you want to use for booting the target server locally
(ISO or UFD image types). See Copying image files to a location for provisioning
on page 1175.
Parameter Description
Arch (Required) Specifies the architecture of the server for which you are
creating the boot image (x86 or x64).
Parameter Description
CustomScript (Optional) Specifies the path to an optional external script that you
want to run when the image is mounted. Specify the scripts full
path and name.
OverwriteFlag (Optional) If DestDir already exists and you want to overwrite it,
specify OverwriteFlag=Y
RSCDDir (Local boot image only) Specifies the path to the directory that
contains the RSCD Agent installer. For example: C:\Installers\RSCD
The directory should contain the rscd.msi file.
OSDrvDir (Local boot image only) Specifies the path to the directory that
contains the driver files required for the operating system
installation. For example: C:\Installers\Drivers
BMIWinExe (Local boot image only) Specifies the path to the bmiwin.exe file you
want to copy the local media. Specify a path name that includes the
file name. For example: D:\DataStore\bmiwin.exe
CopyToISO (Local boot image only) Specifies whether the script copies the
configuration components (RSCD Agent installer files, operating
system driver files and bmiwin.exe) to the WinPE ISO or to the LDS
directory inside the WinPE image.
Specify CopyToISO=Y to copy these files to the root of the WinPE
ISO. This is the default.
Specify CopyToISO=N to copy these files to the LDS directory.
Parameter Description
NetDetailsFile (Local boot image only) Specifies the path to the network.ini file.
This file provides network details for each target server (static IP
address, subnet mask, default gateway, WINS server) in
provisioning environments where there is no DHCP server or where
you want to map MAC addresses to static IPs.
Specify a path name that includes the file name. For example: D:
\Scripts\network.ini
This file must already exist.
AppServer (Local boot image only) Specifies the IP address of the Application
Server that the target server contacts. Specify this parameter when a
DHCP server is not present in the provisioning environment or if
the DHCP server is not configured to provide the address.
If you specify this parameter, the script includes the IP address in
the WinPE image.
AppServerPort (Local boot image only) Specifies the port number for target server
to use in contacting the Application Server. Specify this parameter
when a DHCP server is not present in the provisioning environment
or if the DHCP server is not configured to provide the address.
If you specify this parameter, the script includes the port number in
the WinPE image.
CreatePXEFlag Specifies whether to generate PXE boot files for the image.
Specify CreatePXEFlag=Y to generate the files. (This is the default.)
The script creates the image files and puts them in a PXE bootable
directory with the name you specified for BootDir. For example:
boot_2_0_x86
Specify CreatePXEFlag=N to suppress generation of the files.
CreateISOFlag (Local boot image only) Specifies whether to generate ISO boot files
for the image.
Specify CreateISOFlag=Y to generate the files. The script creates the
ISO file with the name you specified for BootDir, plus the .iso
extension. For example: boot_2_0_x86.iso
Specify CreateISOFlag=N to suppress generation of the files. (This is
the default.)
CreateUFDFilesFlag (Local boot image only) Specifies whether to create a UFD image
files for booting from a USB flash drive.
Specify CreateUFDFilesFlag=Y to generate the files. The script
creates a directory with the name BootDir_UFD and puts in it the
files for booting from a USB flash drive. For example:
boot_2_0_x86_UFD
Specify CreateUFDFilesFlag=N to suppress generation of UFD files.
(This is the default.)
Parameter Description
This example creates a WinPE x86 boot image for booting from the PXE server only.
Arch=x86
BLDir=D:\BladeExtract\winpe
DestDir=D:\WinPEImg\x86
BootDir=boot_2_0_x86
CustomScript=D:\Scripts\addADP.bat
CreatePXEFlag=Y
OverwriteFlag=Y
WAIKRootDir=C:\Program Files\WinAIK
Debug=N
This example creates two WinPE x86 boot images for booting from local media:
Arch=x86
BLDir=D:\BladeExtract\winpe
DestDir=D:\WinPEImg\x86
BootDir=boot_2_0_x86
RSCDDir=D:\DataStore\RSCD\rscd_76_x86
OSDrvDir=D:\DataStore\Drivers
BMIWinExe=D:\DataStore\bmiwin.exe
CopyToISO=Y
CustomScript=D:\Scripts\addADP.bat
NetDetailsFile=D:\Scripts\network.ini
AppServer=190.165.33.1
AppServerPort=9831
CreatePXEFlag=N
CreateISOFlag=Y
CreateUFDFilesFlag=Y
OverwriteFlag=Y
WAIKRootDir=C:\Program Files\WinAIK
Debug=Y
On the machine where you are creating the image files, create a temporary local
directory to hold the image files. For example: C:\BMC_BL\tmp.
Create the input parameters file used by the script. See Creating the input
parameters .ini file on page 1171.
1 At the command prompt, enter the cscript command with the following arguments:
Where:
cscript Calls the Visual Basic (.vbs) script without displaying a message box
type of user interface.
inputFilePath Specifies the path to the input file containing the image creation
parameters.
For example:
1 Copy the image file to the TFTP server. Perform this step only if you created the
image with the CreateWinPE2_x.vbs script. (If you created the image with the
image creation wizard, the image creation process copies the image to the TFTP
server.) See Copying image files to the TFTP server (PXE) on page 1176.
2 Extract the boot files and copy them to the TFTP server. See Extracting boot files
for WinPE 2.0 and later images on page 1177.
3 If the server that contains your data store does not support the NTLMv2 Level 3
setting for Microsoft NT Lan Manager, change the NTLM settings for the WinPE
image on the TFTP server. See Configuring WinPE security settings on page 1178.
1 Copy the bootImageName.iso file to the CD or DVD. You can also copy the image
to a location for use directly through iLO, virtual CD-ROM, or network mapped
driver.
2 Copy the all of the files and folders in the bootImageName_UFD directory to the
root of the USB drive.
The image file is actually a directory containing several separate files. When you
run CreateWinPE2_x.vbs, it creates this directory in the path specified by DestDir.
This new directory has the name specified by BootDir and contains the image files.
For example if you specified a BootDir name of boot_2_0 (the recommended name
for the directory), the script creates the boot_2_0 image in DestDir:
C:\BMC_BL\tmp\boot_2_0
BCD
boot.sdi
WinPE.wim
1 To place the image files on the TFTP server, copy BootDir and its contents to the
tftproot directory on the TFTP server. For example:
C:\tftproot\boot_2_0
BCD
boot.sdi
WinPE.wim
Note
The BLAdmin role must be granted Read and Write access to the TFTP root
directory and its contents, including boot image folders and all image files in the
folders.
1 Create a temporary local directory to store the files you are about to extract, for
example:
C:\BMC_BL\tmpboot
pesetenv.cmd
4 Run the extractpxeboot.vbs script to extract pxeboot.0 and bootmgr.exe. Use the
following syntax:
extractpxeboot DestDir
where DestDir is the temporary local storage directory you created at the
beginning of this procedure. For example:
extractpxeboot C:\BMC_BL\tmpboot
The TFTP server must have the Microsoft Windows Automated Installation Kit
(WAIK) installed.
1 Use the imagex utility to mount the WinPE image to any empty directory. (The
imagex utility comes with WAIK.)
Example:
a Create an empty directory, for example C:\new. Copy the WinPE image file
WinPE.wim to this new directory.
C:\new\mount
pesetenv.cmd
3 Click HKEY_LOCAL_MACHINE.
WinPE_Image_SYSTEM
8 This step describes how to add an entry if the LMCompatibilityLevel value does
not currently exist. If an LMCompatibilityLevel value already exists, you can edit
the existing entry to match these values.
Select Edit => New => DWORD Value, and then add the following registry values:
Value: 3
9 Click HKEY_LOCAL_MACHINE\WinPE_Image_SYSTEM.
BMC Software recommends that you execute the image creation script on a Red Hat
system. Place the resulting image on the TFTP server.
1 Obtain a copy of the Gentoo minimal ISO image file. You can get this file from the
Gentoo website (http://www.gentoo.org.) Place the file in a temporary location
on the system you plan to use to create the image.
In this procedure, this ISO image file is referred to as gentooMinimalIsofile and the
file is located in the following temporary directory:
/tmp/bmc_bl
current_versionprovision-files.zip
This file is included when you download BMC Server Automation from the BMC
Electronic Product Distribution (EPD) website.
Place the file in a temporary location on the system that you plan to use to create
the image. For example:
/tmp/bmc_bl
3 Unzip provision-files.zip
This file unzips to create a directory structure that includes the following
subdirectories:
/provisioning/linux
/provisioning/linux/squashfs-utils
After you unzip, make sure that all of the scripts and squashfs-utils files in these
newly created directories have executable permissions.
4 Add these locations to the PATH environment variable. For example, if you
unzipped provision-files.zip to /tmp/bmc_bl, you would add the following
locations to the PATH environment variable:
/tmp/bmc_bl/provisioning/linux
/tmp/bmc_bl/provisioning/linux/squashfs-utils
6 Run the ls command to verify that the mkgen2img script is in this directory. This
is the script that creates the image file.
7 (Optional) To inject drivers into the Gentoo image, follow these steps:
b Copy the following required files into the driver subdirectory: modules.dep,
ixgbe.alias, igb.alias, and files.
These files are provided by the driver vendor and typically are included in the
driver download.
c Change directory to driver and create two subdirectories named x86 and x64.
d Copy the driver files (.ko files) that you want to inject in the image into the x86
and x64 subdirectories.
Ensure that the x86 directory contains only x86 drivers, and that the x64
directory contains only x64 drivers.
/tmp/bmc_bl/provisioning/linux
driver
files
igb.alias
ixgbe.alias
modules.dep
x64
xxx.ko
xxx.ko
x86
xxx.ko
xxx.ko
mkgen2img.sh
Use the command syntaxes shown below to create x86 and AMD64 Gentoo image
files. Do not execute these commands from NSH; use the native sh, bash, or ksh.
If you included drivers in the image, messages confirm driver injection. For
example:
Unlike other placeholder boot images, the Skip Linux Pre-Install image does not
represent a boot image you created and stored on the TFTP server. Instead,
associating this image with a device tells the provisioning system to skip the Gentoo
pre-installation image when the Provision Job runs.
You cannot configure the Skip Linux Pre-Install image to set it as the default
image type.
If a device associated with the Skip Linux Pre-Install image tries to boot from the
PXE server when a Provision Job for that device is not running, the PXE server
ignores boot requests from the device.
1 When you add or import a device, select Skip Linux Pre-Install as the boot image
file.
2 Create the system package and create and run the Provision Job as you normally
would.
When the Provision Job runs, the provisioning process jumps to the Make Run
Once step and the Kickstart/AutoYast file is generated on the data store.
Configuring provisioning
The provisioning process uses four provisioning technologiesPXE, JumpStart,
NIM, and Ignite. You must configure provisioning for each technology to establish a
connection to the data store and other functional software components.
PXE provisioning requires a DHCP server, a PXE server, a TFTP server, data
stores, and agent installation files.
In particular, you define the location of the data store, which is where you store sets
of installation files that are used for provisioning operating systems. Data store
values are stored in the Data Store system object, which you can edit by using the
Property Dictionary.
Any data store you specify must already be set up. For information about setting
up a data store, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Setting+up+the+provisioning+system.
To provision from a local data store, set up the local data store and use the local
data store instance as described in Provisioning Windows 2003 or 2008 servers
from a local data store on page 1374.
2 In the Property Class Navigation panel at the left, open the Built-in Property
Classes folder. Then open the DataStore sub-folder. Click Jumpstart DataStore,
Pxe DataStore, NIM DataStore, or Ignite DataStore.
A DataStore instance specifies the server that functions as a data store. You must
create at least one instance of a data store. You can create more than one instance.
For example:
One data store instance could contain files for provisioning Windows systems,
and another instance could contain files for provisioning Linux systems.
For an enterprise WAN, you could create one data store instance to serve the
London network segment, another to serve the New York network segment,
and a third to serve the Tokyo network segment.
Even if you plan to use only one data store, you must still create an instance of it.
4 Create a data store instance. As you create this instance, fill in the properties
required by the provisioning technology:
PXE Properties
To configure a data store instance for PXE provisioning, set the following property
values.
LOCATION (Required) The name or IP address of the server that functions as the
data store. (Note that this server must have a running RSCD agent that
is licensed for the BMC Server Automation Console.)
Note: If the PXE server, TFTP server, and the data store are all on the
same machine, follow these naming rules:
ESX Server 2.5 only: The data store is exposed via NFS. Set LOCATION
to the name of the NFS server.
FULL_PATH (Required) The full path to the directory that functions as a data store.
For a data store that resides on a Windows system, specify the path
using Windows path format; for a data store that resides on a UNIX-
like system, use UNIX path format.
When you identify the location of installation files required to
provision a particular operating system, specify the location in relation
to the directory you identify in this step.
VIRTUAL_DIR (Required) Provides the name of the virtual directory used to access the
data store.
UNIX-like systems: Part of the installation process includes providing
HTTP access to the root of your data store (the directory specified in
the LOCATION and VIRTUAL_DIR properties). The VIRTUAL_DIR
property refers to the directory component of the URL that points to
this directory.
For example, suppose your data store resides on a machine called
host1, and your FULL_PATH is:
/var/installs/redhat
Suppose that you set up HTTP access to this directory with the
following URL:
http://host1/installs
You would then set the VIRTUAL_DIR property to:
installs
Windows systems: Part of the installation process includes setting up
directory sharing for the data store directory.
For example, suppose LOCATION is defined as host2 and you set up
directory sharing for a data store directory called datastore:
\\host2\datastore\
You would then set the VIRTUAL_DIR property to:
datastore
ESX Server 2.5: The name of the share on the NFS server specified by
LOCATION.
USERNAME Provides the user name and password required to access the data store.
PASSWORD Linux data store only: USERNAME and PASSWORD do not require
values unless you have password-restricted access to your data store.
ESX Server 2.5 only: The user name and password required to access the
NFS share specified by VIRTUAL_DIR.
Windows data store with domain accounts only: In the USERNAME field,
specify the domain name and user name as domainname\username.
JumpStart properties
To configure a data store instance for JumpStart provisioning, set the following
property values.
BOOT_SERVER Host name of the boot server. This server must have a
running RSCD agent that is licensed for both NSH and the
BMC Server Automation Console.
BOOT_SERVER_FULL_PATH Full path to the Jumpstart root folder on the boot server.
If all three JumpStart services (boot, config, install) are on the same partition of the
same server, then set all three of the property pairs listed above to the same values.
For example:
BOOT_SERVER = jumpstart2
BOOT_SERVER_FULL_PATH = /js
CONFIG_SERVER = jumpstart2
CONFIG_SERVER_FULL_PATH = /js
INSTALL_SERVER = jumpstart2
INSTALL_SERVER_FULL_PATH = /js
NIM properties
To configure a data store instance for NIM provisioning, set the following property
values.
NIM_MASTER The host name of the NIM master. This value must be resolvable from
the BMC Server Automation application server. The NIM master must
have a running RSCD agent that is licensed for both NSH and the BMC
Server Automation Console.
STAGING_DIR_PATH An existing directory location on the NIM master. BMC Server
Automation uses this directory to stage all generated NIM resources.
The directory must be writable by users who create Provision Jobs,
because Provision Job execution creates subfolders and files as necessary.
Ignite properties
To configure a data store instance for Ignite provisioning, set the following property
values.
HOME_DIR_PATH (Optional) The path where Ignite is installed. Set this property if Ignite
is installed in a non-default path (that is, in a place other than /var/opt/
ignite).
IGNITE_SERVER The host name of the primary Ignite server. This value must be
resolvable from the BMC Server Automation Application Server. The
primary Ignite server must have a running RSCD agent that is licensed
for both NSH and the BMC Server Automation Console.
STAGING_DIR_PATH An existing directory location on the primary Ignite server. BMC Server
Automation uses this directory to stage all generated Ignite resources.
The directory must be writable by users who create Provision Jobs,
because Provision Job execution creates subfolders and files as necessary.
2 To configure or change the information for a system package type, select the type
in the list and click Edit. To add a new system package type, click Add.
The fields in the configuration window are specific to the OS of the system
package type:
4 When you finish adding or editing system package types, click OK on the System
Package Types tab.
Check this box if this system package type is for creating system packages
based on a WIM image in a data store.
Check this box if this system package type is for Windows 2008. Then from
the drop-down menu, select the Windows 2008 or Windows 2008 R2
operating system type.
Windows Architecture
Indicates the architecture of the machines you plan to provision with this
system package type.
OS Installer location
The location you specify should be relative to the root directory of the data
store. For example, if the root directory of the data store is the location:
Default: 2000
When you create system packages that are based on this system package
type, the permanent primary partition (typically C:) must be the same size or
larger than the initial partition size you specify here. For example, if you
specify an initial partition size of 4000 here, the permanent primary partition
you specify on the Disk Partition panel must be greater than or equal to 4000.
(For creating a custom system package type.) Select the Red Hat version for
which you want to create a system package type.
OS installer location
The location you specify should be relative to the root directory of the data
store. For example, if the root directory of the data store is the location:
RedHat5
The requirement is that the installer path name must be the parent directory
of the following directory for the version of Red Hat Linux that you are
provisioning:
images
The name assigned to the boot kernel file stored in the X86PC\pxelinux
directory on the TFTP server.
The name assigned to the boot image file stored in the X86PC\pxelinux
directory on the TFTP server.
Check this box if this system package type is for SUSE/SLES Version 10.x or
later. Then from the drop-down menu, select the SUSE/SLES version.
OS installer location
The location you specify should be relative to the root directory of the data
store. For example, if the root directory of the data store is the location:
suse9
The requirement is that the installer path name must be the parent directory
of the following two directories, for the version of SUSE that you are
provisioning:
boot
suse
The name assigned to the boot kernel file stored in the X86PC\pxelinux
directory on the TFTP server.
The name assigned to the boot image file stored in the X86PC\pxelinux
directory on the TFTP server.
ESX version
The operating system type and version are preselected and unavailable for
change if you clicked Edit on the System Package Type tab. If you clicked
Add on the System Package Type tab, select the operating system type and
version that you want to define.
OS installer location
The location you specify should be relative to the root directory of the data
store. For example, if the root directory of the data store is the location:
VMWare\esx3_5
The requirement is that the installer path name must be the parent directory
of the following two directories, for the version of VMWare that you are
provisioning:
VMWare
The name assigned to the boot kernel file stored in the X86PC\pxelinux
directory on the TFTP server.
The name assigned to the boot image file stored in the X86PC\pxelinux
directory on the TFTP server.
The additional image files for ESXi. For ESXi 4.1, four additional image files
are required and must exist on the TFTP server. Use three dashes and a space
before each file name. The path and file names must be relative to the TFTP
root directory, as the following examples show.
If the files exist directly under the TFTP root directory, keep the default
value that appears in this field, which is:
--- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz
If the files are in a subdirectory under the TFTP root directory, add the
subdirectory name to each file name to make the names relative to the
TFTP root directory. For example:
--- ESX41Images\sys.vgz --- ESX41Images\cim.vgz --- ESX41Images
\ienviron.vgz --- ESX41Images\install.vgz
WAN boot
Check this option if you will use the system package type with the WAN
boot installation method to provision Solaris over a public network to Sparc
target servers.
Solaris architecture
The type of machine you plan to provision with this system package type.
OS installer location
Relative path to the Tools directory of the installer tree. The location you
specify should be relative to the data store install server root.
Path to the Solaris Flash archive on the install server, relative to the install
server document root directory.
Path to the miniroot file on the boot server, relative to the boot server
document root directory.
Path to the wanboot installation program on the boot server, relative to the
boot server document root directory.
SPOT name
Lpp_source name
Mksysb name
Bosinst source
The NIM resource you want to use as the primary source for the operating
system. Choose one of the following options:
spot
rte
mksysb
HPUX architecture
The type of machine you plan to provision with this system package type.
Index file
Click Browse to select the Ignite index file you want to use for this system
package.
OS installer location
The location you specify should be relative to the root directory of the data
store. For example, if the root directory of the data store is the location:
XenServer56
The name assigned to the boot kernel file stored in the X86PC\pxelinux
directory on the TFTP server.
The name assigned to the boot image file stored in the X86PC\pxelinux
directory on the TFTP server.
This information applies to applies to PXE, JumpStart, NIM, and Ignite environments.
This procedure requires you to provide the location of installation files stored in the
data store. The data store is a directory structure that holds installation files. When
your BMC Server Automation system is first set up, a data store should also be set up.
You identify the root of the data store by doing one of the following:
3 Under Relative Paths for OS Images, select a system package type and click Edit
.
4 In the System Package Type window, edit the fields that specify installation file
locations. Then click OK.
Each system package type uses different fields for controlling installation file
locations. For information, see Configuring a system package type on page
1190.
For example, you might create a custom system package type to deploy an operating
system based on an earlier Microsoft service pack.
This procedure requires you to provide the location of installation files stored in the
data store. The data store is a directory structure that holds installation files. Identify
the root of the data store by doing one of the following:
4 Under Operating System Type, click the operating system for this system
package.
5 Provide information about the System Package Type window and click OK.
(Fields displayed in the window depend on the operating system type you
selected.) For information, see Configuring a system package type on page
1190.
To see the PXE configuration tab, you must have, at minimum, the
ProvisionConfig.Read authorization.
3 Provide information about the tab. Then click OK to save the current values. See
PXE Server tab on page 1203.
Windows: installDirectory\PXE\br\pxe.conf
UNIX: installDirectory/NSH/br/pxe.conf
Field definitions.
Interface to bind
The name of the Ethernet interface that the PXE server uses to listen. For
example, eth0 or eth1. Type the name of an interface.
Multicast address
The IP address of the multicast group that the PXE server listens on. (A
multicast group is a group of IP addresses that have been defined to receive a
multicast.) By default, the BMC Server Automation PXE server listens on the
multicast address of 224.1.5.1. Multicast addresses must fall in the range
224.0.0.0 to 239.255.255.255.
If you check Use broadcast, you must set the Multicast address to the PXE
servers IP address. This setting prevents the PXE server from continuing to
use the multicast address.
Listening port
The port on which the PXE server listens for connections from target
machines being provisioned. By default, the PXE server listens on port 4011.
Prompt timeout
The amount of time the boot prompt displays before the boot process begins.
If the time-out expires without interruption, the default boot option runs
automatically. If you enter 0, the boot prompt is not displayed.
Domain
Use multicast
Check this option if the PXE Server should listen to multicast requests. Then
enter the Multicast address.
Use broadcast
Check this option if the PXE Server should listen to broadcast requests. A
broadcast transmits to an entire network and thus uses network bandwidth
less efficiently than a multicast. If you check this option, enter the IP address
of the PXE server for Multicast address.
If the PXE server and the DHCP server are on the same machine, before starting the
PXE server you should first stop the DHCP server. Restart the DHCP server after
you start the PXE server.
Windows:
1 The PXE server is a Windows service, so choose Start => Settings =>
Control Panel => Administrative Tools => Services.
Windows:
1 The PXE server is a Windows service, so choose Start => Settings =>
Control Panel => Administrative Tools => Services
To see the TFTP configuration tab, you must have, at minimum, the
ProvisionConfig.Read authorization.
3 Provide information on the TFTP tab. See The TFTP Server tab on page 1205.
Windows: installDirectory\PXE\br\tftp.conf
UNIX: installDirectory/NSH/br/tftp.conf
Field definitions
The base directory of the file system used to store operating system bootstrap
programs to be downloaded.
Windows:
1 The TFTP server is a Windows service, so choose Start => Settings =>
Control Panel => Administrative Tools => Services
Windows:
1 The TFTP server is a Windows service, so choose Start => Settings =>
Control Panel => Administrative Tools => Services
When provisioning a device, the provisioning process uses an image that contains,
among other things, device-specific network drivers that interact with the hardware
and retrieve configuration information (such as the MAC address) for the device.
To prepare for Windows and Linux provisioning, you create the appropriate WinPE
or Gentoo Linux images that contain generic network drivers that work for most
hardware types. By default, the BMC Server Automation Console (UI) contains the
following pointers to these image files:
The pointers become operational after you create the corresponding image files and
place them in their correct locations on the TFTP Server.
Each image file has associated configuration settings, including a description and an
indication of which image file is the default for your environment. You can review
and change these configuration settings using the Image files tab.
Typically, a BMC Server Automation technician creates the custom image file for
you. This file must be located in the same directory as the standard image files:
WinPE image: Under the base TFTP directory, for example C:\tftproot.
Gentoo image: Under the appropriate pxelinux directory for the client
architecture under the base TFTP directory. For example, /tftproot/X86PC/
pxelinux.
3 Add or edit the information for the image type. For information, see The Image
Files tab on page 1208.
To edit the configuration settings for an existing image file listing, highlight the
image file name, then click Open . In the Edit Image File window, make the
changes you want.
To add a listing for a new image file, click Add . In the Add Image File
window, select an image type.
Fields displayed in the Add Image File window depend on the operating system
type you selected. For information, see:
When you finish adding or image file types, click OK on the Image Files tab.
Image file
The name of the image file. Assuming you used the standard BMC Server
Automation image creation wizard or script, the image file is named one of
the following:
WindowsPEImage
WindowsPE64Image
Description
Image path
C:\tftproot\boot_2_0
64 bit image
Check this field if this image is to be used to provision 64 bit machines. Leave
it unchecked otherwise.
The default image is the image that the system uses for auto-discovery. For
example, when an unknown device PXE boots on your network, the system
sends this device the default image.
WinPE 1.6 image type
The Add/Edit Image dialog box lets you define or edit the configuration settings of a
WinPE 1.6 image type.
Image file
The name of the image file. Assuming you used the standard BMC Server
Automation image creation wizard or script, the image file is named one of
the following:
WindowsPEImage
WindowsPE64Image
Description
Image path
C:\tftproot\boot
C:\tftproot\boot64
64 bit image
Check this field if this image is to be used to provision 64 bit machines. Leave
it unchecked otherwise.
The default image is the image that the system uses for auto-discovery. For
example, when an unknown device PXE boots on your network, the system
sends this device the default image.
Check this field if this is the default image for your environment.
Linux image type
The Add/Edit Image dialog box lets you define or edit the configuration settings of a
Linux image file type.
Image file
The name of the image file (RAM drive). Assuming you used the standard
BMC Server Automation image creation script, the image file is named:
gentoord.gz
Description
(Optional)
Kernel name
The kernel required for PXE booting a Linux machine. Assuming you used
the standard BMC Server Automation image creation script, the kernel name
is:
gentoo
Kernel commandline
64 bit image
Check this field if this image is to be used to provision 64 bit machines. Leave
it unchecked otherwise.
The default image is the image that the system uses for auto-discovery. For
example, when an unknown device PXE boots on your network, the system
sends this device the default image.
Check this field if this is the default image for your environment.
DOS image type
The Add/Edit Image dialog box lets you define or change configuration settings for
the DOS image file type.
Image file
The name that will appear in the boot image drop-down menus in the BMC
Server Automation GUI.
Description
The default image is the image that the system uses for auto-discovery. For
example, when an unknown device PXE boots on your network, the systems
sends this device the default image.
Check this field if this is the default image for your environment.
ESXi 4.0 image type
The Add/Edit Image dialog box lets you define or edit the configuration settings of
the ESXi 4.0 image file type.
Image file
ESX4i/vmkboot.gz
Description
Kernel name
The kernel to be loaded when the device boots from the PXE server. Specify a
path to the folder that contains the mboot.c32 file.
Kernel commandline
Command line arguments that the kernel requires at boot time. Separate
arguments with a dash (---). Each argument should include the path to the
folder containing the file (vmk.gz, sys.vgz, cim.vgz, oem.tgz, and license.tgz).
For example:
64-bit image
Because ESXi 4.0 can be used to provision only 64 bit devices, this option is
checked and disabled.
If you want to use an x86 image, you must create a custom image.
The default image is the image that the system uses for auto-discovery. For
example, when an unknown device PXE boots on your network, the system
sends this device the default image.
Because auto-discovery is not supported for the ESXi 4.0 image, you cannot
set this image as the default.
WinPE 2.x ISO image type
The Add/Edit Image dialog box lets you define or edit the configuration settings of a
WinPE 2.x ISO image type.
For information about creating this file, see Provisioning Windows 2003 or 2008
servers from a local data store on page 1374.
Image file
Description
Image path
C:\tftproot\boot_2_0
64 bit image
Check this field if this image is to be used to provision 64 bit machines. Leave
it unchecked otherwise.
The default image is the image that the system uses for auto-discovery. For
example, when an unknown device PXE boots on your network, the system
sends this device the default image.
Because auto-discovery is not supported for the WinPE 2.x ISO image, you
cannot set this image as the default.
Having a system package run a Batch Job allows you to build the server stack
beyond the operating system or to perform other tasks that you might typically
perform using the BMC Server Automation system. For example, you can define a
system package that runs a Batch Job consisting of multiple sub-jobs that configure a
web server. One sub-job might install Apache and another might add web content to
the server.
1 Create the Batch Job. For information, see Creating a Batch Job on page 803.
In the Batch Job, you can leave the target server field blank or allow any existing
value to remain. When a Batch Job is referenced in a system package and executes
as part of a Provision Job, the Batch Job executes on the newly provisioned server
only.
2 When you create the system package, define its configuration settings to include
the Batch Job.
Windows, Linux, ESX, HP-UX system packages: Specify a Batch Job in Post-
installation configuration settings.
AIX system packages: Specify a Batch Job in Agent Install/First Boot Script
settings.
All of the instructions needed to install an operating system over the networkA
system package type uses installation files for a specific operating system.
Consequently, system packages for the various types of Windows, Linux,
VMWare ESX and ESXi, Solaris, AIX, and HP-UX operating systems are not
interchangeable. You must create separate system packages for servers running
different operating systems.
(Optional) Instructions for running jobs that install software and configure a
machine for a particular purposeYou can create a different system package for
each server configuration that you want to provision, rather than just creating one
system package for each type of operating system. For example, you could create
a system package for a web server running Windows 2008 and IIS, and then create
another system package running Windows 2008 without the web server
configuration.
Tip
A system package contains many settings. If you are creating multiple system
packages with similar settings, you can use the Console copy and paste features to
create a new system package from an existing one, rename the copy, and adjust the
settings in the copy, as necessary.
In the Depot, create one or more folders for your system packages.
1 In the Depot, right-click the folder where you want to add a new system package.
From the pop-up menu, choose New => System package.
2 Provide information for the new system package, as described in the following
sections:
4 Define settings in the system package using the tabs at the bottom of the content
editor. Each OS type has a different set of tabs.
For any type of supported Windows operating system, see Defining settings for
Windows servers on page 1218.
For supported Linux operating systems, see Defining settings for Red Hat
Linux servers on page 1243 or Defining settings for SUSE Linux servers on
page 1254.
For any type of supported ESX operating system, see Defining settings for ESX
servers on page 1276.
For the ESXi operating system, see Defining settings for ESXi 4.1 and 5.0 servers
on page 1266.
For the Citrix XenServer operating system, Defining settings for Citrix
XenServers on page 1288.
For any type of supported Solaris operating system, see Defining settings for
Solaris servers on page 1296.
For any type of AIX operating system, see Defining settings for AIX servers on
page 1310.
For any type of supported HP-UX operating system, see Defining settings for HP-
UX servers on page 1322.
Tip
When defining a system package, note the presence of the Select Property icon
next to various input fields. This icon indicates that you can insert a
parameter that refers to a local property to supply the value for the field. For
information on inserting a parameter, see Inserting a parameter in a system
package field on page 1413 and Using properties to reference scripts on page
1414. For an example of how using parameters can streamline provisioning, see
Assigning configuration values during device import on page 1341.
5 When you finish defining the system package, select File => Save.
Field Definitions
Name
Enter an identifying name for the system package. This name appears in the
Depot.
Description
Member of
Verify the folder in the Depot under which this system package belongs. To
change the displayed folder name, click Browse.
Select the type of operating system that you want this system package to
install. The system package type controls which options and tabs are
available when you open the system package to define the installation settings.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to the system
package. You can also set permissions by adding ACL templates.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to this job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
If you want the contents of the selected ACL templates to replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to any existing
entries in the access control list.
1 In the Depot folder, navigate to the system package you want to define. Right-
click the system package and select Open.
2 To define standard system package settings, click the tabs at the bottom of the
system package tab. Each tab represents a category of settings, as described in the
following sections:
3 When you finish defining settings for the system package, click the system
package tab and select File => Save.
To add a pre-install script, click Add , and then specify the scripts name,
contents, and whether or not to reboot after the script runs.
Drive labels
If you define multiple partitions, the drive letters used in the provisioned servers are
not guaranteed to be the same as the drive letters you configured in the system
package. The Windows Operating System reassigns the drive letters in alphabetical
order on boot, skipping A and B. The letter C is the boot partition. The letter K is
reserved for mapping to the provisioning data store; hence, BMC Software
recommends that you not use the letter K for any drive in disk partitioning.
The script executes in its entirety during the disk partition stage of provisioning.
Note
When you use a script for partitioning, you are defining both the initial AND the
permanent partitions. The initial partition size defined in the system package type
object is not used in this case. (For information about specifying the initial partition
size in the system package type object, see Creating custom system package types on
page 1201.)
Field definitions
Use script for disk partitioning
To supply a script that defines the disk partitions, select this option. Then
add a script in the script text box using one of the following methods:
Type the name of a local property that contains the script, enclosing the
property name with double question marks.
To use the GUI fields to define disk partitions, clear this option. Then add
or edit lines in the disk partition table as follows:
To save your changes, click OK. The new or changed partition appears
in the Disk Partitions list.
Label
Primary partition
Type
NTFSNT File System is one of the file systems that Windows operating
systems use for storing files. Microsoft recommends NTFS over FAT32
because of better security, compression, and performance. However, NTFS
may not be compatible with other operating systems, so it may not be the
correct choice if you are configuring a dual-boot system.
Size
The size of the partition in megabytes. Set this value according to Microsofts
available disk space recommendations for the operating system specified in
this system package.
Check this option if you want the partition to fill all remaining space on the
disk. Only one partition can fill all unused space.
Quick format
Check this option to format the partition much faster than the normal format
option.
Partition label
The name for the partition. This name appears with the drive letter. For
example: Misc (D:).
In the text box, type the name of a local property that contains a script, enclosing
the property name with double question marks.
This tab also displays a check box for rebooting the server after those commands
execute.
Field Definitions
Computer Name
The unique name that should be assigned to the server. Enter a name or
check Auto-generate computer name.
Rather than auto-generate names, you can use the same system package to
provision multiple servers and assign a unique name to each server when
you apply the system package to the server. See Provisioning multiple
servers tips on page 1373.
OM Server Name
To have the server display its Computer name when it appears in the BMC
Server Automation Console, leave the OM Server Name field blank.
If you choose to use a different OM Server Name for this machine, make sure
that this new name can be resolved to the IP address of the server.
Administrator password
The local administrators password. Enter the password. Then confirm your
typing by entering the password again in the Confirm password field.
Note
In Windows 2003 system packages, if you use an administrator password
that starts with a pound sign (#), enclose the password in double quotation
marks ().
Workgroup
Specifies that the server should be part of a workgroup. Select this option and
then enter the name of the workgroup in the text box to the right. A
workgroup is a group of computers with the same workgroup name.
Specifies that the server should be part of a domain. Select this option and
then enter the name of the domain in the text box to the right. A workgroup
is a group of computers with the same workgroup name.
If you do not check this option and you are adding a server to a domain, a
computer account for the server must already exist in the domain.
User name
Password
The password for the users computer account. Enter the password and then
confirm your typing by entering the password again in the Confirm
password field.
Field definitions
Name
Organization
For configuring PnP or OEM drivers, for PnP driver paths, click Browse
to select drivers. For information, see Selecting drivers Windows 2008 on
page 1225
drivers\Compaq\Win2008\Display;drivers\HPDLG30g5\Win2008\RAID
License key
Enter the key to the software license you are using, including all hyphens in
the key. Then, under License key, do one of the following:
Note
To install an evaluation version of Windows Server 2008 R2 (or one that uses
a Multiple Activation Key), leave the License Key field blank. You can
activate the license key on the target server later or you can customize the
Unattend.xml file by providing the activation key. By default, the system
package accepts the KMS license key.
Time zone
Locale
Select a language option. For example, in the United States, select English
United States.
1 For configuring PnP or OEM drivers, for PnP driver paths, click Browse to
select drivers.
2 For Select DataStore, click Browse and browse to the data store that contains the
PnP or mass storage drivers.
Note
Browsing the data store for the PnP and mass storage drivers has the following
requirements:
The drivers must be located in the same data store as the rest of the installation
files for this system package.
There must already exist in the BMC Server Automation environment a server
object whose name matches the LOCATION property of the data store instance
you selected.
If multiple databases are in use for multiple physical locations, for example
you can choose an alternate data store instance when you create the Provision Job.
However, data store directories and contents must be identical (relative to the
pxestore virtual directory) for all instances.
The navigation panel displays the directory structure with the data store root as
its root.
Note
The selected folder must contain files with the .inf extension. If you select a folder
that does not contain any .inf files, the system displays an error message.
3 In the left pane, select the root folder that contains drivers or subfolders with
drivers. All drivers in the folder and its subfolders appear in the right panel.
The paths to the drivers appear in PnP driver paths field of the Computer
Settings tab. The paths appear in NSH format.
5 Click OK.
If you have not yet associated this system package with this data store, the system
displays a message, asking you if you would like to set this data store as the
default data store for this system package. If you would like the system to
automatically display the contents of this data store every time you start the
driver selection GUI from this system package, click Yes.
Field definitions
Name
Organization
Specifies whether the $OEM$ drivers are directly beneath the i386 or amd64
directory or in a different location in the data store.
If you leave Specify path to $OEM$ directory unchecked, you are telling the
provisioning process that either your $OEM$ directory and its drivers are
already directly beneath the i386 or amd64 directory, or that you plan to use
the GUI to copy your drivers to this location.
If you check Specify path to $OEM$ directory, you are telling the
provisioning process that your $OEM$ directory is in a different location.
Enter this location in the Path to $OEM$ directory field.
For more information, see When to use Specify path to $OEM$ directory on
page 1229.
Click Browse and use the driver selection GUI to automatically fill in
the PnP driver paths. For information, see Using the driver selection GUI:
PnP driver paths on page 1230.
Note
Browsing the data store for the PnP and mass storage drivers has the following
requirements:
The drivers must be located in the same data store as the rest of the
installation files for this system package.
Click Browse and use the driver selection GUI to automatically fill in the
mass storage drivers. For information about how to use this GUI, see Using
the driver selection GUI: mass storage drivers on page 1231.
License key
Enter the key to the software license you are using, including all hyphens in
the key. Then do one of the following:
Time zone
Locale
Select a language option. For example, in the United States, select English
United States.
If you do not check Specify path to $OEM$ directory, your $OEM$ directory (and
the drivers it contains) must be located directly beneath the i386 or amd64 directory.
For example, assume your data store root is drive :\pxestore and you are storing
your Windows 2003 operating system files in a directory called win2k3. Your $OEM
$ directory and its contents must look similar to the following:
However, you might not want to store your drivers directly beneath the i386 or
amd64 directory. Instead, you may want to store your drivers in a directory
structure similar to the following:
In this case, check Specify path to $OEM$ directory and then specify the location of
the $OEM$ directory in Path to $OEM$ directory. The path to the $OEM$ directory
is from the root of the data store and does NOT include the $OEM$ directory itself.
Continuing with this example, (where drive :\pxestore is the data store root), the
Path to $OEM$ directory is:
drivers\vendor1\model1
1 On the Computer Settings tab, next to PnP driver paths, click Browse .
2 For Select DataStore, browse to the data store that contains the PnP drivers.
Note
Browsing the data store for the PnP drivers has the following requirements:
The drivers must exist in the same data store as the rest of the installation files
for this system package.
A server object whose name matches the LOCATION property of the data
store instance you selected must exist in the BMC Server Automation
environment.
3 In the left pane, expand the root folder down to the folder that contains drivers or
subfolders with drivers.
Note
If you filled in the Path to $OEM$ directory, the navigation panel uses that $OEM
$ path as its root. If you did not fill in the Path to $OEM$ directory, the
navigation panel uses the data store root as its root.
All drivers in the folder and its subfolders appear in the right panel.
Note
The selected folder must contain files with the .inf extension. If you select a folder
that does not contain any .inf files, the system displays an error message.
4 Use the arrow keys to further select drivers. Then click OK.
The paths appear in the PnP driver paths field on the Computer Settings panel
and the required entries are added to the Unattend Entries file. The paths appear
in NSH format.
Note
If you do not fill in the Path to $OEM$ directory, the system checks to see if the
directories you specify are directly beneath the i386 or amd64 directory. If they
are not, they are automatically copied to a location directly beneath the i386 or
amd64 directory. (For this to work, the system package type must specify the OS
installer path. Otherwise, an error message appears.) For more information, see
When to use Specify path to $OEM$ directory on page 1229.
5 If you have not associated this system package with this data store, a message
appears prompting whether to set this data store as the default data store for this
system package.
To display the contents of this data store every time you start the driver selection
GUI from this system package, click Yes. (Note that if you associate this data store
with this system package, this data store is displayed by default if you
subsequently browse for mass storage drivers.)
1 On the Computer Settings tab, next to Mass storage drivers, click Browse .
2 For Select Data Store, browse to the data store that contains the mass storage
drivers.
Note
Browsing the data store for the mass storage drivers has the following requirements:
The drivers must be located in the same data store as the rest of the installation
files for this system package.
There must already exist in the BMC Server Automation environment a server
object whose name matches the LOCATION property of the data store instance
you selected.
3 In the left pane, navigate to the directory that contains the first driver that you
want to add.
Note
If you filled in Path to $OEM$ directory, the navigation panel uses the $OEM$
path you specified as its root. If you did not fill in the Path to $OEM$ directory,
the navigation panel uses the data store root as its root.
4 Click the txtsetup.oem file for that directory. The mass storage drivers appear in
the right pane. (If you do not see the drivers in the right pane, you may need to
examine and correct the format of the entries in txtsetup.oem. See Error to check
in txtsetup.oem on page 1232.)
5 In the right pane, click drivers to add. Use Control-click or Shift-click to select
multiple drivers.
6 Click OK. The GUI automatically fills in the Mass storage drivers field on the
Computer Settings panel. It also adds required entries to the Unattend Entries file.
Note
If you did not fill in the Path to $OEM$ directory, the system checks to see if the
directories you specified are directly beneath the i386 or amd64 directory. If they
are not, they are automatically copied to a location directly beneath the i386 or
amd64 directory, for example:drive :\pxestore\win2k3\i386\$OEM$
\TEXTMODEFor more information, see When to use Specify path to $OEM$
directory on page 1229.
7 If you have not yet associated this system package with this data store, a message
appears, asking if you would like to set this data store as the default data store for
this system package.
To automatically display the contents of this data store every time you start the
driver selection GUI from this system package, click Yes. (Note that if you
associate this data store with this system package, this data store appears by
default if you subsequently browse for PnP drivers.)
The entries in txtsetup.oem are case sensitivespecifically, the case of entries in the
[Defaults] section must match the case of entries in the [Files] section.
[Disks]
d1 = "Smart Array 5x and 6x Storport Driver Diskette",\TXTSETUP.OEM,\
[Defaults]
SCSI = 5x6x
[SCSI]
5x6x = "Storport Driver for Smart Array 5x and 6x Controllers"
[Files.scsi.5x6x]
driver = d1,HpCISSs.sys,HpCISSs
inf = d1,HpCISSs.inf
catalog = d1,HpCISSs.cat
[Config.HpCISSs]
value = "",tag,REG_DWORD,103
value = Parameters\PnpInterface,5,REG_DWORD,1
SCSI = 5x6x
[Files.scsi.5x6x]
To correct this error, you could change the [Files] entry to uppercase:
[Files.SCSI.5x6x]
You could also change the [Defaults] entry to lowercasethe point is that the case of
each character must be the same in [Defaults] and [Files].
Select the operating system type. Then specify the server roles to install by doing one
of the following:
Under Select Server Roles/Features, select the server roles. To install all server
roles, check Windows 2008 Server Roles.
Check Use Script to install Server Roles/Feature and type the script in the text
area. The commands you use depend on the operating system type you selected.
For a Full Server installation, use the commands of the Windows Server 2008
ServerManagercmd.exe command line utility. For example:
servermanagercmd -install File-Services
For a Core Server installation, use the commands of the Windows optional
component setup tool (Ocsetup.exe). For example:
start /w ocsetup DHCPServer
Hyper-V role:
Only Windows 2008 x64 system package types support the Hyper-V role.
Selecting a server role installs the role with the operating system during
provisioning but does not configure the role. You must configure the role
manually or set up a Batch Job.
Component options
IIS
To install all IIS components, check IIS. To install a subset of all IIS
components, check individual IIS components.
Terminal Services
If you select this option, terminal services is enabled in the application server
mode. Terminal services in application server mode requires licensing and,
by default, expires after 60 days.
[TerminalServices]
AllowConnections=On
Network Windows
The Network tab lets you provide networking information for a server, such as its IP
address and DNS configuration.
Field definitions
Obtain an IP address automatically
Specifies that the network connection should use a static IP address that you
specify. If you choose this option, provide the following information:
IP address
Subnet mask
Default gateway
IP address
Subnet mask
The subnet mask number, which is used to identify which segment of the
network the server is on.
The Windows 2003 installer does not support three zeroes in any of the octets
in the subnet mask. For example, if the subnet mask is 255.255.255.0, entering
255.255.255.000 for Subnet mask does not work. You must enter 255.255.255.0.
Default gateway
Specifies that the DHCP server should provide the addresses for DNS servers.
Specifies that addresses are manually provided. Select this option and then
enter IP addresses for Primary DNS server and Secondary DNS server.
When you define settings for a Windows 2008 system package, your input is
automatically converted into entries in the Unattend Entries file (unattend.xml). This
file is used in unattended installations to provide answers to the prompts that would
be provided interactively in a live installation.
The Additional Unattend Entries XML editor is an XML editor only and is
not intelligent about the BMC Server Automation provisioning process or
components required in Windows installations.
If you create a custom unattend.xml file, then when you create a Provision
Job using the system package, the wizard displays the Customized Unattend
Entries panel. You can use the panel to edit the custom unattend.xml file for
the particular Provision Job.
2 In the Generated Unattend area, expand the nodes and select the component to
change. The component appears in the Selected XML Component area.
5 Click OK.
On the Unattend Entries tab, the added or replaced entry appears in both the
Customized Unattend Entries text box and in the Additional Unattend Entries list.
2 In the Add/Replace XML Component area, edit the entry by either typing in the
change or by clicking Select Property and selecting a property reference.
3 Modify the unattend.xml file displayed in the Customized Unattend Entries text
box.
You can add entries to the unattend.txt file and customize the file by editing existing
entries.
Note
If you create a custom unattend.txt file, then when you create a Provision Job using
the system package, the wizard displays the Customized Unattend Entries panel.
You can use the panel to edit the custom unattend.txt file for the particular Provision
Job. See To change existing unattend.txt entries on page 1239.
2 Add your new entries in the Additional entries for the unattend.txt file box.
(Make sure to include entry headers, for example [Display].)
3 Then, still in the first edit box, add your additional entries. (Make sure to include
entry headers, for example [Display].)
In this scenario, because you want to modify the automatically generated entries
in the first edit box, you must add your additional entries to the first edit box, not
the second edit box.
Field definitions
Install RSCD agent
Check this option to install an RSCD agent on the target servers. (An agent
must be installed on every server that you want to manage using the BMC
Server Automation Console or Network Shell.)
Agent Install Options (Optional) Type one or more properties that override
the default settings for the Windows RSCD agent installation. To specify a
property, use the format: PROPERTY=value. Separate properties with a space.
INSTALLDIR The target location for the RSCD Any valid path for Windows.
installation. The default is C: Enclose the path in double
\Program Files\BMC Software quotation marks ("").
\BladeLogic\RSCD
KEYLOGS Enables or disables the use of 1 (enable) or 0 (disable).
keystroke logs for nexec The default is1.
commands.
LOGFILEDIR Location of agent log files. The Valid directory for RSCD log files.
default is C:\Program Files\BMC
Software\BladeLogic\RSCD
MAPUSER A local user's account. If you String
specify a value for this option, the
exports configuration file is
modified to force the agent to
impersonate the specified user for
all activities. By default the
property is not set and no user
mapping is created.
RSCDPORT Sets the RSCD port number in the Valid port number
rscd entry of the agent's secure
configuration file.
SECURELOGS Enables or disables use of secure 1 (enable) or 0 (disable).
(digitally signed) logs for the The default is 1.
RSCD agent.
Secure agent logs have message
authentication codes and sequence
numbers assigned to the current
log and digitally rolled logs.
REBOOT Suppresses server reboot after Suppress
agent installation. Without this
parameter, the server reboots
when the agent installation
finishes.
Use this parameter in system
packages for Windows 2008 Server
Core. For more information, see
Post-install script for Windows
2008 Server Core installations on
page 1243 at the end of this panel
description.
Push ACLs
Check this option to push the ACLs defined for the server in the BMC Server
Automation system to the RSCD agent you are installing on the server.
Check this option to run a post-install Batch Job that can install software and
configure the server. Then for Path to post-install job, enter the path to the
job or Browse to select it.
In order to check Run post-install batch job, you must also check Install
RSCD agent, because running a post-install job requires that there is an agent
installed on the server.
If you specify a Post-install Batch Job, make sure that the provisioning
operator who runs the provisioning wizard logs is using a role that has Read
and Execute authorizations on the Batch Job and has Read and Execute
authorizations on all the Jobs contained in the Batch Job.
Select this option to ensure that the post-install Batch Job runs, even if RSCD
agent enrollment fails. If you do not select this option, the post-provisioning
Batch Job does not execute if RSCD agent enrollment fails.
For example, if you use DNS, the RSCD agent enrollment cannot succeed
until a DNS entry for the target server is provided. If you want to provide the
DNS entry using a script in the Batch Job, you need the Batch Job to run even
when the RSCD agent enrollment fails.
For load balancing, you can use different Application Servers for reporting
Provision Job completion status. Use these fields to identify the Application
Server to which target servers in this job should report their Provision Job
completion status.
Post-install script
The runonce.bat file runs one time when Windows starts for the first time
after an unattended installation of the operating system.
Any commands you enter into this script are appended to commands that
BMC Server Automation provisioning also inserts in this script, including a
command to install the RSCD agent. The commands that you enter run
before any post-install jobs you specify.
where data_store_folder_name in the second line is the same folder that you
specified in the Name field when you created the system package. It is the
CMPNENTS folder's parent folder in the data store.
These instructions assume that the data store contains the Windows R2
installation media in a CMPNENTS folder. For information about setting up
the data store for Windows R2 systems, see BMC technical documentation at
https://docs.bmc.com/docs/display/bsa82/Stocking+the+data+store.
The second line in the preceding script executes the setup2.exe utility from
the Windows R2 installation media. The r: drive was created when you
created the Windows 2003 R2 or Windows 2008 R2 system package type. The
system maps to r: by default.
A system package for Windows 2008 Server Core requires the following
entries on this panel. Otherwise, the Provision Jobs that use the system
package do not complete successfully.
1 In the Agent Installation Options field (earlier on the panel), enter the
following line:
REBOOT=Suppress
The first line, which prevents the server from rebooting, allows the
runonce.bat file to complete. The second line forces the reboot later, which is
required to start up the RSCD agent.
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
Then use the property dialog box to add or modify a local property.
1 In the Depot folder, navigate to the system package you want to define. Right-
click the system package and select Open.
A tab for the system package appears in the Content Editor view.
2 Define standard system package settings by clicking the tabs at the bottom of the
system packages tab. Each tab represents a category of settings, as described in
the following sections:
3 When you finish defining settings for the system package, click the system
package tab and select File => Save.
To add a pre-install script, click Add , then specify the scripts name, contents,
and whether or not to reboot after the script is executed.
There are two ways to define a partition for Gentoo-based system packagesby
supplying a script or using fields in the GUI:
To supply a script, click Use script for disk partitioning. Then do one of the
following:
Type the name of a local property that contains the script, enclosing the
property name with double question marks.
If you want to reboot after script execution, click Reboot after the script is
executed.
To modify an existing partition, select the partition in the Disk Partition list and
click Open .
Field definitions
Mount point
The location within a file directory where a volume should exist. Enter a
location or select one from the drop-down list.
Type
ext2Supports standard UNIX file types and allows file names up to 255
characters.
swapSupports virtual memory, that is, swapping data in and out of this
partition when there is insufficient RAM to perform an operation.
ext4(Red Hat Enterprise Linux 6 only) Supports all features of ext3 plus
adds support for larger file systems, more efficient allocation of disk
space, no limit on the number of subdirectories within a directory and
more robust journaling.
jfsSupports journaling.
xfsSupports journaling.
Size (MB)
The size of the partition in megabytes. If you want the partition to fill all
remaining space on the disk, check Fill all unused space on disk.
If you are specifying the size of a swap partition, make sure the size you
specify is supported by the specific version of this system packages
operating system.
Disk
Field definitions
Computer name
OM Server Name
If you want this server to display its Computer name when it appears in the
BMC Server Automation Console, leave the OM Server Name field blank.
If you do choose to use a different OM Server Name for this machine, make
sure that this new name can be resolved to the IP address of the server.
Root password
The password used to access the root account. Enter a password. Then
confirm your typing by entering the password again in the Confirm
password field.
For example, you might enter eth0 or eth1. Note that the name of the field
under Provisioning SettingsKickstart network device or AutoYaST
network devicevaries depending on the type of system package you are
defining.
When defining settings for provisioning of SUSE Linux servers, if you specify
the AutoYaST network device, it can result in timeout. To avoid this issue, do
not specify the AutoYaST network device for SUSE Linux servers in a multi-
NIC environment. You do not need to specify the AutoYaST parameter; the
SUSE installer is capable of finding the active NIC and retrieving the
AutoYaST file.
Additional boot time kernel parameters you would like to use for the server.
Some commonly used parameters include:
skipddcThis x86 boot command skips the ddc monitor probe which
causes issues on some systems.
For a full list of available boot kernel parameters, see the Red Hat and SUSE
installation documentation.
Field definitions
Keyboard
Select the keyboard layout type that you want to be the system default. For
example, in the United States you would probably select us.
Mouse
Select a type of mouse that you want to use with the machine. (This setting is
not available for Red Hat Enterprise Linux 6.)
Time zone
Check Use Custom TimeZone and type a time zone in the text box.
Locale
Select a language option from the drop-down list. For example, in the United
States, select English (USA).
Enter the 16-character alpha-numeric key that can be used during the
installation process.
The OS Components tab lets you select operating system components to install. You
can use a text-based approach or a GUI-based approach. If you use the GUI-based
approach, check the components to install. If you use the text-based approach, use
the text box to enter entries that should be included in the %packages section of the
kickstart file. You do not have to enter the %packages header. For example, you
might create entries like the following:
Note
When you script your own OS components, you must include wget, either by itself
or by including a package that contains it.
@base
@compat-libraries
These components are required because the core installation for RHEL6 does not
include certain required glib libraries. When you list these components, the required
libraries are included in the installation.
This requirement applies only to RHEL6 custom system package types.The standard
RHEL6 system package type delivered in BMC Server Automation already includes
these components.
Field definitions
Obtain an IP address automatically
Specifies that the network connection should use a static IP address that you
specify. If you choose this option, provide the following information:
IP address
Subnet mask
Default gateway
DNS server
IP address
Subnet mask
The subnet mask number, which is used to identify which segment of the
network the server is on.
Default gateway
Specifies that the DHCP server should provide the addresses for DNS servers.
Specifies that you want to manually configure a DNS server. Select this
option and enter an IP address for DNS Server.
DNS server
When you define a Red Hat Linux system package, your input on the system
package tabs is automatically converted into text in the first edit box at the top of the
Kickstart Entries tab.
You can add entries to the Kickstart file and customize the file by editing existing
entries.
Note
If you create a custom Kickstart file, then when you create a Provision Job using the
system package, the wizard displays the Customized Unattend Entries panel. You
can use the panel to edit the custom Kickstart file for the particular Provision Job. See
To change existing unattend.txt entries on page 1239.
2 Add your new entries in the Additional entries for the kickstart file box.
3 Then, still in the first edit box, add your additional entries.
In this scenario, because you want to modify the automatically generated entries
in the first edit box, you must add your additional entries to the first edit box, not
the second edit box.
Field definitions
Install RSCD agent
Check this option to install an agent on the target servers. (An agent must be
installed on every server that you want to manage using the BMC Server
Automation Console or Network Shell.)
Push ACLs
Check this option to push the ACLs defined for the server in the BMC Server
Automation system to the RSCD agent that you are installing on the server.
Selecting this option automatically translates the permissions you defined for
the server in the BMC Server Automation system into a users configuration
file on the RSCD agent. In this way, you control users access to the server not
only through the BMC Server Automation Console but also through Network
Shell and the BLCLI.
Check this option to run a post-install Batch Job that can install software and
configure the server. Then, for Path to post-install job, enter the path to the
job or Browse to select it.
To check Run post-install batch job, you must also check Install RSCD
agent, because running a post-install job requires an agent on the server.
If you specify a Post-install Batch Job, make sure that the provisioning
operator who runs the provisioning wizard logs is using a role that has Read
and Execute authorizations on the Batch Job and has Read and Execute
authorizations on all the Jobs contained in the Batch Job.
Select this option to ensure that the post-install Batch Job runs, even if RSCD
agent enrollment fails. If you do not select this option, the post-provisioning
Batch Job does not execute if RSCD agent enrollment fails.
For example, if you use DNS, the RSCD agent enrollment cannot succeed
until a DNS entry for the target server is provided. To provide the DNS entry
using a script in the Batch Job, the Batch Job must run even when the RSCD
agent enrollment fails.
For load balancing, you can use different Application Servers for reporting
Provision Job completion status. Use these fields to identify the Application
Server to which target servers in this job should report their Provision Job
completion status.
Post-install Script
Commands that you enter into the post-install script are appended to
commands that BMC Server Automation provisioning also inserts in this
script, including a command to install the RSCD agent. The commands that
you enter run before any post-install Batch Job that you specify.
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
Then use the property dialog box to add or modify a local property.
1 In the Depot folder, navigate to the system package you want to define. Right-
click the system package and select Open.
A tab for the system package appears in the Content Editor view.
2 Define standard system package settings by clicking the tabs at the bottom of the
system packages tab. Each tab represents a category of settings, as described in
the following sections:
3 When you finish defining settings for the system package, click the system
package tab and select File => Save.
To add a pre-install script, click Add , then specify the scripts name, contents,
and whether or not to reboot after the script is executed.
There are two ways to define a partition for Gentoo-based system packagesby
supplying a script or using fields in the GUI:
To supply a script, click Use script for disk partitioning. Then do one of the
following:
Type the name of a local property that contains the script, enclosing the
property name with double question marks.
If you want to reboot after script execution, click Reboot after the script is
executed.
To modify an existing partition, select the partition in the Disk Partition list and
click Open .
Field definitions
Mount point
The location within a file directory where a volume should exist. Enter a
location or select one from the drop-down list.
Type
ext2Supports standard UNIX file types and allows file names up to 255
characters.
swapSupports virtual memory, that is, swapping data in and out of this
partition when there is insufficient RAM to perform an operation.
ext4(Red Hat Enterprise Linux 6 only) Supports all features of ext3 plus
adds support for larger file systems, more efficient allocation of disk
space, no limit on the number of subdirectories within a directory and
more robust journaling.
jfsSupports journaling.
xfsSupports journaling.
Size (MB)
The size of the partition in megabytes. If you want the partition to fill all
remaining space on the disk, check Fill all unused space on disk.
If you are specifying the size of a swap partition, make sure the size you
specify is supported by the specific version of this system packages
operating system.
Disk
Field definitions
Computer name
OM Server Name
If you want this server to display its Computer name when it appears in the
BMC Server Automation Console, leave the OM Server Name field blank.
If you do choose to use a different OM Server Name for this machine, make
sure that this new name can be resolved to the IP address of the server.
Root password
The password used to access the root account. Enter a password. Then
confirm your typing by entering the password again in the Confirm
password field.
For example, you might enter eth0 or eth1. Note that the name of the field
under Provisioning SettingsKickstart network device or AutoYaST
network devicevaries depending on the type of system package you are
defining.
When defining settings for provisioning of SUSE Linux servers, if you specify
the AutoYaST network device, it can result in timeout. To avoid this issue, do
not specify the AutoYaST network device for SUSE Linux servers in a multi-
NIC environment. You do not need to specify the AutoYaST parameter; the
SUSE installer is capable of finding the active NIC and retrieving the
AutoYaST file.
Additional boot time kernel parameters you would like to use for the server.
Some commonly used parameters include:
skipddcThis x86 boot command skips the ddc monitor probe which
causes issues on some systems.
For a full list of available boot kernel parameters, see the Red Hat and SUSE
installation documentation.
Field definitions
Keyboard
Select the keyboard layout type that you want to be the system default. For
example, in the United States you would probably select us.
Mouse
Select a type of mouse that you want to use with the machine. (This setting is
not available for Red Hat Enterprise Linux 6.)
Time zone
Check Use Custom TimeZone and type a time zone in the text box.
Locale
Select a language option from the drop-down list. For example, in the United
States, select English (USA).
Enter the 16-character alpha-numeric key that can be used during the
installation process.
The OS Components tab lets you select operating system components to install. You
can use a text-based approach or a GUI-based approach. If you use the GUI-based
approach, check the components to install. If you use the text-based approach, use
the text box to enter a script that identifies a base package and additional packages.
The script must use an XML format. The script is included verbatim in the AutoYaST
control file. For example, if you are using SUSE 8 or 9, you might enter a script like
the following:
<base>Minimal</base>
<addons config:type="list">
<addon>Kde</addon>
</addons>
<packages config:type="list">
<package>apache</package>
<package>sendmail</package>
</packages>
Note that when you script your own OS components, you must include wget, either
by itself or by including a package that contains it.
Field definitions
Obtain an IP address automatically
Specifies that the network connection should use a static IP address that you
specify. If you choose this option, provide the following information:
IP address
Subnet mask
Default gateway
DNS server
IP address
Subnet mask
The subnet mask number, which is used to identify which segment of the
network the server is on.
Default gateway
Specifies that the DHCP server should provide the addresses for DNS servers.
Specifies that you want to manually configure a DNS server. Select this
option and enter an IP address for DNS Server.
DNS server
Note
If you choose to edit the AutoYaST file, the XML for an AutoYaST file is
automatically generated based on the options you have already chosen for this
SUSE system package. After you make any changes, the AutoYaST file is saved.
Afterwards, if you make additional changes to the system package using the
system package wizard, the AutoYaST file does not reflect those choices.
If you create a custom AutoYaST file, then when you create a Provision Job using
the system package, the wizard displays the Customized Unattend Entries panel.
You can use the panel to edit the custom AutoYaST file for the Provision Job.
Token Description
Token Description
3 Optionally, after editing the AutoYaST file, you can clear Customize the
AutoYaST file to generate a new version of the file based on your settings in the
system package.
A message warns you that all customizations you made to the AutoYaST file will
be lost. A new version of the AutoYaST file will be generated based on your
current settings in the system package wizard.
Field definitions
Install RSCD agent
Check this option to install an agent on the target servers. (An agent must be
installed on every server that you want to manage using the BMC Server
Automation Console or Network Shell.)
Push ACLs
Check this option to push the ACLs defined for the server in the BMC Server
Automation system to the RSCD agent that you are installing on the server.
Selecting this option automatically translates the permissions you defined for
the server in the BMC Server Automation system into a users configuration
file on the RSCD agent. In this way, you control users access to the server not
only through the BMC Server Automation Console but also through Network
Shell and the BLCLI.
Check this option to run a post-install Batch Job that can install software and
configure the server. Then, for Path to post-install job, enter the path to the
job or Browse to select it.
To check Run post-install batch job, you must also check Install RSCD
agent, because running a post-install job requires an agent on the server.
If you specify a Post-install Batch Job, make sure that the provisioning
operator who runs the provisioning wizard logs is using a role that has Read
and Execute authorizations on the Batch Job and has Read and Execute
authorizations on all the Jobs contained in the Batch Job.
Select this option to ensure that the post-install Batch Job runs, even if RSCD
agent enrollment fails. If you do not select this option, the post-provisioning
Batch Job does not execute if RSCD agent enrollment fails.
For example, if you use DNS, the RSCD agent enrollment cannot succeed
until a DNS entry for the target server is provided. To provide the DNS entry
using a script in the Batch Job, the Batch Job must run even when the RSCD
agent enrollment fails.
For load balancing, you can use different Application Servers for reporting
Provision Job completion status. Use these fields to identify the Application
Server to which target servers in this job should report their Provision Job
completion status.
Post-install Script
Commands that you enter into the post-install script are appended to
commands that BMC Server Automation provisioning also inserts in this
script, including a command to install the RSCD agent. The commands that
you enter run before any post-install Batch Job that you specify.
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
Then use the property dialog box to add or modify a local property.
Create the ESXi 4.1 or 5.0 system package in the Depot folder. For information, see
Creating a system package on page 1214.
To successfully install and run VMWare ESXi 4.1 or 5.0, the target servers must meet
the following criteria:
The server must have a minimum of 2GB RAM available for the installation.
To define system package settings for ESXi 4.1 and 5.0 servers
1 Right-click the system package in the Depot folder and select Open.
2 Define standard system package settings by clicking the tabs at the bottom of the
content editor. Each tab represents a category of settings, as described in the
following sections:
3 When you finish defining settings for the system package, click the system
package tab at the top of the content editor and select File => Save.
1 To specify a custom script, click Add . (To edit an existing script, click Edit .)
2 On the Pre-Install Script dialog, for Script Name, do one of the following:
Type the name of a local property that contains a script name, enclosing the
property name with double question marks.
Enter Gentoo Linux commands. The interpreter available in ESXi 4.1 and 5.0 is
either BusyBox (the default) or Python. You can include disk part and other
commands in the pre-install scripts. The system returns an error if a command
used in the scripts is not supported by the interpreter.
Type the name of a local property that contains a script, enclosing the property
name with double question marks.
4 (Optional) Select Reboot after the script is executedto reboot the server after the
script commands execute.
Field definitions
Auto Partition Disk Selection
To specify where to install the hypervisor and which disks to clear, choose
one of the following:
Type the name of a local property that contains the script, enclosing the
property name with double question marks.
Field definitions
Computer name
A unique name to assign to the server. The ESXi 4.1 and 5.0 OS applies the
computer name only when you assign a static IP address to the server. The
name of the server after provisioning is always Local Host if the IP address is
obtained from a DHCP server. (The IP address field is on the Network panel.)
OM Server Name
(Optional) Specifies a different name for this server to display in the BMC
Server Automation Console.
If you want this server to display its Computer Name in the BMC Server
Automation Console, leave the OM Server Name field blank.
If you use a different OM Server Name for this machine, make sure that the
new name can be resolved to the IP address of the server.
Root password
The password used to access the root account. Enter a password. Then
confirm your typing by entering the password again in the Confirm
password field. The password must consist of at least 6 characters and cannot
exceed 64 characters.
Type vmnic0.
If you do not supply a value for the mem parameter, the default value for
mem is 512M (megabytes.)
Type any additional boot time kernel parameters that you would like to use
for the server. For a full list of available boot kernel parameters, see the ESXi
4.1 or 5.0 installation documentation.
Field definitions
Keyboard
Select the keyboard layout type for the target servers. ESXi 4.1 and 5.0 map
the value "Default" to English.
License key
Enter the key to the software license you are using, including all hyphens in
the key. Use the format: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX.
You can obtain a license key for ESXi on the VMware website. The web site
requires you to register to receive a license key.
Note
ESXi 4.1 and 5.0 are freeware. A license is not required.
Field definitions
Note
The name of the server after provisioning is always Local Host if the IP address is
obtained from a DHCP server; if you provide a static address, the server name is
obtained from the Computer name field on the Basic Configuration panel.
Specifies that the network connection should use a static IP address that you
specify. If you choose this option, provide the following information:
IP address
Subnet mask
Default gateway
IP address
Subnet mask
The subnet mask number, which is used to identify which segment of the
network the server is on.
Default gateway
Specifies that the DHCP server should provide the addresses for DNS servers.
Specifies that you want to manually configure a DNS server. Select this
option and enter an IP address for the DNS Server.
DNS server
Kickstart entries are automatically generated based on your input on the system
package tabs. The generated entries appear in the first edit box at the top of the
Kickstart Entries tab.
You can append additional entries to the automatically generated entries. You can
also change the automatically generated entries.
Note
For format and syntax examples for a Kickstart file for ESXi 4.1 servers, see
Kickstart entries example for ESXi 4.1 and 5.0 on page 1272.
If you create a custom Kickstart file, the Provision Job wizard displays the
Customized Unattend Entries panel. Using that panel, you can edit the custom
Kickstart file for the particular Provision Job. See the following procedures.
2 Add your new entries in the Additional entries for the kickstart file box.
3 Then, still in the first edit box, add your additional entries.
In this scenario, because you want to modify the automatically generated entries
in the first edit box, you must add your additional entries to the first edit box, not
the second edit box.
If you set the Kickstart Device using the MAC_ADDRESS_CD property, the
Kickstart entry is --device=??MAC_ADDRESS_CD??
where MAC_ADDRESS_CD is a colon-separated MAC address.
Note
The ESXi platform does not support ethX as the value for --device.
If you provided a License Key on the Computer Settings tab, its Kickstart entry is
serialnum.
The --hostname key specifies the name for the installed system. This key works
only with --bootproto=static.
If you selected Use First Disk for Installation on the disk partition panel, the
generated clearpart entry is:
clearpart --firstdisk=local -overwritevmfs
If you selected Specify Disk for Installation on the disk partition panel, the
generated clearpart entry uses the specified disk. In the following example,
sbh is the disk name from the disk partition panel.
clearpart --drives=sbh --overwritevmfs
If you do not provide a value for ondisk, the system uses --ondiskfirst as the
value.
If you do not provide a value for onvmfsdisk, the system uses --onfirstvmfs.
mouse
lang
lang support
text
accepteula
keyboard Default
network --bootproto=dhcp --device=00:11:22:33:44:55
autopart --firstdisk --overwritevmfs
clearpart --firstdisk=local -overwritevmfs
rootpw --iscrypted ??ROOT_PASSWORD??
install url http://??DATA_STORE_IP??/??DATA_STORE.VIRTUAL_DIR??/
reboot
%firstboot --unsupported --interpreter=busybox
cd /
touch provscript
echo "cd /" >> provscript
echo "connected=1" >> provscript
echo "cnt=0" >> provscript
echo "echo \$cnt" >> provscript
echo "while [ \$cnt -lt 5 ]" >> provscript
echo "do" >> provscript
echo "cnt=\$((cnt+1))" >> provscript
echo "echo "Trying to connect PROV_APP_SERVER_IP Retry count is \$cnt"" >>
provscript
echo "ping -c 3 PROV_APP_SERVER_IP >> /dev/null" >> provscript
echo "if [ \$? -eq 0 ]" >> provscript
echo "then" >> provscript
echo "echo 'breaking'" >> provscript
echo "connected=0" >> provscript
echo "break" >> provscript
echo "fi" >> provscript
echo "sleep 10" >> provscript
echo "done" >> provscript
echo "echo 'checking if'" >> provscript
echo "echo "Ping result \$connected"" >> provscript
echo "if [ \$connected -eq 0 ]" >> provscript
echo "then" >> provscript
echo "echo 'App server connected'" >> provscript
echo "wget http://??DATA_STORE_IP??/??DATA_STORE.VIRTUAL_DIR??/bmilinux.tar
bmilinux.tar" >> provscript
echo "tar -xvf bmilinux.tar">> provscript
echo "chmod +x bmilinux">> provscript
echo "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/">> provscript
echo "./bmilinux PROV_SOCKET_APP_SERVER_IP ??MAC_ADDRESS??" >> provscript
echo "rm -f bmilinux" >> provscript
echo "rm -f bmilinux.tar" >> provscript
echo "rm -f libblssl.so.0.9.8" >> provscript
echo "rm -f libblcrypto.so.0.9.8" >> provscript
echo "rm -f random.byt" >> provscript
echo "else" >> provscript
echo "Could not connect to app server PROV_SOCKET_APP_SERVER_IP" >>
provscript
echo "fi" >> provscript
chmod +x provscript
./provscript >> ProvScript.log
rm -f provscript
The ESXi 4.1 and ESXi 5.0 servers are managed by Agentless Managed Objects
(AMOs). Therefore, the provisioning process does not install an RSCD agent or
specify a Batch Job as part of the post-installation configuration. These options are
disabled.
Field definitions
Application server for BMI callback
For load balancing, you can use different Application Servers for reporting
Provision Job completion status. Use these fields to identify the Application
Server to which target servers in this job should report their Provision Job
completion status.
Post-Install Script
Commands to add to the post-install section of the Kickstart file, which runs
once after a server reboots for the first time after an unattended installation of
an ESX operating system. Enter the commands or click Select Property to
insert a parameter.
Any commands you enter into the post-install script are appended to
commands that BMC Server Automation provisioning also inserts in this script.
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
Then use the property dialog box to add or modify a local property.
1 In the Depot folder, navigate to the system package you want to define. Right-
click the system package and select Open.
2 Define standard system package settings by clicking the tabs at the bottom of the
system packages tab. Each tab represents a category of settings, as described in
the following sections:
3 When you finish defining settings for the system package, click the system
package tab and select File => Save.
Note
If you create a Provision Job and on the System Package Selection panel you select
Skip Gentoo for the Associated Boot Image, the provisioning process does not
execute this script.
1 To specify a custom script, click Add . (To edit an existing script, click Edit .)
2 On the Pre-install Script dialog, for Script Name, do one of the following:
Type the name of a local property that contains a script name, enclosing the
property name with double question marks.
Type the name of a local property that contains a script, enclosing the property
name with double question marks.
4 (Optional) Select Reboot after the script is executed to reboot the server after the
script commands execute.
Define a partition for ESX system packages by supplying a script or using the Disk
Partition dialog:
To supply a script that defines the partition, select Use script for disk
partitioning. Then do one of the following:
Type the name of a local property that contains the script, enclosing the
property name with double question marks.
To reboot after script execution, click Reboot after the script is executed.
1 To create a new partition, in the Disk Partitions area, click Add . To modify
an existing partition, select the partition in the Disk Partition list and click Edit
.
Field definitions
Mount point
The location within a file directory where a volume should exist. Enter a
location or select one from the drop-down list.
ESX 4.0 system packages: To create a data store (storage partition) for the
vmfs3 file system type, select Storage 1 from the drop-down menu or type a
storage partition name for Mount point/DataStore.
Type
ext2Supports standard UNIX file types and allows file names up to 255
characters.
swapSupports virtual memory, that is, swapping data in and out of this
partition when there is insufficient RAM to perform an operation.
resources concurrently. Version 2 has a flat file system. (The ESX 4.0
system package does not support the vmfs2 file system.).
Size (MB)
The size of the partition in megabytes. To let the partition fill all remaining
space on the disk, check Fill all unused space on disk.
ESX 4.0 system package: You can specify both the size of the partition in
megabytes and Fill all unused space on disk.
If you are specifying the size of a swap partition, make sure the size you
specify is supported by the specific version of this system packages
operating system.
Disk
Enter the device name and optionally, parameters related to the device name.
For example:
cciss/c0d0 --asprimary
The generated kickstart file clears the disks specified in this disk partition
list. (In earlier releases, the generated kickstart file cleared all partitions
connected to the target host.)
To create virtual disk partitions for / and /swap, for Disk/Virtual Disk,
select the virtual disk from the drop-down menu.
1 If you have not done so, define a storage partition disk partition for the vmfs3 file
type. See Disk partition ESX on page 1277.
To modify an existing virtual partition, select the partition in the Virtual Disk
Partition list and click Edit .
For Size, enter the size of the partition in megabytes. If you want the partition
to fill all remaining space on the disk, check Fill any available space or max
size. (You can specify both.)
For Datastore, type the name of the storage partition on which you want to
create the virtual partition or select the name from the drop-down list.
4 Click OK.
Field definitions
Computer name
OM Server Name
If you want this server to display its Computer name when it appears in the
BMC Server Automation Console, leave the OM Server Name field blank.
If you do choose to use a different OM Server Name for this machine, make
sure that this new name can be resolved to the IP address of the server.
Root password
The password used to access the root account. Enter a password. Then
confirm your typing by entering the password again in the Confirm
password field.
For ESX 4.0 system packages, provide the MAC address of a Kickstart
network device or the network interface name connected to the device.
Use any of the following values:
Type vmnic0.
For ESX versions earlier than 4.0, type the name of the network interface
connected to the kickstart device. For example: eth0 or eth1.
Type any additional boot time kernel parameters you would like to use for
the server. Some commonly used parameters include:
ESX 4.0 system package: If you do not supply a value for the mem parameter
in Boot Kernel Parameters, the default value for mem is 512M (megabytes.)
For a full list of available boot kernel parameters, see the ESX installation
documentation.
Field definitions
Keyboard
Select the keyboard layout type that you want to be the system default. For
example, in the United States you would probably select us.
Mouse
Select a type of mouse that you want to use with the machine.
The ESX 4.0 system package type does not include this option.
Time zone
ESX 4.0 system packages: Select a time zone or check Use Custom
TimeZone. Then for Custom TimeZone, click Select Property to display
a drop-down menu of available properties. Select the property that contains
the time zone.
Locale
Select a language option from the drop-down list. For example, in the United
States, select English (USA).
The ESX 4.0 system package type does not include this option.
Enter the key to the software license you are using, including all hyphens in
the key. Use the format: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX.
Network ESX
The Network tab lets you provide networking information for a server, such as its IP
and DNS configuration.
Field definitions
Obtain an IP address automatically
Specifies that the network connection should use a static IP address that you
specify. If you choose this option, provide the following information:
IP address
Subnet mask
Default gateway
IP address
Subnet mask
The subnet mask number, which is used to identify which segment of the
network the server is on.
Default gateway
Specifies that the DHCP server should provide the addresses for DNS servers.
Specifies that you want to manually configure a DNS server. Select this
option and enter an IP address for DNS Server.
DNS server
When you define an ESX system package, your input on the system package tabs is
automatically converted into text in the first edit box at the top of the Kickstart
Entries tab.
You can add entries to the Kickstart file or customize the file by editing existing entries.
Note
For ESX 4.0, kickstart file entries have a format and syntax different from all other
ESX platforms. See Kickstart entries example for ESX 4.0 on page 1284.
If you create a custom Kickstart file, then when you create a Provision Job using
the system package, the wizard displays the Customized Unattend Entries panel.
You can use the panel to edit the custom Kickstart file for the particular Provision
Job. See To change existing unattend.txt entries on page 1239.
2 Add your new entries in the Additional entries for the kickstart file box.
3 Then, still in the first edit box, add your additional entries.
In this scenario, because you want to modify the automatically generated entries
in the first edit box, you must add your additional entries to the first edit box, not
the second edit box.
The following are the characteristics of the ESX 4.0 kickstart file:
If you set the Kickstart Device using the MAC_ADDRESS_CD property, the
Kickstart entry is --device=??MAC_ADDRESS_CD??
where MAC_ADDRESS_CD is a colon-separated MAC address.
Note
The ESX 4.0 Kickstart does not support ethX as the value for --device.
If you provided a License Key on the Computer Settings tab, its Kickstart entry is
serialnum.
The --hostname key specifies the name for the installed system. This key works
only with --bootproto=static.
By default, the system clears the disks that you listed on the disk partition panel in
the clearpart entry.
If you do not provide a value for ondisk, the system uses --ondiskfirst as the
value.
If you do not provide a value for onvmfsdisk, the system uses --onfirstvmfs.
mouse
lang
lang support
text
In the clearpart entry in the following example, sbh is an example disk partition
specified by the user on the disk partition panel.
accepteula
keyboard us
serialnum --esx=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
network --bootproto=dhcp --device=??MAC_ADDRESS_CD??
bootloader --location=mbr
clearpart --drives=sbh overwritevmfs
part None --fstype=vmkcore --size=1280 --ondisk=sdb
Field definitions
Install RSCD agent
Check this option to install an agent on the server being provisioned. (An
agent must be installed on every server you want to manage using the BMC
Server Automation Console or Network Shell.)
Push ACLs
Check this option to push the ACLs defined for the server in the BMC Server
Automation system to the RSCD agent you are installing on the server.
Check this option to run a post-install Batch Job that can install software and
configure the server. Then for Path to post-install job, enter the path to the
job or Browse to select it.
In order to check Run post-install batch job, you must also check Install
RSCD agent, because running a post-install job requires that there is an agent
installed on the server.
If you specify a Post-install Batch Job, make sure that the provisioning
operator who runs the provisioning wizard logs is using a role that has Read
and Execute authorizations on the Batch Job and has Read and Execute
authorizations on all the Jobs contained in the Batch Job.
Select this option to ensure that the post-install Batch Job runs, even if RSCD
agent enrollment fails. If you do not select this option, the post-provisioning
Batch Job does not execute if RSCD agent enrollment fails.
For example, if you use DNS, the RSCD agent enrollment cannot succeed
until a DNS entry for the target server is provided. If you want to provide the
DNS entry using a script in the Batch Job, you need the Batch Job to run even
when the RSCD agent enrollment fails.
For load balancing, you can use different Application Servers for reporting
Provision Job completion status. Use these fields to identify the Application
Server to which target servers in this job should report their Provision Job
completion status.
Post-install Script
Commands that you want added to the post-install section of the Kickstart
file, which runs once after a server reboots for the first time after an
unattended installation of an ESX operating system. Enter the commands or
click Select Property to insert a parameter.
Any commands you enter into the post-install script are appended to
commands that BMC Server Automation provisioning also inserts in this
script, including a command to install the RSCD agent. The commands that
you enter run before any post-install Batch Job that you specify.
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
Then use the property dialog box to add or modify a local property.
1 In the Depot folder, navigate to the system package you want to define. Right-
click the system package and select Open.
A tab for the system package appears in the Content Editor view.
2 Define standard system package settings by clicking the tabs at the bottom of the
system packages tab. Each tab represents a category of settings, as described in
the following sections:
3 When you finish defining settings for the system package, click the system
package tab and select File => Save.
You can use the Pre-Install Scripts tab to provide custom scripts for disk cleanup,
hardware configuration, disk array configuration, and pre-disk partitioning.
To add a pre-install script, click Add . Then specify the script's name, contents,
and whether or not to reboot after the script is executed.
The Citrix XenServer has a fixed layout of the file system. You do not need to specify
disk partitions; you specify the disk on which the Citrix XenServer host is installed.
You specify a Primary disk and a Guest disk. The Citrix XenServer is installed on the
Primary disk. The Guest disk is used for installation of operating systems installed
on top of the Citrix XenServer.
You can specify disks in either of two waysby supplying a script or using fields in
the GUI:
Type the name of a local property that contains the script, enclosing the property
name with double question marks.
If you want to reboot after script execution, click Reboot after the script is
executed.
Type
Primary: The disk where the control domain (Citrix XenServer) is installed.
Guest: The disk to be used for storage for a guest operating system.
Disk
The name of the storage device where the domain should be installed.
For Primary Disk: The name of the storage device where the control domain
should be installed.
For Guest Disk: The name of the storage device for guest storage.
If you install an operating system on top of the Citrix XenServer, check this
option to create a storage repository on the Primary disk for the guest
operating system.
Field definitions
Computer name
OM Server Name
If you want this server to display its Computer name when it appears in the
BMC Server Automation Console, leave the OM Server Name field blank.
If you do choose to use a different OM Server Name for this machine, make
sure that this new name can be resolved to the IP address of the server.
Root password
The password used to access the root account. Enter a password. Then
confirm your typing by entering the password again in the Confirm
password field.
Admin interface
The name of the network interface that the server uses to communicate with
the HTTP server. For example, you might enter eth0 or eth1.
Additional boot time kernel parameters you would like to use for the server.
Field definitions
Key map
Time zone
Driver Path
(Optional) Enter the path to the folder where device drivers are stored. The
path should be relative to the data store. Or click Select Property to select
the property that contains the path.
(Optional) Specify the path to the Citrix XenServer license key, relative to the
data store. For example: CitrixXen/XenServer-Enterprise-license.xslic
Field definitions
Obtain an IP address automatically
Specifies that the network connection should use a static IP address that you
specify. If you choose this option, provide the following information:
IP address
Subnet mask
Default gateway
DNS server
IP address
Subnet mask
The subnet mask number, which is used to identify which segment of the
network the server is on.
Default gateway
Specifies that the DHCP server should provide the addresses for DNS servers.
Specifies that you want to manually configure a DNS server. Select this
option and enter an IP address for DNS Server.
DNS server
When you define settings for a Citrix XenServer system package, your input is
automatically converted into entries in the Unattend Entries file (unattend.xml). This
file is used in unattended installations to provide answers to the prompts that would
be provided interactively in a live installation.
The Additional Unattend Entries XML editor is an XML editor only and is
not intelligent about the BMC Server Automationprovisioning process or
components required in Citrix XenServer installations.
If you create a custom unattend.xml file, then when you create a Provision
Job using the system package, the wizard displays the Customized Unattend
Entries panel. You can use the panel to edit the custom unattend.xml file for
the particular Provision Job.
2 In the Generated Unattend area, expand the nodes and select the component to
change. The component appears in the Selected XML Component area.
5 Click OK.
On the Unattend Entries tab, the added or replaced entry appears in both the
Customized Unattend Entries text box and in the Additional Unattend Entries list.
2 In the Add/Replace XML Component area, edit the entry by either typing in the
change or by clicking Select Property and selecting a property reference.
3 Modify the unattend.xml file displayed in the Customized Unattend Entries text
box.
Field descriptions
Application server for BMI callback
For load balancing, you can use different Application Servers for reporting
Provision Job completion status. Use these fields to identify the Application
Server to which target servers in this job should report their Provision Job
completion status.
Post-Install Script
Enter any commands that you want to execute after the unattended
installation of the Citrix XenServer. The commands you enter run one time
immediately after the unattended installation.
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
Then use the property dialog box to add or modify a local property.
1 In the Depot folder, navigate to the system package you want to define. Right-
click the system package and select Open.
A tab for the system package appears in the content editor view.
2 Define standard system package settings by clicking the tabs at the bottom of the
system packages tab. Each tab represents a category of settings, as described in
the following sections:
3 When you finish defining settings for the system package, click the system
package tab and select File => Save.
There are two ways to define a partitionby supplying a script or using the wizard:
To supply a script, click Use script for disk partitioning. Then do one of the
following:
Type the name of a local property that contains the script, enclosing the
property name with double question marks.
To modify an existing partition, select the partition in the Disk Partition list
and click Update or Edit .
If you are adding a new partition, a wizard appears. If you are editing an
existing partition, a tabbed window appears. Both provide the same options.
3 Under Slice Configuration, select one of the following slice options and then
click Next.
Disk Sliceplace the file system on the slice you specify here, using one of
the following formats:
cwtxdysz, for example c0t0d0s0
cwdysz, for example c0d0s0
Root Diskplace the systems root disk on the slice (integer) you specify here.
4 Under Size Options, select one of the following size options and then click
Next.
Autodetermine the size of the file system based on the software you are
installing on this server.
Allhave this slice use the entire disk for the file system. If you choose All,
you cannot place any other file systems on this disk.
Freeuse the remaining unused space on the disk for the file system.
Specify Sizeset the size of the file system to the value (in MB) that you
specify here.
5 Under File System Settings (Optional), select one of the following optional
settings:
Mount Pointuse this mount point name for the file system, for example /
var.
Mount Optionsone or more mount options for the mount point name you
specified in Mount Point.
Field definitions
Computer name
The unique name that should be assigned to the server. Enter a name or use
click Select Property to insert a parameter that refers to a local property
to supply the value for this field.
OM Server Name
If you want this server to display its Computer name when it appears in the
BMC Server Automation Console, leave the OM Server Name field blank.
If you do choose to use a different OM Server Name for this machine, make
sure that this new name can be resolved to the IP address of the server.
Root password
The password used to access the root account. Enter a password. Then
confirm your typing by entering the password again in the Confirm
password field.
(Optional) Check this option and then use the drop-down menu to select
Initial Install or Flash Install.
Note that if you do not specify an install type here, you must do so on the
Additional Profile Entries panel.
Field definitions
Timezone
If the time zone you need is not on the list, check Use parameter or specify
an unlisted timezone.
Check this option if the time zone you need is not on the list for Timezone.
The drop-down list changes to a field.
In the Timezone field, type the name of a time zone or click Select Property
to insert a parameter. (If you created a property for the unlisted time
zones, you can insert a parameter that references this property.)
Valid time zones for this field are contained in the directory:
/usr/share/lib/zoneinfo
If you see your time zone listed as a file in this directory, use the name of the
file as the value for the Timezone field.
If your time zone file is located in a subdirectory, specify the relative path to
the time zone file from the /usr/share/lib/zoneinfo directory, for example:
America/New_York
System Locale
Select the character encoding scheme you want to use for your language.
If the encoding scheme you need is not in the drop-down list, check Use a
parameter.
Check this option if the character encoding scheme you need is not on the list
for System Locale. The drop-down list changes to a field.
Network Solaris
The Network tab lets you provide networking information for a server, such as its IP
configuration settings and name service.
Field definitions
Enable networking on the Primary interface
Check this option if you want this machines primary interface to connect to
the network.
Specifies that the network connection should use a static IP address. If you
choose this option, provide the following information:
IP Address
Netmask
Default Router
IP Address
The static IP address that the network connection should use. Enter the IP
address or click Select Property to insert a parameter that refers to a
local property to supply the value for this field.
Netmask
The subnet mask number, which is used to identify which segment of the
network the server is on. Enter the IP address or click Select Property to
insert a parameter that refers to a local property to supply the value for this
field.
Default Router
If you want the installation program to detect the router by using the ICMP
router discovery protocol, leave this field blank.
Note
If ICMP is disabled, you must provide an IP address for Default Router.
Otherwise, JumpStart switches to interactive mode during an installation and
starts prompting the user for values.
Use IPV
Check this option if the IP address conforms to the Internet Protocol version 6
(IPv6) network layer standard.
The name service that this server should use. Enter a name or select NONE if
this server should not use a name service. The following table lists the name
services.
NIS NIS+ Domain Name: Name of the group of systems using NIS.
Name Server Host Name: Name of the NIS name server.
Name Server IP Address: IP address of the NIS name server.
DNS Domain Name: Domain name for the group of systems using DNS.
Primary DNS Server: IP address of the primary DNS server.
Secondary DNS Server: IP address of the secondary DNS server.
Tertiary DNS Server: IP address of the tertiary DNS server.
Additional Domains: Name(s) of additional domain(s) to search for name service
information.
The total length of this field (including commas) cannot exceed 250 characters.
Check the Meta Cluster that contains the operating system components you want to
install.
The Package Specifications tab gives you the option to check Use script for OS
component selection and then either:
Type in a script that specifies which operating system components you want to
install.
Type the name of a local property that contains a script, enclosing the property
name with double question marks.
The sysidcfg file is a set of keyword/value statements that describe how you want to
configure a machine. Based on the information you provide in the basic system
package panels, the BMC Server Automation system populates this file with some of
your configuration choices.
You can use the Preview panel to examine the existing contents of the sysidcfg file.
security_policy=NONE
timeserver=localhost
terminal=vt100
nfs4_domain=dynamic
Based on the information you provide in the basic system package panels, the BMC
Server Automation system populates this file with some of your configuration choices.
You can use the Preview panel to examine the existing contents of the profile file.
Then, if you want to add or modify the keyword/value statements, you can do so,
using the Additional Profile Entries panel.
install_type initial_install
system_type standalone
Type the name of a local property that contains the script, enclosing the property
name with double question marks.
Type your rules directly in the input box, using conventions and syntax for
creating a rules file for Jumpstart.
Type the name of a local property that contains the rules, enclosing the property
name with double question marks.
Click Select Property to display available properties. Select the property that
contains the rules. For information, see Using properties to reference scripts on
page 1414.
To return to the default rules file contents, clear the Customize add_install_client
script option.
At this point, no operating system or software is installed, but the script can perform
operations such as special disk partitioning operations or change EEPROM settings.
Type the name of a local property that contains the script, enclosing the property
name with double question marks.
Click Select Property to display available properties. Select the property that
contains the script. For information, see Using properties to reference scripts on
page 1414.
Choose whether to install a BMC Server Automation RSCD agent. An agent must
be installed on every server that you want to manage using the BMC Server
Automation Console or Network Shell.
Choose whether to run a Batch Job. A Batch Job can sequentially run a series of
other jobs that install software and perform additional configuration on the server.
Specify any additional scripts to run after the operating system is installed.
Field definitions
Install RSCD agent
Check this option to install an agent on the server that you are provisioning.
Push ACLs
Check this option to push the ACLs defined for the server in the BMC Server
Automation system to the RSCD agent that you are installing on the server.
Selecting this option automatically translates the permissions you defined for
the server in the BMC Server Automation system into a users configuration
file on the RSCD agent. In this way, you control users access to the server not
only through the BMC Server Automation Console but also through Network
Shell and the BLCLI.
Check this option to run a post-install Batch Job that can install software and
configure the server. Then, for Path to post-install job, enter the path to the
job or Browse to select it.
To check Run post-install batch job, you must also check Install RSCD
agent, because running a post-install job requires an agent on the server.
If you specify a Post-install Batch Job, make sure that the provisioning
operator who runs the provisioning wizard logs is using a role that has Read
and Execute authorizations on the Batch Job and has Read and Execute
authorizations on all of the Jobs contained in the Batch Job.
The IP address of the Application Server to which you want to report the
provisioning job completion status. This field lets you use different
Application Servers for load balancing.
Finish Script
Specify the contents of the JumpStart finish script by doing one of the following:
Type the name of a local property that contains the script, enclosing the
property name with double question marks.
The finish script runs one time immediately after an unattended installation
of the operating system.
Any commands you enter into the finish script are appended to commands
that BMC Server Automation provisioning also inserts in this script,
including a command to install the RSCD agent. The commands that you
enter run before any post-install Batch Job that you specify.
Sample reboot scripts are available from your BMC Server Automation
representative. You must customize the scripts for your specific device hardware
and networking environment, but the sample scripts can provide you with a useful
head start.
Type the name of a local property that contains the script, enclosing the property
name with double question marks.
The fdisk information you provide here becomes part of the JumpStart profile file.
The x86 kernel parameters are passed to add_install_client.
FDisk Partitions
This section lets you create or modify fdisk partitions for provisioning x86 servers.
To modify an existing partition, select the partition in the FDisk Partitions list and
click Open .
To delete a partition, select the partition in the FDisk Partitions list and click
Delete .
If you are adding a new partition, a wizard appears. If you are editing an existing
partition, a tabbed window appears. Both provide the same options.
1 The Disk Name panel lets you specify where this fdisk partition is located. Select
one of the following options and then click Next.
Disk SlicePlace the partition on the slice you specify here, using one of the
following formats:
cxtydz, for example c0t0d0
cxdz, for example c0d0
2 The Type panel lets you specify what type of fdisk partition this is. Select one of
the following options and then click Next.
Specify size (in MB)Make the size of this partition the number of megabytes
specified here.
AllCreate this fdisk partition on the entire disk. All existing fdisk partitions
are deleted. You can select All only if the fdisk type is solaris.
Max FreeCreate an fdisk partition in the largest contiguous free space on the
specified disk. You can select Max Free only if type is solaris or dosprimary.
DeleteDelete all fdisk partitions of the specified type on the specified disk.
Kernel Parameters
This section lets you add new or modify existing kernel parameters for x86 servers
being provisioned.
To modify an existing attribute/value pair, select the pair in the x86 Kernel
Parameters list and click Open .
Specify a kernel Attribute Name and associated Value. Then click OK.
To delete an attribute/value pair, select the pair in the x86 Kernel Parameters list
and click Delete.
Preview Solaris
The Preview tab lets you examine customizations you made to the sysidcfg file,
profile file, and rules file, and add_install_client command options.
sysidcfg file
profile file
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
Then use the property dialog box to add or modify a local property.
1 In the Depot folder, navigate to the system package you want to define. Right-
click the system package and select Open.
A tab for the system package appears in the content editor view.
2 Define standard system package settings by clicking the tabs at the bottom of the
system package tab. Each tab represents a category of settings, as described in the
following sections:
3 When you finish defining settings for the system package, click the system
package tab and select File => Save.
Field definitions
Computer name (Required)
The unique name that should be assigned to the server. Enter a name or use
click Select Property to insert a parameter that refers to a local property to
supply the value for this field.
OM Server Name
If you want this server to display its Computer name when it appears in the
BMC Server Automation Console, leave the OM Server Name field blank.
If you do choose to use a different OM Server Name for this machine, make
sure that this new name can be resolved to the IP address of the server.
The name by which this machine will be known within the NIM
environment. The provisioning process creates a machine object with this
name in the NIM database. The name must be a legal NIM machine name
(one that does not include periods).
If you do not explicitly specify a name in this field, the Computer name is
used as the NIM machine name. In that case, you must make sure that the
Computer name is a legal NIM machine name.
Root password
The password used to access the root account. Enter a password. Then
confirm your typing by entering the password again in the Confirm
password field.
By default, bosinst.data has one target_disk_data stanza, but you can add additional
stanzas by adding multiple entries on this panel. Each entry corresponds to a stanza.
Multiple stanzas let you install the operating system on multiple disks, one stanza
for each disk.
There are two ways to provide information about the disks in the target machine:
To use a script to provide target disk information, click Use script for target disk
selection. Then either type in your script in the large text box, or click Select
Property . This icon indicates that you can insert a parameter that refers to a
local property to supply the value for this field. For information about inserting a
parameter, see Inserting a parameter in a system package field on page 1413.
Then fill in at least one of the following fields: PVID, Physical Location, San Disk
ID, Connection, Location, Size (MB), HDISKNAME. Refer to the AIX
documentation for information about the rules of precedence for these fields.
Field definitions
BosInst Locale
If the locale you need is not on the list, check Use parameter or specify an
unlisted timezone.
Check this option if the locale you need is not on the list for BosInst Locale.
The drop-down list changes to a field.
In the field, type the name of a time zone or click Select Property to
insert a parameter that references a property you created for the unlisted
locales.
For information about the locales supported in the AIX environment, consult
the AIX documentation.
Cultural Convention
If the convention you need is not on the list, check Use parameter or specify
an unlisted locale for the cultural convention.
Check this option if the cultural convention you need is not on the list for
Cultural Convention. The drop-down list changes to a field.
In the field, type the name of a convention or click Select Property to insert a
parameter that references a property you created for the unlisted cultural
conventions.
Messages Catalogs
If the name of the messages catalogs is not on the list, check Use parameter or
specify an unlisted locale for the messages catalogs.
Check this option if the messages catalogs name is not on the list for
Messages Catalogs. The drop-down list changes to a field.
In the field, type the messages catalogs name or click Select Property to insert
a parameter that references a property you created for the unlisted messages
catalogs.
Keyboard
If the keyboard you need is not on the list, check Use parameter or specify an
unlisted locale for the keyboard map.
Check this option if the keyboard you need is not on the list for Keyboard.
The drop-down list changes to a field.
In the field, type the name of a keyboard map or click Select Property to
insert a parameter that references a property you created for the unlisted
keyboard map.
Field definitions
Use an existing network object. Leave unchecked to use find_net
To use an existing network object, check this option. The enter and the
objects name in the Network object name field or click Browse to select
an object.
To use the NIM find_net keyword to find the target machine you want to
provision, leave Use an existing network object check box unchecked, and
leave the Network object name field blank. If you do these two things, NIM
will use information you provide in other fields on this panel to find the
target on the network.
Network Type
Subnet Mask
(For use with the find_net keyword.) Enter a subnet mask number, which is
used to identify which segment of the network the server is on.
Network Name
(Optional) The name to use for a network object you define, if NIM is not
able to match the NIM device to an existing network.
Client Gateway
(Optional) The IP address or host name of the default gateway that the target
machine uses to communicate with the NIM master.
Master Gateway
(Optional) The IP address or host name of the default gateway used by the
NIM master to communicate with clients on other subnets.
The logical device name of the network adapter in the target machine you
plan to provision.
DNS IP Address
The IP address of the DNS server that the target machine will use.
Domain Name
The default domain to use when looking for machines via a host name, and
the host name is not fully qualified.
Client IP Address
Choose whether you want to install a BMC Server Automation RSCD agent. An
agent must be installed on every server you want to manage using the BMC
Server Automation console or Network Shell.
Choose whether you want to run a Batch Job. A Batch Job can sequentially run a
series of other jobs that install software and perform additional configuration on
the server.
Specify the NIM first boot script you want to run after the operating system is
installed. This script runs before any post-install Batch Job that you specify.
Field definitions
Install RSCD agent
Note
Before installing the RSCD agent, the provisioning process dynamically
computes the size of these disk partitions on the target server and extends
them if necessary:
For these extensions to be successful, you must ensure that each partition is
mounted on a logical volume with enough space the partition to be extended.
Use the following AIX operating system commands:
To show information about the current size of the file system, percentage
of utilization, and the name of its logical volume, enter:
df
For information about required space for RSCD agent installation, see BMC
technical documentation at https://docs.bmc.com/docs/display/bsa82/
System+requirements.
Push ACLs
Check this option to push the ACLs defined for the server in the BMC Server
Automation system to the RSCD agent you are installing on the server.
Check this option to run a post-install Batch Job that can install software and
configure the server. Then for Path to post-install job, enter the path to the
job or Browse to select it.
In order to check Run post-install batch job, you must also check Install
RSCD agent, because running a post-install job requires that there is an agent
installed on the server.
If you specify a Post-install Batch Job, make sure that the provisioning
operator who runs the provisioning wizard logs is using a role that has Read
and Execute authorizations on the Batch Job and has Read and Execute
authorizations on all the Jobs contained in the Batch Job.
Firstboot Script
Specify the contents of the NIM first boot script by doing one of the following:
Type the name of a local property that contains the script, enclosing the
property name with double question marks.
The script runs one time immediately after an unattended installation of the
operating system.
NIM scripts
NIM scripts are shell scripts that the NIM master will run on the client when the
base operating system is finished being installed. You can use these scripts to
customize the target machines operating system before it reboots for the first time.
To modify an existing script, select the script in the list and click Edit .
In the script dialog, provide information for the following options and click OK.
Type the name of a local property that contains a script name, enclosing the
property name with double question marks.
For Verbose Level, use the drop-down menu to specify the verbose level of the
scripts output. Specify a level from 1 to 5, 1 being the least verbose and 5 being
the most verbose. You can also select 0, which means that the verbose level is
unspecified.
Type the name of a local property that contains a script, enclosing the property
name with double question marks.
Control flow
The Control Flow tab lets you edit the first section of the bosinst.data file. This
section is called the control_flow stanza. You can modify this section to change any
of the default settings.
Type the name of a local property that contains a setting, enclosing the property
name with double question marks.
The nim -o bos_inst operation lets you specify attributes to customize the
operating system installation.
adding or editing attributes. For example, to execute a custom script on the target
machine after installation, add the script attribute with a value that is the name of
the script.
To modify an existing attribute/value pair, select the pair in the list and click Edit
.
In the edit dialog box, provide information for the following options and click OK.
Type the name of a local property that contains an attribute name, enclosing the
property name with double question marks.
Type the name of a local property that contains a value, enclosing the property
name with double question marks.
Type the name of a local property that contains a script, enclosing the property
name with double question marks.
To select an existing script, click Browse . On the Edit dialog, click Import and
select the script. The contents of the script appear in the text box. To add to the
script, you can type commands or click Properties to reference scripts.
Pre-bos_inst script
The Pre-bos_inst Script tab lets you specify a script to run on the NIM master before
the nim -o bos_inst operation runs.
You can leave this panel empty or specify a script as described in Using properties to
reference scripts on page 1414.
You can leave this panel empty, or specify a script as described in Using properties
to reference scripts on page 1414.
Preview AIX
The Preview tab lets you examine the customizations you made to the bosinst.data
file, the machine definition command, NIM resource definition, and the Bosinst
command.
bosinst.data file
Bosinst command
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
Then use the property dialog box to add or modify a local property.
1 In the Depot folder, navigate to the system package you want to define. Right-
click the system package and select Open.
A tab for the system package appears in the Content Editor view.
2 Define standard system package settings by clicking the tabs at the bottom of the
system packages tab. Each tab represents a category of settings, as described in
the following sections:
3 When you finish defining settings for the system package, click the system
package tab and select File => Save.
Field Definitions
Computer Name
Type the name or click Select Property to insert a parameter that refers
to a local property to supply the value for this field.
OM Server Name
(Optional) You can choose a different name for this server to display when it
appears in the BMC Server Automation Console.
If you want this server to appear with a different name, enter that name in
the OM Server Name text box. (Make sure that this new name can be
resolved to the IP address of the server.)
Type the name or click Select Property to insert a parameter that refers to
a local property to supply the value for this field.
If you want this server to display its Computer name when it appears
within the BMC Server Automation Console, leave the OM Server Name
text box blank.
Root password
Confirm password
You can use the default Ignite disk partitioning, or specify your own disk
partitioning script:
To use the default disk partitioning configuration associated with this system
package type, click Use Default Disk Partition.
To provide your own script for disk partitioning, click Use Custom Disk
Partition. Then type the script into the box, or click Select Property to use a
property to reference the script.
Field definitions
Timezone
If the time zone you need is not on the list, check Use parameter or specify
an unlisted timezone.
Check this option if the time zone you need is not on the list for Timezone.
The drop-down list changes to a field.
In the Timezone field, type the name of a time zone or click Select Property
to insert a parameter. (If you created a property for the unlisted time
zones, you can insert a parameter that references this property.)
Valid time zones for this field are contained in the directory:
/usr/share/lib/zoneinfo
If you see your time zone listed as a file in this directory, use the name of the
file as the value for the Timezone field.
If your time zone file is located in a subdirectory, specify the relative path to
the time zone file from the /usr/share/lib/zoneinfo directory, for example:
America/New_York
Keyboard
If the keyboard you need is not on the list, check Use parameter or specify an
unlisted locale for the keyboard map.
Check this option if the keyboard you need is not on the list for Keyboard.
The drop-down list changes to a field.
In the field, type the name of a keyboard map or click Select Property to
insert a parameter that references a property you created for the unlisted
keyboard map.
Field definitions
Obtain an IP address automatically
Specifies that the network connection should use a static IP address that you
specify. If you choose this option, provide the following information:
IP address
Subnet mask
Default gateway
IP address
Subnet mask
The subnet mask number, which is used to identify which segment of the
network the server is on.
Default gateway
Specifies that the DHCP server should provide the addresses for DNS servers.
Specifies that you want to manually configure a DNS server. Select this
option and enter an IP address for DNS Server.
DNS server
Hardware Address
Check this option to use a network configuration script. Type script into the
box or click Select Property to use a property to reference the script.
To modify an existing script, select the script in the list and click Update or Edit
.
Type the name of a local property that contains a script name, enclosing the
property name with double question marks.
Type the name of a local property that contains a script, enclosing the property
name with double question marks.
3 Click OK.
Variables script
Type your changes directly into the text box under the heading for that script.
Type the name of a local property that contains a setting, enclosing the property
name with double question marks.
To install the default software from the Ignite depot, leave this tab blank.
Otherwise, you can specify a script that installs a custom set of software. You can
either type the script into the box, or use a property to reference the script.
To specify a Boot script, type the script into the box, or use a property to reference
the script.
Choose to run a Batch Job. A Batch Job can sequentially run a series of other jobs
that install software and perform additional configuration on the server.
Specify the first script to run after the operating system is installed. This script
runs before any post-install Batch Job that you specify.
Field definitions
Install RSCD agent
Check this option to install an agent on the server being provisioned. (An
agent must be installed on every server you want to manage using the BMC
Server Automation Console or Network Shell.)
Push ACLs
Check this option to push the ACLs defined for the server in the BMC Server
Automation system to the RSCD agent you are installing on the server.
Check this option to run a post-install Batch Job that can install software and
configure the server. Then for Path to post-install job, enter the path to the
job or Browse to select it.
In order to check Run post-install batch job, you must also check Install
RSCD agent, because running a post-install job requires that there is an agent
installed on the server.
If you specify a Post-install Batch Job, make sure that the provisioning
operator who runs the provisioning wizard logs is using a role that has Read
and Execute authorizations on the Batch Job and has Read and Execute
authorizations on all the Jobs contained in the Batch Job.
Select this option to ensure that the post-install Batch Job runs, even if RSCD
agent enrollment fails. If you do not select this option, the post-provisioning
Batch Job does not execute if RSCD agent enrollment fails.
For example, if you use DNS, the RSCD agent enrollment cannot succeed
until a DNS entry for the target server is provided. If you want to provide the
DNS entry using a script in the Batch Job, you need the Batch Job to run even
when the RSCD agent enrollment fails.
Post-install Script
Specify the first script you want to run after the operating system is installed.
Enter the script in the box or click Select Property to use a property to
reference the script.
This script runs before any post-install Batch Job that you specify.
Preview HP-UX
The Preview tab lets you examine the customizations that you made to the complete
configuration, software selection, other configuration, disk partition, and network
configuration script files.
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
Then use the property dialog box to add or modify a local property.
Suppose that in your organization, there are certain users who are responsible for
designing system packages and other users who are responsible for running the
provisioning wizard to provision the devices.
1 As BMC Server Automation administrator, you create two roles. For example:
ProvisioningDesigners
ProvisioningOperators
2 In the Depot folder, you create two folders for system packages. For example:
InDevelopment
ApprovedForProduction
When you set the access control list (ACL) for the InDevelopment folder, give
access only to the ProvisioningDesigners role.
When you set the ACL for the ApprovedForProduction folder, give access to both
the ProvisioningDesigners role and the ProvisioningOperators role.
3 A user with the ProvisioningDesigners role might then create a system package in
the InDevelopment folder, and work on it there until it is approved for
production. During this time, the only users with access to the system package are
users who have the ProvisioningDesigners role.
4 When the system package is approved and ready for production, the designer
might move the system package to the ApprovedForProduction folder, where
both ProvisioningOperators and ProvisioningDesigners can access the system
package.
In a PXE provisioning environment, devices are imported when they boot up. In a
Jumpstart, NIM, or Ignite environment, you must manually import all devices.
In the BMC Server Automation Console, devices have one of the following states:
When they boot up and are connected to the network, they automatically appear
as imported devices in the BMC Server Automation Console.
You can manually import devices before they boot up or are connected to the
network.
In a JumpStart, NIM, or Ignite environment, you must manually import all devices.
For example, suppose you placed an order with a vendor for a hundred new devices.
The vendor has sent you a list of the MAC addresses, but the devices themselves are
still in transit. You can use the import facility to assign values to each device, based
on its MAC address. Then when the devices arrive and you use the provisioning
wizard to provision them, many of the fields will be automatically filled in.
Add devices one at a time, as described in Manually adding one device on page
1333.
To organize devices using smart groups, see Device smart groups on page 1347.
To delete devices (and decommission the servers associated with those devices, if
any), see Deleting devices on page 1348.
3 Click Finish. The device appears in the Imported folder under Devices in the
BMC Server Automation Console.
Add Device
The Add Device panel lets you specify the MAC address of the new device, the
provisioning technology you plan to use for the device, an image file (for PXE
provisioning), and values for properties associated with the device.
Field Definitions
MAC Address
Enter the MAC address of the device that you are adding. The acceptable
formats for a MAC address are:
xx-xx-xx-xx-xx-xx
xx:xx:xx:xx:xx:xx
xx xx xx xx xx xx
Description
Choose the image file you want to use for this device.
Architecture
Choose the architecture of the device that you are adding; the values are x86
or x64.
Provisioning Method
Select the provisioning technology you plan to use for this devicePXE,
JumpStart, x86 JumpStart, NIM, Ignite PA-RISC, or Ignite Itanium.
(If you are provisioning a Solaris SPARC machine, choose JumpStart. If you
are provisioning a Solaris x86 machine, choose x86 JumpStart.)
Properties
x86
x64
sun4u
sun4v
i86pc
tp
bnc
dix
N/A
chrp
rs6k
rspc
mp
up
100 full
100 auto
100 half
1000 full
1000 auto
1000 half
10 full
10 auto
10 half
auto full
auto half
auto auto
PA-RISC
Itanium
The Properties list shows properties defined for the Device class in the
Property Dictionary.
Permissions
The Permissions panel lets you associate access control lists (ACLs) and ACL policies
to the device.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
To import a list of devices, you must first create one or more MAC address import
files. These files contain the MAC addresses of the devices to import.
You can also use the import process to assign configuration values to the devices by
adding properties to the MAC address files. If you assign configuration values in
this way, the provisioning operator does not have to type the values for each device
at provisioning time.
To assign configuration values, you must first create properties for the configuration
items and add those properties to the system package. Then you can add the
properties and values into the MAC address files.
For information about the MAC address file format and examples, see Creating a
MAC address file on page 1338. For information about creating properties and
adding them to the MAC address file, see Assigning configuration values during
device import on page 1341.
When you import a MAC address file, you select the provisioning method for the
devices in that file. You must create separate MAC address files for each
provisioning method.
One header line, in comma-separated format, identifying the properties that you
are including in the file. The properties must be defined as device properties.
Data lines, in comma-separated format, one line for each device that you are
importing. The values must appear in the same order as the property names in the
header line.
Note
Before you list a property name in the import file, the property must already exist as
a Device property.
The properties in the following table are predefined. If you want the import process
to configure other properties, you must first define the properties. For example, you
can enter computer names into the MAC address file and let the import process
assign the names to your devices, but you must first create the property for
computer name and add it to the appropriate system package. For information, see
Assigning configuration values during device import on page 1341 and Creating
a local property in the system package on page 1343.
The following table describes the predefined device properties for each type of
provisioning method.
x86
x64
sun4u
sun4v
i86pc
Itanium
PA_RISC
CABLE_TYPE
PLATFORM
NETBOOT_KERNEL
NET_SETTINGS
Examples
The following examples show only the required properties for each provisioning type.
Note
COMPUTER_NAME is not a preconfigured device class property. The following
examples assume that COMPUTER_NAME was previously configured as a device
property and added to the NIM and PXE system packages. For information, see
Assigning configuration values during device import on page 1341 and Creating
a local property in the system package on page 1343. (Note that
COMPUTER_NAME values must not contain spaces.)
If you assign configuration values in the MAC address file, the provisioning operator
does not have to type the values for each device when provisioning the devices. This
description explains how to associate a computer name with each MAC address.
You can use the techniques described below to automatically fill in many other
wizard fields as well.
1 Add a property to the root Device class. The Device class is one of the built-in
classes in the Property Dictionary. In this example, you add a property that
represents a computer name. Call your Device property:
COMPUTER_NAME
2 Add a local property to the system package you plan to use to provision your
devices. This local property makes use of the Device property you created in the
previous step. Assume that you call your local system package property:
COMPUTER_NAME
In this example you would set the Default value field for
LOCAL_COMPUTER_NAME to:
??DEVICE.COMPUTER_NAME??
For instructions on how to add a local property, see Creating a local property in
the system package on page 1343.
4 Create a MAC address import file. This file contains the MAC addresses of all the
devices to import, along with the property values to assign to each device.
Enter your newly created local property in the Computer name field on the
system packages Basic Configuration panel. For this example, type:
??LOCAL_COMPUTER_NAME??
in the Computer name field. Be sure to include the double question marks at the
beginning and the end. (Another way to enter this property into this field is to
click Select Property and select LOCAL_COMPUTER_NAME from the drop-
down menu.)
For more information about using the Basic Configuration panel, see:
Now when you run the provisioning wizard to configure each of the devices
listed in the MAC address file, the Computer name field is automatically filled in
for each device.
Remember that you can use these same techniques to add and reference other
properties, which you can use to fill in other fields in the wizard as well. The table
below shows some common examples. (Note that the names of the Device class
properties and the system package properties are samples onlyyou can call
your properties whatever you want.)
If you want this Create a Device class Create a local system Then define your system
provisioning wizard field to property called... package property called... package to use the new
be filled in... property like this...
This local property makes use of the COMPUTER_NAME Device property you
created earlier in this process.
LOCAL_COMPUTER_NAME
1 In the Depot folder, navigate to the system package, right-click and select Open
from the pop-up menu.
3 Click Add to add a new property. The Add Property dialog box appears.
LOCAL_COMPUTER_NAME
5 For Type, click Simple, then choose String from the drop-down list.
??DEVICE.COMPUTER_NAME??
The first part is the name of the built-in system package property (DEVICE)
that references the Device class.
Followed by the name of the Device propertyin this case the property is
called COMPUTER_NAME.
Be sure to include the double question marks at the beginning and the end.
You can use this syntax for other properties. For example, if you had created a
Device property called OM_NAME, you would specify it like this:
??DEVICE.OM_NAME??
1 (Required) Create a MAC address import file. See Preparing to import a list of
devices on page 1338.
2 Specify information about the import file, as described in the following sections:
3 Click Finish.
You can view the imported devices in the Imported folder under the Devices folder.
Field Definitions
MAC addresses
Lists the MAC addresses to import. To add addresses to the list, click Add
and select a MAC address file. For information about creating a MAC
address file, see Creating a MAC address file on page 1338.
Select File
The Import Devices panel lets you select a MAC address file and associate a
provisioning method to the devices in the file.
Field Definitions
Provisioning Method
Choose the provisioning method for the devices in this file. Click either PXE,
JumpStart, x86 JumpStart, NIM, Ignite PA-RISC, or Ignite Itanium.
Select the boot image file to provision on these devices. For information, see
Boot image files and placeholders on page 1159.
Navigate to and select the MAC address file. Then click OK.
The import process displays alerts about syntactical errors in the file. For
information about the format of a MAC address file, see Creating a MAC
address file on page 1338.
Boot image files are architecture-specific. The import process compares the
ARCHITECTURE property values in the MAC address file to the architecture
associated with the selected boot image file. The process sets provisioning attributes
separately for each device using the following rules:
Permissions
The Permissions panel lets you associate access control lists (ACLs) and ACL policies
to the devices in the MAC address file.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
A smart group is a group for which you define membership conditions based on
object propertiesin this case, device properties. Any device with properties
matching the conditions you specify automatically becomes a member of the smart
group.
You can use smart groups to organize devices according to specific criteria. For
example, you might use smart groups to group devices by device type: all PXE
provisioning devices, NIM devices, Jumpstart devices, and so on.
Another use for device smart groups is to group all PXE devices based on MAC
address prefix. For example, the first three parts of the MAC address 00-0C-29-XX-XX-
XX are commonly used for VMware ESX instances. To define a smart group that
puts all VMware virtualized devices together in a single group, you would define a
membership condition of any PXE device where MAC_ADDRESS starts with 00-0C-29.
Open a smart group in the smart group editor to view and edit its membership
conditions. Right-click the smart group and select Open.
Narrow the number of devices displayed in the hierarchical tree by filtering them
using a string. Only devices that include the string, which can appear anywhere in
the object name or description, are displayed in the results.
Note
The Imported and Provisioned folders are BMC Server Automation-provided
smart groups in the Devices folder. You can open these smart groups in the
editor to view their membership conditions but you should not edit them in
any way.
Deleting devices
You can delete devices that were previously imported.
If the device is included in any Jobs, the device is removed from those jobs.
If the device is associated with any servers (provisioned), those servers are
decommissioned.
To delete devices
1 In the Devices folder, right-click the device you want to delete and select Delete.
A list of Jobs that include the device you are trying to delete, if applicable.
You can monitor the provisioning status of devices using these methods:
View devices that are registered with BMC Server Automation but not yet
provisioned (see Viewing imported devices on page 1349).
View devices that are provisioned (see Viewing provisioned devices on page
1350).
Change the provisioning status of devices. You can classify a device as imported
(see Reprovisioning servers on page 1371) or provisioned (see Manually
classifying devices as provisioned on page 1353).
In a PXE environment, imported devices include both devices that you add
manually and devices that automatically appear when they boot up.
When a device is provisioned, the operating system is successfully installed and a post-
install job may be running, depending on the scheduling parameters set for that job.
The post-install job does not have to complete for a device to be in a provisioned state.
1 In the Devices folder, right-click the name of the device and select Open.
Information about the device (MAC address, device type, description, boot
image file, and architecture).
Setting Description
Setting Description
b To display a view, click its tab in the Properties, Permissions, and Audit Trail
tab group.
2 In the Properties, Permissions, and Audit Trail tab group, click the Properties tab
to display the Properties view.
3 To edit a property, click in the properties list, and then click in the Value column
for the property you want to edit. If the property is editable, the Value field
becomes active and displays utilities for editing the selected property value.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MyPARAMETER??) or click Select
Property.
To set a property value back to its default value, click Reset to Default Value
. The value of the property is reset to the value it inherits from a built-in
property class .
1 In the Devices folder, expand either the Provisioned or the Imported folder.
2 Right-click a device and select View provision history from the pop-up menu.
The Provision History window appears. The System Packages area lists job runs
executed on the device.
3 To view the log for a provisioning job, in the System Packages area, click a job
run. Then click the Job Run Log tab.
Details for a particular job run (system package name, start time, end time,
status, user, role).
Events of the job run log. To view the full text of any job run log entry, double-
click that entry. To view the previous or next message in the log, click the up or
down arrow in the Log Item Details window.
4 To view the system package settings that were used in a job run, click the System
Package Details tab.
Note
If you migrated this Job from a previous version, the Properties section of the
System Package Details window does not appear.
If you cancel a JumpStart provisioning job while it is running, you might later
see an error executing remove install client script note in the provisioning
history for the target device. This is normalignore this error message.
This information lists every device that a system package has provisioned. You can
also view detailed log information for each provisioning job that ran on each device.
1 In the Depot folder, open the folder containing your system packages.
2 Right-click a system package and select View provision history from the pop-up
menu. A window displays the system packages provisioning history, listing all
job runs that used this system package. Each job run entry includes the name and
MAC address of the device on which the job run took place.
3 To view the log for a provisioning job in which the system package was applied,
select the system package.
4 To view the full text of any job run log entry, double-click that entry. In the Log
Item Details window, you can click the up arrow or the down arrow to view the
previous or next message in the log.
This procedure is useful if a Provision Job does not complete, but the operating
system and the RSCD agent installed as expected. For example, a call back port error
occurs. In this case, you might decide to manually move the device from the
Imported to the Provisioned folder, rather than rerunning the entire job. You can
then update the server properties in the Server folder (not the Device folder), to
make the server appear as an enrolled and managed server in BMC Server
Automation.
2 Select the device, right-click, and select Set as provisioned from the pop-up
menu.
Deleting devices
You can delete devices that were previously imported.
If the device is included in any Jobs, the device is removed from those jobs.
If the device is associated with any servers (provisioned), those servers are
decommissioned.
To delete devices
1 In the Devices folder, right-click the device you want to delete and select Delete.
A list of Jobs that include the device you are trying to delete, if applicable.
Create the system package for the Provision Job. A system package contains all of
the instructions needed to install an operating system over the network with an
unattended installation. For information, see Creating a system package on page
1214.
Create a folder under the Jobs folder to store your Provision Jobs. To create a
folder, right-click the Jobs folder and select New => Job Folder.
In the Jobs folder, right-click a folder, and select New => Provision Job =>
<OS_type>.
In the Devices folder, expand the Imported folder, right-click one or more
devices, and select New => Provision Job => <OS_type>. This option offers a
convenient way to provision one or more devices immediately. The job wizard
adds the device information into the job for you, and it checks the Execute Now
option by default on the Schedules panel, which makes the job execute
immediately after you finish the wizard.
Tip
When you are familiar with the fields in the wizard, you can streamline some of
the wizard selections by using parameterized properties in the system package
definitions. For an example, see Streamlining the wizard with parameterized
properties: an example on page 1412.
A Provision Job is stored in the Jobs folder. You can open the job and edit it.
Field definitions
Name
Identifying name.
Description
Save in
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Field definitions
Path to System Package
Click Browse to select the system package to use to provision the servers.
Property Settings
You can change values for local properties associated with the system
package. Values that you set here override values set in the system package.
To change a property value, select a property and click Edit .
Note
You can add a property to the system package only through the Local
Properties panel when you create or edit a system package.
Field definitions
IP Configuration
The IP Configuration settings also appear in the system package. The IP
Configuration settings you enter in a Provision Job override the settings in the
system package.
Specifies that the network connection should use the static IP addresses that
you specify on the Devices list at the bottom of this panel.
Specify IP Range
Specifies a range of IP addresses that the system can use to assign a unique
address to each device. Select this option and provide an address for Start IP
and End IP of the range. The Devices list at the bottom of this panel displays
the IP address assigned to each device.
Subnet mask
Note
The Windows 2003 installer does not support three zeroes in any of the octets
in the subnet mask. For example, if the subnet mask is 255.255.255.0, entering
255.255.255.000 for Subnet mask does not work. You must enter 255.255.255.0.
Default gateway
(PXE devices only) From the Selected Boot Image list, select the boot image
for provisioning the servers.
For Red Hat Linux, SUSE, Citrix, and VMWare ESX, to skip using a pre-boot
image and boot directly using the installer ramdisk and kernel, select this
option. For information, see Using the Skip Linux Pre-Install image option
on page 1183
Devices to Provision
Build the list of devices to provision by clicking Add , Delete , and Edit .
When you click Add, the Add a New Device panel appears.
Computer Name
Enter a unique name for the server. If you are provisioning multiple servers,
the wizard names the first server using the name you provide, and then it
appends sequential numbers to that base name for the other servers. For
example, if you enter MyServer in the Computer Name field, the wizard uses
MyServer for the first server, names the second server MyServer_1, the third
server MyServer_2, and so on.
OM server name
The Available Devices list displays the devices available for provisioning. For
each device, the list displays information supplied when the device was
imported into the BMC Server Automation system.
Select one or more devices and click the right arrow, which moves your
selections to the Selected Devices list in the right panel.
Use the left arrow to remove an item from the Selected Devices list.
Use the double left arrow to remove all items from the Selected Devices list.
Field definitions
Pause and Continue
pre-disk partition -> pause 5 seconds -> disk-partition-> pause 5 seconds ->
post-disk partition... and so on
Tells the provisioning process to prompt the user to press the Enter key on the
console of the provisioning target after each logical step. The provisioning
process will not go on to the next step until the user presses the Enter key on
the target console.
For example, if you clicked Prompt user after each step, a Provision Job
might proceed like this:
pre-disk partition -> prompt user to press Enter -> disk-partition-> prompt
user to press Enter -> post-disk partition... and so on.
To restart the Provision Job at the same place, at the target console, type: bmi
If you plan to stop and restart a Provision Job, be sure to either set Pause and
Continue to a number greater than zero, or select Prompt user after each step. Then
stop the job when it is paused. This ensures that the job will restart in a consistent state.
Field definitions
Server Properties
Browse to the ACL template that you want to apply to all of the devices being
provisioned. An ACL template is a group of predefined authorizations
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Field definitions
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
You can open a job after you create it and schedule it for execution. If the job already
executed, you can edit the job and schedule re-execution. For example, if a job was
running and you canceled it, you could schedule the job to run again. Also see
Reprovisioning servers on page 1371.
Field definitions
Execute job now
Executes the job immediately after you finish a new job or save an edited job.
If your system has been configured to require approval information for this
job type, select Execute on Approval and then click Browse to display the
Enter Approval Information dialog box.
Schedules
Use the tabs on the scheduling window to provide the following categories of
information:
Field definitions
On Date
Enter the month, day, and year when the job should occur. Use a yyyy/mm/
dd format.
At
Enter the time when the job should occur. Use a 24-hour clock format (00:00
to 23:59).
Time Zone
If your system is configured to require approval information for this job type,
select Execute on Approval and then click Browse to display the Enter
Approval Information dialog box.
Priority
Select an execution priority level from the drop-down list. Available priority
levels are Critical, High, Normal, Low, and Lowest. You cannot select a
priority level higher than the maximum runtime level that is set for your role,
which is indicated next to the drop-down list.
Send email to
Lists email addresses of the accounts that should be notified when a job
completes with the statuses that you specify. Separate multiple email
addresses with semicolons, such as [email protected];[email protected].
After entering email address information, check the statuses that cause an
email to be generated.
Provides name or IP address of the server that should be notified when the
job completes. After entering server information, check the statuses that
should cause an SNMP trap to be generated.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
When you create a Provision Job, you can optionally select devices to provision.
More typically, you create and save a Provision Job without devices. Later, you open
the Provision Job, add devices that are ready to provision, and run the Job. You can
rerun the same job many times, with new devices selected each time.
1 Open the Jobs folder, navigate to a Provision Job, right-click the job and select
Open.
3 See Provision Job Devices on page 1357 for information about adding and
deleting devices.
5 When you are finished changing the Provision Job, click the Provision Job tab and
then click File > Save.
Note
This procedure does not change the Job name. Typically, it is not necessary to
change the Job name. The Job log produced during Job execution names the
devices included in that Job run.
If necessary, you can change Job names manually in the Jobs folder. You can also
copy a Job and paste a new Job with a new name.
In the Jobs folder, select the Provision Job, right-click, and select Execute.
This procedure executes the job immediately. (To schedule the jobs execution for a
specific date and time, see Provision Job Schedules on page 1362.)
If your system has been configured to require approval information for this job type,
select Execute on Approval and then click Browse to display the Enter Approval
Information dialog box.
The job appears on the Tasks in Progress view, where you can view its status or
cancel it, if necessary.
Note
If you execute a Provision Job against target devices that are not booted, the
Provision Job remains in the Task in Progress pane for the time set in the
JOB_TIMEOUT Job property or until the device boots up. By default, the
JOB_TIMEOUT value is 0, which means that the job does not time out. For
information, see Defining time-outs for jobs on page 644.
Note
If you execute a Provision Job on servers already provisioned, the job re-provisions
the servers. For information, see Reprovisioning servers on page 1371.
In PXE environments:
If you select a bare metal server that just completed a network boot and is
waiting for provisioning instructions, the server is provisioned.
If you select an existing server, you must reboot the server. Then the server is
provisioned automatically.
In all environments:
You can re-provision a server by re-executing the Provision Job associated with
the server. If the existing server was part of the BMC Server Automation system
before you re-provisioned it, you must redefine any jobs you want to run on the
newly re-provisioned server. Jobs that were defined for the server before you re-
provisioned it do not run now, even if you keep the same host name for the machine.
Show the results of a job. See Viewing the results of a Provision Job on page 1368.
Cancel a job in progress. See Canceling a Provision Job in progress on page 1369.
Add devices to or delete them from an existing job. See Changing or adding
devices in a Provision Job on page 1366.
Show the messages generated by a job. See Viewing the log for a Provision Job on
page 1370.
Export the log from a job. See Exporting the log for a Provision Job on page 1370.
The tab for the job contains a hierarchical tree that shows results for each run of the
job. Each run displays results for each target server provisioned by the job run.
1 In the Jobs folder, select a Provision Job, right-click, and select Show Results.
A new tab appears in the content editor. It shows the Provision Job results.
2 In the hierarchical tree on the left, expand a run of the Provision Job.
The pane on the right shows summary information for each job run.
View information about the devices targeted by the job Click the job run in the
hierarchical tree. The right pane lists the devices and provides information
about each.
View log messages about the provisioning of a device. Click the device in the
hierarchical tree.
Execute the job: In the hierarchical tree on the left of the tab, right-click the job
and select Execute from the drop-down menu.
Show the log for the job. See Viewing the log for a Provision Job on page 1370.
Export the log for the job. See Exporting the log for a Provision Job on page
1370.
View the device-specific system package settings. Right-click the device and
select Show System Package.
To cancel a Provision Job, your role must be granted the following permissions:
Device.Read
DeviceFolder.Read
DeviceGroup.Read
JobFolder.Read
JobGroup.Read
ProvisionJob.Cancel
ProvisionJob.Read
Server.Read
1 In the Tasks in Progress view, a Provision Job appears as one job with a node for
each device being provisioned. Select any node in the Provision Job.
2 Click Cancel .
1 Open the Jobs folder, navigate to a Provision Job, right-click the job and select
Show Results.
The hierarchy on the left side of the Results tab lists the job runs.
3 To display messages in a dialog box that allows you to scroll through messages
one by one, double-click on a message. The Log Item Details dialog box opens.
Click the Up arrow or Down arrow to scroll through messages.
1 Open the Jobs folder, navigate to a Provision Job, right-click the job and select
Show Results.
The hierarchy on the left side of the Results tab lists the job runs.
3 Specify the location where you want to store the exported results.
5 From Object Type, select the default file format for the exported log file. Log files
are exported in CSV format.
6 From File encoding, select the type of character encoding used for the exported
file.
7 Click Save.
Reprovisioning servers
You reprovision a server by re-executing the Provision Job associated with the server.
Reprovision from the Provision Job in the Jobs folder. Use this method to execute
the same Provision Job on the same devices, with the same system package as
before. See Reprovisioning from the Provision Job on page 1372
To reprovision a server, assuming that the server is already provisioned and you are
executing the same job again (to reprovision the same machine with the same name),
you must have the following permissions:
DepotFolder.Read
DepotGroup.Read
Device.Modify
Device.ModifyProperties
Device.Read
Device.Re-Provision
DeviceFolder.Read
DeviceGroup.Read
JobFolder.Read
JobGroup.Read
PropertyInstance.Read
ProvisionJob.Read Execute
Server.Create
Server.Read
Server.Decommision
Server.Modify
SystemPackage.Read
SystemPackageType.Read
1 Open the Jobs folder, navigate to a Provision Job, right-click the job and select
Execute.
When the Provision Job starts, the provisioning process does the following:
Changes the status of the device to Imported. (In the Devices folder, the device
is moved from the Provisioned folder to the Imported folder.)
In addition, the job appears in the Tasks in Progress view of the BMC Server
Automation Console, where you can view its status or cancel it.
You might use this reprovisioning method to provision the same devices using a
different system package.
1 In the Devices folder, open the Provisioned folder and select a device.
2 Right-click and select either Re-Provision Now or Re-Provision Later from the pop-
up menu.
If you click Re-Provision Now > OS_type, the provisioning wizard starts and
you can create a new job that executes automatically on the same devices as before.
When the Provision Job starts, the provisioning process does the following:
Changes the status of the device to Imported. (It is moved from the
Provisioned folder to the Imported folder.)
In addition, the job appears in the Tasks in Progress view, where you can
view its status or cancel it.
Suppose you are provisioning many servers using the same Provision Job. You can
use the following options to automatically generate computer names for the devices.
On the Provision Job Devices panel, you can enter a base name in the Computer
Name field and in the OM Server Name field. The wizard appends sequential
numbers to the base name you provide and assigns the values to the selected
servers. For example, if you enter MyServer in the Computer Name field, the
wizard uses MyServer_1 for the first server, MyServer_2 for the second server,
and so on. These unique names are visible after you select those devices for
provisioning on the Provision Job Devices panel. If needed, you could then
change the two values (Computer name and OM server name) by editing each
device individually.
Before you create the Provision Job, you can use the Import Device feature to
associate a generated computer name with each devices MAC address when you
import the devices to the BMC Server Automation Console. For information about
how to do this, see Importing a list of devices on page 1344. When you select
those devices for provisioning on the Provision Job Devices panel, you see a
parameterized property value like ??LOCAL_COMPUTER_NAME?? in the
Computer Name field.
If this parameterized property value results in unique computer names for all
devices, the wizard leaves the names as specified. However, if the wizard finds
duplicate names, it automatically appends sequence numbers to the duplicate
names to make them unique (NAME_1, NAME_2, and so on).
If the parameterized property value results in some devices not having names,
you can provide names on the Provision Job Devices panel.
The Provision Job overrides the parameters obtained from the system package.
Hence, changes that you make in a system package after you save a Provision Job
are not reflected in the saved Job.
Provisioning the Windows operating system to bare-metal servers is most often done
in a PXE environment, where files for operating system installation reside on a
remote PXE data store. However, BMC Server Automation provisioning also lets you
provision Windows 2003 or 2008 servers from a local data store.
The CD/DVD media must be removable or CD-ROM drive types. These types
include: CD, DVD, Integrated Lights Out (HP iLO), Dell Remote Access
Controller (DRAC), and USB devices.
The CD/DVD media must be connected to the target server and available.
The CD/DVD media must contain valid operating system installation files for the
Windows 2003 or 2008 installation you want to perform.
1 Create a WinPE 2.0 and later image to use in provisioning from the local data store.
To create a ISO or UFD image files for booting from local media (local boot), see
Creating a WinPE image for booting from local media on page 1375
To create a WinPE image for booting the target server from the PXE server
(PXE boot), see Creating an image for booting from the PXE server on page
1378.
2 Create a system package that points to the local data store as the location of the
installation files. See Creating a Windows system package for use with a local
data store on page 1378.
3 Associate the local data store instance with the system package. See Associating
the LocalDataStore instance with the system package on page 1381.
Supported media includes any locally connected media with a removable or CD-
ROM drive type, such as a virtual or physical CD/DVD, USB, Integrated Lights Out
(HP iLO), or Dell Remote Access Controller (DRAC).
Provisioning of operating system installation files is done from the local media,
which can be helpful in locations with network bandwidth challenges or security
restrictions that do not allow booting from the PXE server.
For provisioning from a local data store, you can use either:
ISO or UFD image files for booting the target server from a WinPE image
mounted on media local to the server, without using the PXE server (local boot).
A local boot can be done from the same media that you use for the local data store
or from different supported media. For example, you can keep operating system
installation files on a DVD and boot the WinPE image from an iLO.
A WinPE image for booting the target server from the PXE server (PXE boot).
At the root of any locally connected media: the WinPE ISO or UFD image, the
local data store CD/DVD, or any other locally connected media. (Local boot).
You specify the location of these components using the CONFIG_STORE property.
To create the image file, use either the image creation wizard or the BMC Server
Automation script.
Prepare the machine on which images are created. See Preparing a machine for
WinPE 2.0 and later image creation on page 1161.
If you plan to specify network details for the target server (static IP addresses,
WINS server, DNS server) in the image, create a network.ini file. For information,
see Creating a network.ini file on page 1169.
To use the image creation wizard to create the image for local boot
Architecture
UFD Image : Creates an image in UFD format for booting from USB flash
drive. The image is a directory with the name bootImageName_UFD; the
directory contains the files for booting from a USB flash drive.
3 For Boot Image Target Directory, type the full path to the directory in which
you want the image created, or click Browse to select a location. Use NSH
format for the path. The image creation process uses the name of last directory
in the path as the image name. For example: //myComputerHostname/
myImageDirectory/boot_2_0_x86
Note
Spaces are not supported in the boot image name. (The image creation
process considers the last directory in the Boot Image Target Directory Path
as the image name.)
3 In the Driver Selection window and Custom Script window, provide information
as you normally would in creating a WinPE image. (For information, see Creating
WinPE 2.0 and later images using the Image Creation wizard on page 1164.)
a Select the network.ini file. (Click Browse.) You would specify this file if the
provisioning environment does not contain a DHCP server. For information
about this file, see Creating a network.ini file on page 1169.
Manually copy the file to the root directory of the media (CD, DVD, USB)
you use for local provisioning of the server.
b Accept or change the Application Server IP address and port. (Specify this
information if there is no DHCP server present in the provisioning environment.)
For information about Configuration Details options, see Creating WinPE 2.0 and
later images using the Image Creation wizard on page 1164.
5 Click Finish.
1 Create the input file containing image creation parameters. In the file, specify all
required parameters and all parameters labelled Local boot image only. For
parameter descriptions and an example script, see Creating the input
parameters .ini file on page 1171.
3 Copy the WinPE image file to the media you plan to use for provisioning the
target server. See Copying image files to a location for provisioning on page 1175.
In provisioning from a local data store, installation files are located on local media.
Usually, a local boot image is used. However, you can create a WinPE 2.0 or later
image file for booting the target machine from the PXE server (PXE boot) instead of a
local boot. To create the image, do either of the following:
1 To create the boot image file using the Image Creation wizard, follow the steps
Creating WinPE 2.0 and later images using the Image Creation wizard on page
1164. Specify settings as you normally would to create a WinPE image. In
addition, specify the following settings:
On the Toolkit Select panel, for Image type, select PXE Image.
2 To create the boot image file using the BMC Server Automation script, follow the
steps in Creating WinPE 2.0 and later image files using the BMC Server
Automation script on page 1171.
Specify all required parameters and other parameters as you normally would
to create a WinPE image.
1 Edit the system package type to specify the location of the operating system
installer as relative to the local data store and the RSCD agent installer as relative
to the CONFIG_STORE location.
b On the System Package Type tab, under Relative Paths for OS images, select
the type of system package and click Edit .
c On the System Package Type window, for OS Installer location, type the path
to the directory where the operating system installation files reside in the local
data store (CD/DVD, USB flash drive). The path must be relative to the root
directory of this local data store. If these files are at the root directory of the
local data store, type a backslash (\).
d For RSCD Installer location, type the path to the directory where the RSCD
agent installer files reside.
If these files are in an ISO or UFD boot image, specify a path relative to the root
of ISO or UFD.
D:\DataStore\RSCD\rscd_76_x86
3 In the system package, define settings on the Disk Partition, Basic Config, OS
Components, Network, and Post-Install Config tabs as described in Defining
settings for Windows servers on page 1218.
4 On the Local Properties tab, accept or change the default setting for the
CONFIG_STORE property. This property specifies the locations that the
provisioning process searches for the configuration components (bmiwin.exe,
RSCD Agent installers, and operating system drivers) when booting from local
media. See The CONFIG_STORE property on page 1382.
5 On the Computer Settings tab, define settings for User Information, License setup,
and Localization as described in Computer settings Windows 2008 on page 1224
or Computer settings all Windows operating systems except Windows 2008 on
page 1227.
6 For Driver Setup, type the paths to the drivers as relative to the CONFIG_STORE
location, according to the OS Drivers Path you specified on the Configuration
Details panel during image creation. (You cannot browse to select drivers if the
LocalDataStore is associated with the system package.)
Windows
2008 system packages: If D:\DataStore\Drivers contains mass
storage drivers at:
D:\DataStore\Drivers\MassStorage\SCSI
Then for Mass storage drivers, you would type: MassStorage\SCSI
Windows
2003 system packages: If D:\DataStore\Drivers contains mass
storage drivers at:
D:\DataStore\Drivers\$OEM$\$1\MassStorage\SCSI
Then you would select Specify path to $OEM$ directory and for the Path to
$OEM$ directory, you would type: Drivers. For Mass Storage Drivers, you
would type: MassStorage\SCSI
7 To create a system package for Windows 2003 that includes mass storage drivers,
add entries for the drivers in the unattend.txt file, as follows:
b Clear the Customize the Unattend Entries file checkbox and add the entries to
the Additional entries for the unattend.txt file.
For example:
[MassStorageDrivers]
[OEMBootFiles]
vmscsi.sys
vmscsi.inf
vmscsi.cat
txtsetup.oem
8 When you finish defining system package settings, select File => Save.
1 Create the Provision Job, as described in Creating a Provision Job on page 1354.
3 For System Package Properties, select the DATA_STORE property and click Edit
.
4 Click in the Value column and then click Browse . The Choose Property Class
Instance dialog box appears.
6 Complete the remaining steps of the Provision Device wizard and click Finish.
When the Provision Job executes, the target servers are provisioned from the local
data store.
This property is a local property of a system package. Use this property only to
provision from a local data store.
You can set the default value of this property to specify locations to search. The
values are:
WinPE The provisioning process searches the LDS directory inside the WinPE
image on the local data media.
All (The default value) The provisioning process searches both locations in this
order:
To change the default value of CONFIG_STORE, use the Local properties panel of
the Windows system package.
Note
For information about provisioning ESXi 4.1, see Defining settings for ESXi 4.1 and
5.0 servers on page 1266.
The BMC Server Automation installation provides an ESXi 4.0 boot image.
You can use the ESXi 4.0 boot image to provision 64-bit devices only.
You cannot configure this image as the default image for your environment.
However, you can configure the custom ESXi boot image to support 32-bit devices
and you can set that image as the default image. For information, see Configuring
boot image files on page 1206.
You cannot use the ESXi 4.0 boot image with a system package in a Provision Job.
The ESXi 4.0 boot image does not support auto-discovery of devices.
1 Download and extract the ESXi 4.0 image to the TFTP server at this location: tftproot/
X86PC/prelinux.
For information about extracting the image, see PXE booting VMware ESXi
on the VMWare website.
2 Edit the values for the ESXi 4.0 image file (vmkboot.gz) provided in the BMC
Server Automation installation:
c Edit the values for Image File and Kernel name to specify paths that are
relative to the TFTP server.
d For modules in the Kernel commandline, specify paths that are relative to the
TFTP server.
e Click OK.
3 Associate the ESXi 4.0 boot image with a target device by manually importing the
device. See Manually adding one device on page 1333.
4 Reboot the target device. It boots from the ESXi 4.0 image.
When the device boots from the PXE server, the ESXi 4.0 kernel is loaded,
followed by the modules specified in the kernel command line.
Note
The ESXi 4.0 boot image contains several large modules, which can cause timeout
failures during the transfer of the image from the TFTP server. If this problem
occurs, you can edit the tftp.conf file and increase the value for retries. (The
retries entry specifies the number of times that the TFTP server tries to send a file
to the target server.) The setting should be large enough to allow the transfer of
large modules but the setting is network specific. For example, you might try
retries=30.
The tftp.conf file resides in the following locations:
Windows: installationDirectory \PXE\br\tftp.conf
UNIX: installationDirectory /NSH/br/tftp.conf
1 On the TFTP server, make sure that the PXELINUX.0 file in tftproot is version
3.86 and that the file named ifcpu64.c32 is present. You can obtain the correct
version of the file from provision.zip provided with BMC Server Automation
installation.
3 Download and extract the ISO for ESXi 5.0 to the above folder on the TFTP server.
5 In the BMC Server Automation Console menu bar, select Configuration >
Provisioning Configuration.
6 Select the system package type for VMWare ESXi 5.0 and click Edit.
8 Save the system package type configuration and exit the configuration window.
Note
ESXi 5.0 does not require an RSCD agent installation file. This operating system
uses agentless managed objects.
9 Configure a system package referencing the ESXi 5.0 system package type.
10 Create a Provision Job that references the system package, import devices, add
those devices to the Provision Job, and execute your Provision Job.
Note
The BMILINUX.log file generated on the host after provisioning is located
directly under / instead of in the /root folder used by other operating system
versions.
A boot server must be installed and running. This server must have a running
RSCD agent that is licensed for both NSH and the BMC Server Automation
Console.
An install server must be installed and running. This server must have a running
RSCD agent that is licensed for both NSH and the BMC Server Automation
Console.
Both the boot server and the install server must have a web server configured and
running.
The Flash archive must have the RSCD agent installed on it.
To provision a Solaris SPARC target server using the WAN boot program:
1 Create an instance of the Jumpstart WAN Install data store property class. (See
Configuring the data store on page 1185.)
2 Provide values for the following properties of the Jumpstart WAN Install data
store instance:
3 Configure the system package type for the Solaris SPARC WAN Boot:
c On the Configurations tab, for Operating System Type, select Solaris. Then
check WAN Boot.
System package type: The name of the new system package type.
Archive Location: The path to the Solaris Flash archive on the install server,
relative to the document root directory.
Miniroot Location: The path to the miniroot file on the boot server, relative
to the document root directory.
Wan Boot Location: The path to the wanboot program on the boot server,
relative to the document root directory.
6 On the Basic Config tab, provide information for Local Settings as you normally
would for a Solaris installation.
7 To set up a secure WAN boot installation, for WAN Boot Parameters, select either
of the following options:
Authenticate Server during the installation: Specifies that the server generates
hashing and encryption keys and displays them in the logs. If you check this
option, you can select either key type: 3DES (the default) or AES.
You must use the set-security-key command to set the values of these keys
in the OpenBoot PROM (OBP) of the client. (For information, see the Solaris
WAN boot installation documentation.)
8 On the Network Config tab, provide information for Local Settings as you
normally would for a Solaris installation. For the WAN Boot Network IP, enter
the network IP address of the target server. (This field is required for a WAN boot
installation.)
9 Provide information on the other tabs of the system package as you would for a
Solaris Flash installation.
On the Finish Script/Agent Install tab, the Install RSCD agent option is not
available. (The RSCD agent is part of the Flash archive.) If you specify a post-
installation Batch Job or if you select the Push ACL option, the provisioning
process executes these actions only if the RSCD agent is installed and running on
the Flash archive.
2 Use Microsoft Sysprep to prepare a reference machine for capturing the WIM image.
This procedure describes capturing WIM images for deployment from a BMC Server
AutomationApplication Server on a Windows 2003 platform to target VMs on
VMware workstation 7. You may need to change the procedure for Windows 2008
and specific hardware.
Install and configure the provisioning infrastructure. See the topics on setting up
the provisioning system in BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Setting+up+the+provisioning+system.
Download and install the Microsoft Windows Automated Installation Kit (WAIK).
See Preparing a machine for WinPE 2.0 and later image creation on page 1161.
1 Create a WinPE ISO image using the BMC Server Automation WinPE image
creation process and copy the image to a CD. See Creating WinPE 2.0 and later
boot image files on page 1160.
2 Use Microsoft Sysprep to prepare a reference machine for capturing the WIM
image.
a Install the version of Windows on the machine that is to serve as the source for
the WIM image. For example, you might install Windows 2003 on a virtual
machine.
c If the hardware on the target servers is not the same as on the reference
machine, inject mass storage drivers during system preparation with Sysprep.
Before you run Sysprep, populate the SysprepMassStorage section of the
sysprep.inf file with the driver information.
Note
For images for Windows 2003 or Windows 2003 x64, include mass storage
drivers in the image during creation.
For information about injecting mass storage drivers, see the Microsoft Technet
articles on the following topics:
3 To remove any unique information and reseal the operating system, run the
Sysprep tool on the reference machine.
b Change directory to the sysprep directory and run Sysprep. For example, for
Windows 2003, you would enter: sysprep.exe /mini /reseal
a Configure the reference machine to boot from a CD. If the machine goes into
HDD boot, it runs the mini-setup wizard and you have to run Sysprep again.
b Boot from the CD with the WinPE ISO image you created.
c (For WinPE images created with BMC Server Automation) When the machine
boots, press Ctrl+C to exit the bmi (bare metal interface) and display the
Windows command prompt.
d Start the Diskpart.exe utility and use the following commands to verify the
disk configuration. Note the drive you are imaging (listed in the output of the
list volume command).
diskpart
select disk 0
list volume
exit
e Mount the data store drive. Use the following Windows operating system
command:
f Use ImageX to capture the WIM image from the drive. Use the format:
For example, this command creates a Windows 2003 Standard WIM image
(W2K3STDx86.wim) in the WimImages directory in the data store:
Note
You might need to relicense applications bundled in the WIM image if they use
the host name, MAC address, or some other unique key.
Capture the WIM image using the Microsoft Sysprep and ImageX tools. See
Capturing WIM images for use in provisioning on page 1388.
Name the image file or files using the name of the captured disk drive. For
example: C.wim. The image from a second disk drive might be named D.wim.
Copy the WIM image files to the data store folder that you created for it. For
example: C:\Program Files\BMC Software\BladeLogic\PXE\pxestore
\WIMimages\C.wim
The BMC Server Automation system provides these system package types for
use in provisioning with a WIM image:
Note
To provision WIM Based Windows 2008 R2, use the WIM Based Windows
2008 x64 system package type. You can either create a new custom system
package type with a different name or use the existing out-of-the box WIM
Based Windows 2008 x64 system package type.
b Edit a system package type or create one. To edit a system package type, select
it and click Edit. To create a custom WIM system package type, click Add.
c On the System Package Type window, provide the following information and
click OK.
For Operating System Type, select Windows. Then check WIM Based
System Package.
For OS Installer Location, enter the path to the WIM image directory,
relative to the data store path name.
For example, if the root directory of the data store is: C:\Program Files
\BMC Software\BladeLogic\PXE\pxestore
and the WIM image resides in: C:\Program Files\BMC Software\BladeLogic
\PXE\pxestore\WIMimages
then for OS Installer Location, specify: WIMimages
Note
The provisioning process uses the WIM image files stored in this location as
follows:
Addititonal images stored here are used only if their names match
additional disk partitions specified in the WIM system package. The D.wim
image, for example, is provisioned on target servers only if you add the D
disk partition to the disk partition panel of the WIM system package. For
more system package information, see Step 3.
For RSCD Installer Location, enter the path of the directory where the
installer files for the RSCD agent are stored. Specify a path relative to the full
path of the data store.
For Initial Partition Size, specify a minimum disk partition size for the C:
drive.
2 Create the system package. On the General panel, select a WIM based system
package type. For information, see Creating a system package on page 1214.
3 In the system package, define settings as you normally would for a Windows
system package, with the following exceptions:
To provision more than one disk partition using WIM images (for example,
C and D), clear the Use Script for Disk Partitioning check box, click Add,
and specify the D partition. (C is included by default.) Also, ensure that
WIM images with matching names (for example, C.wim and D.wim ) exist
in your WIM directory in the data store.
Note
You cannot use a disk partition script to add additional disks for WIM
provisioning.
To provision only the C partition, ensure that no other disks are listed. Also
ensure that an image file named C.wim is in your WIM directory in the data
store.
On the Computer Settings tab, for WIM-based Windows 2003 and WIM-based
Windows 2003 x64 system packages, the Mass Storage Drivers selection box is
dimmed. You must include mass storage drivers in the WIM image when you
create it.
The Unattend Entries tab displays only the entries specific to WIM-based
provisioning.
For information, see Defining settings for Windows servers on page 1218.
4 Create the Provision Job. For information, see Creating a Provision Job on page
1354.
For Paths to the System Package, select the WIM based system package in
the data store.
For Selected Boot Image list, select the WinPE 2.0 or later boot image to use
in provisioning.
On the System Package Properties panel, select the instance of the data store
where the WIM image is stored.
During provisioning, the WIM image is applied to the target server. The image
runs the installation using the Unattend Entries file generated in the system package.
When auto-discovery is set up, an iDRAC device boots on your network and
registers itself with the provisioning service. The device is then recognized as a
known device (auto-discovered) by the BMC Server Automation system and appears
in the Devices list of the BMC Server Automation Console.
In the iDRAC configuration utility, make sure that the Auto-discovery option is
enabled and the Admin account option is disabled. To access the configuration
utility, press Ctrl-E during boot of the iDRAC device.
To set up auto-discovery
1 Configure the DHCP server for iDRAC auto-discovery. See Configuring the
DHCP server for iDRAC auto-discovery on page 1394.
2 Import the Dell Certificate into the bladelogic.keystore. See Importing Dell
certificates into the keystore on page 1396.
4 Edit the iDRAC configuration file to set the user name and password that the auto-
discovery process requires. See Creating the configuration file for the iDRAC
provisioning service on page 1397.
Perform this task in addition to configuring the DHCP Server for provisioning. For
information, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Configuring+the+DHCP+server.
1 Run DHCP from the Start menu by selecting Programs => Administrative
Tools => DHCP. The default server is the server where you installed DHCP.
2 Select the default server, right-click and select Define Vendor Classes.
5 Select the default server, right-click and select Set Predefined Options.
7 Click Add and provide the following information. Then click OK.
8 Expand the hierarchy for the default server and then expand the hierarchy for
Scope.
12 For String value, enter the provisioning server string, in the following format:
ApplicationServer:port
Where:
port is the port on which the iDRAC auto-discovery service on the Application
Server listens.
Where:
port is the port on which the iDRAC auto-discovery service on the Application
Server listens.
1 On the Application Server that is the provisioning server, change directory to the
_template directory.
Windows: installDirectory\NSH\br\deployments\_template
UNIX: installDirectory/NSH/br/deployments/_template
Where:
Windows: From the Start menu, select Programs => BMC Software =>
BladeLogic Server Automation Suite => Utilities => Application Server
Administration.
Linux and UNIX: From the BMC Server Automation installation directory,
enter: .br/blasadmin
3 Set the https port on which the iDRAC auto-discovery service listens. (The default
is 4433.) Enter:
The idrac-config.xml file contains user name and password entries that correspond
to the service tag of each iDRAC device. Initially, the file contains only the format for
this information; you edit the file and add the information for your iDRAC devices.
Then when the iDRAC device sends a request to the provisioning service, the service
uses the configuration file to identify the device and send the appropriate user name
and password to it.
Service tag for the iDRAC device. (You can get this tag from the System summary
on the iDRAC web console or from the iDRAC BIOS information.)
Encrypted password for the device. Use the blenc utility in Network Shell to
generate the encrypted password.
</IDRAC>
<IDRAC ServiceTag=YYYY>
<username></username>
<password></password>
</IDRAC>
</IDRACS>
You can import both iDRAC6 Express and iDRAC6 Enterprise level devices into the
BMC Server Automation system and provision them with the Windows operating
system.
After iDRAC devices are managed in the system, you can copy drivers from an
iDRAC device to a data store so they can be shared for provisioning other iDRAC
devices in the system. For servers equipped with iDRAC6 Enterprise with Virtual
Flash (vFlash) and Firmware 1.3, you can also download the .iso to the iDRAC vFlash.
The Stage ISO to vFlash option requires iDRAC 6 Enterprise with vFlash and
Firmware 1.3.
Only a network ISO boot image and booting from vFlash are supported. Booting
from a PXE server is not supported.
You may encounter issues with provisioning servers equipped with the Dell
iDRAC device due to issues with the setup of the device itself. For information
about these issues, see the Dell iDRAC Release Notes and knowledge base.
BMC Server Automation provisioning uses the txtsetup.oem file supplied by the
iDRAC device. Currently, this file has an incorrect item that you must remove in
order to provision successfully. Edit the txtsetup.oem file and in the [scsi] section,
remove \percsas.sys, \ from the line for PERC_32. (The example shows the
item to remove in bold.)
[scsi]
# This section lists the options available for a particular component.
#
# <id> is the unique string for the option
# <description> is a text string, presented to the user in a menu
# <key_name> gives the name of the key to be created for the component in
# HKEY_LOCAL_MACHINE\ControlSet001\Services
PERC_32 = "DELL PERC5 and PERC6/CERC6 RAID Controller Driver (Server 2003
32 bit)", \percsas.sys, \
For information, see Creating WinPE 2.0 and later boot image files on page
1160.
3 Copy operating system drivers from the iDRAC device to the data store so the
drivers can be used in provisioning other iDRAC devices.
For information, see Copying iDRAC drivers to a data store on page 1402.
4 (Optional) If you plan to boot the iDRAC device from an ISO image on the
devices vFlash, download the ISO image from the data store to the vFlash.
6 Create the Provision Job as you normally would for a Windows Provision Job.
a On the Select System Package panel, select the system package you created and
select the WinPE 2.x ISO image you specified.
b On the System Package Properties panel, set the value for DATA_STORE
property to the data store where operating system installation files for the
iDRAC device.
c Provide drivers and boot information on the iDRAC panel. For information,
see The iDRAC panel on page 1404.
Field Definitions
iDRAC Host/IP
Username
Password
Field Definitions
MAC address
The panel displays the MAC addresses for the iDRAC device. Select the MAC
address to use as the identifier for the device in the BMC Server Automation
system.
Add Device
The Add Device panel lets you specify the boot image and set properties for the
iDRAC device.
Field Definitions
MAC address
The MAC address that identifies the iDRAC device in the BMC Server
Automation system.
Description
The image to use for booting the iDRAC device. You must select a Windows
2.x or later ISO image.
Device Properties
Properties that are specific to the device in the BMC Server Automation system.
Permissions
The Permissions panel lets you define ACLs and ACL policies for the iDRAC device.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
An ACL policy is a group of authorizations that can be applied to this object but can
be managed from one location.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
You might share drivers in this way to use a particular version of a driver in
provisioning multiple iDRAC devices, irrespective of the driver version hosted by
each device locally.
Create a data store instance that represents the Windows share on which to copy the
shared driver set.
Note
Do not keep the $WinPEDriver$ folder on the data store. When the Windows 2008
installer searches for drivers, it looks for the $WinPEDriver$ folder on all available
drives. The data store is one of the drives the installer searches. If the drivers stored
in the $WinPEDriver$ folder are not correct, the Windows 2008 installation fails.
1 In the Devices folder, navigate to the iDRAC device whose drivers you want to
share.
The operating system drivers to share with other iDRAC devices. Select the
driver set from the drop-down menu.
The data store instance in which to store the shared drivers. Click Browse
to navigate to the instance of the data store.
Provide the folder name where the driver set will be copied inside the data store
Enter a folder name. The system creates the folder in the data store where the
drivers are stored.
4 Click Finish.
Downloading the ISO image file to vFlash lets you boot the iDRAC device locally
during the provisioning process.
This option requires iDRAC6 Enterprise with vFlash and Firmware 1.3.
3 On the dialog, select the data store where the ISO is stored. Then select the .iso file.
4 Click OK.
You can also specify that the iDRAC device boots from a network ISO or an ISO on
the vFlash of the iDRAC.
Field definitions
Use drivers from datastore
Select this option to use drivers stored in the data store. Then browse to the
data store folder where the drivers are stored.
To use this option, you must first copy drivers to the data store with the
Copy drivers to data store option.
Information you specify in this field overrides the drivers specified in the
system package.
Select this option to use drivers that reside on the iDRAC device instead of
those in the data store. Then select the drivers from the OS Drivers list.
For jobs that provision multiple iDRAC devices, this option is supported only
for devices with iDRAC Firmware 1.3.
This option is not supported for provisioning with Windows 2003 system
packages.
Note
Boots the device from the ISO image in the data store. You can specify an ISO
image different from the one on the vFlash.
Boots the device from the ISO image on the vFlash. The image must already
be present on the vFlash. (Use the Stage ISO to vFlash option.)
You can provision Citrix XenServer release 5.5 and 5.6. The provisioning process
uses the PXE provisioning environment and the Citrix XenServer system package.
b Copy the following files from the XenServer Base Pack CD to the XenServer
directory you created. (You can find the files in the root directory of the Base
Pack CD and in its /boot directory.)
install.img
vmlinuz
xen.gz
The BMC Server Automation installation provides the mboot.c32 and prelinux.
0 files.
a Copy the contents of the package directories from the Base Pack CD to a
directory in the data store that provides HTTP access.
For example, in the document root of a web server, you might create a
directory called XenServer_5.6.0.
c In the System Package Type dialog, select Citrix XenServer. Then fill in the
information as described in Citrix XenServer system package type on page
1199
5 Create the system package. Then define its settings. See Defining settings for
Citrix XenServers on page 1288.
6 Create and execute the Provision Job. See Creating a Provision Job on page
1354.
The following Red Hat operating system versions include support for the KVM
hypervisor:
Red Hat Enterprise Linux version 5.4 and later, x64 architecture.
Because only one hypervisor can be active at a time, you can install either the Xen
hypervisor or the KVM hypervisor on a server.
Set up and configure the data store for Red Hat Linux provisioning.
2 Create a RHL 5 system package and select Red Hat as the system package type.
a Define these settings as you normally would for a Linux system package: Pre-
Install Script, Disk Partition, Basic Config, Computer Settings, Network,
KickStart, Post-Install Configuration, and Local Properties. For information,
see Defining settings for Red Hat Linux servers on page 1243
4 Create and execute the Provision Job. See Creating a Provision Job on page
1354.
Because only one hypervisor can be active at a time, you can install either the Xen
hypervisor or the KVM hypervisor on a server.
Set up and configure the data store for Red Hat Linux provisioning.
2 Create a RHL 5 system package and select Red Hat as the system package type.
a Define these settings as you normally would for a Linux system package: Pre-
Install Script, Disk Partition, Basic Config, Computer Settings, Network,
KickStart, Post-Install Configuration, and Local Properties. For information,
see Defining settings for Red Hat Linux servers on page 1243
4 Create and execute the Provision Job. See Creating a Provision Job on page
1354.
Where:
path/filename is the location where you want to save the archive and the filename.
Note: These two parameters are required. For information about other
parameters, see the man page for the flarcreate command on a Solaris machine.
2 Copy the archive file to a location you use for provisioning. For example, copy it
to the BMC Server Automation file server.
3 Create the Solaris system package as you normally would, except on the Basic
Config tab, do the following:
c For Archive Location, type the path to the archive file or specify a property
that contains the value.
For information about device properties, see Device properties on page 1410.
For information about system package properties, see System package properties
on page 1410.
For information about data store instances, see Data store instance properties on
page 1415.
Inserting parameters that refer to properties can streamline the provisioning process.
For information about using parameters during provisioning, see:
Device properties
Every device inherits its properties from the built-in Device class in the Property
Dictionary. You cannot edit values for the properties included by default in the
Device class. They are intrinsic properties, meaning they are derived from the nature
and configuration of a device, such as its MAC address and serial number. However,
you can add properties to the Device class in the Property Dictionary. Any property
you add applies to every device.
Like other system objects, system packages inherit properties defined for a built-in
class in the Property Dictionary. However, you cannot change the properties defined
for the system package built-in class in the Property Dictionary, the way you can for
many other system objects. (In fact, the built-in class for system package is hidden
from display within the Property Dictionary.) Instead, to add a property to a system
package, you add it to the individual system package itself, using the Local
Properties panel for that system package.
Note
To use your own properties, define them in the Local Properties panel for a system
package before you attempt to provision a server using that system package.
Using parameters that refer to properties can be very useful when provisioning.
For information about how to insert a parameter into a system package, see
Inserting a parameter in a system package field on page 1413.
For information about how to use a property to refer to a script, see Using
properties to reference scripts on page 1414.
2 To create a custom property in the Server class, expand Built-in Property Classes,
navigate to the Server class, and click Add. Then click OK.
3 To verify that the new property (created in the Server class) appears automatically
in the PROVSERVER subclass, expand PROVSERVER in the left panel and scroll
to find the new property.
4 To create an instance of the PROVSERVER subclass, ensure that you have the
PROVSERVER subclass selected in the left panel, and click the Instances tab in the
right panel. Then click Add and complete the dialog boxes to create the new
instance.
5 To populate the new instance with property values, select a property, click Edit,
and type the value.
For example, select the Site property, click Edit, and type Austin as the property
value. Then, select MS_OFFICE_INSTALL_USERNAME, click edit, and type a
username that you plan to create on the servers. Similarly, select and populate
MS_OFFICE_INSTALL_PSW.
Note
You can select and populate only those properties that are marked as editable in
the Server class.
6 To set up a Provision Job to assign these values to all of the target servers in the
Job, open or create the Provision Job. On the Server Settings panel, navigate to a
PROVSERVER instance and select the properties whose values you want to assign
to all target servers.
For example, select the Austin_Windows_Servers instance, and then select the
Site and the MS_OFFICE properties that you populated with values.
8 To verify that the server property values are provisioned, in the Servers folder,
select one of the target servers that you just provisioned and browse the
Properties tab.
For example, all of the target servers in the Provision Job have a value of Austin in
their Site property.
Insert a parameter that refers to this property in the system package definition.
Run the wizard and view the resulting drop down menu for the field.
Suppose you are creating a system package for a Red Hat system, and you want the
Kickstart network device field in the provisioning wizard to include a drop-down
menu of available choices. (The Kickstart network device field is one of the Basic
Configuration settings.) To accomplish this, you can:
Name Value
Port 0 eth0
Port 1 eth1
Port 2 eth2
Port 3 eth3
3 On the Basic Configuration panel for your Red Hat system package, type the
following into the Kickstart network device field:
??ACTIVE_NIC_PORT??
4 Create a Provision Job to provision a device with your Red Hat package. When
the provisioning wizard displays the Basic Configuration panel, note that the
Kickstart network device field displays a drop-down menu with the choices Port
0, Port 1, Port 2, and Port 3.
The provisioning operator can simply select one of the available choices without
worrying about the underlying syntax, which you specified when you defined the
system package.
You can generalize a system package using a parameterized property. For example,
you can define a system package that uses a parameter to represent the path to a
network driver. Later, when this system package is being used to provision a device,
a user can insert the value for the network driver path that is applicable to the device
being provisioned.
Note
You can use parameterized property references in any field that displays the Select
Property icon.
1 In the field where you want to insert the reference to the property, do either of the
following:
You can also type the name of the property directly into the system package
field. Be sure to delimit the property with two question marks, such as ??
NIC_DRIVER_PATH??.
You can create a local property that contains a script, and then insert a parameter
that refers to this property in the system package.
Note
The script contents cannot exceed the limitations on the length of the property.
b Click Add , and for Type, select Simple => Long Text.
c To the right of the Default value field, click Browse to open a text window.
e Click OK and then save the system package. Your property appears on the
Local Properties tab.
2 In the relevant system package field, insert a parameter that refers to the newly
created script property. Enclose the property name with double question marks.
For example, suppose you created a long text script property called
PARTITION_SOLARIS_8. In the script field on the Disk Partition panel, you
could either type in:
??PARTITION_SOLARIS_8??
You can create multiple data stores throughout your network, and then choose the
most appropriate one for provisioning a specific device. For more information, see
Data store instances and provisioning strategies on page 1415.
In the Provision Job, you choose the appropriate data store instance for the machines
that you are provisioning. The following examples illustrate this flexible
provisioning feature.
To provision target 1, you specify the VLAN1 Data Store instance in the Provision
Job. Similarly, to provision target 2, you specify the VLAN2 Data Store.
For example, consider the following topology. To provision one Linux machine on
VLAN 1 and a second Windows machine, also on VLAN 1, you can create two data
store instances:
Both of these data stores can reside on the same physical machinein this example
on machine 1.
The Linux Data Store VLAN1 instance points to the directory on machine 1 that
contains the Linux installation files. Because Linux targets require the data store
property LOCATION to be set to the data stores IP address, you must set
LOCATION to machine 1s IP address.
The Windows Data Store VLAN1 instance points to the directory on machine 1
that contains the Windows installation files. Because Windows targets require the
data store property LOCATION to be set to the data stores host name, you must
set LOCATION to machine 1s host name.
From the BMC Server Automation Console, you can import well-formed SCAP-
expressed data streams from third-party sources. You then run SCAP Compliance
Jobs to analyze selected servers against the SCAP rules and checklists. The BMC
Server Automation Console displays the results by SCAP rule and by server. You
can also export the job results to an XML file, and then view the exported file in a
web browser or use it with third-party tools for reporting or other purposes.
Using features in the BMC Server Automation Console, you import SCAP content
from third-party sources.
Validation against the SCAP schemas occurs during the import. An imported
benchmark is a well-formed XCCDF expressed data stream. You can import multiple
SCAP Benchmarks.
After importing the SCAP Benchmarks, you create, run, and manage SCAP
Compliance Jobs. Each job selects an SCAP Benchmark, profiles within the
benchmark, and target servers. SCAP Compliance Jobs are fully integrated into the
BMC Server Automation product and include all standard Job features of the
product, such as server smart groups to automatically collect target servers based on
rules; GUI-based Job editing; automatically recurring job scheduling; automated
email notifications and SNMP traps to report job results; and role-based access
control (RBAC) on all activities.
OVAL checks are processed on the target servers. Their results are used by BMC
Server Automation in forming the final XCCDF results. The BMC Server Automation
Console shows the result state for each rule. Results are organized in two views: one
view shows results by target server and another view shows results for each rule
across all servers. Rule results can be one of nine values, including Pass, Fail, Error,
and Unknown.
You can export the results to an XML file compliant with the XCCDF specification.
The exported file is accompanied by an XSLT file, enabling you to view the contents
in a human readable format using a web browser.
The exported results include active links to full descriptions for all referenced
Common Platform Enumeration (CPE) IDs, Common Configuration Enumeration
(CCE) IDs and Common Vulnerabilities and Exposures (CVE) IDs. Results also
include severity indications using the Common Vulnerability Scoring System (CVSS)
specification, if applicable to the benchmark.
BMC Server Automation version 8.2 supports the following SCAP capabilities:
BMC Server Automation version 8.2 supports the following operating systems as
targets for SCAP Compliance Jobs:
Microsoft Windows XP, Windows 7, Windows Server 2003, and Windows Server
2008
XCCDF is an SCAP XML language for expressing security checklists. The source
data stream that BMC Server Automation uses for SCAP compliance scans must be
well-formed XCCDF. The result data stream that BMC Server Automation produces
is well-formed XCCDF.
The imported data stream appears as an SCAPBenchmark object in the BMC Server
Automation Console. Multiple SCAPBenchmarks are permitted to accommodate
usage of multiple XCCDF content sources and versions.
An SCAP Compliance Job produces an XCCDF results file compliant with the
XCCDF specifications.
OVAL content is imported into the BMC Server Automation Console as part of the
SCAP data stream. The import process validates the OVAL content against its
schema and captures validation errors in a log file which is accessible from the BMC
Server Automation Console.
The process then synthesizes the results file into a small-sized file and sends it to the
BMC Server Automation Application Server. The Application Server creates the
XCCDF results file from the collected results. By default, the process deletes the
OVAL result files from each target server; however, administrators can configure the
SCAP Compliance Jobs to retain those files.
Users can view the XCCDF results in the BMC Server Automation Console. They can
also export results from the Console to an XML file. The export includes a .xslt file
which enables a fully formatted view of the results in a web browser. In the browser-
displayed report, users can click a specific Benchmark rule to view details about the
rule, including OVAL IDs associated with the rule. Each listed OVAL ID is an active
link to the specific web page about that test on http://oval.mitre.org.
To view those results, from the GUI console, users export the XCCDF results to an
XML file. The export includes a .xslt file that enables a fully formatted view of the
results in a web browser. In the browser-displayed report, users can click a rule to
display details about that rule, including CPE nomenclature attached to the rule. The
In the XML results file, to identify BMC Server Automation as the benchmarking
tool, the <TestResult> element sets the test-system attribute to cpe:/
bmc:bsa:server:automation.
To view the impact-metric value associated with a rule, users perform the export
function from the GUI console, exporting the XCCDF results to an XML file. The
export includes a .xslt file that enables a fully formatted view of the results in a web
browser. In the browser-displayed report, users can click a specific Benchmark rule
to view details about the rule, including the CVSS impact-metric value assigned to
the rule by the Benchmark author. If a rule does not have an impact-metric value
assigned to it, then the CVSS field in the report is blank.
A benchmark can optionally define profiles, which are variations of rules for different
classes of servers.
For example, an SCAP Benchmark might include three profiles: one for production
servers, one for development servers, and one for testing servers. Password integrity
rules in the benchmark might have different tests for each of the profiles. The
production profile might require passwords that are 8 characters in length and
change every 3 months; whereas the testing profile might allow 4-character
passwords and not test for the frequency of changes.
You can obtain SCAP benchmark content from any source. A common source is the
NIST SCAP content website at:
http://scap.nist.gov/content/
Many other organizations and companies provide SCAP benchmark content, or you
can import custom content. Regardless of the source of the content, it must be well-
formed XML and validate without major errors. The import process creates a log file
of all validation errors.
The XCCDF file references the other files. To import a benchmark, you navigate to
the XCCDF file. The import process reads the XCCDF file and searches for any other
files referenced in the XCCDF file. All of the files comprising a benchmark must be in
the same folder for the import.
2 Make sure that all files referenced in the XCCDF file are present in the same
folder with the XCCDF file.
The following example shows two sets of SCAP content files ready for import.
The OVAL interpreter is installed automatically with the RSCD agent version 8.2 on
supported platforms. Existing installations must upgrade the RSCD agent to version
8.2 to obtain the OVAL interpreter.
The OVAL interpreter is bundled with the RSCD agent. No special actions are
required to install the OVAL interpreter.
Note
The blcontent.exe script included with BMC Server Automation includes sample
roles and authorization profiles for SCAP-specific activities. For more information
about blcontent.exe, see the BMC technical documentation at https://docs.bmc.com/
docs/display/bsa82/Loading+prepackaged+content.
A role with the following permissions can import and view SCAP benchmarks but
not delete them, and it does not have the ability to create SCAP Compliance Jobs:
DepotFolder.*
DepotGroup.*
XccdfBenchMark.Read
XccdfBenchmark.Create
ScapContentFile.Create
ScapContentFile.Read
A role with the following permissions can create SCAP Compliance Jobs:
DepotFolder.Read
DepotGroup.Read
XccdfBenchmark.*
SCAPContentFile.*
Server.*
ServerGroup.*
JobFolder.*
ScapComplianceJob.*
All SCAP content files that are referenced by the XCCDF file that you intend to
import must be in the same folder as the XCCDF file. For information, see
Obtaining SCAP benchmark content on page 1425.
1 Right-click a folder under the Depot folder, and select New > SCAP Benchmark.
2 The SCAP Benchmark wizard starts. Provide information in the wizard panels as
follows:
3 Click Finish.
If the import is successful, the new SCAP benchmark object appears in the BMC
Server Automation Console.
Field definitions
Select XCCDF file
The XCCDF file that defines the new benchmark. Click Browse to
navigate to the server and select the XCCDF file that defines the benchmark
you want to import. The import process imports all files, such as OVAL, CPE,
and patch files, that are referenced in the selected XCCDF file. All of the
referenced files must be in the same directory with the XCCDF file.
cpe-dictionary file
The cpe-dictionary file that defines the platform-specific information for the
benchmark. Typically, the wizard finds and supplies the name of the cpe-
dictionary file that is in the same directory as the XCCDF file that you
specified in the previous field. However, if you have more than one cpe-
dictionary files in the directory, you must provide the name of the file.
Save in
The Depot folder name where you want to save the imported benchmark object.
Note
The benchmark object name used by the BMC Server Automation Console is
an element in the XCCDF file and is typically supplied by the benchmark
author.
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
This procedure describes how to access the Application Server log using Live
Browse in the BMC Server Automation Console. Alternatively, you can access the
files in the server's native file system.
1 In the Servers folder, right-click the server that hosts the Application Server and
select Browse.
For example, using the default installation directory, the file path is:
4 Double-click appserver.log.
The XCCDF tab opens in the Content panel showing summary information about
the benchmark. All information comes from elements in the imported XCCDF file.
PlatformThe CPE identifier that describes the operating system platform for
which this benchmark is intended.
In the Jobs folder, you must have a subfolder to hold your SCAP Compliance Jobs.
To create a subfolder, right-click the Jobs folder and select New > Folder.
In the Depot folder, you must have an imported SCAP Benchmark that is
appropriate for the operating system of the target servers you plan to select in the
SCAP Compliance Job. To import a benchmark, see Importing SCAP content on
page 1428.
1 Right-click a folder in the Jobs folder and select New > SCAP Compliance Job.
Note
Other ways to create an SCAP Compliance Job are:
Right-click an SCAP benchmark in the Depot and select New > SCAP
Compliance Job.
Right-click a server in the Servers folder and select New > SCAP Compliance
Job.
2 Complete the panels in the SCAP Compliance Job wizard using the following
instructions:
3 Click Finish.
The job is saved in the Jobs folder. To open the job and view or edit it, right-click
the job name and select Open.
Field definitions
Name
Identifying name.
Description
Save in
Select if this job should always execute as if your current role and user are
scheduling the job. After you click this option, the job definition shows the
role:user combination under which the job executes.
Field definitions
XCCDF Benchmark
Specifies the SCAP benchmark to use in this job. The benchmark must
already exist in a folder in the Depot folder. For information, see Importing
SCAP content on page 1428.
Profile
Lists the profile names in the selected benchmark. Select a profile to use in
the scans initiated by this job. If you select No Profile - All rules selected, all
rules in the benchmark are evaluated.
Profiles are defined by the benchmark author. They are used to describe
multiple policies in a benchmark. For example, a single benchmark could use
profiles to define different policies for development, test, and production
systems. Some benchmarks do not have profiles.
Advanced Settings
Run Mode
Controls the type of result files produced by the OVAL interpreter and the
level of cleanup. Modes are:
Files from File retention and Certification modes are located here on each
target server:
<RSCD_install_dir>\RSCD\tmp\SCAPCompliance_nnn\...
For example:
C:\Program Files\BMC Software\BladeLogic\RSCD\tmp
\SCAPCompliance_2000001_96_localhost
\20000301-2000001_72cf9500-6f4f-4fb0
Controls the logging level of the OVAL interpreter. Levels are: Info (the
default), Debug, Warning, and Error. The log file is located on each target
server in the directory described previously for Run mode.
Controls the level of nesting that the OVAL interpreter traverses through to
retrieve and evaluate the members of a Windows group, such as Windows
Active Directory groups or local groups. Valid values are:
-1 Recurses through all levels, retrieving all members in the entire structure.
Use this value if you want to recurse through all levels.
0 Disables recursion. Member subgroups are not evaluated.
1 (the default) Recurses through the stated number of levels. The default (1) recurses one
through level, retrieving members through one level of nested subgroup.
255
Note
Higher levels that recurse through many subgroups to retrieve all members are
expensive in time and memory.
Field definitions
To select or remove target servers, use the arrows to move servers or server groups
between the Available Targets list and the Selected Targets list.
Available targets
Lists all managed servers and server groups that are not in the Selected
Targets lists.
Selected targets
Lists the servers that you have selected as targets for this job. Be sure to select
targets with operating systems that match the intended OS of the benchmark
that you selected. For example, a benchmark intended for Windows 2003
servers does not work on targets running Windows XP.
Default notifications can take the form of emails or SNMP traps. When a job
completes, an SNMP trap is sent to a specified server, where it can be read using
software that receives and interprets SNMP traps. Default notifications are sent
when you run a job immediately (that is, you do not schedule the job) or a scheduled
job completes but you have not set up email or SNMP notifications for that
scheduled occurrence.
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job
The Schedule tab lets you schedule a job so it can run one time, recur hourly,
daily, weekly, or monthly, or recur at some arbitrary interval. For more
information, see SCAP Compliance Job Scheduling on page 1438.
The Job Notifications tab lets you set up notifications that are generated when
a scheduled job runs. For more information, see SCAP Compliance Job
Scheduled Job Notifications on page 1437.
Notifications can take the form of emails or SNMP traps. When a job completes, an
SNMP trap is sent to a specified server, where it can be read using software that
receives and interprets SNMP traps.
Send email to
Lists email addresses of the accounts to notify when a job completes with the
status that you specify. Separate multiple email addresses with semicolons,
such as [email protected];[email protected]. After entering email address
information, check the statuses that cause an email to be generated.
Provides name or IP address of the server to notify when the job completes.
After entering server information, check the statuses that should cause an
SNMP trap to be generated.
Indicates email notifications should list all servers on which a job has failed.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job always executes at the time you specify. BMC Server
Automation automatically accounts for differences in time zones and changes in
daylight savings time. For example, if you schedule a job that should run weekly at
06:00 Eastern Standard Time, the job always runs at 06:00 Eastern Time, no matter
whether standard or daylight savings time is in effect.
When entering dates, use a yyyy/mm/dd format. When entering times, use a 24-
hour clock format (00:00 to 23:59).
To schedule jobs
To modify an existing schedule, select the schedule and click Edit Schedule .
2 Using Schedule tab, specify whether the job should run once or define a schedule
for a recurring job.
3 For Time Zone, select the time zone in which the job should run.
The Schedules panel lists the scheduled jobs frequency and the time for which it
is initially scheduled. The time includes the jobs time zone relative to Greenwich
Mean Time.
4 For Priority, select an execution priority level from the drop-down list (available
priority levels are Critical, High, Normal, Low, and Lowest).
Note that you cannot select a Priority level higher than the maximum runtime
level that is set for your role, which is indicated next to the drop-down list.
To set a property value back to its default value, click Reset to Default Value .
The value of the property is reset to the value it inherits from a built-in property
class. The Value Source column shows the property class from which the value is
inherited.
Depending on the type of property you are editing, you can take different actions
to set a new value, such as entering an alphanumeric string, choosing from an
enumerated list, or selecting a date.
To insert a parameter into the value, enter the value, bracketed with double
question mark delimiters (for example, ??MYPARAMETER??) or click Select
Property .
ACLs control access to all objects, including the sharing of objects between roles.
Using the Permissions panel, you can add individual permissions to an object. You
can also set permissions by adding ACL templates or ACL policies.
Adding an authorization
An authorization grants permission to a role to perform a certain type of action on
this object.
To add an authorization to this object, click Add Entry in the Access Control List
area. Then use the Add New Entry dialog box to specify the role and authorization
you want to add.
To add an ACL template to the job, click Use ACL Template in the Access
Control List area. Then use the Select ACL Template dialog box to specify an ACL
template that you want to add to this object.
To set the contents of the selected ACL templates so they replace all entries in the
access control list, check Replace ACL with selected templates. If you do not check
this option, the contents of the selected ACL templates are appended to existing
entries in the access control list.
To add an ACL policy to this object, click Use ACL Policy in the ACL Policies
area. Then use the Select ACL Policy dialog box to specify an ACL policy that you
want to add to the object.
To set the contents of the selected ACL policies so they replace all entries in the
access control list, check Replace ACL with selected policies. If you do not check
this option, the contents of the selected ACL policies are appended to existing entries
in the access control list.
You can open, change, save, and rerun SCAP jobs and view the job results in the
same way as any other BMC Server Automation job.
1 In the Jobs folder, right-click the SCAP Compliance Job name and select Open.
2 To view job information, click the tabs at the bottom of the opened job. To change
a field value, use the interface on the tabs to make the change.
3 To save a changed job, click in the job or on the job tab at the top of the content
view. Then select File > Save from the menu bar.
To allow the Job to run as scheduled on the Schedules panel in the Job, you do
not need to do anything.
To run the Job immediately, right-click the Job name in the Jobs folder, and
then select Execute.
To run the Job immediately against a different set of target servers from the set
defined in the saved Job, right-click the Job name in the Jobs folder, and then
select Execute Against. This command lets you choose the target servers for a
one-time run, and it does not change the targets specified in the saved Job.
When a Job is actively running, a line for it appears in the Tasks in Progress view.
2 To monitor Job progress as it executes, watch the Activity column in the Tasks in
Progress view.
When the Job disappears from the Tasks in Progress view, it is finished running.
view the server-specific OVAL results on each server if the option to save those files
was set at the time of the SCAP Compliance Job run.
State Description
BMC Server Automation collects the XCCDF results from the target servers and
makes those results available on the BMC Server Automation Console.
1 To see job results, right-click the job name in the Jobs folder, and select Show
Results.
Objects representing each run of the job appear in the Content View, identified by
the date and time of the run.
2 To see results of a specific job run, expand that job run object.
Each job run shows two views of the SCAP Compliance Job results:
Rules view Displays the results by checklist rule in the XCCDF benchmark.
Use this view to explore SCAP compliance for a specific rule across all targets
in the job run.
Server view Displays the results by target server name. Use this view to
explore SCAP compliance for a specific target in the job run.
3 Expand the Server view or Rules view. In the Server view, expand a target server.
The hierarchy of groups and rules contained in the XCCDF benchmark appears,
with partial descriptions.
Black entries indicate that all rules under the entry have a state of Pass.
Red entries indicates that at least one rule under the entry has a state other than
Pass. Click the entry to expand the hierarchy and find the non-compliant rules.
Note
The BMC Server Automation Console shows part of the description for each rule.
To see the entire text of the rules, you must export the results and open the
exported file in a web browser.
4 To see specific rules and their result states, continue to expand the entries until
you reach the lowest level in the hierarchy.
For information about exporting and opening an XCCDF results file, see Exporting
SCAP results on page 1447.
To view all security configuration issues and associated CCE IDs and descriptions
2 Expand Target Results using the down arrow on the right of the output.
The results shows one of nine states for each rule, including a value of Pass, Fail,
Error, and so on.
3 To see CCE IDs associated with a failed rule (or any rule), click on the rule.
The link goes to the Rules section of the report, which contains more information
about the rule, including CCE IDs referenced in the rule.
A web page from www.mitre.org opens that includes details about the CCE.
2 Expand target results using the down arrow on the right of the output.
The results shows one of nine states for each rule, including a value of Pass, Fail,
Error, and so on.
3 To see CVE IDs and patch IDs associated with a rule, click on the rule.
Note
The report shows this information only for rules with a result of Pass or Fail.
The link goes to the Rules section of the report, which contains more information
about the rule, including CVE IDs referenced in the rule.
A web page from www.mitre.org opens that includes details about the CVE.
A web page from the issuing vendor opens with details about the patch.
To indicate the relative severity of non-compliance, the exported results file shows a
value in either the CVSS score or the Weight field. In either case, the displayed value
originates in the source benchmark content.
To create detailed OVAL result files, an SCAP Compliance Job must be configured to
run in Certification mode or File Retention mode.
3 Click Advanced Settings, and change the Run mode setting to Certification mode.
5 To run the job, right-click the job name and select Execute.
This procedure describes how to access the result files by exporting them from the
target server to a location of your choice using a feature in the BMC Server
Automation Console.
1 In the Jobs folder, right-click the job and select Show Results.
2 Expand the Run of interest and then expand the Server view.
3 Right-click the target of interest and select Export Oval Interpreter Logs.
This option exports the detailed OVAL result and the OVAL log files.
4 Select the folder where you want to save the files, and click Export.
Note
If the SCAP Compliance Job was run in Default mode, there are no files to export.
If the SCAP Compliance Job was run in File Retention mode, some files are
available for export, but not the detailed OVAL results.
1 To access OVAL result files in the target server's native file system, navigate to
the following location:
<RSCD_install_dir>\RSCD\tmp\SCAPCompliance_nnn\...
For example:
From the BMC Server Automation Console, you can export the SCAP results to an
XML file, storing it in the location of your choice. The exported results file is an XML
file compliant with the XCCDF specification. The export includes an XSLT file in the
same directory as the XCCDF file, enabling a browser to display a human-readable
version of the XCCDF results.
1 Right-click the SCAP Compliance Job name in the Jobs folder and select Show
Results.
Two objects appear under the job run instance: the Rules View and the Server View.
3 Right-click one of the views and select Export SCAP Compliance Results.
a Select the server on which you want to store the exported file.
c To select a folder on the drive, double-click the drive name and continue to
double-click folder names to expand to the desired folder.
To export results for each server to a separate file, select the Split files checkbox.
To export results for all servers into the same file, clear the checkbox.
If the Split files checkbox is selected, the exported file names are in this
format: yourFileNameValue_serverName
If the Split files checkbox is cleared, the exported file name is in this format:
yourFileNameValue
2 Open the exported XML file in a web browser. You specified the file name in the
export process.
Note
If you move the exported XML file, make sure to move the XSLT file along with it.
The XSLT file name is xccdf.xsl.
4 Scroll to the right side of the browser window and click the down arrows to
expand sections of the report. Similarly, click an up arrow to contract a section.
Features
The SCAP analyzer combines information from both the XCCDF and the OVAL
result files for the selected target. The analyzer produces a customized XML report
that is unique to BMC Server Automation, and not compliant to any SCAP schemas.
The report includes:
The benchmark rules and the resulting OVAL state for each one.
Information about the state of the target system during the SCAP Compliance Job
Run.
The SCAP analyzer is available for SCAP Benchmarks for Windows, Linux, and
Solaris platforms.
Prerequisites
The SCAP analyzer examines the results of an SCAP Compliance Job. Before running
the SCAP analyzer, make sure that your results satisfy the following prerequisites:
The SCAP Compliance Job whose results you want to analyze must run in
Certification Mode. Certification mode retains the OVAL result and system
characteristics files, which are required by the SCAP analyzer.
The OVAL result and system characteristics files must be present on the target
server whose results you want to analyze at the time that you run the SCAP
analyzer. (Do not delete those files from the target server if you intend to run the
SCAP analyzer on that server's SCAP results.)
The target server must not be marked as failed or completed with warning in the
SCAP Compliance Job Run.
1 In the Jobs folder, right-click an SCAP Compliance Job and select Show Results.
3 In the Server View, right-click the server of interest and select Analyze.
Note
If the prerequisites are not met, an error message appears and the analyzer
process stops. Otherwise, the analyzer dialog appears.
4 In the dialog:
a Specify the output path for the SCAP analyzer report file. To save results
locally, accept the default path displayed in the dialog. To save results on
another computer, use the navigation features on the dialog to specify a NSH
path.
b In the file name field, type a name for the SCAP analyzer report file.
c In the file extension field, choose XML as the final file format. The system saves
an eXtensible Stylesheet Language (XSL) file along with the XML file in the
specified output path. You can open the XML results in a Web browser and the
browser transforms the file into a customized, formatted report as defined in
the XSL file.
Cancel the analysis using the Cancel button to the right of the progress bar.
Scoring Shows the total compliance score, copied from the XCCDF results file
Benchmark Details --- Shows information about the benchmark that was used in
the SCAP Compliance Job whose results are being analyzed
Group Rule Hierarchy --- Shows details about the benchmark's rule groups,
including the rules in each group
A navigation bar at the top of the report lets you go directly to each of the sections.
To navigate from the Group Rule Hierarchy section to the Rule Results section, click
a rule. The rule criteria tree in the definition table includes active links to the tests
table, and, for complex tests, active links exist between the rule table and the
definition table.
You can filter the report to show only passed rules or only failed rules. To filter, go
to the Scoring section in the report, click the Filter Result Type dropdown list, and
select a filter.
Rules, definitions, and tests that produced a status of Pass, Not Applicable, Not
Selected, Informational, or Not Checked appear in blue.
Rules, definitions, and tests that produced a status of Error, Unknown, or Fail
appear in red.
The tests table in the Rule Results section displays expected and actual settings on
the target, as follows:
When the criteria result has an OVAL state of Pass or Fail, the report shows the
expected and actual settings.
When the criteria result has an OVAL state of Error or Unknown, the report
shows the expected setting, but not the actual setting.
When the criteria result has an OVAL state of Not evaluated or Not applicable,
the report does not show the expected nor the actual setting.
If a rule result is Not Applicable, Not Checked, Not Selected, or Informational, the
report does not show a definition table for that rule.
1 Open the log file referenced in the SCAP import error message.
You cannot view the log file in the BMC Server Automation Console. Make a note
of the file name in the displayed error message and open the file on your
computer's file system.
2 Examine the log file to determine which SCAP component contains the error. (For
example, discover whether the error was reported against XCCDF, OVAL, or
CPE.)
3 Determine the nature of the error. Is the error an XML syntax error or an
incomplete file (for example, missing elements)?
The content was not fully downloaded from its original source location or was
corrupted during the download. You can download the content again.
The content was edited or corrupted after the download. You can attempt to
correct the error using the error messages in the import log file.
The original content contains an error. In this case, contact the content owner.
4 Take appropriate action to fix the error on the file system on which you originally
assembled the content.
Note
You cannot edit the content in the BMC Server Automation Console.
5 To delete the flawed SCAPBenchmark from the BMC Server Automation Console,
right-click the benchmark object in the Depot folder and select Delete.
6 To reimport the corrected SCAP content, right-click your SCAP folder in the
Depot and select New > SCAP Benchmark.
If the OVAL interpreter fails on one of the target servers, a red X icon appears with
the Job Run results to indicate that an error occurred.
2 Scroll in the log to find error messages. A message about a failed OVAL
interpreter contains the affected target server name.
3 In the BMC Server Automation Console, Live Browse the target server with the
failed process.
4 Examine the OVAL log file. The log file is in the same folder as the OVAL result
files:
<RSCD_install_dir>\RSCD\tmp\SCAPCompliance_nnn\...
For example:
The following topics provide general information about viewing job run results and
job logs in the BMC Server Automation Console.
1 In the Jobs folder, right-click the SCAP Compliance Job and select Show Results.
3 Scroll down in the Message panel, looking for errors. Errors are marked with a
red X.
4 Look for the following message. Note that the server name appears at the end of
the message. A separate message appears for each server that does not match the
benchmark's CPE definition.
Benchmark not applicable to the target:serverName
On UNIX, you can increase the number of file descriptors using the ulimit -n
command. The Application Server runs as bladmin on UNIX and inherits the current
ulimit values of root when it starts. An easy way to implement this change is to add
a ulimit -n command to the /etc/init.d/blappserv script.
This message might be due to insufficient root privileges for executing the OVAL
checks on the target server. The user account that runs an SCAP Compliance Job
requires root privileges on each target server in the job.
To check privileges mapped to user accounts, on the target server, use the BLCLI
agentinfo command or inspect the exports file.
When you audit Security Settings, BMC Server Automation displays the name that
Windows 2003 and 2008 use for the policy even though Windows 2000 may use a
different name for the same policy or the policy may not be available in Windows
2000. (One policy is not available in Windows 2003 and 2008, and in that case BMC
Server Automation uses the Windows 2000 name.) An audit does not show
inconsistencies even though names may be different between the different versions
of Windows. When an audit includes a policy that is not available for a servers
operating system, the local and effective settings for that policy are shown as Not
defined.
Audit: Shut down system immediately if unable to Shut down system immediately if unable to log
log security audits security audits
Devices: Allow undock without having to log on Not available
Devices: Allowed to format and eject removable media Allowed to eject removable NTFS media
Devices: Prevent users from installing printer drivers Prevent users from installing printer drivers
Devices: Restrict CD-ROM access to locally logged- Restrict CD-ROM access to locally logged-on user only
on user only
Devices: Restrict floppy access to locally logged-on Restrict floppy access to locally logged-on user only
user only
Devices: Unsigned driver installation behavior Unsigned driver installation behavior
Not available in Windows 2008.
Domain controller: Allow server operators to Domain controller: Allow server operators to
schedule tasks schedule tasks (Domain controllers only)
Domain controller: LDAP server signing requirements Not available
Domain controller: Refuse machine account Not available
password changes
Domain member: Digitally encrypt or sign secure Secure channel: Digitally encrypt or sign secure
channel data (always) channel data (always)
Domain member: Digitally encrypt secure channel Secure channel: Digitally encrypt secure channel
data (when possible) data (when possible)
Domain member: Digitally sign secure channel data Secure channel: Digitally sign secure channel data
(when possible) (when possible)
Domain member: Disable machine account password Prevent system maintenance of computer password
changes
Domain member: Maximum machine account Not available
password age
Domain member: Require strong (Windows 2000 or Secure channel: Require strong (Windows 2000 or
later) session key later) session key
Interactive logon: Display user information when the Not available
session is locked
Not available in Windows 2008.
Interactive logon: Do not display last user name Do not display last user name in logon screen
Interactive logon: Do not require CTRL+ALT+DEL Disable CTRL+ALT+DEL requirement for logon
Interactive logon: Message text for users attempting Message text for users attempting to log on
to log on
Interactive logon: Message title for users attempting Message title for users attempting to log on
to log on
Interactive logon: Number of previous logons to Number of previous logons to cache (in case domain
cache (in case domain controller is not available) controller is not available)
Interactive logon: Prompt user to change password Prompt user to change password before expiration
before expiration
Interactive logon: Require Domain Controller Not available
authentication to unlock workstation
Interactive logon: Require smart card Not available
Interactive logon: Smart card removal behavior Interactive logon: Smart card removal behavior
Microsoft network client: Digitally sign Digitally sign client communication (always)
communications (always)
Microsoft network client: Digitally sign Digitally sign client communication (when possible)
communications (if server agrees)
Microsoft network client: Send unencrypted Send unencrypted password to connect to third-
password to third-party SMB servers party SMB servers
Microsoft network server: Amount of idle time Amount of idle time required before disconnecting
required before suspending session session
Microsoft network server: Digitally sign Digitally sign server communications
communications (always)
Microsoft network server: Digitally sign Digitally sign server communication (when possible)
communications (if client agrees)
Microsoft network server: Disconnect clients when Automatically logoff users when logon time expire
logon hours expire (local)
Network access: Allow anonymous SID/Name Not available
translation
Network access: Do not allow anonymous Not available
enumeration of SAM accounts
Network access: Do not allow anonymous Additional restrictions for anonymous accounts.
enumeration of SAM accounts and shares Note: In Windows the following options are possible:
Note: Shows as Enabled and Disabled
None. Rely on default permissions
System objects: Strengthen default permissions of Strengthen default permissions of global system
internal system objects (e.g. Symbolic Links) objects (e.g. Symbolic Links)
System settings: Optional subsystems Not available
System settings: Use Certificate Rules on Windows Not available
Executables for Software Restriction Policies
User Account Control: Admin Approval Mode for Not available
the Built-in Administrator account
User Account Control: Allow UIAccess applications Not available
to prompt for elevation without using the secure
desktop
User Account Control: Behavior of the elevation Not available
prompt for administrators in Admin Approval Mode
User Account Control: Behavior of the elevation Not available
prompt for standard users
User Account Control: Detect application Not available
installations and prompt for elevation
User Account Control: Only elevate executables that Not available
are signed and validated
User Account Control: Only elevate UIAccess Not available
applications that are installed in secure locations
User Account Control: Run all administrators in Not available
Admin Approval Mode
User Account Control: Switch to the secure desktop Not available
when prompting for elevation
User Account Control: Virtualize file and registry Not available
write failures to per-user locations
User Rights Assignment: Access Credential Manager Not available
as a trusted caller
User Rights Assignment: Change the time zone Not available
User Rights Assignment: Create symbolic links Not available
User Rights Assignment: Increase a process working Not available
set
User Rights Assignment: Modify an object label Not available
Not available Unsigned non-driver installation behavior
Packaging content
All XML-based content format files adhere to the content.xsd XML schema provided
with BMC Server Automation (and stored in the installation directories). A typical
XML-based content format file contains definitions of and references to a range of
BMC Server Automation configuration objects, such as BLPackages and grammar
files. When you use a content format file during an export or import process, these
referenced files (commonly referred to as payload files) must be packaged together
with the content format file in a compressed ZIP file.
The ZIP packages are used during the version-neutral export and import processes,
which you can invoke through the BMC Server Automation Console or through the
BLCLI (using BLCLI commands from the ContentImportExport name space). The
ZIP packages are created automatically during export processes. You create your
own ZIP packages manually to introduce content that originated outside of the BMC
Server Automation system.
enumerations
ranges
lists
property classes
configuration objects
The following example presents a block of XML code at its highest level within a
content format file, with all subordinate nodes collapsed:
Note
Attribute values in the XML file are enclosed in quotation marks. Therefore, to
include a quotation mark within an attribute value, use the " character entity
reference to escape the markup-sensitive quotation mark character.
Operators node
In the operators node in the content format file, you list operators to make them
available for reference from other nodes.
Note
All listed operators reflect the current configuration; you cannot use the content
format file to define new operators or to modify the definitions of existing operators.
The following XML code presents an example of several operators under the
operators node. Each operator is identified by its ID; other definitions (name, short
name, and short ID) are optional.
<operators>
<operator name="between" id="between" short-name="between" short-
id="between"/>
<operator name="matches" id="matches" short-name="matches" short-
id="matches"/>
<operator name="has all flags" id="has all flags" short-name="has all
flags" short-id="has all flags"/>
</operators>
Grammars node
Under the grammars node in the content format file, you can list various grammar
files that are used to parse configuration objects (configuration files or extended
objects) so that they are available for referencing from within the specifications of
configuration objects elsewhere in the content format file.
Note
For built-in grammar files (with built-in="true"), grammar definitions merely
reflect the current configuration. For custom grammar files (with built-
in="false"), you can also use the content format file to define new grammar files or
to modify existing grammar files.
The following XML code presents an example of several grammar files listed under
the grammars node.
<grammars>
<grammar id="tomcat-users.xml.gm" built-in="true">
<description>grammar to parse tomcat users.xml</description>
</grammar>
<grammar id="inittab.gm" built-in="true">
<description>grammar for /etc/inittab file on UNIX</description>
</grammar>
</grammars>
Packages node
Under the packages node in the content format file, you can list various BLPackages
that are used in compliance rule remediation so that they are available for
referencing from compliance rules in policies or in the rules library.
Note
BLPackages that contain Depot objects are not supported. Do not include such
BLPackages under the packages node.
The following XML code presents an example of a BLPackage listed under the
packages node.
<packages>
<package id="SOX Compliance Content">
<description>Disable accounts after a number of logon attempts.</
description>
<path>/SOX Compliance Content/Remediation Packages</path>
<payload-path>blpackages\DS-5.3.7-2002366.1</payload-path>
<local-properties>
<property deprecated="false" editable="true" built-in="false"
required="false" used-in-report="false" id="MAX_ATTEMPTS"
type="Primitive:Integer">
<description></description>
<default>
<value>3</value>
</default>
</property>
</local-properties>
</package>
</packages>
The path element specifies the path to the BLPackage within the Depot folders in
BMC Server Automation.
The local-properties element, beginning in version 8.2, can use Boolean tests
for properties of Boolean type.
Types node
The types node presents various types of data used in BMC Server Automation as
accepted, for example, by rules, properties, or configuration objects.
The types node can contain the following data type nodes:
enumerations
ranges
lists
property-classes
configuration-objects
Note
For built-in data typesenumerations, property classes, and configuration objects
with built-in="true", as well as all primitivesdefinitions reflect the current
configuration; you cannot use the content format file to define new built-in data
types or to modify the definitions of existing built-in data types.
Primitives are the most basic data forms, such as those based on simple strings or
numbers. For each primitive, you specify an ID and a name, as well as a list of
operators supported by the primitive.
Note
If an operator uses a different data type for the right-hand-side operand (as
compared to the left-hand-side operand), that type appears in the rhs-type attribute
before the id attribute. If the rhs-type is List, the additional rhs-backing-type
attribute specifies the type of list (for example: Primitive:Decimal).
The following XML code defines a primitive data type named Decimal.
<primitives>
<primitive name="Decimal" id="Primitive:Decimal">
<operators>
<operator-ref id="greater than or equal to"/>
<operator-ref rhs-type="Range:Primitive:Decimal Range" id="between"/
>
<operator-ref id="equals"/>
<operator-ref id="does not equal"/>
<operator-ref rhs-backing-type="Primitive:Decimal" rhs-type="List"
id="is not one of"/>
<operator-ref rhs-backing-type="Primitive:Decimal" rhs-type="List"
id="is one of"/>
<operator-ref id="greater than"/>
</operators>
</primitive>
</primitives>
The enumeration data type enforces a choice of values from a closed list. The ID of
an enumeration always begins with the Enumeration: prefix.
<enumerations>
<enumeration name="ServiceErrorControlEnumeration"
id="Enumeration:ServiceErrorControlEnumeration" type="Primitive:String"
built-in="true">
<value name="IGNORE" id="IGNORE">IGNORE</value>
<value name="NORMAL" id="NORMAL">NORMAL</value>
<value name="SEVERE" id="SEVERE">SEVERE</value>
<value name="CRITICAL" id="CRITICAL">CRITICAL</value>
</enumeration>
</enumerations>
A range defines values between two points. Supported operators are listed for each
range. Currently, BMC Server Automation supports three ranges: Integer Range,
Date Range, and Decimal Range.
<ranges>
<range name="Integer Range" id="Range:Primitive:Integer Range"
type="Primitive:Integer">
<operators>
<operator-ref id="equals"/>
<operator-ref id="does not equal"/>
</operators>
</range>
<range name="Date Range" id="Range:Primitive:Date Range"
type="Primitive:Date">
<operators>
<operator-ref id="equals"/>
<operator-ref id="does not equal"/>
</operators>
</range>
<range name="Decimal Range" id="Range:Primitive:Decimal Range"
type="Primitive:Decimal">
<operators>
<operator-ref id="equals"/>
<operator-ref id="does not equal"/>
</operators>
</range>
</ranges>
The list data type accepts multiple values provided by the user. For each list you
specify the list type and provide a list of operators supported by the list.
Note
If an operator uses a different data type for the right-hand-side operand (as
compared to the left-hand-side operand), that type appears in the rhs-type attribute
before the id attribute. If the rhs-type is List, the additional rhs-backing-type
attribute specifies the type of list (for example: Primitive:Decimal).
<lists>
<list type="Class://SystemObject/Device">
<operators>
<operator-ref rhs-type="Class://SystemObject/Device" id="contains"/>
<operator-ref id="equals"/>
<operator-ref id="does not equal"/>
</operators>
</list>
<list type="Primitive:Encrypted String">
<operators>
<operator-ref rhs-type="Primitive:Encrypted String" id="contains"/>
<operator-ref id="equals"/>
<operator-ref id="does not equal"/>
</operators>
</list>
</lists>
The property-classes data type defines property classes as configured in the Property
Dictionary. For each property class, you provide a list of operators that are
supported by that property class, as well as an optional list of properties included in
the class.
Note
If an operator uses a different data type for the right-hand-side operand (as
compared to the left-hand-side operand), that type appears in the rhs-type attribute
before the id attribute. If the rhs-type is List, the additional rhs-backing-type
attribute specifies the type of list (for example: Primitive:Decimal).
The ID of a property class always begins with the Class: prefix, and includes the
full path to the property class within the Property Dictionary (for example: //
SystemObject/User).
<property-classes>
<class visible="true" deprecated="false" name="Class://SystemObject/User"
id="Class://SystemObject/User" built-in="true">
<description>Every User is an Instance of this Class</description>
<operators>
<operator-ref rhs-type="Primitive:String" id="not instance of"/>
<operator-ref rhs-type="Primitive:String" id="instance of"/>
<operator-ref id="equals"/>
<operator-ref id="does not equal"/>
</operators>
<properties>
<property deprecated="false" editable="false" built-in="true"
required="true" used-in-report="false" id="DEFAULT_ROLE" type="Class://
SystemObject/Role">
<description>Default Role</description>
</property>
<property deprecated="false" editable="false" built-in="true"
required="true" used-in-report="false" id="FAILED_LOGINS"
type="Primitive:Integer">
<description>Number of failed logins</description>
<default>
<value>0</value>
</default>
</property>
<property deprecated="false" editable="true" built-in="false"
required="false" used-in-report="false" id="MY_INTEGER_ENUM"
type="enumeration">
<description></description>
<enumeration type="Primitive:Integer">
<value name="intvalue1" id="intvalue1">1</value>
<value name="intvalue2" id="intvalue2">2</value>
</enumeration>
<default>
<value>1</value>
</default>
</property>
</properties>
</class>
</property-classes>
The configuration-objects data type defines extended objects, server objects, and
configuration files, as defined in the Configuration Object Dictionary.
<configuration-objects>
<extended-objects>
<extended-object id="Groups">
<description></description>
<grammar-data grammar-ref="ini.gm" os="Windows" encoding="Default"/>
<command remote-execution="false">blquery $server:host$ -E "/C/
Program Files/BMC Software/BladeLogic/ 8.0/share/sensors/extended_objects/
groups.blq"</command>
</extended-object>
</extended-objects>
<server-objects>
<class root="false" version="1" name="Extended Object" id="Extended
Object" built-in="true">
<properties>
<property name="Path" id="Path" type="Primitive:String"/>
<property name="Name" id="Name" type="Primitive:String"/>
</properties>
</class>
</server-objects>
<configuration-files>
<configuration-file id="??TARGET.WINDIR??/desktop.ini">
<grammar-data grammar-ref="ini.gm" os="Windows" encoding="Default"/>
<path>??TARGET.WINDIR??/desktop.ini</path>
</configuration-file>
</configuration-files>
</configuration-objects>
The following XML code presents an example of a single data instance of one
property class under the data-instances node.
<data-instances>
<class-ref id="Class://SystemObject/DataStore/Pxe DataStore/Local
DataStore"/>
<instance id="LocalDataStoreInstance">
<description>OOB local Instance</description>
<property id="BROKEN_OBJECT">
<value>false</value>
</property>
<property id="NAME">
<value>LocalDataStoreInstance</value>
</property>
<property id="FULL_PATH">
<value>Non-Applicable</value>
</property>
<property id="LOCATION">
<value>Non-Applicable</value>
</property>
<property id="VIRTUAL_DIR">
<value>Non-Applicable</value>
</property>
</instance>
</class-ref>
</data-instances>
The following XML code presents an example of two rules within the rule librarya
discovery signature and a compliance rule.
<rule-library>
<rule id="Template Signature" service="Imported Template">
<expression><![CDATA[>
exists("Directory:??INIT_ORA_HOME??")) AND
((??TARGET.OS?? is one of ["HP-UX", "Windows"]) OR
(??TARGET.AGENT_STATUS?? != "agent is not licensed"))
]]></expression>
</rule>
<rule id="Property Condition" description="Compliance rule with Property
Condition" ref-number="1.0.0" service="Imported Template">
<notes>Checks Property Conditions</notes>
<expression><![CDATA[>
(??ORACLE_SOFTWARE_OWNER?? is one of ["ORA_DBA", "ORA DBA", "ORA"])
AND
((??TEST_INTEGER?? > 5) OR
(??TEST_INTEGER?? > 100)) AND
(??ORACLE_HOME?? starts with "/D")
]]></expression>
<remediation-package action="Do not remediate" />
</rule>
</rule-library>
For the syntax of references to rules in the rule library, see the sample code in
Policies node on page 1475.
Services node
A service entity in the content format file represents most of the definitions of a
component template. Each defined service corresponds to a single component
template in the BMC Server Automation console.
Note
The definitions of the compliance rules associated with a component template are
represented separately in the content format file as policy entities.
Under the services node, individual services are grouped under folders, which
correspond to component template groups. The service ID is used internally in the
file for associating other objects, such as entities, to services.
The following XML code shows the basic format of the services node.
<services>
<folder name="Component Template Group">
<service id="internal_service_id">
<notes>notes for service</notes>
</service>
</folder>
</services>
For each service, you can choose to include the following nodes of service definitions:
allowed-operations
configuration-objects
properties
local-properties
parts
signature
Allowed-operations node
This node lists allowed operations for a component template, as defined on the
General panel of a component template in the BMC Server Automation Console.
<allowed-operations>
<operation id="Discover"/>
<operation id="Snapshot"/>
<operation id="Audit"/>
<operation id="Deploy"/>
<operation id="Compliance"/>
<operation id="Allow_Remediation"/>
<operation id="Allow_Auto_Remediation"/>
</allowed-operations>
Configuration-objects node
This node defines local configuration objects for a component template, as defined
on the Local Configuration Objects panel of a component template in the BMC
Server Automation Console. Configuration objects include extended objects, server
objects, and configuration files.
<configuration-objects>
<extended-objects>
<extended-object id="Groups">
<description></description>
<grammar-data grammar-ref="ini.gm" os="Windows" encoding="Default"/>
<command remote-execution="false">blquery $server:host$ -E "/C/
Program Files/BMC Software/BladeLogic/8.0/share/sensors/ extended_objects/
groups.blq"</command>
</extended-object>
</extended-objects>
<server-objects>
<class root="false" version="1" name="Extended Object" id="Extended
Object" built-in="false">
<properties>
<property name="Path" id="Path" type="Primitive:String"/>
<property name="Name" id="Name" type="Primitive:String"/>
</properties>
</class>
</server-objects>
<configuration-files>
<configuration-file id="??TARGET.WINDIR??/desktop.ini">
<grammar-data grammar-ref="ini.gm" os="Windows" encoding="Default"/>
<path>??TARGET.WINDIR??/desktop.ini</path>
</configuration-file>
</configuration-files>
</configuration-objects>
Properties node
This node defines properties assigned to the component template, not including
local properties. The following XML code defines one property.
<properties>
<property id="AUTO_GENERATED">
<value>true</value>
</property>
</properties>
Local-properties node
This node defines local properties assigned to the component template, as defined on
the Local Properties panel of a component template in the BMC Server Automation
Console.
<local-properties>
<property deprecated="false" editable="true" built-in="false"
required="false" used-in-report="false" id="MY_INTEGER_ENUM"
type="enumeration">
<description></description>
<enumeration type="Primitive:Integer">
<value name="intvalue1" id="intvalue1">1</value>
<value name="intvalue2" id="intvalue2">2</value>
</enumeration>
<default>
<value>1</value>
</default>
</property>
<property deprecated="false" editable="true" built-in="false"
required="false" used-in-report="false" id="TEST_INTEGER"
type="Primitive:Integer">
<description></description>
<default>
<value>10</value>
</default>
</property>
</local-properties>
Parts node
This node defines the server objects that make up the component template, as
defined on the Parts panel.
<parts>
<part id="File:??EXTPROC_HOME??/extproc.exe">
<notes>My part notes</notes>
<item>
<type>File</type>
<path>??EXTPROC_HOME??/extproc.exe</path>
</item>
<allowed-operations>
<operation id="Discover"/>
<operation id="Snapshot"/>
<operation id="Audit"/>
<operation id="Compliance"/>
</allowed-operations>
<includes-excludes recurse-subfolders="true"/>
</part>
<part id="Windows Service:BladeLogic RSCD Agent">
<notes></notes>
<item>
<type>Windows Service</type>
<path>BladeLogic RSCD Agent</path>
</item>
<allowed-operations>
<operation id="Browse"/>
<operation id="Snapshot"/>
<operation id="Audit"/>
<operation id="Compliance"/>
</allowed-operations>
<includes-excludes recurse-subfolders="true"/>
</part>
</parts>
Signature node
This node defines the component signature used in discovery, as defined on the
Discovery panel. You can instead refer to a signature defined in the rule library.
<signature>
<rule name="Template Signature" service="xml test service">
<expression><![CDATA[??TARGET.OS?? is one of ["AIX", "Linux", "HP-UX",
"Windows"]]]></expression>
</rule>
</signature>
The following XML code presents an example of two service instances associated
with one service under the service-instances node.
<service-instances>
<service-ref id="xml test service">
<instance id="oracle1">
<description></description>
<property id="NAME">
<value>oracle1</value>
</property>
<property id="DESCRIPTION">
<value>oracle1 description</value>
</property>
<property id="ORACLE_HOME">
<value>/C/Program Files/Oracle</value>
</property>
<property id="PATH">
<value>My Path</value>
</property>
</instance>
<instance id="oracle2">
<description></description>
<property id="NAME">
<value>oracle2</value>
</property>
<property id="DESCRIPTION">
<value>null</value>
</property>
<property id="ORACLE_HOME">
<value>/D/Program Files/Oracle</value>
</property>
</instance>
</service-ref>
</service-instances>
Policies node
A policy is a group of compliance rules associated with a service. The rules within
the policy may be nested within folders, which correspond to rule groups in BMC
Server Automation.
Note
In the content format file, multiple policies can be associated with a single service. In
BMC Server Automation, on the other hand, each component template has only one
set of compliance rules. Therefore, during an import to BMC Server Automation,
each policy is associated with a single component template and the policy groups
together all compliance rules defined for that component template.
The following XML code presents an example of a policy under the policies node
that contains several rules. Two rules are included in a folder named Basic
Conditions, one without a remediation action defined and the other with a
remediation action. Another folder named Referenced Rules contains several
referenced rules, which refer back to the rule library.
<policies>
<folder name="Component Template Group">
<description>Description of Component Template Group</description>
<policy id="component_template" service="associated_service_id">
<description>Description of Component Template</description>
<rules>
<folder name="Basic Conditions" ref-number="1.0"
name="CONFIGURATION_ITEMS">
<rule name="Rule 1" ref-number=""
service="associated_service_id">
<description>Description of Rule 1</description>
<notes>Notes for Rule 1</notes>
<expression><![CDATA[??TARGET.OS?? contains "Windows"]]></
expression>
<remediation-package action="Do not remediate"/>
</rule>
<rule name="Rule 2" ref-number=""
service="associated_service_id">
<description>Description of Rule 2</description>
<notes>Notes for Rule 2</notes>
<expression><![CDATA[
"Configuration File Entry:/etc/login.defs//PASS_MAX_DAYS"."Value1 as
Integer" less than or equal to "??PASS_MAX_DAYS??"
]]></expression>
<remediation-package allow-auto-remediation="false" package="/
SOX Compliance Content/Remediation Packages/SOX RedHat Linux"
action="Remediate">
<properties>
<property id="PASS_MAX_DAYS">
<value>??PASS_MAX_DAYS??</value>
</property>
</properties>
</remediation-package>
</rule>
<description>Description of Basic Conditions rule group</
description>
<notes>Notes for Basic Conditions rule group</notes>
</folder>
<folder name="Referenced Rules" ref-number="2.0"
name="CONFIGURATION_ITEMS">
NAME
AGENTLESS_MANAGED_OBJECT_ICON_FILE*
AGENTLESS_MANAGED_OBJECT_PROXY_HOST*
AGENT_BUILD_VERSION*
AGENT_CONNECTION_TIMEOUT
AGENT_MAJOR_VERSION*
AGENT_MINOR_VERSION*
AGENT_PATCH_VERSION*
AGENT_PLATFORM*
AGENT_QUEUE_WAIT_TIMEOUT
AGENT_STATUS
AIX_SECURITY
AIX_UPDATE_TYPE*
ALLOWED_OPERATIONS*
APAR
APPLICABLE_COMP_ID
APPLICATION_TYPE*
NAME
APPROVAL_TYPE_ID
APP_ML
APP_SERVER_IP
ARCHITECTURE
ATRIUM_SYNC_ENABLED*
AUDIT
AUDITED_OBJECT
AUDIT_TRAILS*
AUTO_CLOSE
AUTO_GENERATED
BASE_DN*
BLSEPARATOR
BL_ACL*
BL_AUTH
BL_AUTH_ENUM
BL_PATCH_ID*
BOOT_SERVER
BOOT_SERVER*
BOOT_SERVER_CGI_BIN_PATH*
BOOT_SERVER_CGI_BIN_URL*
BOOT_SERVER_DOCUMENT_ROOT_PATH*
BOOT_SERVER_FULL_PATH
BOOT_SERVER_URL*
BROKEN_OBJECT
BUILD_ENVIRONMENT
BULLETIN_ID
BULLETIN_ID*
BUNDLE
BY_PHASE_ALL_HOST_MUST_PASS_COMMIT
CABLE_TYPE
CATEGORY_TAGS
NAME
CHANGED_ITEM_TOTAL
CHANGE_ID
CHANGE_TIMING
CHANGE_TYPE
CHARSET*
CLUSTER
COMMAND
COMMAND_ARGUMENT
COMMAND_INTERFACE
COMMAND_ORDER
COMMAND_TYPE
COMMENTS
COMMIT_MAX_PARALLEL_TARGETS*
COMPLIANCE_JOB_RESULT_COMPONENT_NAME*
COMPONENT
COMPONENT*
COMPONENTS*
COMPONENT_HEADER_NAME
COMPONENT_VERSION
CONFIG_SERVER
CONFIG_SERVER_FULL_PATH
CONFIG_STORE
CONFLICTS
CONNECTION_DOMAIN
CONNECTION_PASSPHRASE
CONNECTION_PASSWORD
CONNECTION_URL
CONNECTION_USER
COPY_LOCKED_FILES
CREATED_DATE
CREATION_CHANGE_REQUEST_ID
NAME
CREATION_SERVICE_REQUEST_ID
CREATION_TASK_ID
CREATION_TEMPLATE_TYPE
CURRENT_ROLE
CURRENT_ROLE_AUTH_NAMES
CUSTOMER
CUSTOM_OBJECTS_ENVIRONMENT*
CVE_ID*
CVE_IDENTIFIERS
CVE_IDS*
C_PARTITION_SIZE*
DATA_FILE_DESTINATION*
DATA_STORE
DATA_STORE_IP
DATA_STORE_PASSWORD
DATE_CREATED
DATE_MODIFIED
DATE_POSTED*
DEBUG_MODE_ENABLED*
DEFAULT_ROLE*
DEFAULT_VALUE
DEF_GATEWAY
DEPENDENCY_LIST
DEPLOYNAME
DEPLOYPATH
DEPLOY_ALLOW_NFS_DURING_SUM
DEPLOY_JOB_NSH_CMD_TIMEOUT
DEPLOY_JOB_TYPE
DEPLOY_JOB_URL_COPY_TIMEOUT
DEPLOY_OPTIONS_INSTANCE_FOR_REMEDIATION
DEPLOY_URL_TYPE
NAME
DEPOT_FILE_ID*
DESCRIPTION
DEVICE
DEVICE_ID*
DISABLED
DISPLAY_NAME
DNS_SERVER
DNS_SERVER2
DOMAIN_NAME
ENABLE_SINGLE_JOB_MODE
END_ML
END_TIME
ENHANCEMENT
EQUIVALENT_PATCHES
ERRATA_ADVISORY*
ERRATA_SEVERITY*
ERRATA_TYPE*
EVENT_DATE*
EXECUTE_TYPE
EXECUTION_ROLE
EXECUTION_TASKS
EXECUTION_USER
EXIT_CODE*
EXPIRY_DATE
EXTRA_ITEM_TOTAL
FAILED_LOGINS*
FILESETS
FILESET_ID
FILESET_PACKAGE*
FIXED_COMP_ID
FLOW_CONTROL
NAME
FOLLOW_SYMLINKS_ON_URL
FQ_HOST
FULL_PATH
GLOBAL_FLAGS*
GROUP*
GROUPS*
HAD_ERRORS
HAD_ERRORS*
HAD_WARNINGS
HAD_WARNINGS*
HIPER
HOME_DIR_PATH
HOST
HOSTIP_BITS
HOSTNAME
HOTFIX_TYPE*
IDRAC_HOST*
IDRAC_PASSWORD*
IDRAC_USER_NAME*
IGNITE_SERVER
IGNORE_COPY_ON_BOOT_FILES
IMPACT
INCLUDED_IN_MAINT_LEVEL
INCLUDED_IN_SP
INCLUDED_IN_UPDATE
INSTALLED_SERVERS*
INSTALL_COMMAND*
INSTALL_SERVER
INSTALL_SERVER*
INSTALL_SERVER_CGI_BIN_PATH*
INSTALL_SERVER_CGI_BIN_URL*
NAME
INSTALL_SERVER_DOCUMENT_ROOT_PATH*
INSTALL_SERVER_FULL_PATH
INSTALL_SERVER_URL*
INTERACTION_TYPE
INTERIM
IP_ADDRESS
IS_ABORTED
IS_ALLOWED_IN_ACL
IS_ALLOW_ROLLBACK
IS_ATTEMPTED
IS_ATTEMPTED*
IS_AUTH_PROFILE
IS_AUTO_DISABLE*
IS_AUTO_ROLLBACK
IS_CANCELLED
IS_CHANGES_DETECTED*
IS_COMMIT_ENABLED
IS_COMPLETED
IS_COMPONENT_SPECIFIED*
IS_DEPLOYABLE
IS_DIRECT_DEPLOYMENT*
IS_ENABLED*
IS_ENABLED_ADK_AUTH*
IS_ENABLED_LDAP_AUTH*
IS_ENABLED_PKI_AUTH*
IS_ENABLED_SECUR_ID_AUTH*
IS_ENABLED_SRP_AUTH*
IS_INCOMPLETE
IS_OBSOLETE*
IS_ONLINE
IS_PKG_BEING_CONVERTED*
NAME
IS_PWD_EVER_EXPIRED*
IS_RECOMMENDED*
IS_RECONFIGURE_REBOOT
IS_REPEATER
IS_RESET
IS_RUNNING
IS_SCHEDULED
IS_SECURITY*
IS_SERVER_SPECIFIED*
IS_SHAVLIK_XML_COPIED*
IS_SIMULATE_ENABLED
IS_SOLARIS_LIVE_UPGRADE*
IS_STAGING_INDIRECT
IS_SYNCHRONIZABLE*
IS_TARGETS_MODIFIED*
IS_TRANSIENT*
IS_USED_IN_REPORTS*
IS_VALID*
IS_VIRTUAL*
ITEM_ID*
ITEM_NAME*
ITEM_RECONFIGURE_REBOOT_OPTIONS
JOB
JOBRUN
JOB_LOG_ITEMS*
JOB_NAME
JOB_PART_TIMEOUT
JOB_RESULT
JOB_RESULT*
JOB_RESULTS*
JOB_RESULT_COMPONENTS*
NAME
JOB_RESULT_DEVICES*
JOB_RESULT_ID*
JOB_RESULT_PROPERTY_NAME*
JOB_RUN
JOB_RUNS*
JOB_TIMEOUT
JPA_JAVA_HOME*
JPA_JVM_ARGUMENTS*
JPA_JVM_LIB*
LANGUAGE_ID*
LAST_ACTIVE_DATE*
LAST_FAILED_LOGIN_DATE*
LAST_PWD_CHANGE_DATE*
LAST_UPDATED_DATE
LATE_BINDING_IP
LDAP_ATTRIBUTE*
LDAP_FILTER*
LIFECYCLE*
LINUX_USERS_FILE_ENTRY
LOCATION
LOCATION*
LOGGING_LEVEL
LOG_DATE
MAC_ADDRESS
MAC_ADDRESS_CD
MAINTENANCE_LEVEL
MAXCACHESIZE
MAXIMUM_ALLOWED_RUNTIME_JOB_PRIORITY*
MAX_PACKAGE_SIZE
MAX_PARALLEL_PER_VM_HOST*
MESSAGE
NAME
MIN_SP
MISSING_ITEM_TOTAL
MS_OFFICE_INSTALL_LOCATION
MS_OFFICE_INSTALL_PWD
MS_OFFICE_INSTALL_USERNAME
NAME
NETBOOT_KERNEL
NETWORK_ADDRESS
NETWORK_CONFIG
NETWORK_PAYLOAD_LOCATION
NET_DEVICE
NET_SETTINGS
NIM_MASTER
OBJECT_NAME
OBJECT_TYPE
OBSOLETE
ON_EDGE
OS
OS_ENUMERATED_VALUE*
OS_PATCHLEVEL
OS_PLATFORM
OS_RELEASE
OS_VENDOR
OS_VERSION
OVERWRITE_READONLY_FILES
OWNER
PARALLEL_PROCS*
PARAMETER_FLAGS
PARAMETER_ID
PARAMETER_NAME
PASSWORD
NAME
PATCH_LANGUAGE
PATCH_TYPE*
PAYLOAD_LOCATION
PE
PLATFORM
PM_STATE*
POLICY_BL_ACL
POLICY_MODE*
PORT
PREREQUISITES
PRESERVE_STAGING_DIR_ON_FAILURE
PRINCIPAL
PRIORITY*
PRODUCT
PRODUCT_MANUFACTURER*
PRODUCT_NAME*
PRODUCT_VERSION*
PROGRESS_STATUS
PROGRESS_STATUS*
PROMPT_RUNTIME_ARGUMENTS
PTF
PUSH_ACL_NO_USERS_FLAG
QNUMBER*
QUICK_LAUNCH
Q_NUMBER
RBAC_ACES
REBOOT_OPTIONS
REBOOT_TYPE
RECOMMENDED
RECONCILIATION_ID
RECONCILIATION_IDENTITY*
NAME
REF_NUMBER
REGISTER_COM_COMPONENTS
REGISTER_COM_COMPONENTS_FOR_UNDO*
RELEASE_DATE
RELEASE_DATE*
REPEATER_MAX_CACHE_SIZE
REPEATER_NAME
REPEATER_STAGING_DIR
REQUIRED
REQUIRES_REBOOT
REQUIRES_REBOOT*
REQUIRES_REBOOTS
RESET_JOB_ON_FAILURE
RESOLVES_HOSTNAME
RESULTS_RETENTION_TIME
RISK_LEVEL
ROLE
ROLES*
ROLE_CREATED
ROLE_MODIFIED
ROLE_NAME
ROLLBACKPATH
ROOT_PASSWORD
RPM_BUILD_DATE*
RPM_LICENSE*
RSCD_DIR
RSCD_VERSION
SEARCH_SCOPE*
SECURITY
SECURITY_LEVEL
SERIAL_NUMBER
NAME
SERVER*
SERVER_HEADER_NAME
SESSION_TYPE
SEVERITY_RATING
SIMULATE_MAX_PARALLEL_TARGETS*
SKIP_COPY_SOURCE_TO_UNDO*
SNAPSHOT_NAME
SOFTWARE_PATCH_STATUS_FLAGS*
SOFTWARE_PAYLOAD_EXISTS_AT_URL_FLAG*
SOFTWARE_TYPE*
SOLARIS_ALTERNATIVE_BOOT_ENV*
SOURCE_DEPOT_OBJECT
SP
SPL_AWARENESS
STAGINGDIR
STAGING_DIR
STAGING_DIR_PATH
STAGING_MAX_PARALLEL_TARGETS*
START_TIME
STATE
STATUS
STRING_DELIMITER
SUBNET_MASK
SUBSCRIPTIONS
SUB_JOBS*
SUCCESS
SUPERSEDED_BY*
SUPERSEDES
SYSTEMROOT
SYSTEM_PACKAGE_TYPE*
TARGET
NAME
TARGET*
TASK_ID
TEMPLATE
TEMPLATE*
TEMPLATE_BL_ACL
TEMPLATE_OBJECT_ID*
TRANSACTIONS_DIR
TYPE
TYPE*
UNBUNDLED
UNDO_MAX_PARALLEL_TARGETS*
UNINSTALL_COMMAND*
UNREGISTER_COM_COMPONENTS_FOR_COMMIT*
UNREGISTER_COM_COMPONENTS_FOR_UNDO*
UPDATE_LEVEL
URGENCY
URL
USERNAME
USERS*
USER_CREATED
USER_MODE
USER_MODE_OPTIONS_UNIX_ONLY
USER_MODIFIED
USER_NAME
USER_RECOMMENDATION
USE_ALL_VERSIONS
USE_DELIM
USE_FOR_SERVICE_CONTEXT*
USE_HEADERS
USE_LATEST_CLASSES
UUID
NAME
VENDOR
VENDOR_IDENTIFIER
VENDOR_IMPACT*
VENDOR_NAME*
VERSION
VGPACKAGE_TYPE_ID*
VGP_GUEST_ENVIRONMENT*
VGP_GUEST_OS_ID*
VGP_GUEST_OS_VERSION_ID*
VGP_MEMORY_IN_MB*
VGP_NO_OF_PROCESSORS*
VGP_TYPE_ID*
VIRTUALIZATION*
VIRTUAL_DIR
VIRTUAL_ENTITY_CONNECTION
VIRTUAL_ENTITY_CONTAINER
VIRTUAL_ENTITY_GUEST_OS*
VIRTUAL_ENTITY_ID
VIRTUAL_ENTITY_MANAGER
VIRTUAL_ENTITY_MEMORY_IN_MB*
VIRTUAL_ENTITY_NO_OF_CPUS*
VIRTUAL_ENTITY_RESOURCE_POOL*
VIRTUAL_ENTITY_TYPE
VMWARE_CLUSTER*
VMWARE_DATASTORE*
VMWARE_TOOLS_STATUS*
VM_HOST
VM_VIRTUAL_MACHINE
VM_WS_PWD
VM_WS_URL
VM_WS_USERNAME
NAME
VRMF*
WINDIR
WINDOW_TYPE
WITHDRAWN
ACL policy
A list of roles that have been granted permissions in the form of system authorizations,
command authorizations, authorization profiles, and ACL templates. ACL policies can be
managed from a central location. Any changes made to the policy automatically take effect on
any objects where the policy has been applied. Like an ACL template, an ACL policy lets you
develop complex set of permissions that can be easily applied to system objects.
ACL template
A list of roles that have been granted permissions in the form of system authorizations,
command authorizations, and authorization profiles. By defining an ACL template, you can
grant a complex set of permissions that are not associated with any particular object. Then,
when defining permissions for a role or system object, you can add the ACL template to the
permissions for that role or system object.
Active Directory
The Microsoft directory service, which provides a centralized system for automating
management of networked entities, such as applications, files, printers, and users.
AD/Kerberos authentication
Glossary 1495
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
The approach BMC Server Automation uses for authentication based on Active Directory and
Kerberos.
AES
Advanced Encryption Standard (AES). An encryption algorithm that has become the
encryption standard used in most commercial transactions.
agent
Another term for RSCD agent. The agent is a small software program that must be installed
and running on each remote server that BMC Server Automation accesses.
agent ACL
An access control list that controls user access and permissions on RSCD agents. Running an
ACL Push Job automatically generates an agent ACL for designated servers. On the agent, the
ACL is enforced by the servers operating system.
AMO proxy
A server that is equipped with a custom configuration object that can communicate with an
agentless managed object (AMO).
Application Server
A program that controls how client applications communicate with remote servers. Not only
does the Application Server manage communication between clients and servers, it also
controls the systems interaction with the database, file, and mail servers and is used for the
unattended provisioning of operating systems onto servers.
asymmetric encryption
A method of encryption that uses public and private keys. The public key, known to everyone,
is used to encrypt data, and the private key, known only to the recipient of the data, is used to
decrypt that data.
audit
The process of comparing servers to determine how configurations may differ. When an audit
reveals a difference between servers, you can deploy software and server objects to correct the
discrepancy.
audit trail
A record of who has sought authorization for specific actions in BMC Server Automation.
authentication
The process of determining whether users really are the people they declare themselves to be.
authentication profile
A collection of information that a BMC Server Automation client (BMC Server Automation
Console, Network Shell, or the BLCLI) uses to specify the environment where a session
credential should be obtained.
Authentication Service
A service that is responsible for authenticating a BMC Server Automation user and issuing a
session credential to the user. Typically, an authentication service is implemented within the
BMC Server Automation Application Server, but for BMC BladeLogic Decision Support for
Server Automation, the authentication service stands alone.
authorization
A permission granted to a role to perform certain actions. You can grant system authorizations
and command authorizations. A system authorization is a permission to perform a specific
type of action in BMC Server Automation, such as DepotObject.Read, which lets you read
depot objects. A command authorization is a permission to perform a specific Network Shell or
nexec command.
authorization profile
A group of authorizations for actions in BMC Server Automation. You can assign authorization
profiles to a role, an ACL template, or an ACL policy.
automation principal
A technique for defining a user credential that can be used for accessing external systems. The
most typical use for automation principals is Windows user mapping on page 1516.
Automation principals can also be used for accessing Active Directory servers.
Glossary 1497
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
B
bare metal
A term describing a computer that has not yet been provisioned with an operating system.
basic condition
The most common building block within a signature or compliance rule of a component
template. A basic condition analyzes configuration objects in either of the following ways:
Evaluates properties by comparing them with constant values or with other properties.
Batch Job
A type of job that runs a concatenated series of jobs.
blasadmin
A command that starts the Application Server Administration console, a command line
interface for setting Application Server options. The Application Server Administration console
is sometimes referred to as the blasadmin utility.
BLCLI
The BMC Server Automation command line interface (CLI).
BLPackage
A bundle of configuration assets that can be reliably deployed to multiple remote hosts. A
BLPackage consists of an instruction set and any required files needed for implementing
configuration changes. You create a BLPackage by selecting components, software, or server
objects or by using various mechanisms that automatically bundle assets. After you have
created a BLPackage, you can use a Deploy Job to install it on remote servers.
browse
The act of viewing a server in the Servers folder. When you right-click the entry for a server in
the Servers folder and select Browse from the pop-up menu, a tab appears in the content
editor. On the left side of the tab, you see a hierarchical tree that consists of multiple nodes.
Each node represents a different category of information for that server, including the servers
live state, which shows all server objects and components on the server.
C
cardinality condition
A type of basic condition that you can define within a signature or compliance rule of a
component template. This type of condition checks for the existence or number of occurrences
of a configuration object (such as a service or a certain type of installed software).
certificates
Digital documents used for secure authentication of communicating parties. A certificate binds
identity information about an entity to the entity's public key for a certain period. Certificates
can be thought of as analogous to passports that guarantee the identity of their bearers.
checksum
A numerical value based on the number of bits in a file. Audits can be based on checksums.
When checksum values differ, the data being compared is not identical.
CLI
The BMC Server Automation command line interface. Using the CLI, you can perform most
procedures available in the BMC Server Automation Console.
client
A machine running the BMC Server Automation Console, the BLCLI, or Network Shell. A
client establishes contact with a server by means of the RSCD agent installed on the server.
COM+
Microsofts technology for developing Component Object Model (COM) and Microsoft
Transaction Server (MTS) applications.
Glossary 1499
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
commit phase
A phase of a Deploy Job. During the commit phase, the system applies a package to a server.
Compliance Job
A job that compares component parts to compliance rules defined in a component template
and provides a mechanism for remediating any discrepancies.
compliance rules
A set of rules you define as part of a component template. To enforce compliance rules, you can
run a Compliance Job, which compares a subset of the component parts to the compliance
rules. Compliance rules can range from simple requirements like the presence of a particular
server object to complex conditions based on multiple component parts and properties. Each
compliance rule can specify a BLPackage that can be used to remediate failures detected by a
Compliance Job.
component
A managed object that provides a higher level of abstraction than other server objects. Using
components, you can manage applications rather than the server objects that make up those
applications. For example, a component can specify the files, configuration entries, and registry
values needed to support an Apache server, WebLogic, or Oracle.
component template
The server objects, properties, signature, compliance rules, and other information that together
make up the definition of a component. To create a component, you must use a component
template to discoverthat is, associatea component template with a server.
conditional construct
configuration files
Files used for either of the following:
Defining permissions that determine which clients and users have access to RSCD agents.
BMC Server Automation configuration files also control how communication occurs
between Network Shell and the BMC Server Automation Console and RSCD agents running
on servers and how logging is performed. The primary BMC Server Automation
configuration files are the users, exports, and secure files.
content editor
The primary area of user interaction in the BMC Server Automation Console. The content
editor displays tabs that show information related to items selected in the hierarchical tree on
the left.
custom command
A user-definable command that allows you to launch a script or executable program on a
designated server.
D
data store
A repository for operating system installation files and other types of files needed to provision
servers.
deploy
The process of pushing content to remote servers. Most deployments are based on a Deploy
Job, which can deploy BLPackages and software packages. You can also use a File Deploy Job
to copy files and directories.
Depot
A central repository for all BLPackages, software packages, scripts, and files a system
administrator typically uses.
deprecate
Any of the following actions:
Glossary 1501
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
The decision to stop ongoing support for certain types of functionality. BMC Server
Automation continues to support deprecated functions in limited contexts to allow for
backward compatibility. In a future release BMC Server Automation will stop all support
for deprecated functionality.
The removal of a property, custom property class, or instance from the Property Dictionary
even though that item is being used elsewhere in BMC Server Automation. A deprecated
item still exists but it is no longer displayed in the Property Dictionary. After it is
deprecated, you cannot create another property, custom property class, or instance with the
same name.
discovery
The process of creating a component by associating a component template with a server.
distinguished name
An LDAP entry that identifies a user for an LDAP server. A distinguished name consists of the
name of an entry as well as the names of the objects above that entry in the LDAP directory.
Those objects are listed from bottom to top. For example, a distinguished name might be
CN=admin, CN=Users, DC=sub1, DC=kerbtest, DC=bladelogic, DC=com.
DN
An LDAP distinguished name.
Domain Authentication
An approach to authentication that is based on AD/Kerberos authentication. Domain
Authentication only requires a user to provide a name, domain, and password when logging
on. This information is passed to the Authentication Service, which delegates user
authentication to the Active Directory domain controller.
domain controller
A role assigned to a server in a network of computers running the Windows operating system.
In Windows, domains are used to manage access to network resources. A user can access
network resources by logging into the domain.
dry run
An option for deploying server objects that simulates the actions taken during a deployment
without actually performing those actions. A dry run can help determine what server objects
will be changed during a real deployment.
E
effective authorization
The combination of role-based and object-based authorizations that determine the actions a
role can actually perform on a system object. A role can only perform an action on an object
when that action is authorized at both the role level and the object level.
encryption
The conversion of data into a form called cipher text that cannot be easily understood by
unauthorized individuals. Decryption is the process of converting cipher text back into its
original form so it can be understood.
ESX server
A VMware ESX server.
Execution Task
A job-management object associated with an individual job to keep track of its multiple job
runs. The Execution Task grants you control over the execution schedule and choice of target
servers without modifying the definitions of the original job. Through the Execution Task you
can define separate job schedules for different target servers and coordinate job schedules with
upcoming maintenance windows on the various servers.
exports file
A BMC Server Automation configuration file that sets access permissions for client machines
that communicate with a server. With the exports file you can also establish global user
permissions.
extended object
A custom object that can present information not included in a standard implementation of
BMC Server Automation. After creating an extended object, you can use the system to browse,
snapshot, and audit its contents, just as you would any other server object.
Glossary 1503
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
F
failover
A mode of operating in which a secondary component takes over the functions of a primary
component when the primary component cannot function.
file server
A server used by BMC Server Automation to store large snapshots of files, Network Shell
scripts, BLPackages, patches, Windows installables, and other types of information not easily
stored in a database.
flow control
An option for controlling the behavior of a Deploy Job. Using flow control, you can instruct a
Deploy Job to proceed as far as it can for each server included in the job or to complete one
phase of a deployment on all servers before proceeding to the next phase.
folder
Term used for any of the following:
A functional area within the BMC Server Automation Console, such as the Jobs or
Components folder. The left side of the console provides access to all folders.
A collection of unique objects; each object in a folder can only occur in one place. You can
create folders in the Depot, Component Templates, and Components folders.
G
grammar files
Files capable of parsing data presented in standard formats and generating output in a format
consistent with other textual data. Although grammar files have multiple applications in BMC
Server Automation, they are primarily used to present configuration file data for various
operating systems.
group
A collection of system objects or references to system objects. In groups, system objects are not
necessarily unique; the same object can occur in more than one group. You can create groups in
the Servers and Components folders.
I
indirect deployment
A type of deployment that uses an intermediate machine serving as a repeater. Using an
indirect deployment, you can deploy a package to multiple servers simultaneously.
Infrastructure Management
A console view that displays information about the Application Server and the services it uses
to support BMC Server Automation. From the Infrastructure Management window you can
also set up the Application Server to communicate with remote servers through one or more
SOCKS proxy servers.
intrinsic property
A type of property that is derived from the nature and configuration of a system object, such as
a server or job.
J
job definition
The set of instructions that are in effect for a particular job run. You can change job definitions
for each job run.
job part
A portion of a job. The BMC Server Automation Application Server breaks some types of jobs
into parts so it can process those parts in parallel.
job run
A job that has been executed at a particular time on one or more servers. There may be many
job runs for a single job.
job-level time-out
A property assigned to jobs that specifies a maximum period of time for a job to run before it is
automatically canceled.
Glossary 1505
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
K
Kerberos
A cross-platform mechanism for mutual authentication between a client and server or between
two servers before a network connection is opened between the two. The Kerberos protocol
uses strong cryptography so a client can prove its identity to a server (and vice versa) across an
insecure network connection. After a client and server have used Kerberos to prove their
identity, they can encrypt all of their communications to assure privacy and data integrity. The
BMC Server Automation implementation of Kerberos is based on MITs Kerberos v5.
keystore
A file used to store a list of trusted X.509 certificates.
L
LDAP
Lightweight Directory Access Protocol (LDAP). The LDAP protocol is used for querying and
modifying directory entries that are arranged in a hierarchical, tree-like structure.
LHS operand
local properties
Properties that can be assigned to a single BLPackage, component template, or system package.
Local properties differ from regular properties because they do not appear in the Property
Dictionary and they are not available globally.
log4crc file
A BMC Server Automation configuration file that controls logging so that all events are logged
using consistent formats.
loop
An expression within a compliance rule of a component template that enables the iterative
analysis of conditions or conditional constructs on a group of configuration objects.
M
master
The server configuration used as the basis of an audit. A master can be a live server,
component, or snapshot of a server or component.
N
Network Shell
The BMC Server Automation cross-platform shell with full scripting capability that gives
seamless access to remote servers.
nexec command
A command you can execute in Network Shell that is not native to Network Shell.
no access node
A system object that you can see in a BMC Server Automation Console but you cannot interact
with because you do not have the appropriate permissions.
NTFS
NT File System. One type of file system for Windows operating systems.
Glossary 1507
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
O
object permissions template
An ACL template assigned to a role. Authorizations in the object permissions template are
automatically assigned to any object created by a role.
out-of-band reboot
A required reboot that is caused by an external instruction in the install or uninstall command
for a software package or by an external command in a BLPackage. The reboot is not caused by
the BMC Server Automation deployment process.
P
parameter
A variable representing a property in BMC Server Automation. When a parameter is used, the
value of a referenced property is determined using local information when the parameter is
processed.
patch
A term that refers collectively to operating system and application fixes that are typically
downloaded over the Internet. Individual platforms and vendors may use other terms to refer
these fixes, such as RPMs and hotfixes.
payload
A patchs installable file. A patch payload is not downloaded until you need to package the
patch or you specifically choose to download the payload.
permission
Authorization to perform an action on a system object or class of system objects. In BMC Server
Automation, permissions must be defined for all system objects.
perspective
A configuration of views, tab groups, and editors. By default, the BMC Server Automation
Console opens to the Classic perspective. The Classic perspective contains the Folders view, the
Properties view, Permissions view, and Audit Trail view tab group, the Tasks in Progress view,
and a space (upper right quadrant) reserved for content editors.
PKI
policy based-objects
A BMC Server Automation object that is created according to organizational policies.
Component templates, BLPackages, and server object-based Audit and Snapshot Jobs are policy-
based objects.
post-command
A command that executes after a deployment ends.
pre-command
A command that executes before a deployment begins.
privilege mapping
The process of assuming an effective user identity and a set of user permissions on remote servers.
property
A symbolic representation of information that is likely to change from object to object in BMC
Server Automation, such as the path to an installation directory on a server. You can assign
properties to most objects.
Property Dictionary
A master list of all properties that can be assigned to system objects in BMC Server
Automation.
proxy mode
A method of using Network Shell to connect to a remote server via a Network Shell Proxy
Server rather than connecting directly to the remote server.
Glossary 1509
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
The keys used for encrypting and decrypting messages sent over a network. Private keys are
secret and known only to their owners. They are used for signing and decrypting messages.
Public keys, which are publicly available, are used for validating signatures and encrypting
messages. Public and private keys are mathematically dependent but the private key cannot be
derived from the public key.
A method for authenticating a sender or encrypting a message sent over a network. In public
key cryptography, the encryption and decryption of messages is done with two different keys,
a public key and a private key.
A collection of mechanisms that together allow network users to exchange data securely over a
network. Public key infrastructure consists of a certificate authority, certificate repositories
(directories), and other mechanisms needed to authenticate, encrypt, and decrypt
communication using public key cryptography. BMC Server Automation provides an approach
to user authentication based on PKI.
PXE
Pre-boot Execution Environment. A protocol that allows Intel-based computers to boot up
without access to a hard drive or boot diskette.
PXE server
A BMC Server Automation component used for the unattended provisioning of operating
systems onto servers.
R
raw iron
A term describing a computer that has not yet been provisioned with an operating system.
RBAC
See role-based access control.
reconfiguration reboot
A type of reboot sometimes required for Solaris servers for some new hardware and software
patches.
remediation
The process of correcting the configuration of a server or component. Patching and Compliance
Jobs can perform remediation when a server or component does not match a standard
configuration.
remediation package
A BLPackage that is automatically created when you remediate a Compliance Job failure for a
target component. A remediation package contains all the items in each BLPackage that are
supposed to be deployed for each compliance rule failure.
repeater
An intermediate host that receives data from a source and pushes it to multiple destinations.
RHS operand
role
A set of authorizations that reflect the responsibilities of an organizational entity, such as QA
engineers, application developers, or web administrators. A user can have many roles, but a
user can only assume one role at a time. Roles are defined using the RBAC Manager.
RSA SecurID
See SecurID.
RSCD agent
A small software program that must be installed and running on each remote server that BMC
Server Automation accesses.
Glossary 1511
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
S
secadmin utility
A BMC Server Automation utility that allows you to configure the secure file on a particular
machine.
secure file
A BMC Server Automation configuration file that defines how client and server machines
communicate.
A protocol for integrating secure password authentication into networked applications. SRP is
the default approach to user authentication in BMC Server Automation.
securecert file
A BMC Server Automation configuration file that stores encrypted password information
needed to access the private key for X.509 certificates. By storing private key passwords in the
securecert file, BMC Server Automation can access those passwords without any need for user
interaction.
SecurID
RSAs authentication protocol based on two-factor authentication.
server
In the BMC Server Automation context, a machine where an RSCD agent is installed.
server object
The files, software, packages, services, and other constituent elements of a server. BMC Server
Automation presents all of these elements as objects you can browse, snapshot, audit, and deploy.
service URL
The identity and address of a BMC Server Automation Application Service or Network Shell
Proxy Service that can be accessed using a session credential.
session credential
A credential issued to a BMC Server Automation client application after a successful user login.
BMC Server Automation clients use session credentials to establish secure sessions with BMC
Server Automation Application Servers and Network Shell Proxy Servers.
session key
A key used for encrypting and decrypting traffic during a communication session. Session keys
are symmetric, meaning the same key is used to encrypt and decrypt data. Because symmetric
encryption is fast and asymmetric encryption is slow, asymmetric encryption is used only to
encrypt a session key. After the session key is decrypted, it is used for symmetric encryption of
all subsequent communication during a session.
SHA1
The most commonly used function in the Secure Hash Algorithm (SHA) family of
cryptographic hash functions. A hash function like SHA1 takes a long string as input and
produces a fixed-length string as output. This output is sometimes called a digital fingerprint.
SHA1 is used for many security applications and protocols, including TLS.
signature
A set of criteria that must be satisfied for a component to be discovered on a server. A
signature may be as simple as the presence of a certain application, or it may involve
sophisticated tests, such as determining whether a server has a particular active listening port.
simulate phase
An optional phase of a Deploy Job. During the simulate phase, the system performs a dry run
of a deployment.
single sign-on
The capability for users to cache session credentials so they can be used to secure subsequent
sessions between client-tier applications and the Application Server or Network Shell Proxy
Server. As long as the session credential is valid, the user does not have to authenticate again.
single-job mode
A server state in which only one Deploy Job can run at a time. After a Deploy Job starts
running on a server in single-job mode, other Deploy Jobs targeting the same server must wait
until the Deploy Job running in single-job mode completes.
single-user mode
A minimal UNIX environment typically used when installing or removing software. To run in
single-user mode, a server must also be running in single-job mode.
Glossary 1513
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
smart group
A group with contents that are determined by a set of membership conditions. Any system
object with properties meeting those conditions is automatically added to the smart group. In
smart groups, system objects are not necessarily unique; the same object can occur in more than
one group or smart group.
snapshot
A record of how a server is configured at a point in time. Snapshots allow administrators to
audit the configuration of servers and deploy files and software to correct discrepancies.
Snapshots can be based on components or specified server objects.
software package
An executable file and any associated commands needed to install and uninstall software
unattended. After you have packaged software, you can use a Deploy Job to install it on remote
servers.
stage phase
A phase of a Deploy Job. During the stage phase, BMC Server Automation typically delivers a
package to a target server or repeater without applying the package to the server.
state
A group of classifications for Deploy Jobs. A Deploy Job can be in any of the following states:
Succeeded, Incomplete, Running, Failed, or Reset.
synchronized push
A type of File Deploy Job that allows you to specify criteria, such as changes to modification
dates, that qualify a file to be copied. Using a synchronized push can minimize the amount of
data carried over a network.
system object
Any object that you interact with in the BMC Server Automation Console. Servers, jobs, depot
objects, system packages, and many other objects are system objects.
system package
A collection of instructions needed to install an operating system and perform additional
configuration on a server.
T
tab group
Two or more views that appear in a tabbed notebook format called a tab group. You can move
the views together as a single unit or move each view independently of the others in the tab group.
TFTP server
A server that downloads the bootstrap program needed to initiate the BMC Server Automation
provisioning process.
time-out
A maximum period of time that can elapse before a job or job part is automatically canceled.
You assign properties to jobs that specify time-out values for the job or for job parts.
two-phase push
A type of push that is segmented into two phases. In a two-phase push, the second phase of the
push does not proceed unless the first phase successfully completes on a minimum number (or
percentage) of hosts.
U
unattended installation
An installation that does not require user interaction. Sometimes called a silent installation.
UNC
Glossary 1515
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
undo
The act of rolling back a deployment to a server.
V
view
A logical grouping of information, objects, and actions in the console for ease of navigation and
increased productivity.
virtual machine
A machine configuration that is created logically within another server.
virtual server
The guest operating system, running on a virtual machine that constitutes a server running
within another server.
W
Windows user mapping
The process of mapping a BMC Server Automation role to a local or domain user on a
Windows server. Windows user mapping allows an RSCD agent to temporarily assume the
privileges of a user on a Windows server.
X
X.509
A standard for defining digital certificates.
Index
ACLs
avoiding common mistakes 239
%f macro 550 filters when displaying summary 238
%h macro 550 for files 345
for one or more system objects 235
for property classes 159
A for registry keys 345
for system objects 117, 231, 239
aborting previewing 242
jobs 621 pushing to agents 240, 242, 243
about job priority 609 pushing to servers 242
access control setting up for roles 213
enforcing 172 viewing a summary for an object 236
managing 165 action on failure
overview 165 in BLPackages 526
system package sharing 1331 Active Directory
understanding 165 browsing 341
access control list templates 184, 189 custom configuration objects 565
access control lists defined 1495
for files 345 synchronizing with RBAC 227, 229
for one or more system objects 235 Active Node view 104
for property classes 159 activity view
for registry keys 345 of jobs 638
for system objects 117, 230, 231, 239 AD/Kerberos authentication
viewing a summary for an object 236 defined 1495
ACL policies Add Install Client script
adding a maintenance window 192 Solaris system package 1304
creating 169, 189 add_install_client command
modifying 195 customizing 1304
ACL Push Jobs administrative tools 977
creating 243 configuring servers for repeaters 990
modifying 251 custom commands 977, 978, 981
ACL Summary view 236, 238 infrastructure management 997, 1001
ACL templates SOCKS proxy servers 982
creating 169, 184 troubleshooting 1017
modifying 189 AES
defined 1496
agent ACLs
pushing during provisioning 1239, 1274, 1286,
1306, 1316, 1329
pushing to agents 240, 242, 243
setting up for roles 213
understanding 240
Index 1517
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
BLPackages 477
adding custom actions 541
B adding external commands 539
adding files 541
backgrounding operations 77 adding local properties 532
backup options adding payloads 543
for deploying files 781 adding to Depot 509
baselines 650 caveats 721
basic conditions closing an edited package 549
defined 1498 commenting out assets 548
in compliance rules 389, 390, 396 creating asset groups 545
in signatures 376, 377, 396 creating from components 470
basic configuration creating from snapshot results 671
AIX system package 1311 creating RPM groups 544
HP-UX system package 1323 deleting objects while editing 535
Linux system package 1247, 1257 deploying 713, 721
Solaris system package 1299 deploying to multiple components 726
VMware system package 1268, 1280 deploying to remediate compliance results 442,
Windows system package 1222 467, 469
Batch Jobs 803 editing 517, 521523, 525, 527530, 533535
creating 803 exporting 118, 120
including in Provision Jobs 1213 finding and replacing text in instruction file 536
modifying 813 importing 118, 123
viewing results 814 importing assets into 539, 541
begin script Map Missing 132
Solaris system package 1305 opening for edit 520
BL Editor overview 480
editing text files 79 packaging a component 470
viewing text files 79 replacing file content 543
bladduser utility 251, 252 setting action on failure 526
BLAdmin user 174, 177 tracking deployments 772
adding 252 verifying 548
BLAdmins role 174 BMC Preferences
BLPackage Deploy Jobs 724 Display Options 86, 87
creating 718 File Deploy Options 87
default values for 754 Live Browse Results Option 88
deploying security settings 753 Paging Options 88
modifying 754
Index 1519
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index 1521
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index 1523
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
directories
backup options when deploying 781
copying and pasting 343 E
deleting 344
discovery editing BLPackages 517
of components 375, 425 adding custom actions 541
disk partition adding external commands 539
HP-UX system package 1324 adding files 541
Linux system package 1245, 1256 adding local properties 532
Solaris system package 1297 adding payloads 543
VMware system package 1267, 1277 changing file ownership attributes 528
Windows system package 1219 changing network-based software deploy
Display Options for BMC Preferences 86, 87 options 527
Distribute Configuration Objects Jobs changing object attributes 521
creating 583 changing object properties 530
modifying 583 closing a package 549
docking a view 70 commenting out assets 548
domain controller creating asset groups 545
defined 1502 creating RPM groups 544
DOS scripting cutting and pasting 534
in system package 1219 defining action on failure 526
Downloading patch payloads 11041108 deleting an object 535
dragging and dropping 100 finding text 536
importing assets 539
moving objects within 533
opening a BLPackage 520
ordering by dependency 535
providing password information 535
replacing file content 543
replacing text 536
setting a reboot 525
setting single user mode 523
verifying an object 548
working with soft links 522
editing component templates 371
browsing 381
compliance 384
discovery 375
general information 373
install and uninstall 415
local configuration objects 414
local properties 412
parts 374
snapshots and audits 382
editors
BL Editor 79
content editor 64
selecting 83
setting preferences 82
ShellEd 80
working with 78
email notification options
for Execution Tasks 631
for Snapshot Jobs 661
encoding
of characters 79, 80
entries F
in configuration files 57
ESX fdisk partitions 1308
system package for 1276 Solaris X86 1308
ESX servers File Deploy Jobs 773, 1084
configuring properties 323 global deployment options 782
ESXi modifying 790
provisioning 1382 pre/post commands 783
ESXi 4.1 File Deploy Options for BMC Preferences 87
system package for 1266 file deploys 773, 1084
exceptions backup options 781
to compliance rules 434, 464 global deployment options 782
excludes list 365, 656, 683, 690, 846 indirect push 779
for component templates 364 pre/post commands 783
Execute on approval 311, 737, 788, 799, 810, 847, synchronized push 778
1126 file ownership attributes
execution overrides changing in BLPackage 528
for jobs 616 file paths
Execution Tasks rules for entering 56
creating and fully defining 625 file properties
creating through jobs 624 security 345
deleting job runs 637 viewing 345
email notification options 631 file servers 650
executing 635 files
for managing job runs 624 adding to Depot 556, 557
general settings 626 backup options when deploying 781
modifying 633 configuration 570, 574
overriding job properties 627 copying and pasting 343
permissions 632 deleting 344
properties 632 editing 79, 80
schedules 628 exporting 118, 120
targets 627 grammar 570
viewing history 635 importing 118, 123
Explorer perspective 67 filters 63, 73, 74
export finding system objects with broken dependencies
of Audit Job results 675, 710 115
of Compliance Job results 471 fixed-column tables
of Snapshot Job results 675, 710 customizing 96
exporting 120 folder content
exporting objects 118 organizing 104
extended objects 339, 559, 560, 578
creating icons 581
creating or modifying 577
exporting 118, 120
grammars for creating 570
importing 118, 123
external changes
removing 670
tracking 668
Index 1525
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
folders groups
adding 359 copying, cutting, and pasting 112, 113
adding groups or folders 104 creating 104, 106, 107
adding smart groups 104 deleting 113
Component Templates 40, 101
Components 40, 101
copying, cutting, and pasting within 104 H
creating 104, 107
cutting and pasting 112, 113 Help Desk perspective 67
deleting 113 history
Depot 41, 102 viewing for jobs 637
Devices 41, 102 hotfixes
in BMC Server Automation 101 adding to Depot 496, 498
Jobs 41, 102 deploying 718
organizing content 104 modifying 505
RBAC Manager 103 HP-UX
Servers 40, 103 bundles 482
Folders view 101 patches 482
Depot folder 102 products 482
Devices folder 102 HP-UX provisioning
Jobs folder 102 overview of 1152
RBAC Manager folder 103 HP-UX system package
Search 103 basic configuration 1323
Servers folder 103 boot script 1328
formatting columns 98 computer settings 1324
disk partition settings 1324
Ignite commands/scripts 1327
G Ignite parameters 1328
network settings 1326
General panel post-install script/agent install 1329
for Compliance Rule Editor 388 software selection 1328
Gentoo pre-installation image Hyper-V
skipping during provisioning 1183 specifying in Windows system package 1234
getting started 43, 51 hypervisors
Authentication Profiles 44 Red Hat KVM 1406
BMC Server Automation 46 Red Hat Xen 1407
changing passwords 55
logging on 46
session credentials 52 I
stored certificates 53
switching roles 54 IBM
global deployment options creating a Virtual Guest Job 879
for deploying files 782 IBM frame
global menu bar browsing 911
description 62 managing 910
global toolbar 62 IBM Frame
grammar files 570 managing 913, 917
importing 126 icons
in content format files 1464 defining 581
Group Explorer tables iDRAC device
customizing 96 booting from local ISO 1403
Index 1527
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index 1529
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index 1531
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Q
Quick Access 63
Index 1533
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
roles scripts
assigning users 216 adding to Depot 301, 549, 551, 553
authorizations for 166 exporting 118, 120
creating 170 importing 118, 123
modifying 218 modifying 554
permissions for 166 using properties to reference 1414
pre-packaged 174 viewing and editing 555
rollback files 715, 740, 746, 770 SCSI controller 1236, 1238
routing rules 1013 Search
assigning SOCKS proxy servers to 1006 Folders view 103
creating 984 searching for objects 106
creating complex rules 1016 secure remote password
deleting 1015 defined 1512
evaluating job execution rules 1000 security
evaluating repeater rules 1009 BMC Server Automation 39
for determining repeater server 992 for files 345
for job execution 997 security settings
re-ordering 1015 editing 530
viewing 1013 effective 509
RPM groups in BLPackages 509, 753
in BLPackages 544 limitations when deploying 753
RSCD agents 35 local 509
installing during provisioning 1239, 1274, 1286, viewing 345
1306, 1316, 1329 selecting editors 83
Rule Definition panel server groups
for Compliance Rule Editor 389 smart 108
rule groups server objects 339
for component compliance 387 adding to component templates 362
rules copying and pasting files and directories 343
conditions within 389 creating for repeaters 991
creating or editing 389 creating for SOCKS proxy servers 983
defining in a content format file 1470, 1475 deleting files and directories 344
for component compliance 387389, 411 for snapshots and audits 650
for routing to remote servers 984 included in Snapshot Jobs 655
operand data types 402 listing 560
operators 402 managing 342
rules view modifying in component templates 363, 374
of Compliance Job results 461 snapshots of 652
running operations in background 77 starting and stopping services 344
using jobs to manage custom 582
viewing 344
S server tier
of BMC Server Automation 36, 38
SCAP 1448 server view
SCAP analyzer 1448 of Compliance Job results 461
Schedule Till Completion 629
Scheduled Job Notifications 422, 809, 1099, 1125, 1138,
1437
schedules 454, 845
viewing for jobs 644
Scheduling Jobs 455, 594, 602, 663, 691, 810, 1098, 1125,
1138
Index 1535
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index 1537
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
testing users
compliance 411 assigning roles 216
compliance rules 407 BLAdmin 177, 252
component discovery 379 creating 170, 220, 252
text files creating without RBAC 252
adding to Depot 556 file 240, 242
viewing and editing 79, 80 modifying 226
text filters 73 pre-packaged 174, 177
TFTP server RBACAdmin 177, 252
configuring 1204 synchronizing with Active Directory 227, 229
starting and stopping 1206 synchronizing with LDAP 229
time-outs synchronizing with LDAP servers 227
for Deploy Jobs 751 users.local file 240
for jobs 644 using filters to limit objects 73
job part 644, 646
job-level 644, 646
toolbars V
quick tour 65
tracking internal and external changes 668 validation, of components 433
Transactions directory 715, 770, 771 values
TRANSACTIONS_DIR server property 770 for properties 161
troubleshooting tools 1017 version-neutral import and export 1461
types of preconfigured perspectives 67 viewing dependencies 117
viewing keyboard shortcuts 94
views 63, 64, 67
U accessing 70
detaching from perspective 70
unattended entries maximizing 71
Windows system package 1236, 1238 minimizing 71
UNC moving and docking 70
defined 1515 navigating 69
undo opening 70
files 746 preconfigured 67
for a Deploy Job 768 reattaching to the perspective 71
for a remediation job 466 restoring 71
Unified Agent Installer 273, 287 tab group 70
uninstall jobs 762 working with 68
UNIX virtual environments
objects 561, 564 Citrix XenServer 1405
Update Server Properties Jobs 325 contents of the Live node 858
Updates list IBM frame 910
Patching AIX 1048 IBM Frame 917
Upgrade Model Objects Jobs managing Solaris Zones 907
creating 590 Microsoft Hyper-V 914
modifying 590 monitoring compliance 892
URL syntax overview 853
for network data transmission 492 supported platforms 854
user impersonation 169 Xenserver 923
user mapping 169
user privilege mapping 169
Index 1539
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z