BMC Server Automation User Guide

BMC Server Automation User
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.
United States and Canada

Address BMC SOFTWARE INC Telephone 1 713 918 8800 Fax 1 713 918 8000
2101 CITYWEST BLVD or
HOUSTON TX 77042-2827 USA 1 800 841 2031
Outside United States and Canada

Telephone +01 713 918 8800 Fax +01 713 918 8000
Copyright 2002-2012 BladeLogic, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are
registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in
other countries. All other BMC 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.
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.
Linux is the registered trademark of Linus Torvalds.
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.
Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHEDRIGHTS RESERVED
UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data
and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR
Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS
252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101
CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.
Customer support
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
Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or
send an e-mail message to customer_support@bmc.com. (In the subject line, enter SupID:yourSupportContractID, such
as SupID:12345). Outside the United States and Canada, contact your local support center for assistance.
Before contacting BMC

Have the following information available so that Customer Support can begin working on your issue immediately:
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)
product error messages

messages from the operating system, such as file system full
messages from related software
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
ContractsPasswordAdministration@bmc.com.
(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 password@bmc.com.
(Asia-Pacific) Contact your BMC sales representative or your local BMC office.
4 BMC Server Automation User Guide

Contents
Chapter 1 Introduction 31
Introduction to BMC Server Automation ...................................................................31
Documentation conventions .........................................................................................32
References to online documentation ............................................................................33
Chapter 2 BMC Server Automation overview 35

BMC Server Automation components .........................................................................35
System architecture ........................................................................................................36
Access control ..................................................................................................................38
BMC Server Automation system security ...................................................................39
Folder overview ..............................................................................................................39
Chapter 3 Getting started with server automation 43

BMC Server Automation authentication process .......................................................43
Preparation for user logons ...........................................................................................44
Setting up an authentication profile .............................................................................44
Starting the BMC Server Automation Console .........................................................46
Viewing an untrusted certificate .......................................................................50
Additional command line options for logon ...................................................51
Deleting cached session credentials .............................................................................52
Viewing cached session credentials .............................................................................52
Viewing or deleting stored certificates ........................................................................53
Switching roles ................................................................................................................54
Changing passwords ......................................................................................................55
Rules for entering paths .................................................................................................56
Chapter 4 BMC Server Automation Console 59

Console overview ...........................................................................................................59
BMC Server Automation Console elements ...............................................................59
Quick tour of the console ....................................................................................64
BMC Server Automation perspectives and views ..........................................67
Global capabilities of the console ......................................................................71
Running background operations ..................................................................................77
Content editors ................................................................................................................78
Viewing and editing text files using BL Editor ...............................................79
Viewing and editing Network Shell Script files using ShellEd .....................80
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
Chapter 5 Properties 143

Property Dictionary overview ....................................................................................143
Property class description ................................................................................145

Properties description .......................................................................................145
Parameters description .....................................................................................146
Custom property class description ..................................................................146
Acceptable data types for properties ..............................................................149
Adding a custom property class ......................................................................150
Adding or modifying properties .....................................................................152
Creating or modifying an instance of a property class ................................155
Removing or deprecating a property, custom property class, or instance .
157
Viewing and modifying properties for property classes .............................158
Setting values for system object properties ...............................................................161
Changing property values for one or more system objects ....................................161
Inserting a parameter ..................................................................................................163
Chapter 6 Access management 165

Access control overview ..............................................................................................165
Authorization overview ...............................................................................................165
Role-based authorizations ................................................................................166
Object-based authorizations .............................................................................166
Resource-based authorizations ........................................................................167
Effective authorizations ....................................................................................168
Managing authorizations .............................................................................................168
Automation principals and server management ..........................................171
Authorization enforcement .........................................................................................172
No access nodes .................................................................................................173
Audit trail management ...............................................................................................173
Built-in roles and users ................................................................................................174
RBACAdmin and BLAdmin users ..................................................................177
Setting up authorizations ............................................................................................177
Adding or modifying an nexec command .....................................................178
Deleting an nexec command ............................................................................179
Defining audit trails ...........................................................................................179
Creating an authorization profile ...............................................................................180
Authorization profile Authorizations ..........................................................181
Authorization profile Permissions ...............................................................182
Modifying authorization profiles ....................................................................183
Creating an ACL template ...........................................................................................184
ACL template General ...................................................................................185
ACL template Template Access Control List ..............................................185
ACL template Permissions ............................................................................187
Modifying ACL templates ................................................................................189
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

Updating permissions for one or more system objects ................................235
Viewing an ACL summary ...............................................................................236
Common issues while using permissions ......................................................239
Agent ACL description ................................................................................................240
Windows user mapping and agent ACLs ......................................................242
Previewing and pushing agent ACLs .............................................................242
Creating ACL Push Jobs ..............................................................................................243
ACL Push Job General ...................................................................................245
ACL Push Job Targets ....................................................................................246
ACL Push Job Default Notifications ............................................................246
ACL Push Job Schedules ................................................................................247
ACL Push Job Properties ...............................................................................249
ACL Push Job Permissions ............................................................................250
Modifying ACL Push Jobs ................................................................................251
Using the bladduser utility ..........................................................................................251
Creating users without using RBAC ...............................................................252
Creating users in bulk .......................................................................................252
Authorizations for changing job priority ..................................................................253
Authorizations for the Configuration menu .............................................................256
Chapter 7 Agent installation 259

Agents in BMC Server Automation ...........................................................................259
Agent installation overview ........................................................................................260
Adding a server to the system ....................................................................................261
Add New Server Properties ..........................................................................262
Add New Server Permissions .......................................................................263
Importing servers into the system .............................................................................265
Import Servers Import Servers ......................................................................266
Import Servers Permissions ...........................................................................267
Defining alternative staging directories ....................................................................269
Adding agent installer packages to the Depot .........................................................269
Setting up a PsExec server ...........................................................................................272
Running the Unified Agent Installer .........................................................................273
Authorizations for the Unified Agent Installer .............................................275
Unified Agent Installer Introduction ...........................................................277
Unified Agent Installer Agent Bundle Platform Selection ....................277
Unified Agent Installer Agent Bundle Installer Selection .....................278
Unified Agent Installer Agent Bundle Configuration ...........................278
Unified Agent Installer Remote Host Authentication (non-Windows) .
280
Unified Agent Installer Remote Host Authentication (Windows) .........281
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
Chapter 8 Managing servers 319

Servers folder overview ...............................................................................................319
Properties and servers ..................................................................................................320
Editable intrinsic properties for servers .........................................................321
Server properties: update concepts .................................................................322
Creating Update Server Properties Jobs ....................................................................325
Update Server Properties Job General .........................................................326
Update Server Properties Job Targets ..........................................................327
Update Server Properties Job Default Notifications ..................................328
Update Server Properties Job Schedules .....................................................328
Update Server Properties Job Properties .....................................................330
Update Server Properties Job Permissions ..................................................331
Modifying Update Server Properties Jobs .....................................................332
Server organization concepts ......................................................................................333
Assigning servers to server groups ............................................................................333
Assigning a server to a server group ..............................................................334
Moving or copying a server between server groups ....................................335
Decommissioning a server ..........................................................................................335
About decommissioning servers .....................................................................336
Server browse options ..................................................................................................338
Contents of the Live node .................................................................................339
Server objects: management concepts .......................................................................342
Copying and pasting files and directories .....................................................343
Deleting files and directories ...........................................................................344
Starting and stopping services .........................................................................344
Viewing server objects ......................................................................................344

Executing custom commands .....................................................................................347
Configuration for Network Shell Proxy Server traffic ................................349
Chapter 9 Components and component templates 351

Components and component template overview ....................................................351
Component usage and capabilities ............................................................................352
Process for using components ....................................................................................353
Component requirements .................................................................................353
Component design .............................................................................................353
Component discovery .......................................................................................356
Component usage implementation .................................................................357
Organization of components and component templates .......................................358
Creating a component template .................................................................................359
Component Template General ......................................................................360
Component Template Parts ...........................................................................361
Component Template Properties ..................................................................370
Component Template Permissions ..............................................................370
Editing a component template ....................................................................................371
General tab for a component template ...........................................................373
Parts tab for a component template ................................................................374
Discover tab for a component template ..........................................................375
Browse tab for a component template ............................................................381
Snapshot/Audit tab for a component template ............................................382
Compliance tab for a component template ....................................................384
Local properties for a component template ...................................................412
Local Configuration Objects tab for a component template ........................414
Install/Uninstall tab for a component template ............................................415
Creating Component Discovery Jobs .........................................................................416
Component Discovery Job General ..............................................................417
Component Discovery Job Component Templates ...................................418
Component Discovery Job Targets ...............................................................420
Component Discovery Job Default Notifications .......................................420
Component Discovery Job Schedules ..........................................................421
Component Discovery Job Properties ..........................................................423
Component Discovery Job Permissions ......................................................424
Modifying Component Discovery Jobs ..........................................................425
Adding components to servers manually .................................................................425
Component General .......................................................................................426
Component Properties ...................................................................................427
Component Permissions ................................................................................428
Component Compliance exceptions ............................................................429
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
Chapter 10 Creating packages and other depot objects 477

Depot object overview .................................................................................................477
Software package overview ........................................................................................478
BLPackage overview ....................................................................................................480
Adding software to the Depot ....................................................................................482
Add Depot Software Add Software .............................................................484
Add Depot Software Properties ....................................................................494
Add Depot Software Permissions ................................................................495

Adding a hotfix to the Depot ......................................................................................496
Add Depot Software (Hotfix) Add Software ..............................................497
Add Depot Software (Hotfix) Properties .....................................................503
Add Depot Software (Hotfix) Permissions .................................................504
Modifying the definition of a software package ......................................................505
Modifying the contents of a software package .........................................................505
Matching software with depot items .........................................................................507
Adding a BLPackage to the Depot .............................................................................509
Create BLPackage Package Type ..................................................................511
Create BLPackage Select Server Objects ......................................................512
Create BLPackage Components ....................................................................512
Create BLPackage Snapshots ........................................................................512
Create BLPackage Depot files .......................................................................513
Create BLPackage Software ...........................................................................513
Create BLPackage Master Snapshot .............................................................513
Create BLPackage Empty Package ...............................................................513
Create BLPackage Package Item Options ...................................................514
Create BLPackage Properties ........................................................................515
Create BLPackage Permissions .....................................................................516
BLPackage Editing ........................................................................................................517
Opening a BLPackage to edit ...........................................................................520
Changing object attributes in a BLPackage ....................................................521
Adding a local property to a BLPackage ........................................................532
Moving an object within a BLPackage ............................................................533
Cutting and pasting in a BLPackage ...............................................................534
Ordering software within a BLPackage by dependency .............................535
Deleting an object in a BLPackage ...................................................................535
Providing password information in a BLPackage ........................................535
Finding and replacing text in a BLPackage ....................................................536
Adding content to a BLPackage .......................................................................539
Creating an RPM group ....................................................................................544
Creating an asset group ....................................................................................545
Commenting out assets .....................................................................................548
Verifying assets in a BLPackage ......................................................................548
Closing the BLPackage editor ..........................................................................549
Adding a Network Shell script ...................................................................................549
Add NSH Script Script Options ....................................................................550
Add NSH Script Parameters .........................................................................551
Add NSH Script Properties ...........................................................................553
Add NSH Script Permissions ........................................................................553
Modifying a Network Shell script ...................................................................554
Contents 13
Adding files to the Depot ............................................................................................556
Add File General .............................................................................................556
Add File Properties .........................................................................................557
Add File Permissions ......................................................................................557
Chapter 11 Configuration objects 559

Configuration objects overview ..................................................................................559
Configuration Object Dictionary ................................................................................560
Custom configuration objects .....................................................................................561
Custom configuration object versions ............................................................563
Deployable actions for UNIX objects ..............................................................564
Setting up an Active Directory object .............................................................565
Upgrading custom configuration objects .......................................................566
Adding a custom configuration object ......................................................................567
Deleting a custom configuration object .....................................................................569
Configuration files ........................................................................................................570
Grammar files supported by BMC Server Automation ..............................570
Identifying additional configuration files .................................................................574
Extended objects ...........................................................................................................577
Creating an extended object ........................................................................................577
Defining custom icons .......................................................................................581
Jobs to manage custom configuration objects ..........................................................582
Creating or modifying a Distribute Configuration Objects Job ..................583
Creating or modifying an Upgrade Model Objects Job ...............................590
Creating or modifying a Deregister Configuration Object Job ...................597
Chapter 12 Managing jobs 605

Basic concepts for jobs ..................................................................................................605
Job management tasks ..................................................................................................606
Job types ..............................................................................................................607
Organization of jobs .....................................................................................................608
Properties and jobs .......................................................................................................609
About job priorities .......................................................................................................609
Managing jobs through the Jobs or Servers folder ..................................................610
Opening a job ......................................................................................................611
Executing a job ...................................................................................................612
Executing a job against specific targets ..........................................................612
Executing a job against failed targets ..............................................................614
Defining a job execution override for a role and user ..................................616
Executing a job with BMC Remedy ITSM approval .....................................617
Managing jobs in progress ..........................................................................................621

Information in the Task in Progress view ......................................................623
Execution Tasks for managing job runs ....................................................................624
Creating an Execution Task while executing a job against failed targets
.....................................................................................................................................624
Creating and defining an Execution Task manually ....................................625
Modifying Execution Task definitions ............................................................633
Executing a job through an Execution Task ...................................................635
Viewing job run information through an Execution Task ...........................635
Viewing history for a job .............................................................................................637
Viewing job activity ......................................................................................................638
Viewing the status of a job ..........................................................................................638
Status types for change management approval jobs ....................................640
Viewing the job definition of a job run ......................................................................641
Managing job logs .........................................................................................................642
Viewing job schedules ..................................................................................................644
Defining time-outs for jobs ..........................................................................................644
Setting job priority ........................................................................................................646
Chapter 13 Snapshot Jobs 649

Snapshot overview .......................................................................................................649
Snapshot and audit basics ...........................................................................................650
Symbolic links in snapshots and audits ..........................................................650
Snapshot storage ................................................................................................650
Creating Snapshot Jobs ................................................................................................652
Snapshot Job General .....................................................................................653
Snapshot Job Components Templates for Filtering ...................................654
Snapshot Job Server Objects ..........................................................................655
Snapshot Job Targets ......................................................................................659
Snapshot Job Default Notifications ..............................................................659
Snapshot Job Schedules ..................................................................................661
Snapshot Job Properties .................................................................................664
Snapshot Job Permissions ..............................................................................664
Modifying Snapshot Jobs .............................................................................................665
Snapshot and change tracking results .......................................................................666
Viewing snapshot and change tracking results .............................................669
Backing out changes ..........................................................................................670
Viewing changes using the Compare Editor .................................................670
Showing deploy-related job activity ...............................................................670
Bundling snapshot results into a BLPackage .................................................671
Adding software to the Depot from snapshot results ..................................674
Exporting results of an audit or snapshot ......................................................675
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
Chapter 15 Software and BLPackage Deploy Jobs 713

Software and BLPackage Deploy Job overview .......................................................713
Phases of a Deploy Job .................................................................................................714
Deploy Job states ...........................................................................................................716
Deployments to agentless managed objects .............................................................716
Basic and advanced BLPackage Deploy Jobs ...........................................................717
Creating a Deploy Job ..................................................................................................718
Caveats for deploying BLPackages .................................................................721
Deploy Job General .........................................................................................722
Deploy Job Software .......................................................................................724
Deploy Job Package ........................................................................................724
Deploy Job Targets .........................................................................................729
Deploy Job Default Notifications ..................................................................729

Deploy Job Phases and Schedules ................................................................730
Deploy Job Job Options ..................................................................................737
Deploy Job Phase Options .............................................................................746
Deploy Job Properties ....................................................................................750
Deploy Job Permissions .................................................................................752
Limitations for Windows security settings ....................................................753
Modifying Deploy Jobs ................................................................................................754
Assigning default values for Deploy Jobs .................................................................754
DeployOptions properties for controlling Deploy Job behavior ................755
Uninstalling software ...................................................................................................762
Deploy Job results .........................................................................................................764
Performing actions on a job ..............................................................................765
Performing actions on a server or phase ........................................................767
Undoing a Deploy Job .......................................................................................768
Rebooting servers ...............................................................................................769
Server properties controlling Deploy Job behavior .................................................769
Designating servers that cannot be targeted by Deploy Jobs ......................770
Configuring the location of the transactions directory ................................770
Using NFS to mount a location while running single-user mode ..............771
Tracking BLPackage deployments .............................................................................772
Chapter 16 File Deploy Jobs 773

File Deploy Job overview ............................................................................................773
Creating a File Deploy Job ...........................................................................................773
File Deploy Job General .................................................................................775
File Deploy Job Targets ..................................................................................777
File Deploy Job Options .................................................................................777
File Deploy Job Advanced Options ..............................................................783
File Deploy Job Default Notifications ..........................................................784
File Deploy Job Schedules .............................................................................785
File Deploy Job Properties .............................................................................788
File Deploy Job Permissions ..........................................................................789
Modifying File Deploy Jobs .........................................................................................790
Chapter 17 Network Shell Script Jobs 791

Creating Network Shell Script Jobs ............................................................................791
Network Shell Script Job General .................................................................792
Network Shell Script Job Targets ..................................................................794
Network Shell Script Job Parameters ...........................................................794
Network Shell Script Job Default Notifications ..........................................796
Network Shell Script Job Schedules .............................................................796
Contents 17
Network Shell Script Job Properties .............................................................799
Network Shell Script Job Permissions .........................................................800
Modifying Network Shell Script Jobs ........................................................................801
Chapter 18 Batch Jobs 803

Batch Job overview .......................................................................................................803
Creating a Batch Job .....................................................................................................803
Batch Job Options ............................................................................................805
Batch Job Default Notifications .....................................................................807
Batch Job Schedules ........................................................................................808
Batch Job Properties ........................................................................................811
Batch Job Permissions ....................................................................................811
Modifying a Batch Job ..................................................................................................813
Viewing Batch Job results ............................................................................................814
Effect of execution settings on display of results ..........................................814
Chapter 19 Workflow Jobs 819

Workflow Job objectives ..............................................................................................819
Requirements and preparatory tasks for Workflow Jobs .......................................820
Configuring input parameters in a process ..............................................................820
Including metadata in input parameter names .............................................821
Defining input parameter information through XML code ........................826
Data types for input parameters of a Workflow Job .....................................834
BLCLI commands for inclusion in a process ............................................................837
Enabling the AO integration .......................................................................................838
Setting up the connection to BMC Atrium Orchestrator .............................838
Enabling HTTPS support for the AO connection ..........................................840
Choosing modules for Workflow Jobs ......................................................................841
Creating Workflow Jobs ...............................................................................................842
Workflow Job General ....................................................................................843
Workflow Job AO Process .............................................................................843
Workflow Job Workflow Input Parameters ................................................844
Workflow Job Default Notifications ............................................................844
Workflow Job Schedules ................................................................................845
Workflow Job Properties ...............................................................................848
Workflow Job Permissions ............................................................................849
Modifying Workflow Jobs ...........................................................................................850
Viewing Workflow Job results and logs ....................................................................851
Chapter 20 Working with virtual environments 853

Overview of virtualization support ...........................................................................854

Browsing virtual inventory .........................................................................................857
Deploying assets to the virtual infrastructure ..........................................................861
About deploying virtual assets ........................................................................861
Deploying virtual systems based on existing virtual systems ....................863
Deploying virtual systems using a Virtual Guest Package .........................868
Rolling back a deployment ...............................................................................892
Monitoring compliance in the virtual environment ................................................892
Running Snapshot, Audit, and Compliance Jobs on virtual
infrastructure ......................................................................................................894
Discovering and registering assets in a virtual environment .................................895
About the Virtual Infrastructure Discovery Job ............................................896
Creating the Virtual Infrastructure Discovery Job ........................................898
Scheduling a Virtual Guest Job or Virtual Infrastructure Discovery Job
.....................................................................................................................................899
Reviewing the results of the Job ......................................................................900
Modifying the Virtual Infrastructure Discovery Job ....................................901
Managing virtual environments .................................................................................901
Managing a VMware vSphere environment .................................................902
Managing a Solaris Zones environment .........................................................907
Managing an IBM PowerVM environment ...................................................910
Managing a Microsoft Hyper-V environment ...............................................914
Managing a Red Hat Enterprise Virtualization environment .....................917
Managing a Citrix XenServer environment ...................................................923
Managing virtualization sprawl .................................................................................928
Creating the server lifecycle properties mapping file ..................................929
Generating reports for virtualization ..............................................................931
Virtual Guest Job Wizard Panels ................................................................................932
Virtual Guest Job - General ..............................................................................933
Virtual Guest Job - Virtual Guest Package Selection ....................................934
VMware specific panels ....................................................................................935
IBM specific panels ............................................................................................939
Solaris specific panels ........................................................................................947
Citrix XenServer specific panels ......................................................................951
RedHat KVM-specific panels ...........................................................................953
Red Hat Enterprise Virtualization-specific panels ........................................956
Microsoft Hyper-V-specific panels ..................................................................958
VM Basic Config - Microsoft Windows ..........................................................961
VM Basic Config - Linux ...................................................................................962
VM Computer Settings .....................................................................................962
Virtual Guest Job - Schedule ............................................................................963
Virtual Guest Job - Default Notifications .......................................................964
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
Chapter 21 Administrative tools 977

Custom commands .......................................................................................................977
Creating or modifying a custom command ...................................................978
Deleting a custom command ............................................................................981
Setting up communications with remote servers .....................................................982
Creating SOCKS proxy server objects .............................................................983
Creating rules for routing to remote servers .................................................984
Adding remote servers ......................................................................................988
Configuring servers to use repeaters during deployments ....................................989
Creating repeater server objects ......................................................................991
Creating rules to determine the repeater used for target servers ...............992
Assigning repeaters to target servers ..............................................................996
Creating rules to determine Application Servers used for job execution .............997
Creating routing rules for job execution .........................................................997
Enabling/disabling job routing rule evaluation .........................................1000
Infrastructure management from the BMC Server Automation Console .........1001
About the Infrastructure Management window .........................................1001
Getting information about Application Servers ..........................................1002

Reporting Application Server information ..................................................1003
Getting information about PXE servers ........................................................1004
Getting information about the database .......................................................1005
Managing SOCKS proxy servers ...................................................................1005
Managing repeater servers .............................................................................1007
Managing remote host authentication for agent installations ...................1011
Managing routing rules ..................................................................................1013
About troubleshooting tools .....................................................................................1017
Chapter 22 Patch management 1019

Patch management overview ....................................................................................1019
Patch management workflow ...................................................................................1020
Preparatory tasks ........................................................................................................1023
Role-based permissions for patch catalog ....................................................1023
Global Configuration parameters ..................................................................1024
Defining the location of Microsoft Windows installation media for
Microsoft Office patch deployment ..............................................................1032
Offline Patch Downloader utility .............................................................................1032
Downloading patch downloader utilities ....................................................1033
Patch Downloader utility for Microsoft Windows .....................................1034
Patch Downloader utility for Oracle Solaris ................................................1038
Patch Downloader utility for IBM AIX .........................................................1043
Patch Downloader utility for Red Hat Enterprise Linux ...........................1051
Patch Downloader utility for SUSE Linux Enterprise ................................1061
Patch Downloader utility for Oracle Enterprise Linux ..............................1070
Creating a patch catalog ............................................................................................1076
Patch Catalog General ..................................................................................1077
Patch Catalog Windows Catalog ................................................................1077
Patch Catalog Solaris Catalog .....................................................................1080
Patch Catalog AIX Catalog ..........................................................................1084
Patch Catalog Red Hat Catalog ..................................................................1088
Patch Catalog SUSE Linux Catalog ............................................................1091
Patch Catalog Oracle Enterprise Linux Catalog .......................................1096
Patch Catalog Schedules ..............................................................................1098
Patch Catalog Properties ..............................................................................1100
Patch Catalog Permissions ..........................................................................1100
Modifying patch catalog definitions ........................................................................1101
Smart Groups in the patch catalog ...........................................................................1102
Updating an existing catalog ....................................................................................1103
Downloading patch payloads to the catalog ..........................................................1104
New Patch Download Job General .............................................................1105
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
Chapter 23 Provisioning basics 1143

Operating systems supported for provisioning .....................................................1143
Provisioning process .................................................................................................1143
Provisioning process for Windows and Linux ............................................1144
Provisioning process for AIX .........................................................................1147

Provisioning process for Solaris ...................................................................1149
Provisioning process for HP-UX ...................................................................1152
Integration of provisioning and server management .................................1154
Provisioning tasksChecklist ..................................................................................1155
Chapter 24 Provisioning servers 1159

Boot image files and placeholders ............................................................................1159
Creating WinPE 2.0 and later boot image files .......................................................1160
Preparing a machine for WinPE 2.0 and later image creation ..................1161
Creating WinPE 2.0 and later images using the Image Creation wizard
...................................................................................................................................1164
Creating a network.ini file ..............................................................................1169
Creating WinPE 2.0 and later image files using the BMC Server Automation
script ..................................................................................................................1171
Copying image files to a location for provisioning .....................................1175
Creating a Gentoo Linux image file .........................................................................1179
Using the Skip Linux Pre-Install image option ......................................................1183
Configuring provisioning ..........................................................................................1184
Configuring the data store ..............................................................................1185
Configuring a system package type ..............................................................1190
Changing the location of installation files ....................................................1200
Creating custom system package types ........................................................1201
Configuring the PXE server ............................................................................1202
Configuring the TFTP server ..........................................................................1204
Configuring boot image files ..........................................................................1206
Including a Batch Job in a system package .............................................................1213
Creating a system package ........................................................................................1214
System Package Creation General ..............................................................1216
System Package Creation Properties ..........................................................1216
System Package Permissions ..........................................................................1217
Defining settings for Windows servers ...................................................................1218
Pre-install scripts Windows .........................................................................1219
Disk partition Windows ...............................................................................1219
Post-disk partition Windows ......................................................................1222
Basic configuration Windows .....................................................................1222
Computer settings Windows 2008 .............................................................1224
Computer settings all Windows operating systems except Windows
2008 ....................................................................................................................1227
OS components Windows 2008 ..................................................................1233
OS components all Windows operating systems except Windows 2008
1234
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

Kickstart entries ESX ....................................................................................1283
Post-install configuration ESX ....................................................................1286
Local properties ESX ....................................................................................1287
Defining settings for Citrix XenServers ...................................................................1288
Pre-install scripts Citrix XenServer ............................................................1289
Disk partition Citrix XenServer ..................................................................1289
Basic configuration Citrix XenServer .........................................................1290
Computer settings Citrix XenServer ..........................................................1291
Network Citrix XenServer ..........................................................................1292
Unattend entries Citrix XenServer .............................................................1293
Post-install configuration Citrix XenServer ..............................................1295
Local properties Citrix XenServer ..............................................................1295
Defining settings for Solaris servers ........................................................................1296
Disk partition Solaris ....................................................................................1297
Basic configuration Solaris ..........................................................................1299
Computer settings Solaris ............................................................................1300
Network Solaris .............................................................................................1301
Package specifications Solaris .....................................................................1303
Additional sysidcfg entries Solaris .............................................................1303
Additional profile entries Solaris ................................................................1304
Add install client script Solaris ...................................................................1304
Rules file script Solaris .................................................................................1305
Begin script Solaris .......................................................................................1305
Finish script/agent install Solaris ...............................................................1306
Reboot script Solaris .....................................................................................1307
x86 parameters Solaris .................................................................................1308
Preview Solaris ..............................................................................................1310
Local properties Solaris ................................................................................1310
Defining settings for AIX servers .............................................................................1310
Basic configuration AIX ...............................................................................1311
Target disk AIX .............................................................................................1312
Localization settings AIX .............................................................................1313
Network config AIX .....................................................................................1315
Agent install/first boot script AIX .............................................................1316
NIM scripts .......................................................................................................1318
Control flow ......................................................................................................1319
Optional bos_inst attributes ...........................................................................1319
Pre-machine definition scripts .......................................................................1320
Pre-bos_inst script ............................................................................................1321
Post bos_inst Script ..........................................................................................1321
Preview AIX ...................................................................................................1321
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

Executing a Provision Job ...............................................................................1366
Managing Provision Jobs ...........................................................................................1368
Viewing the results of a Provision Job ..........................................................1368
Canceling a Provision Job in progress ..........................................................1369
Viewing the log for a Provision Job ..............................................................1370
Exporting the log for a Provision Job ............................................................1370
Reprovisioning servers ..............................................................................................1371
Reprovisioning from the Provision Job ........................................................1372
Reprovisioning from a device ........................................................................1372
Provisioning multiple servers tips ........................................................................1373
Provisioning Windows 2003 or 2008 servers from a local data store ..................1374
About provisioning from a local data store .................................................1375
Creating a WinPE image for booting from local media .............................1375
Creating an image for booting from the PXE server ...................................1378
Creating a Windows system package for use with a local data store ......1378
Associating the LocalDataStore instance with the system package .........1381
The CONFIG_STORE property .....................................................................1382
Provisioning target servers with ESXi 4.0 ...............................................................1382
Provisioning target servers with ESXi 5.0 ...............................................................1384
Provisioning Solaris servers using a WAN boot installation ...............................1385
Capturing WIM images for use in provisioning ....................................................1388
Using WIM images to provision Windows servers ...............................................1390
Setting up auto-discovery of iDRAC devices .........................................................1393
Configuring the DHCP server for iDRAC auto-discovery ........................1394
Importing Dell certificates into the keystore ...............................................1396
Enabling the iDRAC provisioning service ...................................................1396
Creating the configuration file for the iDRAC provisioning service .......1397
Provisioning iDRAC devices .....................................................................................1398
Importing an iDRAC device ...........................................................................1399
Copying iDRAC drivers to a data store ........................................................1402
Downloading an ISO image to vFlash ..........................................................1403
The iDRAC panel .............................................................................................1404
Provisioning Citrix XenServer to target servers .....................................................1405
Provisioning the Red Hat KVM hypervisor ...........................................................1406
Provisioning the Red Hat Xen hypervisor ..............................................................1407
Provisioning Solaris servers using a Solaris Flash archive file ............................1408
Properties and provisioning ......................................................................................1409
Device properties .............................................................................................1410
System package properties .............................................................................1410
Provisioning server properties using the PROVSERVER class .................1411
Streamlining the wizard with parameterized properties: an example ....1412
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
Chapter 25 SCAP compliance analysis 1419

About the Security Content Automation Protocol .................................................1419
Overview of SCAP features ............................................................................1419
Supported SCAP capabilities ........................................................................1420
SCAP content components .............................................................................1421
SCAP Benchmarks and profiles .....................................................................1424
Setting up the SCAP environment ...........................................................................1424
Obtaining SCAP benchmark content ............................................................1425
Installing the RSCD agent version 8.2 ..........................................................1426
Establishing role-based permissions for SCAP ..........................................1426
Importing SCAP content ............................................................................................1428
New XCCDF Benchmark General ..............................................................1428
New XCCDF Benchmark Permissions .......................................................1429
Viewing SCAP schema errors ........................................................................1430
Viewing an imported SCAP benchmark ......................................................1431
Creating an SCAP Compliance Job .........................................................................1431
SCAP Compliance Job General ..................................................................1433
SCAP Compliance Job Profile Selector and Advanced Settings ...........1433
SCAP Compliance Job Targets ....................................................................1435
SCAP Compliance Job Default Notifications ............................................1436
SCAP Compliance Job Schedules ...............................................................1437
SCAP Compliance Job Properties ...............................................................1439
SCAP Compliance Job Permissions ............................................................1439
Managing SCAP Compliance Jobs ...........................................................................1440
Modifying an SCAP Compliance Job ............................................................1440
Running an SCAP Compliance Job ...............................................................1441
Viewing SCAP results ................................................................................................1441
SCAP Rule Result States .................................................................................1442
Viewing SCAP rule results in the Console ...................................................1442
Viewing configuration issues and CCE descriptions .................................1444
Viewing vulnerability issues, CVE descriptions, and patches ..................1444
Viewing CVSS impact metrics .......................................................................1445
Viewing OVAL result files .............................................................................1445
Exporting SCAP results .............................................................................................1447
Analyzing SCAP results .............................................................................................1448
Running the SCAP analysis and creating the report .................................1449

Understanding the SCAP analyzer report ..................................................1450
SCAP troubleshooting and tips ...............................................................................1451
Correcting SCAP import validation errors ..................................................1451
Researching a failed OVAL interpreter process ..........................................1452
Researching SCAP Compliance Job error messages ...................................1453
Appendix A Windows security settings 1455

Windows security settings list ..................................................................................1455
Appendix B Content format 1461

Packaging content .......................................................................................................1461
Content format XML files overview ........................................................................1461
Operators node ............................................................................................................1463
Grammars node ..........................................................................................................1463
Packages node .............................................................................................................1464
Types node ...................................................................................................................1465
Data instances node ....................................................................................................1469
Rule library node ........................................................................................................1470
Services node ...............................................................................................................1471
Service instances node ...............................................................................................1474
Policies node ................................................................................................................1475
Appendix C System authorizations 1477
Appendix D Intrinsic properties 1479

Intrinsic properties list ...............................................................................................1479
Glossary 1495
Contents 29
1
Introduction
This section introduces BMC Server Automation.
Introduction to BMC Server Automation

BMC Server Automation lets IT organizations automate the management of enterprise-
class data centers.
BMC Server Automation is part of the BMC BladeLogic Automation Suite.
Using BMC Server Automation, system administrators can:
View and manage configurations
Deploy software, patches, and complex packages of files and other assets
Store configurations
Compare servers to detect discrepancies in their configurations
Measure and enforce compliance to organizational standards
Administer configuration changes to servers and other devices
Share routine server management tasks between functional teams in an organization
Perform many other data center automation tasks
BMC Server Automation lets system administrators provision operating systems

onto servers, including the initial provisioning of machines (sometimes called bare
metal provisioning or raw iron provisioning). Administrators can specify how a
server should be configured, including its operating system, partitions, and network
information. Administrators can install and register an agent so BMC Server
Automation can manage the server and then run a BMC Server Automation job to
install software and perform additional configuration on the machine.
Documentation conventions
System administrators can also take advantage of many virtualization features.

Virtualization provides a one-to-many capability for managing virtual
infrastructure, including VMware ESX and vCenter servers and virtual configuration
information for all virtual machines hosted by ESX servers. BMC Server Automation
lets you manage physical or virtual servers with a consistent user experience.
Together, the capabilities of BMC Server Automation let system administrators

manage the life cycle of data center servers. The BMC Server Automation suite of
tools can boost the efficiency of senior system administrators while simultaneously
providing an interface suitable for operations managers and junior system
administrators.
All BMC Server Automation capabilities are available on multiple operating systems.
Documentation conventions
This document uses some special conventions.
User action required

Within a procedure, bold text highlights actions that you should take. For example, a
procedural step might read, From the File menu, select Add."
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.
UNIX and Windows path separators

When describing paths, this guide uses UNIX path separators (forward slashes)
except in situations where Windows path separators (back slashes) are specifically
required.
Multiple approaches for a task

When you perform a task in the console, multiple approaches are usually possible.
You can use menu options, tool bar icons, or pop-up menus to achieve the same
goals. Typically, the documentation describes only one approach, usually involving
the use of pop-up menus.

References to online documentation
Straight quotes in examples

Examples use straight quotes and therefore can be copied into the BMC Server
Automation UI or command line. However, a copy and paste of text into a UI field
or command line from a source that uses smart quotes (for example, a PDF or a
Microsoft Word document) can cause the command to fail. To avoid this issue, copy
text from a source that uses the ASCII character set (for example, Notepad).

This document contains many references to online BMC technical documentation. To
access this information, you must have an account with BMC Support.

2
BMC Server Automation overview
This section provides an overview of the BMC Server Automation system.
BMC Server Automation components

BMC Server Automation provides a comprehensive solution for the initial
provisioning and ongoing automated management of servers.
A BMC Server Automation system consists of the following components:
BMC Server Automation consoleA GUI-based system for provisioning of

servers and automating their management.
Network ShellA cross-platform shell with scripting capability that gives

seamless access to remote servers from central management workstations.
RSCD agent (Remote System Call Daemon)Software that must be installed and
running on each remote server that BMC Server Automation accesses.
Application ServerSecure, scalable software for controlling communication

between BMC Server Automation components and remote servers and databases.
Also used during initial server provisioning.
BMC BladeLogic Decision Support for Server AutomationA reporting utility

that delivers server configuration information to a web-based report viewer.
PXE serverComponent used for the unattended provisioning of operating

systems onto servers.
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
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:
The BMC Server Automation Console

System architecture
A command line interface (BLCLI) that provides application programming

interface (API) access to the functionality available through the console
Network Shell for ad hoc administration of one or more servers
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.
Network Shell is a network scripting language that enables cross-platform access

through a command line interface.
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
Interaction with the database
Interaction with the file server
The Application Server is scalable, allowing administrators to adjust its performance

to accommodate added users and increased database activity. If necessary, a BMC
Server Automation system can incorporate multiple application servers that
cooperate by balancing job processing workloads.
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

Access control
warehouse. The reporting data warehouse is populated with information from the
core BMC Server Automation database.
Network Shell can optionally incorporate a middle tier componentan Application

Server that is configured to run a Network Shell Proxy Server. Operating as an
intermediary between Network Shell clients and the managed servers those clients
target, the Network Shell Proxy Server authenticates Network Shell client users and
ensures traffic is encrypted between clients and managed servers.
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.
In BMC Server Automation, a role is an organizational entity such as junior

administrators or database managers. You define authorizations that are appropriate
to a role and then assign users to that role. In this way, users are granted the
permissions defined for a role. For example, a junior administrator role might only
be granted permission to see certain types of objects, such as files, while a senior
administrator role might be given full authorization to create and modify files. A
user can have many roles, but a user can only assume one role at a time.
In addition to role-based authorizations, you must also define permissions for

objects. In BMC Server Automation, an object you interact with is called a system
object. Servers, jobs, and system packages are examples of system objects. To take an
action on a system object, you must have both role-level and object-level
authorization. If you are running a job on an object such as a server, you must have
object-level authorization for both the job and the target server. Object-level
authorizations enable you to make fine-grained decisions about access to objects
throughout your system.
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.

BMC Server Automation system security
BMC Server Automation system security

BMC Server Automation provides multiple levels of system security, ranging from
unrestricted communication between management consoles and remote servers to
security models that incorporate the strongest available security mechanisms.
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:
RBAC Manager folder on page 39
Servers folder on page 40
Component Templates folder on page 40
Components folder on page 40
Depot folder on page 41
Devices folder on page 41
Jobs folder on page 41
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.
RBAC Manager folder

Use the RBAC Manager folder to define sets of permissions and then assign those
permissions to roles. In this way you can authorize actions for whole classes of users,

Folder overview
such as junior administrators or system architects. Using the RBAC Manager folder,
you can take many actions, including:
Creating roles and users
Defining authorization profiles, which are collections of individual authorizations
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.
Component Templates folder

Use the Component Templates folder to define and store component templates and
create components.
A component is a managed object that provides a higher level of abstraction than

other server objects. Using components, you can manage applications and policies
instead of the server objects that make up those applications or policies. For example,
a component can specify files, configuration entries, and registry values needed to
define an Apache server or an Oracle database. Or, a component can specify a
compliance policy, such as the system and configuration settings recommended by
the Center for Internet Security.
Typically, senior users define a component template representing an application or

policy. They create components by associating the component template with servers
that match a profile defined in the template. Then, junior users can use these
components to browse, snapshot, audit, and analyze compliance for the application
or policy.
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.

Folder overview
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.

Folder overview

3
Getting started with server
automation
This section describes the BMC Server Automation logon process. It also provides
some conceptual explanation about the authentication process.
BMC Server Automation authentication

process
The BMC Server Automation Console includes many security mechanisms for
authenticating users.
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.
If the Authentication Service successfully authenticates you, it generates a session

credential and delivers the credential back to the BMC Server Automation console. A
session credential validates you as a legitimate user for a finite period of time. When
you log on, you can optionally choose to cache sessions credentials. If you have a
valid session credential cached, you do not have to authenticate the next time you
start BMC Server Automation.
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.

Preparation for user logons
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).
Preparation for user logons

Before you can log on, you or your system administrator must first create one or
more authentication profiles, which are collections of information needed to conduct
logons.
An authentication profile specifies the authentication mechanism that should be

used during a logon, the Application Server to which a user should connect, and a
port for the Authentication Service. (The Authentication Service always resides on
the same server as the Application Server.) For details about authentication profiles,
see Setting up an authentication profile 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).
Setting up an authentication profile

An authentication profile is a collection of information that the system uses to
conduct a logon session. When you log on to the BMC Server Automation console,
you must select an authentication profile.
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.

Setting up an authentication profile
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.
To set up an authentication profile
1 To open the logon window for the BMC Server Automation Console, do one of
the following:
(Windows) Perform one of the following steps:
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.
3 Click the Authentication Profile tab.
4 Do one of the following:
To modify an existing authentication profile, select the profile in the profiles

list. Then click Edit. The Edit Authentication Profile dialog opens.
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.

Starting the BMC Server Automation Console
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
Name or IP address of the Application Server to which the client should

connect.
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
The authentication mechanism for this authentication profile. Specify the

mechanism by performing one of the following actions:
Select Secure Remote Password.
Select AD/Kerberos Single Sign-on.
Select Domain Authentication.
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.
Select RSA SecurID Authentication.
Select Public Key Infrastructure Authentication.
6 Click OK.

To log on, you may be asked to provide a user name and password, although that is
not required for all authentication methods. For all types of authentication, you must
choose an authentication profile.

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.
Before you begin
To log on, you must choose an authentication profile, which is a collection of

information that a BMC Server Automation client uses to conduct a logon session.
You or your system administrator must set up an authentication profile before
performing this procedure. For more information about creating authentication
profiles, see Setting up an authentication profile on page 44.
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.
To start the BMC Server Automation Console
1 Open the BMC Server Automation dialog box by doing one of the following:

.\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
./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.
2 Using the Authentication profile tab, select an authentication profile.
3 If you:
Possess a valid cached session credential, skip this step and go to the next step.
Are using Active Directory/Kerberos (ADK) or public key infrastructure (PKI)

authentication, 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.

Save credential for this session
Saves a session credential between sessions.
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
The language displayed represents your choice of language (either your

previous choice or your acceptance of the installation default). Select a new
display language for the console or keep the current user preference. The
selection remains in effect as your default language for future logons until
you make a new choice. For more information, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Installing.
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.)
8 Click OK. The BMC Server Automation Console appears.

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.
Viewing an untrusted certificate

In certain situations, when you log on to BMC Server Automation, a security dialog
box warns that you are presented with an untrusted certificate.
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.
To view an untrusted certificate
1 Log on to BMC Server Automation, as described in Starting the BMC Server

Automation Console on page 46.
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.
2 Click View Certificate.
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.
4 To return to the Security Alert dialog box, click Close.
To trust the certificate and continue logging on, click Yes.

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.
Additional command line options for logon

When you use a Windows or UNIX command line to launch the BMC Server
Automation console, you can append parameters to the command. The parameters
provide the location of files that can be used during logon.
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.
Logon parameter Description

-f Location of session credential cache file.
When you log on, the system issues you a session
credential, which the console uses to establish a
secure connection with the Application Server. You
can choose to cache your session credential.
-w Location of authentication profile file.
Authentication profiles are collections of information
that a BMC Server Automation client application
needs to log on. All authentication profiles are stored
in one XML file. Within that file each authentication
profile must be assigned a unique name.
-x Location of trusted keystore.
The trusted keystore is a list of trusted certificates.
When you first use the BMC Server Automation
Console to log on, the authentication process
presents you with a certificate to trust. If you accept
it, the certificate is added to the trusted keystore.

Deleting cached session credentials
Deleting cached session credentials

The BMC Server Automation logon window lets you delete valid cached session
credentials.
When a BMC Server Automation Application Server authenticates you, it generates a

credential for your session, which you can optionally cache. This credential remains
cached until it expires.
To log on to BMC Server Automation as a different user, you must first delete all
cached session credentials.
To delete cached session credentials
1 Open the BMC Server Automation logon window by doing one of the following:
.\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.
example, /opt/bmc/BladeLogic/ CM), enter:
./rcp/launcher.sh
2 Click Delete Cached Credentials.
Viewing cached session credentials

The logon window for BMC Server Automation lets you view valid cached session
credentials.
When a BMC Server Automation Application Server authenticates you, it generates a

credential for your session, which you can optionally cache. This credential remains
cached until it expires.

Viewing or deleting stored certificates
To view cached session credentials
.\rcp\BSAClient.exe
./rcp/launcher.sh
2 Click Options. The logon window expands to show additional options in a

tabbed format.
3 Click the Credentials tab.
The logon window lists cached sessions.
4 Select a credential and click View.
The Cached Session Credential window opens. It displays information about the
credential, such as the authentication protocol in effect and the credential
expiration date.
5 Click Close to close the Cached Session Credential window.
Viewing or deleting stored certificates

The logon window for BMC Server Automation lets you view or delete a stored
certificate.
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.

Switching roles
To view or delete stored certificates
.\rcp\BSAClient.exe
If you more than one version of the client is installed, the different versions
example, /opt/bmc/BladeLogic/ CM), entering:
./rcp/launcher.sh
2 Click Options. The logon window expands to show additional options in a

tabbed format.
3 Click the Certificates tab. The logon window lists all certificates in the client
keystore.
4 From the certificates list, select a certificate and either:
Click Delete. A confirmation dialog box appears.
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.

Changing passwords
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.
2 From Select Role, choose a role you want to use.
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.
SRP is the default authentication mechanism for BMC Server Automation.
To change passwords
1 Select Configuration => Change SRP Password.
The Change Password dialog box appears.
2 For Old Password, enter your current password.
3 For New Password, enter a new password.
4 For Retype New Password, confirm the new password by typing it again.
5 Click OK.
The password is changed.

Rules for entering paths

BMC Server Automation requires you to enter paths using conventions that are
atypical for Windows or UNIX platforms.
Entering UNIX host names

For UNIX, precede a host name with two slashes. Use a slash to identify a directory.
The following is an example of a directory on a UNIX host called unixtest1.
//unixtest1/usr/bin
Entering Windows host names

For Windows, precede the host name with two slashes. For files, COM+, and
metabase, use slashes to identify the disk drive, folders, and sub-folders. Windows
paths are not case sensitive. The following is an example of a folder on a Windows
host called win2ktest1:
//win2ktest1/c/winnt/system32
The following is an example of a path to a COM+ property:
Applications/IIS Utilities/Activation
The following is an example of a path to a metabase value:
LM/W3SVC/Default Web Site/ServerSize
When entering a path to an item in the registry, use backslashes. The following is an
example of a path to a registry value:
HKEY_LOCAL_MACHINE\SOFTWARE\BMC BladeLogic\RSCD Agent

\AgentHome
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

Entering paths to configuration file entries

When you enter paths to configuration files on Windows or UNIX, use a double
slash (//) to separate the path to the configuration file from the path to a hierarchy
within the file.
For example, you might identify a configuration file entry as follows:
/c/winnt/odbc.ini//Excel files/Driver32
In this example, /c/winnt/odbc.ini provides the path to a configuration file, while

Excel files/Driver 32 is the path to an entry in the configuration file.
Slashes appearing in values

For most hierarchical assets, the path separator is a slash. To enter a value that
includes a slash, you must escape the slash by preceding it with a backslash.
For example, to create the value driver/32, enter driver\/32.
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.
Using trailing slashes

When you enter a folder or directory name, BMC Server Automation does not
support trailing slashes.
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:
HKEY_LOCAL_MACHINE\SOFTWARE\BMC BladeLogic\RSCD Agent\


4
BMC Server Automation Console
BMC Server Automation contains global menus, toolbars, perspectives, views,
objects, and content editors, referred to collectively as the console.
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.
To customize the appearance of the console, refer to Console management on page

83.
BMC Server Automation Console elements

The console contains standard graphical user interface (GUI) elements, which you
can modify using the Preferences menu (Window => Preferences).
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.
Console element Description

console title bar Identifies the system name, the user, the users role, and the
application server pool to which the client is connected. Contains
the basic controls to minimize, maximize and close the console
window.


global menu bar Contains commands that can be executed throughout the console. If
a command is unavailable in a particular context, it is dimmed. The
menus and menu options are organized for quick access to
frequently used commands and tasks.
The menu identifies modifiable keystroke combinations or key
bindings and mnemonics (ALT + underlinedLetter) for commonly
used commands and tasks. You can change the key bindings by
choosing Windows => Preferences => General => Keys or
pressing CTRL+Shift+L twice. For more information, see
Customizing keystroke combinations on page 94.
global toolbar Contains icons for common actions such as open, search, and close.
perspective A perspective represents a configuration of views, view 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. The name of the
perspective appears at upper right on the console.
Perspectives are configured for certain tasks. For example, the
Classic perspective is configured to make it easy to perform typical
BMC Server Automation configuration and provisioning tasks. The
Explorer perspective, a preconfigured perspective, is designed for
navigating objects in your enterprise.
You can open additional perspectives from the drop-down list of
perspectives in the Perspective title bar or by choosing Window =>
Open Perspective => perspectiveName. Perspective names appear
on tabs at right as well as in the drop-down list of perspectives,
making it easy to navigate between perspectives. You can
customize existing perspectives to suit your content.
Perspectives contain menus and toolbars for navigating multiple
perspectives, opening, resizing, moving, or closing perspectives,
and changing the look. The system saves any customization until
you click the Restore icon or choose Window => Reset Perspective.
All perspectives contain:
A system menu which can be accessed when you right-click the

perspective title tab.
Icons to minimize, maximize, send to toolbar, and close the

perspective.
For more information, see BMC Server Automation perspectives

and views on page 67.


view Defines a logical grouping of information, objects, and actions in the
console for ease of navigation and increased productivity.
A view has a tab with the view name on it, a menu and toolbar for
navigating multiple views, opening, resizing, moving, or closing a
view, and changing the look.
You can move views around within the perspective and dock them
in a new location, create tab groups with multiple views, and
detach views from the perspective.
All views contain:
A system menu which can be accessed when you choose

Window => Navigation => Show System Menu or when you
right-click the view title tab.
Icons to minimize, maximize, and restore the view to its original

size.
In addition, some views have a specialty toolbar and corresponding

menu (indicated by the pop-up menu icon).
tab group Describes two or more views that appear in a tabbed notebook
format called a tab group. You can move the views together as a
unit or move each view independently in the tab group.
content editor Serves as the area of the perspective where you perform an action
on an object selected from a view. The type of editor that opens in
the content editor depends on the type of object or action you select
from a view.
All editors contain:
A tab with the object name on it.
A system menu which you access by choosing Window =>

Navigation => Show System Menu or right-clicking the
content editor title tab.
Icons to minimize, maximize, and restore the editor to its

original size and location.
When you have multiple content editors open, they appear as

named tabs in the content editor pane of the perspective.
For more information, see Content editors on page 78.
Quick Access (CTRL+3) Brings up a window that lets you specify a filter to access
commands and resources. For more information, see Navigating the
console using Quick Access on page 72.

Quick tour of the console

The BMC Server Automation Console is a single application window that contains
global menus, a simple toolbar, and a perspective.
A perspective is a configuration of different types of panes called views, plus a pane

called the content editor. Sometimes a single pane contains multiple views that
operate as a single element called a tab group. Depending on the perspective, one
view might contain objects or resources while another view could contain a list of all
the jobs currently running. The primary element of each perspective is the content
editor.
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.
If you are opening a:
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.
Microsoft Word document on a Windows computer on which Word is installed

The document opens using Word inside the system by means of object linking
and embedding (OLE)
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.
Perspectives and views

BMC Server Automation provides several preconfigured views called perspectives,
which you can customize to suit your needs.
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.
Menus and toolbars

In addition to perspectives, views, and content editors, other important features of
the console include the main menu, the main toolbar, and the shortcut toolbar. Note
that menus and toolbars may change depending on the tasks and features available
in the current perspective.
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.
To save a customized perspective, add it to the list of preconfigured perspectives.

From the main global menu, select Window => Save Perspective As. At the prompt,
provide a name for the new perspective.

BMC Server Automation perspectives and views

A perspective is a visual configuration of elements for organizing your work space.
A view is an element of a perspective, organized around a specific work theme.
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.
For more information, see
Preconfigured perspectives and views on page 67
Classic perspective (default) on page 68
Working with perspectives and views on page 68
Preconfigured perspectives and views

BMC Server Automation provides preconfigured perspectives and views.
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.

Classic perspective (default)

The default, or Classic, perspective is the general purpose perspective that opens the
first time you run the console.
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.
Working with perspectives and views

You can arrange the preconfigured perspectives using the views and the underlying
perspective grid.
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.
You can work with perspectives and views as follows:
To navigate perspectives and views using a menu on page 69
To open a perspective on page 69
To reset perspective defaults on page 69
To customize a perspective on page 69

To save a customized perspective on page 70
To open a new view on page 70
To move and dock a view on page 70
To move a tab group on page 70
To detach a view from the perspective grid on page 70
To reattach a view to the perspective grid on page 71
To minimize and maximize a view or tab group on page 71
To resize a view on page 71
To navigate perspectives and views using a menu
1 Choose Window => Navigation => navigationOption.
To open a perspective
Choose Window => Open Perspective => perspectiveName.
Choose Open Perspective in the perspective title tab and choose a perspective.
Choose Other to see all available perspectives and select one.
To reset perspective defaults
1 Choose Window => Reset 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.
The Customize Perspective - perspectiveName dialog box opens.
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.
Click OK to apply changes.
To save a customized perspective
1 Choose Window => Save Perspective As.
2 Enter a name for the new perspective and click OK.
To open a new view
1 Choose Window => Show View => viewName.
To move and dock a view
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.
To move a tab group
1 Right-click in one of the tab title bars.
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.
To detach a view from the perspective grid
1 Right-click the view tab.
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.

To reattach a view to the perspective grid
Click the tab title bar to change the view back to an attached view.
Right-click the view title tab and clear Detached.
To minimize and maximize a view or tab group
Use the minimize and maximize buttons on a view or tab group.
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 toggle between minimize and maximize, enter Ctrl + M.
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.
2 Resize to accommodate your content.
Global capabilities of the console

BMC Server Automation has a global menu bar and a limited global toolbar. You can
initiate most operations in BMC Server Automation using the options on these bars.
You can also right-click an object and choose from context sensitive menu options.
The following sections describe other BMC Server Automation global capabilities:
Navigating the console using Quick Access on page 72

Limiting objects using filters on page 73
Clearing filters on page 74
Paging through multiple objects on page 74
Paging through job results on page 75
Running background operations on page 77
Content editors on page 78
Folders view and resource management on page 101
Import and export concepts on page 118
Searching for objects on page 106
Navigating the console using Quick Access

Use the Quick Access pop-up to scan for commands based on entering partial
command syntax.
To use the Quick Access popup
1 Press Ctrl+3. The Quick Access pop-up appears.
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.
4 To see your previous choices, press Ctrl+3.

Limiting objects using filters

To manage a large number of objects, limit the scope of your work by filtering
objects using a string.
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.
To limit objects using filters
1 Open any of the following folders:
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.
3 Use the following filter options:
Specify a string in the Name text box. The string may appear anywhere in the
object name.
Specify a date range in the Date box.
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:
If the Filters dialog box is still open, choose Clear.
Right-click the icon representing the object (smart group, group, folders, and so
on) whose filter you want to clear and choose Clear Filter.
Paging through multiple objects

Several options exist for paging through multiple objects.
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.
To page through objects
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.
Paging through job results

Administrators of large IT infrastructures might want to display the results of job
runs, independent of the number of targets against which the jobs run.
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.
To browse job results
1 In the Jobs folder in the Folders view, navigate to the job whose results you want
to browse.
2 Right-click the job and select Show Results.
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.
Using online help

BMC Server Automation provides online help, including context-sensitive help for
many GUI elements.
The BMC Server Automation online help system corresponds to the information in
the BMC Server Automation User Guide.

To access online Help
1 Select Help => Help Contents.
To access context-sensitive Help
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.
The help may appear in two ways:
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.
To browse Help contents
1 Display the Help in an external window, if it is not already present.
2 Click a topic in the Contents frame at left.
The selected topic appears in the frame at right.
3 Use the Go Back and Go Forward arrows to navigate within the history of
viewed topics.
To search
1 To quickly locate topics on a particular subject in the documentation, enter a

query in the Search field and click GO.
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.
Show results descriptionDisplays the titles and short descriptions of the

topics that match your search criteria.

Running background operations
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.
Running background operations

When you perform an operation that takes a long time to complete, the BMC Server
Automation Console offers the option to run the operation in the background.
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

Content editors
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.
To run an operation in the background
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 Run in Background. The progress dialog box is no longer displayed.

Instead the Show background operations icon appears in the lower right
corner of the console. It indicates an operation is running in the background.
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.
To display additional information about the operation in progress, click

Details. The dialog box expands and shows any background operations that
are currently in progress. To cancel an operation in this list, click Cancel
operation .
If an operation is running in the background, you can click Show background

operations in the lower right corner to display a Progress view. When the
Progress view is open, you can cancel an operation by clicking Cancel
operation.
Content editors
BMC Server Automation integrates multiple editors to provide you with access to
files based on the file type.
The system supports the following content editors:
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.

Content editors
SystemAn operating system editor that is read-only.
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.
Viewing and editing text files using BL Editor

You can use BL Editor for depot files and Network Shell script objects from the
Folders view, as well as while browsing the Servers folder and jobs results.
To use BL Editor
1 Navigate to a text file in one of the following folders:
Depot
Jobs
Servers
2 Right-click a text file and select Open with => BL Editor.

Content editors
The file appears in the content editor.
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.
Viewing and editing Network Shell Script files using ShellEd

ShellEd is the default editor for Network Shell Scripts.
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
1 In the Servers folder, select a server, right-click, and select Browse.
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.
The file appears in the content editor.
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, right-click the file and select Save.
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.

Content editors
6 To close the tab representing the file, click Close in the file title tab.
Viewing files using a tail -f editor

Use the Tail File editor option to monitor the contents of log files dynamically. The
editor retrieves the initial 100 lines (the default value) and continues to monitor and
update the display as new lines are added by other processes.
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.
To use the Tail File Editor
1 Navigate to the Live Browse tab of the object whose log files you want to
monitor.
2 Right-click the log file to monitor and select Tail -f File.
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:
Wrap TextSelect to support text wrapping in the monitored file. Text

wrapping is off by default.
Regular ExpressionSelect to use Java regular expressions. If you check the

Regular Expression box and input an illegal regular repression, you receive an
error message and Apply is disabled. The Regular Expression option is off by
default.
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.
Pause Polling and Resume Polling ButtonEnables you to toggle polling on

and off. By default, polling occurs at 3-minute intervals. (You can modify the
interval by selecting Preferences => BMC => Tail File Options => Polling

Content editors
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.
Setting preferences for text editors

The system ships with default settings that you can modify to suit your work,
including preferences for certain editors.
You can associate editors by file type or content type. You can specify the default
editor for a particular file or content type.
To set preferences for text editors
1 Choose Window => Preferences.
2 Expand General and select Editors.
3 Edit the general editor settings by selecting or clearing options.
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.
Extensions are added in alphabetical order to the list.
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.

Console management
7 Click Apply to implement the new settings or Restore Defaults to return to the
original values.
8 To exit the Preferences dialog box, click OK.
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
1 Select the object you want to open in the content editor.
2 Right-click and choose Open with => Other.
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.
4 To use a third-party editor, select External Program.

Note
When using an external editor, you cannot save changes unless you first copy the
changes into an internal editor.
5 Select one of the external editors from the list or select Browse to view a list of
additional editors.
6 Select the editor and click OK.

Note
If the editor you select is not appropriate for the object, the system generates an
error message.
Console management
Several options let you manage the appearance of the BMC Server Automation console.

Console management
Customizing preferences on page 84
Viewing keyboard shortcuts on page 94
Customizing keystroke combinations on page 94
Customizations for tables and columns on page 95
Refreshing data on page 99
Customizing preferences
The BMC Server Automation Preferences window provides you with a centralized
location for managing the look and behavior of your console.
Preferences are not intended to modify or reference a resource currently defined in

the workspace, for example a job or server. They are intended to tailor editors,
views, or other objects with which you perform operations on a resource. The
changes you make in the Preferences window persist until you make additional
changes or restore the original defaults.
To set and save preferences
1 Choose Window => Preferences.
2 To see preference categories in the hierarchy at left, do one of the following:
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.

Console management
4 To set preferences, refer to Preference settings BMC category on page 85 for

BMC Server Automation-specific preferences and Preference settings General
category on page 89 for general preferences.
5 Select from the following actions:
Choose Restore Defaults to remove preferences.
Choose Apply to activate new preferences.
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.
Preference settings BMC category

The console provides many types of preferences. This section describes preferences
that are specific to BMC Server Automation.
See Preference settings General category on page 89 for a description of

standard Eclipse preferences.

Console management
Preference Setting Options/ Default
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 compliant software in audit resultsShows software items when

they appear on both the master and target servers. Clearing this option
means that audit results only show software items when they appear on
either the master or target server.
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.
Remember most recent live browse objectInstructs the console to

remember the last object you opened using a dialog box and open that object
again the next time you use the same dialog box. For some objects, this can
result in slow performance. If you clear this option, a dialog box does not
open an object by default. This preference is not selected by default.
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.
Always show notification for Move/CopyInstructs the console to display

a dialog box after you do a paste during a move or copy operation. The
dialog box announces that a move or copy is occurring in the background.
This dialog box only appears when you have chosen to run operations in the
background (see Running background operations on page 77). An option
in the dialog box itself also lets you specify whether you want to display the
dialog box in the future.

Console management
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.
Executed by current roleShows all running jobs executed by the

current role.
Executed by current userShows all running jobs executed by the

current user.
File Deploy Options

Parallel processesNumber of parallel deployments you want to occur.
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.
Minimum disk freeMinimum amount of disk space (in kb) for a

destination directory.
Default destination dirDefault destination directory for push jobs.
Default staging directoryDefault directory on repeater hosts that holds

content while it is being copied to destination machines.
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.
Default backup directoryDirectory where a backup of a target file or

directory can be stored.

Console management
Live Browse/Snapshot/ Number of live browse/snapshot/audit results to returnMaximum number

Audit Results Option of items that can be displayed when you select a node while browsing the
Servers folder or while viewing snapshot or audit results.
This limit can also be set for the Application Server. (For more information
about using the blasadmin utility to set a maximum, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Limiting+the
+number+of+results+displayed+when+browsing .) If you enter a value that is
lower than the maximum defined for the Application Server, the limit you enter
takes precedence over the limit set for the Application Server. You cannot set
this value greater than the value that is defined for the Application Server.
Setting this number to 0 indicates no results are displayed.
If you select a node while browsing the Servers folder or select snapshot or
audit results and the potential number of results exceeds the limit defined at the
Application Server level or as a console preference, the results are truncated. An
icon indicating truncation is superimposed on the node. For example, if you
browse a Windows registry (a simple folder icon) and truncation occurs, the
registry icon appears as:
Paging Options Page SizeNumber of items each page displays. The default value is 50 items.
You can specify a value between 1 and 1000. For more information, see Paging
through multiple objects on page 74.
Config Object Dictionary Page SizeMaximum number of server objects that
the Configuration Object Dictionary displays. The default value is 50. This
option does not affect how the Configuration Object Dictionary displays
configuration objects or extended objects.
Execution Task Matrix Page SizeMaximum number of target servers that
appear in a matrix when viewing the results of an Execution Task. The default
value is 100. For more information, see Executing a job through an Execution
Task on page 635.
Tail File Options
Open FilesNumber of Tail File Editors that you can have open
simultaneously. The default is 5; the range is 1 to 10. The more editors you
have open, the more impact it has on performance. To stop polling data to
minimize the performance impact of multiple open files, click Pause.
Initial LinesNumber of lines of string to be retrieved upon the first

request. The default value is 100; the range is 1 to 1000.
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.
Polling Interval (seconds)Number of seconds before retrieving new Tail -f

data. The default value is 3.

Console management
Preference settings General category

The General category of preferences lets you establish the types of behavior
described below.
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
Run the system in the background
Keep next and previous editors, views, and perspectives open
Display the heap status in the status bar
Double- or single-click to open items
Appearance general
Current presentation: BMC Presentation, Classic Presentation, or Default
Override presentation settings
Editor tab positionsTop
View tab positionsTop
Perspectives switcher positionsTop Left
Show text on the perspective title bar
Current theme: Default, Reduced Palette, Classic
Show traditional style tabsenabled
Enable animationsenabled
Enable colored labelsenabled
Appearance colors and fonts
Use filters to narrow selection lists. Use wildcards as place-holders in filters.

Console management
Set preferences for the appearance of dialog boxes, text comparisons, and other
aspects of the interface
Appearance label decorations
Show additional information about items using label decorations.
Compare/patch
General tab
Open compare automatically
Show compare in Outline view when possible
Show additional compare information in status line
Ignore white space when comparing two objects
Automatically save dirty editors before browsing patches
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
Text Compare tab
Synchronize scrolling between both panes of the compare editors
Initially show the original version
Show pseudo conflicts
Connect ranges with one line
Highlight individual changes
When reaching the end or beginning of an element:
Prompt to go to the beginning or the end
Loop back to the beginning or end
Go to the next or previous element
Preview the results of your choices

Console management
Content types
Content types include:
Properties (Preferences)
Refactoring History Files
Refactory History Index
Runtime log files
XML (Ant Buildfiles)
File associationsDisplays the files associated with a specific content type. You can
add new file associations and edit or remove existing associations.
Default encodingSets default encoding for a content type, such as UTF-8.
Editors general
Size of recently opened files list
Show multiple editor tabs in the content editor
Allow in-place system editors
Restore editor to its original state at system startup
Prompt to save on close, even if the editor is still open elsewhere
Close editors automatically, when xx number of editors are open
When editors are dirty or pinned:
Prompt to save and reuse
Open new editor
Editors file associations
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.

Console management
Editors text editors general
Undo history size (default: 200 mb)
Displayed tab width: 4
Insert spaces for tabs
Highlight current line
Show print margin
Print margin column: 80
Show line numbers
Show range indicator
Show white space characters
Show affordance in hover on how to make it sticky
When mouse moves into hover:
Close hover
Enrich immediately
Enrich after delay
Enrich on click
Enable drag and drop of text
Warn before editing a derived file
Smart caret positioning at the line start and end
Appearance color options
Editors text editors accessibility
Use custom caret
Enable thick caret
Use characters to show changes in vertical ruler

Console management
Editors text editors annotations
Shows preference settings available by annotation type
Editors text editors hyperlinking
Shows preference settings for the type of hyperlinking navigation enabled and the
default modifier key
Editors text editors linked mode
Shows preference settings for ranges by range type
Editors text editors quick diff
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.
Editors text editors spelling
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
Identify any associated web browsers.

Console management
Viewing keyboard shortcuts

BMC Server Automation uses standard keystroke combinations for common
commands as well as less common commands. Using keyboard shortcuts can make
your work easier and faster.
For example, Ctrl+C is the same as choosing Edit => Copy .
The system provides a quick review of all the keystroke combinations in a simple,
filterable window.
To view keyboard shortcuts
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.
Customizing keystroke combinations

You can customize keystroke combinations to meet your needs.
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.
To customize keystroke combinations
1 Choose Window => Preferences. Expand General and click Keys.
2 Select the default keyboard scheme or EMACS, the Apple MacIntosh editor
keyboard command scheme.

Console management
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.
To see all commands again, click Clear to clear the filter.
4 Select the command you want to modify from the list.
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.
7 Select one or all of the following actions:
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.
To activate new or changed keystroke combinations you have made, select

Apply.
8 Click OK to exit the Preferences window. The console automatically saves your
preferences.
Customizations for tables and columns

If the system presents data in a table format, you can customize the columns in the
tables.
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.
Types of tables include:

Console management
Fixed-column tablesDisplay a fixed number of columns that are predetermined.

You may choose which columns to display but you cannot add to the original
configuration. See Customizing fixed-column tables on page 96
Group Explorer tablesDisplay a default number of columns but the number of

columns you can add to the table is limited only by the number of properties
available for the object. See Customizing Group Explorer tables on page 96.
Custom configuration object tablesDisplay a default number of columns but the

number of columns you can add to the table is limited only by the number of
properties available for the object. See Customizing custom configuration object
tables on page 97.
Customizing fixed-column tables

You can customize a fixed-column table.
To customize a fixed-column table
1 Right-click inside the table and choose Customize Columns.
A Column Customization window opens.
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.
Customizing Group Explorer tables

Group Explorer tables display information about a parent object. You can select the
parent object in a content editor or in the Folders view when viewed in table format.
You can tailor Group Explorer tables, including adding attributes or properties as
columns.
To customize columns in a Group Explorer table

Console management
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.
5 In the Ascending/Descending column, click to choose whether you want to sort

from highest to lowest (Ascending to Descending) or lowest to highest
(Descending to Ascending).
arrows at right.
7 To expand the Column Customization window, click beside Format. For

more information, see Formatting columns on page 98.
Customizing custom configuration object tables

Custom configuration objects display tables with many columns but relatively few
rows. To make the tables more manageable, you can select which columns to display.
To customize columns in a custom configuration object table.
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.
arrows at right.
5 To expand the Column Customization window, click beside Format. For

more information, see Formatting columns on page 98.

Console management
Customizing columns from a pop-up menu

You can customize a fixed-column table from a pop-up menu.
To customize columns from a pop-up menu
1 Right-click the header of any column of information.
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.
Changing the sort order of a column

You can change the sort order of a column.
To change the sort order 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
1 In the Column Customization window, click beside Format to expand the

Column Customization window.
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.

Console management
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.
7 To apply changes and view the formatted table, click OK.
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.
Although the product automatically refreshes information, it is a good practice to

refresh manually on a regular basis.
To refresh data
1 To refresh, do any of the following:
Choose File => Refresh.
Select Refresh from a pop-up menu (available by right-clicking in most contexts).
Press F5.
Click Refresh .
To refresh a hierarchical object, select the parent object and then select Refresh.

Console management
Dragging and dropping jobs and targets

Dragging and dropping jobs and targets saves you from stepping through wizards.
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.
Before you begin
At minimum, ensure that you have Read, Execute, and ModifyTargets

authorizations for the job. For example, to execute an Audit Job, your role must
have, at minimum, AuditJob.Read, AuditJob.Execute, and AuditJob.ModifyTargets
authorizations.
To drag and drop a job against specific targets
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.
2 Release the job or target.
The Execute Job window appears.
3 To execute the job immediately, click OK.

Folders view and resource management
If necessary, you can specify additional targets before executing the job.

The BMC Server Automation Folders view is a general purpose view that provides
access to all BMC Server Automation resources.
The Folders view contains the following folders:
Components folder on page 101
Component Templates folder on page 101
Depot folder on page 102
Devices folder on page 102
Jobs folder on page 102
RBAC Manager folder on page 103
Search on page 103
Servers folder on page 103
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.
Component Templates folder

The Component Templates folder holds all component templates that your role is
authorized to see.
Using this folder, you can create and edit component templates and components,
run Snapshot, Audit, and Component Discovery Jobs, and change the properties and

permissions of a component template. For a complete description of the Component

Templates folder, see Components and component templates on page 351.
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
Network Shell scripts
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.

RBAC Manager folder

The RBAC Manager folder lets you define roles that correspond to organizational
entities, such as QA engineers or web administrators, and then assign authorizations
to the roles.
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.
Creating new objects

Use the Folders view to see objects in the BMC Server Automation Console and to
populate all subfolders.
To create a new object
1 Use the New menu to create new objects as follows:

Folder content organization
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.
In the Folders view, right-click a folder (Component Template, Component,

Depot, Devices, Jobs, Servers) or an object in a folder. Choose New =>
resourceType to open the appropriate wizard. For example, expand the RBAC
Manager folder. Right-click ACL Template. Choose New => ACL Template to
open the Create New ACL Template wizard.
Using the Active Node view

The Active Node view provides information about an object that is currently selected
in the Folders view.
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.
2 Select another server or job.
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."

Use the BMC Server Automation Console to organize the contents of functional areas
into folders, groups, and smart groups.

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.
Folder Folders Groups Smart Groups

Jobs, Depot, Devices, Component Yes No Yes
Template
Devices No No Yes
Servers, Components No Yes Yes
RBAC Manager No No No
To define folders, groups, and smart groups, use the following procedures:
Searching for objects on page 106
Creating a folder or group on page 107
Defining a smart group on page 108
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.
Searching for objects

You can search for BMC Server Automation resources and objects.
A simple search returns objects in a Search view. A BMC Server Automation

resource search returns objects as nodes under Search in the Folders view. BMC
Server Automation search returns are available until you save them to a Smart
Group or until you perform another search.
To search for objects
1 From the toolbar, click Search .
2 Click Customize to open the Search Page Selection dialog box.
3 Check BMC BladeLogic Search and click OK.
4 Select the type of object for which you want to search.
Component Templates
Components
Depot
Jobs
Servers
5 For Match, select one of the following:
anyObjects must match at least one of the membership conditions you define
(equivalent to a logical or for the conditions you specify).

allObjects must match all of the membership conditions you define

(equivalent to a logical and for the conditions you specify).
6 To specify the search criteria, do the following:
In the next drop-down box to the right, select the name of a property. For
example, select DATE_CREATED.
In the next drop-down box to the right, select a comparison-operator, such as

begins with, is one of, or is before.
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.
7 Click Search. To see the results, expand Search.
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).
Creating a folder or group

You can create a folder or group. When creating a folder or group, you can nest a
folder within a folder or a group within a group.
To modify an existing folder or group, see Setting values for system object
properties on page 161.
To create a folder or group

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.
3 Click Next. The Permissions panel appears.
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.
4 Define permissions for the folder or group and click Finish.
Defining a smart group

Smart groups are groups for which you define membership conditions based on
object properties.

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.
To define a smart group
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:
Smart Group General on page 110
Smart Group Permissions on page 111
3 Click Finish.
The new smart group is created. Objects matching the conditions you have
specified automatically populate the group.

Smart Group General

The General panel lets you identify a smart group and define its membership
conditions.
Name
Identifying name.
Description
Optional descriptive text.
Member of
Click Browse to navigate to a folder where you want to add this smart
group.
Match
Select one of the following options:
anyObjects must match at least one of the membership conditions you

define (equivalent to a logical or for the conditions you specify).
allObjects must match all of the membership conditions you define

(equivalent to a logical and for the conditions you specify).
Condition list
To define member conditions, perform the following steps:
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.
3 In the next drop-down box to the right, select a comparison-operator, such

as begins with, is one of, or is before.

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.
Smart Group 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.
Adding an ACL template
An ACL template is a group of predefined authorizations granted to roles. Using an

ACL template, you can add a group of authorizations to the object.
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.
Adding an ACL policy
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.
Copying, cutting, and pasting groups, folders, and system

objects
When using the Folders view, you can copy and paste or cut and paste folders,
groups, smart groups, and most types of system objects.
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).
To cut, copy, and paste
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.
2 Right-click and select Copy or Cut from the pop-up menu.
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.
Default permissions for cutting and pasting

You can control permissions when cutting and pasting.
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.
For information about using blasadmin to set the UseDefaultAclOnObjectCopy

option, which controls how permissions are assigned during copy and paste
operations, see BMC technical documentation at https://docs.bmc.com/docs/
display/bsa82/Controlling+the+permissions+of+copied+objects.
Deleting a folder, group, smart group, or system object

You can delete a folder, group, smart group, or system 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.
To delete a folder, group, smart group, or system object
1 Open any folder and navigate to the folder, group, or system object you want to
delete.
Use Control-click or Shift-click to select multiple folders, groups, or objects.
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 no folders, groups, or system objects have dependencies on other objects or you

selected the Skip dependency view... option in the previous step, the Delete
dialog box shows the results of your actions. A green check indicates an object
was successfully deleted. Proceed to step Step 7 on page 115.
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.

Properties, Permissions, and Audit Trail tab group
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.
7 To close the Delete dialog box, click Close.
Finding system objects with broken dependencies

You can find system objects with broken dependencies by using the
BROKEN_OBJECT property.
All objects have an intrinsic property called BROKEN_OBJECT. By default, this

property is set to False. When a dependency on another object is broken, the
BROKEN_OBJECT property is automatically set to True.
To find system objects with broken dependencies
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, Permissions, and Audit Trail tab

group
Most objects in BMC Server Automation include properties, permissions, and an
audit trail. When you select an object, the Properties, Permissions, and Audit Trail
tab group includes tabbed views that show current data for that object.

Properties, Permissions, and Audit Trail tab group
For information about these views, see:
Properties view on page 116
Permissions view on page 117
Audit Trail view on page 117
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.
In the Properties view, three categories of properties exist:
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.

Viewing dependencies
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.
For an extensive discussion of permissions, see Access control overview on page

165. For a detailed description of using the Permissions view to define permissions
for system objects, see Defining permissions for a system object on page 231.
Audit Trail view

The Audit Trail view provides a record of who has sought authorization for specific
actions on the current object.
Each audit trail entry records the following information:
Date when a user requests authorization to access the object
Role trying to access the object
User who has assumed a role in the current session
Authorization requested
Status (success or failure)
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

Import and export concepts
upward point of view). By default, an upward view of dependencies is displayed.

The console displays dependencies in a tab called Dependency display in the content
editor.
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
1 In the Component Templates, Depot, or Jobs folder, select an object.
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.
3 Using the dependency view, do any of the following:
To switch to a downward view, click the Downward tab.
To show dependencies for a particular level, expand that level.
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.

BMC Server Automation lets you import and export objects.
You can import and export the following types of BMC Server Automation objects:
BLPackages
Configuration files

Component templates
Depot software
Extended objects
Files
Jobs (all job types with the following exceptions):
Application Discovery
Deregister Configuration Objects
Distribute Configuration Objects
Patching (all operating systems)
Provision
Upgrade Model Objects
Virtual Guest
Network Shell Scripts
Smart group definitions for components, component templates, depot objects,

jobs, and server smart groups (actual contents of the smart group are not exported)
Snapshots (that is, a job run of a Snapshot Job)
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.
Import prepackaged content provided by BMC Server Automation.

Package problematic objects so they can be forwarded to BMC Server Automation

support for diagnosis.
Promote application changes between functional areas of an organization, such as

when you promote functionality from a development environment to a
production environment.
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.
Exporting BMC Server Automation objects

You can export system objects from BMC Server Automation to a file system.
If you export an object that includes references to network-based objects, the

referenced objects are not exported. Only referenced objects stored on the file server
are exported. For example, if a BLPackage includes network-based software
packages, those packages are not exported. Only the references to those packages are
exported.
Note
To export to machines other than your local machine, you must have, at minimum,
the Server.Browse authorization.
To export an object

In the Component, Component Templates, Depot, Jobs, or Servers folder,

select one or more of the following:
BLPackages
Component templates
Depot software
Files
Jobs (any type with the following exceptions):
Application Discovery
Deregister Configuration Objects
Distribute Configuration Objects
Patching (all operating systems)
Provision
Upgrade Model Objects
Virtual Guest
Network Shell Scripts

Smart groups
Snapshots (that is, a job run of a Snapshot Job)
System packages
Select Configuration => Config Object Dictionary. Then, select one or more
configuration files or extended objects in the left pane of the Config Object
Dictionary.
2 Right-click and select Export from the pop-up menu.
The Export window opens.
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:

Exclude Option Displays When You Export:
Exclude BLPackages Audit Jobs

Batch Jobs
Compliance Jobs
Component Templates
Deploy Jobs
Snapshot Jobs
Exclude Compliance Jobs Batch Jobs
Exclude Component Templates Audit Jobs

Batch Jobs
Compliance Jobs
Component Discovery Jobs
Deploy Jobs
Snapshot Jobs
Exclude Deploy Jobs Batch Jobs
Exclude Depot Files Audit Jobs

Batch Jobs
BLPackages
Compliance Jobs
Component Templates
Deploy Jobs
Snapshot Jobs
Exclude Discovery Jobs Batch Jobs
Exclude NSH Scripts Batch Jobs

Network Shell Script Jobs
Exclude NSH Script Jobs Batch Jobs
Exclude Software Audit Jobs

Batch Jobs
Compliance Jobs
Component Templates
Deploy Jobs
Snapshot Jobs
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.
6 If the object being exported is a BLPackage, or it refers to a BLPackage (such as a

component template), and you want to convert soft links in the BLPackage to
hard links, check Convert BLPackage soft links to hard links.
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.
7 If the object being exported is a configuration file or extended object that

references a custom grammar and you want to export the grammar with the
object, check Include referenced grammar files.
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.
Importing BMC Server Automation objects

You can import system objects from a file system into BMC Server Automation.
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
In the Component, Component Templates, Depot, Jobs, or Servers folder,

select the folder or group to which you want to import an object. Right-click
and select Import from the pop-up menu.
Select Configuration => Config Object Dictionary. Then, click Import

Configuration Object .
The Import wizard opens.
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.
3 Use the Import wizard, as described in the following sections:
Import Select Import Source Directory on page 125

Import Import contents on page 126
Import Select destination grammars on page 126
Import Select destination group on page 127
Import Select remediation groups on page 127
Import Map Missing Servers and Server Groups on page 128
Import Map Missing Properties on page 129
Import Property Values Mapping on page 130
Import Map Existing System Package Types on page 131
Import Map Missing BLPackages on page 132
Import Map Missing Component Templates on page 133
Import Map Missing Depot Objects on page 133
Import Map Missing Component Discovery Jobs on page 134
Import Map Missing Compliance Jobs on page 134
Import Map Missing Deploy Jobs on page 135
Import Map Missing Network Shell Scripts on page 135
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.
4 After completing the last step of the wizard, click Finish.
Import Select Import Source Directory

Use the Select Import Source Directory panel to identify the file that contains the
BMC Server Automation object you want to import.
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.
Automatically map or create export groups
Check to instruct the import process to automatically map imported objects

to a group structure on the importing system that matches the exporting
system. If necessary, the import process creates groups to make the group
structure on the import system match the exporting system.
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.
Import Import contents

The Import contents panel shows all of the objects that are created by importing this
object. Objects are displayed in a hierarchical tree.
The Import contents panel is for review only; you cannot modify its contents.
Import Select destination grammars

Use the Select destination grammars panel to map a grammar file that is used to
define a configuration file or extended object to a grammar file that exists on the
importing system.
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.
Import Select destination group

Use the Select Destination Group panel to identify the groups that should contain all
parts of the object you plan to import.
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.
Import Select remediation groups

Use the Select Remediation Groups panel to identify groups to contain objects that a
Compliance Job creates.
If a Compliance Job that you plan to import is defined to automatically remediate

compliance failures, the job must be able to automatically create Deploy Jobs that
deploy BLPackages. If more than one Deploy Job is created, the Compliance Job
must also be able to create a Batch Job to run all the Deploy Jobs.
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.
Import Map Missing Servers and Server Groups

Use the Map Missing Servers and Server Groups panel to identify a server to replace
a server referenced by the object you plan to import.
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.

Import Map Missing Properties

Use the Map Missing Properties panel to identify properties to replace properties
referenced by the object you plan to import.
When an imported object references properties, the import process automatically

maps the properties to existing properties if the existing property has the same
name, is the same type, and belongs to the same property class. If the imported
object references properties that are not defined for your installation, the Import
wizard displays this panel.
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.
If all mappings seem appropriate, the procedure is complete. If a property is

not mapped or you want to change a mapping, in the Property Selection list,
select a property and click Change Property Mapping .
When the Select Property dialog box opens, you can do one of the following:
From Property, select a property to replace the property you selected in

the Property Selection list.
You can only select a property that belongs to the same property class and
is the same property type as the property being replaced.
Click Add to add the selected property to a class in the Property

Dictionary. A dialog box opens. Use the dialog box to define the property
and add it to the Property Dictionary. (For details, see Adding or
modifying properties on page 152. After you add the property to the
Property Dictionary, select the newly-added property from the Property
drop-down list in the Select Property dialog box.
On the Select Property dialog box, click OK. Repeat this process for each
property in the list that is not properly mapped.
Import Property Values Mapping

Use the Property Values Mapping panel to provide a value for a property when you
are importing a property that is required for a custom property class but no default
value is defined for that property on the importing system.
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 does not exist.
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.)
In these circumstances, the imported object includes an instance of a custom

property for which a property is required but no value exists for that property.
Consequently, you must define a value for the property to continue using the Import
wizard.
Field definitions
Missing Property Name
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.
Import Map Existing System Package Types

Use the Map Existing System Packages Type panel to identify the type of system
packages you plan to import.
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
System Package Type Selection
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.
Choose Select an existing package type. Then, from Choose an existing

system package type, choose an existing system package type.
Repeat this process for each system package type in the System Package Type
Selection list.
Import Map Missing BLPackages

Use the Map Missing BLPackages panel to identify a BLPackage to replace a
BLPackage referenced by the object you plan to import.
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.
Repeat this process for each BLPackage in the list.

Import Map Missing Component Templates

Use the Map Missing Component Templates panel to identify a component template
to replace a component template referenced by the object you plan to import.
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
Component Template Selection
In the Component Template Selection list, select a component template and

click Change Component Template Mapping .
When the Component Templates dialog box opens, navigate to the

component template to replace the missing component template you have
selected and click OK.
Repeat this process for each component template in the list.
Import Map Missing Depot Objects

Use the Map Missing Depot Objects panel to identify depot files and software to
replace depot files and software referenced by the object you plan to import.
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
Depot Object Selection
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.
Repeat this process for each depot object in the list.
Import Map Missing Component Discovery Jobs

Use the Map Missing Component Discovery Jobs panel to identify Component
Discovery Jobs to replace Component Discovery Jobs referenced by the Batch Job
you plan to import.
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
Component Discovery Jobs Selection
In the Component Discovery Jobs Selection list, select a Component

Discovery Job and click Change Component Discovery Job Mapping .
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.
Import Map Missing Compliance Jobs

Use the Map Missing Compliance Jobs panel to identify Compliance Jobs to replace
Compliance Jobs referenced by the Batch Job you plan to import.
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
Compliance Jobs Selection
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.
Repeat this process for each Compliance Job in the list.
Import Map Missing Deploy Jobs

Use the Map Missing Deploy Jobs panel to identify Deploy Jobs to replace Deploy
Jobs referenced by the Batch Job you plan to import.
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
Deploy Jobs Selection
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.
Repeat this process for each Deploy Job in the list.
Import Map Missing Network Shell Scripts

Use the Map Missing NSH Scripts panel to identify Network Shell scripts to replace
scripts referenced by a Network Shell Script Job you plan to import.

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
NSH Scripts Selection
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.
Repeat this process for each script in the list.
Exporting templates using a version-neutral mechanism

A version-neutral mode of export is available for exporting component templates
along with their payloads and referenced objects.
Note
The version-neutral export and import mechanism does not support the export of a
component template that uses remediation BLPackages containing soft links to other
depot objects.
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.
The version-neutral export process creates an easily readable, XML-based content

format file. The content format file is described in Content format on page 1461.

Note
To export to machines other than your local machine, you must have, at minimum,
the Server.Browse authorization.
To export component templates
1 In the Component Templates folder, right-click a component template or a

component template group or folder and select Export.
The Export window opens.
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 Server Objects
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.
5 To include referenced custom grammar files, select the Include referenced

grammar files check box.
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.

Importing templates using a version-neutral mechanism

Use the version-neutral import process to import component templates along with
their payloads and referenced objects. This import process works with any zipped
export package created during a version-neutral export process or created manually
outside of the BMC Server Automation environment.
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.
To import component templates
1 In the Component Templates folder, right-click the component template group or

folder to which you want to import the component templates and select Import.
The Import wizard opens.
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.
4 On the Import Template Selection panel, set the following specifications of

template import:
Select templates to import
In the hierarchical presentation of the folders and templates contained within

the export package that you are importing, select the folders or individual
templates to import.

Handling of existing dependencies
Choose one of the following options for handling objects that are referenced
by the imported templates and already exist on the target system:
Overwrite existing objectsOverwrite the objects that exist on the target

system with the objects from the source system.
Keep existing objectsKeep the objects that exist on the target system.
Abort if there are conflicts with existing objectsTerminate the import

process without importing any objects if conflicts are discovered.
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:
Preserve source group pathReconstruct the folder path and hierarchy

exactly as they exist on the source system and store the imported templates in
the same folders.
Locate templates under selected group (flat)Store all imported templates in

the folder that you selected in Step 1 on page 138, with no hierarchical nesting.
Locate templates under selected group (preserve path within node)

Reconstruct the folder hierarchy that exists on the source system under the
folder that you selected in Step 1 on page 138, and store the imported
templates in the same folders.
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.

Run a preview in the background by selecting the Run preview in the

background check box and then clicking Finish.
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.
Import object status and action

All objects that are planned to be imported are first analyzed and compared to any
equivalent objects that may already exist on the target system. The results of this
analysis determine the status of each object and the action to be performed on the
object. You can see the status and action for each object when you run an import
preview.

The following table describes possible statuses for import objects:
Status Description
New Object on the source system does not exist on the

target system.
Obsolete Object that exists on the target system is missing on
the source system.
Identical Exact same object exists on both the source system
and the target system.
Changed Object exists on both the source system and the
target system, but has been changed on the source
system.
Compatible Object exists on both the source system and the
target system, and are compatible but not the same.
For example, a property class to which a new
property has been added on the source system.
Exists Object has an associated payload on both the source
system and the target system, but the payload on the
source system cannot be compared to the payload on
the target system. The object is treated as a changed
object.
Missing Object on the source system is missing its associated
payload.
The following table describes the possible actions for import objects:
Action Description
Create New object is created on the target system.

No Action Existing object is used (and will not be updated).
This is the standard action for an existing identical
object, and also for a changed object if you chose the
Keep existing objects option in the Import wizard.
This is also the action for an object that exists on both
the source system and the target system but is
missing its associated payload on the source system.
Update Existing changed object on the target system is
updated according to the object on the source system.
A typical example of a required update is the default
value of a property.
Extend Existing compatible object on the target system is
extended according to the object on the source system.
For example, a property is added to an existing
property class.

Action Description
Fail Import process fails due to an insoluble conflict

between the source and target object.
Examples:
A property with conflicting types
An object that exists only on the source system

but is missing its associated payload
Remove Obsolete object is removed from the target system.

5
Properties
Most system objects in BMC Server Automation have properties associated with
them. Properties define a wide range of characteristics. Typically, you manage
properties using a master list called the Property Dictionary.
Property Dictionary overview

The Property Dictionary is a master list of all properties that can be assigned to
system objects.
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.
The Property Dictionary lets you perform the following procedures:
Tasks related to properties Description

Create hierarchical custom Use BMC Server Automation to create hierarchical custom property
property classes and subclasses classes and subclasses.
You can assign properties to each custom class and subclass. A subclass
inherits all the properties of its parent class. Using inheritance, you can
create complex property sets built from custom classes and subclasses.
Then, you can create multiple instances of these property sets. For each
instance, you can set individual properties to particular values.
Adding a custom property class on page 150
Creating or modifying an instance of a property class on page 155
Viewing and modifying properties for property classes on page 158
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.

Tasks related to properties Description

Associate a custom property class To explicitly associate a custom property class with a system object,
with a system object you must create a property class property, which is a particular type of
property that references another property class or subclass (either
custom or built-in).
The values that you can assign for a property class property are the
instances that have been defined for the referenced property class. For
an extended example illustrating the use of custom property classes,
instances, and property class properties, see Custom property class
description on page 146.
Property class description

Most built-in classes or sub-classes in the Property Dictionary correspond to a type
of system object in BMC Server Automation.
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.
Some common uses for properties are:
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).
Creating parameters, which are references to properties (see Parameters

description on page 146).
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.
On Windows servers, this property might have a value of /c/Program Files/Apache.

On UNIX servers the property might have a value of /usr/local/Apache.
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.
You can use parameters and properties in BLPackages, component templates,

configuration files, and extended objects. Resolving a parameter to a property value
happens at different times. For example, in a component template, a parameter
might get resolved when you discover a component based on that template. For an
extended object, a parameter could be used to identify content when you attempt to
run a job based on the extended object. In all cases, however, the parameter serves as
a reference to a property. The property value is determined when the parameter is
processed.
Custom property class description

Use custom property classes to create complex sets of properties that you can
associate with an object such as a BLPackage.

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 properties ROOT_DIR, APP_DIR, VER_DIR, and LEVEL_DIR. Three instances of

the DEV custom property class are defined.
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.
Acceptable data types for properties

System object properties can accept a variety of data types as input.
The following table describes the types of data that properties can accept, including
limitations inherent to each data type.
Data Type Limitations
Alphanumeric strings 2,000 characters.

Integers A 64-bit signed integer, which can have a minimum
value of -9,223,372,036,854,775,808 and a maximum
value of 9,223,372,036,854,775,807.
Boolean True, false, or null.

Data Type Limitations
Decimal numbers A double-precision 64-bit IEEE 754 floating point

number.
Dates A day/month/year value, designating a point in
time under the Gregorian calendar.
Encrypted string A string that is encrypted. Encrypted strings are
often used to define values for passwords.
Enumerated list of strings A user-defined list.
Enumerated list of integers A user-defined list.
Long blocks of text 2,000 characters, displayed in a text editor format so
new lines can be easily seen. This data type is
typically used for provisioning.
Complex, built-in data such as file permission Regular expression formats provided by the Java
bitmasks and regular expressions Development Kit (JDK) 1.4. Regular expressions are
limited to 2,000 characters.
References to a custom or built-in property class User-defined custom property classes or built-in
property classes.
Adding a custom property class

You can add your own custom property classes using the Property Dictionary.
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.

Before you begin
To perform this procedure, your role must have, at minimum, a

PropertyClass.CreateCustom authorization. For information about granting
authorizations to roles, see Creating roles on page 210.
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.
To add a property class
1 Select Configuration => Property Dictionary View. The Property Dictionary

opens.
2 Select Custom Property Classes or navigate to an existing custom property class

where you want to create a class or subclass.
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
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.
For more information, see Adding or modifying properties on page 152.
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.
7 To save the new custom property class, click Finish.
8 To close the Property Dictionary, click Close.

Adding or modifying properties

You can add properties to both custom and built-in classes. You can also add local
properties to BLPackages and system packages stored in the Depot folder and
component templates stored in the Component Templates folder.
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:
Automatically associated with all jobs.
Inherited by all subordinate built-in subclasses.
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.
Before you begin
Property class properties reference another property class. To apply a custom

property class to an object, you must create a property class property that refers to
that custom property class. Then, assign the property class property to a built-in
property class or create a local property for a BLPackage or component template.
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.
A default value for a required property cannot be deleted.
Options for an enumerated list cannot be removed. You can only add options to
properties that use an enumerated list.
To add or modify a property
1 Do any of the following:
Choose Configuration => Property Dictionary View. Using the Property

Class Navigation pane, select a property class or subclass for which you want
to add or modify a property. In the property list at right, select the Properties tab.
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.
Create a BLPackage, component template, or system package that requires a

local property. Open the BLPackage, component template, or system package
for editing. Click the Local 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 create a new property, click Add New Property .
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.

The name can be a maximum of 255 characters.
4 For Type, select one of the following options:
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.
5 To add another value, repeat the process.
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.
6 Specify additional characteristics for the property by checking any of the

following:
EditableUsers can alter the value of this property.
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).
Used in reportsThis property can be included in reports generated by BMC

BladeLogic Decision Support for Server Automation. This flag is set to true for
most properties provided in a standard installation of BMC Server Automation.
By default it is set to false for all new properties you create.
7 Click OK. The property is added to the list on the Properties tab.
Creating or modifying an instance of a property class

You can create or modify an instance of a property class. An instance is a set of
properties and property values associated with a property class.
Before you begin
Often this procedure is used to create an instance of a custom property class or an

instance of any of the following property classes or subclasses:
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.
To create or modify an instance
1 Choose Configuration => Property Dictionary View.
2 Navigate to the property class or subclass for which you want to create an
instance.
3 Click the Instances tab.
To create an instance of a property class, click Add New Property Set Instance
.
The New Instance wizard opens, displaying the General panel.
To modify an existing instance of a property class, select that instance in the

right pane and click Edit Property Set Instance .
The Modify Instance window appears. This window and the New Instance
wizard differ in that you display panels by selecting tabs instead of stepping
through a wizard.
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
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.
Removing or deprecating a property, custom property class,

or instance
You can remove custom property classes, instances of property classes, or user-
defined properties in a custom or built-in property class.
You cannot remove a property, custom property class, or instance if it is already

being used in BMC Server Automation, as described below:
A property cannot be removed when the property is
Referenced, such as in a parameter or component template signature.
Included in an instance of a custom property class or a component template

property set
A custom property class cannot be removed when
The custom property class is referenced by a property class property
The custom property class has a subclass
An instance of the custom property class exists
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.
An instance of a property class cannot be removed when it is being used as a

value of a property class property.
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.
To remove or deprecate a property, custom property class, or instance
1 Choose Configuration => Property Dictionary View.
2 Using the Property Class Navigation pane, do one of the following:
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 custom property class or subclass 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.
4 If necessary, click Yes to deprecate an item.
Viewing and modifying properties for property classes

For all property classes in the Property Dictionary, you can display a properties
dialog box box. This dialog box box provides tabs that display general identifying
information, permissions, and audit trail entries.
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.
To view and modify properties for property classes
1 Right-click a property class in the Property Dictionary and select Properties from
the pop-up menu. A tabbed dialog box box appears.
2 You can perform the following actions:
Defining permissions for a system object on page 231

Audit Trail view on page 117
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.
To access the Permissions tab
1 In the Property Dictionary, right-click a property class and select Properties from
the pop-up menu.
2 On the resulting dialog box, click the Permissions tab.
To add a set of authorizations for a role
1 From the Permissions tab, click Add Entry . The Add New Entry window
opens.
2 From Role, select a role to which you want to grant permissions.
3 Under Available Authorizations, 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 individual command authorizations, click the Commands tab at the

bottom of the Available Authorizations list. Then, select the command
authorizations you want to make available to the role you chose in the previous
step. The Commands tab is only available when you are assigning permissions
to a server.
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.
To add a predefined set of permissions to one or more roles
1 From the Permissions tab, click Use ACL Template . The Select ACL
Template dialog box opens.
2 Select one or more ACL templates in the dialog box.
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.
To apply ACL policies
1 From the Permissions tab, click Use ACL Policy . The Select ACL Policy
dialog box opens.
2 Select one or more ACL policies in the dialog box.
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
4 Click OK.
To delete an entry
1 From the Permissions tab, select the entry.
2 Click Delete Entry .

Setting values for system object properties
Setting values for system object properties

You can list the properties for an object by selecting it to display the Properties view,
or you can use a wizard to create a system object, which also displays a properties
list. In either case, you can set the value of a system property using the properties list.
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.
To set values for system object properties
1 Do either of the following:
Select an existing system object, which displays that objects properties in the
Properties view.
Display the Properties panel in a wizard.
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.
example, ??MyPARAMETER??) or click the Select Property . For more
Changing property values for one or more

system objects
You can change a property value for one or more system objects.

Changing property values for one or more system objects
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.
You cannot change property values for custom server objects.
To change property values for one or more system objects
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.
To select multiple items, display the contents of a folder in a Group Explorer

view. Then select the items you want to modify.
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:
.
property class.
example, ??MyPARAMETER??) or click Select Property . For more
5 Click OK.
The new value is applied to all selected system objects.

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.
For example, enter ??TARGET.WINDIR?? or ??TARGET.STAGING_DIR??. A

single string can contain multiple parameters such as ??TARGET.ROOT_DIR??/??
TARGET.APP_DIR??/TARGET.VERSION??.
The Property Dictionary supports hierarchical property structures. Parameters

referring to hierarchical properties separate the levels of the hierarchy with a dot. For
example, a parameter such as ??TARGET.DEPLOYPATH?? refers to the
DEPLOYPATH property, which has a parent property of TARGET. (In this example,
TARGET is analogous to the Server built-in property class, because a target for a
Deploy Job is a server.)
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.
Type the parameter delimited by pairs of question marks.
Click Select Property . A list of properties appears. Use the list to do one of
the following:
Select a property from the list.
Display a subordinate list of properties by clicking the right arrow that

appears next to some properties. From this subordinate list, you can select a
property. To return to the parent list, click the left arrow next to the property
at the top of the list.


6
Access management
This section describes how to manage access control for performing actions within
BMC Server Automation.
Access control overview

BMC Server Automation provides a unified and flexible system of access control that
allows you to grant the minimum authorizations needed to perform any action,
thereby limiting security risks.
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.
The following sections describe managing access in BMC Server Automation:
Authorization overview on page 165
Managing authorizations on page 168
Authorization enforcement on page 172
Audit trail management on page 173
Built-in roles and users on page 174
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.
The definition of a system object includes a set of authorizations specifying roles

who can access the object and the actions those roles can perform. You can set
authorizations for all system objects in BMC Server Automation, including objects
that function as resources, such as servers and components.
Performing any action in BMC Server Automation typically requires three levels of
authorization:
Role-based authorizations on page 166
Object-based authorizations on page 166
Resource-based authorizations on page 167
The combination of role-based and object-based authorizations determines a users

effective authorizationsthat is, the actions a role can perform on a system object.
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.
To perform an action such as running a Deploy Job on a server, a role must be

authorized to perform that class of action, such as DeployJob.Execute. However, to
actually run a Deploy Job, the next level of authorizationsobject-based permissions
must also be granted.
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.
To perform some actions in BMC Server Automation, role-based authorization and

object-based authorization are sufficient. However, if you are taking action on any
server object that functions as a resource, such as a server, device, or component, you
must also be authorized for that particular resource.
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.
To perform actions on resources, you typically need three levels of authorization:
Role level
Object level
Target level
For example, to run a Deploy Job on a server:
Your role must be granted the authorizations DeployJob.Read and

DeployJob.Execute.
At the object level, your role must be granted DeployJob.Read and

DeployJob.Execute authorizations for the Deploy Job you want to run.
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.

Managing authorizations
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.
For example, consider a JuniorAdmin role, which is granted a full set of

authorizations on servers (that is, Server.*) at the role level. For a particular server,
however, the JuniorAdmin role is only granted Server.Browse and Server.Read
permissions. Those authorizations are object-based authorizations. A role can only
perform an action that is authorized at both the role level and the object level.
Because the JuniorAdmin role is limited to Server.Browse and Server.Read for the
server in question, the JuniorAdmin role can only read and browse that server.
Those are the roles effective permissions.
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.
Authorizations are permissions to perform specific types of actions in BMC Server

Automation. Two types of authorizations exist:
SystemGrants permission to perform a certain class of action, such as

creating a particular type of job or creating components.
CommandGrants permissions to perform Network Shell and nexec commands.
For more information, see Setting up authorizations on page 177.
2 Create authorization profiles.
An authorization profile is a group of system and command authorizations. After

you create authorization profiles, use them to assign complex sets of system and
command authorizations to roles, objects, and ACL templates. For more
information, see Creating an authorization profile on page 180.
3 Create ACL templates.

An ACL template is a collection of authorizations granted to one or more roles but

not associated with a specific object. After you create ACL templates, use them to
repeatedly assign complex sets of authorizations to system objects throughout
BMC Server Automation. For example, you can define an ACL template that
grants an architect role the right to create jobs, an administrator role the right to
run jobs, and everyone else the right to view jobs. An ACL template can consist of
individual system and command authorizations, authorization profiles, and ACL
policies.
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.
For more information, see Creating an ACL template on page 184.
4 Create ACL policies
Like an ACL template, an ACL policy is a collection of authorizations granted to

one or more roles but not associated with any specific object. Unlike ACL
templates, however, the changes made to an ACL policy automatically take effect
for any object where the ACL policy has been applied. This allows you to
centrally manage ACLs for multiple objects, which is useful for organizations that
employ many server objects with complex sets of 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.
For more information, see Creating an ACL policy on page 189.
5 Create automation principals.
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
6 Create LDAP connections and queries.
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.
A role defines a set of permissions that reflect the responsibilities of an

organizational entity, such as QA engineers, application developers, or web
administrators.
To define these permissions you assign system authorizations, command

authorizations, and authorization profiles to the role. In addition, a role provides
information that determines how a user establishes a connection to an RSCD
agent on a remote server. A role definition lists the users assigned to the role. A
role definition can also specify an ACL template that functions as the object
permissions template. If you plan to synchronize an LDAP user registry with
RBAC, you can associate a role with LDAP connections and queries. For more
information, see Creating roles on page 210.
8 Create users.
Creating a user in the RBAC Manager folder sets up a user account so an

individual can access the BMC Server Automation consoles. When you add a
user, you provide the user with a password and you specify the roles that the user
is assigned to. You can also optionally provide some SRP security settings. For
more information, see Creating users on page 220.
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.
9 Assign object-based permissions.
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.

10 Update permissions for multiple objects.
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.
Automation principals and server management

When using BMC Server Automation to perform actions on a managed server, you
must be granted privileges to act on that server. The approach for granting these
privileges varies between Windows and UNIX servers.
On Windows servers, you can use two possible approaches:
Windows user mappingThe operating system on a managed Windows server

can recognize the identity encapsulated in an automation principal. When BMC
Server Automation performs an action on a managed server, the system can
map one or more roles to an automation principal, in effect mapping those
roles to the identity defined in the automation principal.
User privilege mappingUsers are granted permissions on managed servers

through the BMC Server Automation configuration files.
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.
To set up Windows user mapping, you must define an automation principal in

RBAC and associate it with one or more roles. Then you must associate the
automation principal with a role. For more information, see Creating automation
principals on page 195.

Authorization enforcement
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.
Step during job Use automation principal?

Application Server initiates communication Yes
with agent on target server.
Application server copies payload to repeater. Yes
Repeater copies payload to agent. No
Note: Because automation principals cannot
be used during this step, Deploy and File
Deploy Jobs must rely on user privilege
mapping to copy payloads to target servers
running Windows. In this situation, you
should not disable user privilege mapping
on the agent. Also, you should not remove
the BladelogicRSCD user from the agent.
Agent deploys software on target server. Yes
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.
For servers, an additional layer of access control is available. This enforcement

mechanism employs configuration files on the agent. With these configuration files,
you can restrict all incoming connections to the agent, whether those connections
originate in the BMC Server Automation console, Network Shell, or the BLCLI.
When using configuration files, you can manage access at the agent level by running
ACL Push Jobs (see Creating ACL Push Jobs on page 243). This job uses the
authorizations specified for all roles granted access to a server and generates entries

Audit trail management
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.
Although you may be able to see a no access node, if it represents a hierarchical

object, you cannot see any of the objects children. For example, you can see a no
access server group, but you cannot see any servers in that group.
Audit trail management

Audit trails record who attempts to perform specific actions in BMC Server
Automation.
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

Built-in roles and users
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.

A standard BMC Server Automation installation provides the following built-in roles:
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.
Built-in authorizations are intrinsic to a role. You cannot delete a built-in

authorization. When you look at the definition of a role, you do not see built-in
authorizations explicitly listed.
Out-of-box authorizations are permissions that are automatically assigned to roles

when you initially perform a standard installation of BMC Server Automation.
Unlike built-in authorizations, out-of-box authorizations are visible in RBAC. You
can modify and delete out-of-box authorizations.
By default the built-in roles function as follows:
RBACAdminsBuilt-in authorizations grant the RBACAdmins role Read and

ModifyACL authorizations for all system objects in BMC Server Automation. This
allows the RBACAdmins role to always have access to any system object in BMC
Server Automation. Even if all roles that are granted access to a system object are
deleted, the RBACAdmins role can still modify that objects authorizations so
other roles can then access the object. In addition, out-of-box authorizations grant
the RBACAdmins role authority to perform any actions in the RBAC Manager
folder. For example, the RBACAdmins role can perform any action relating to
roles, users, ACL templates, and authorization profiles. The RBACAdmins role
can be renamed but it cannot be deleted.

BLAdminsBuilt-in authorizations grant the BLAdmins role Read permission for

all system objects in BMC Server Automation. This allows the BLAdmins role to
view all activity within BMC Server Automation. In addition, out-of-box
authorizations grant the BLAdmins role full authority to perform any actions on
any system object in BMC Server Automation except for roles, users, and
authorization profiles. For these, the BLAdmins role is only granted Read
authorization. This default set of authorizations lets the BLAdmins role view any
system object in BMC Server Automation and modify any object except roles and
authorization profiles. The BLAdmins role can be renamed but it cannot be deleted.
GlobalReportAdminsOut-of-box authorizations grant the

GlobalReportAdmins role authority to see and manage data for all reports in BMC
BladeLogic Decision Support for Server Automation. Within BMC BladeLogic
Decision Support for Server Automation, GlobalReportAdmins is granted
additional authorizations that give the role full privileges for using and
maintaining reports. The GlobalReportsAdmins role can be renamed but it cannot
be deleted. By default, no users are assigned to this role.
GlobalReportViewersOut-of-box authorizations grant the

GlobalReportViewers role authority to read all reports at all sites for an
installation of BMC BladeLogic Decision Support for Server Automation. Within
BMC BladeLogic Decision Support for Server Automation, GlobalReportViewers
is granted additional authorizations that give the role full privileges for viewing
reports. The GlobalReportViewers role can be renamed but it cannot be deleted.
By default no users are assigned to this role.
The following table summarizes the authorizations granted to the built-in roles:
Default Role Built-in Authorizations Out-of-box Authorizations

RBACAdmins
Granted Read authorization on all Granted * authorization for all
objects in BMC Server Automation system objects relating to RBAC
(for example, BLPackage.Read). (for example, Role.* and
ACLTemplate.*).
Granted ModifyACL authorization
on all objects in BMC Server Granted Server.PushACL to push
Automation (for example, ACLs to servers.
BLPackage.ModifyACL).
The above authorizations can be
The above authorizations are built-in modified as necessary.
and cannot be modified.

Default Role Built-in Authorizations Out-of-box Authorizations

BLAdmins
Granted Read authorization on all Granted * authorization on all
system objects within BMC Server classes of system objects within
Automation. BMC Server Automation except
the following:
The Read authorization is built-in
and cannot be modified. Role.Read (grants read-only
access to roles)
AuthProfile.Read (grants read-

only access to authorization
profiles)
PatchAnalysisConfig.Modify
(used for modifying the
download locations for
Windows patch analysis
configurations)
The above authorizations can be

modified as necessary.
GlobalReportAdmins N/A Granted all reports-related
authorizations in RBAC, including
Reports.Administration, which allows
the role to manage BMC BladeLogic
Decision Support for Server
Automation.
GlobalReportViewers N/A Granted all reports-related
authorizations in RBAC except
Reports.Administration.
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:
EveryoneA role that is available when assigning object-based permissions.

Granting permissions to the Everyone role is an easy way to make an object
publicly available. For more information, see Defining permissions for a system
object on page 231.

Setting up authorizations
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.
RBACAdmin and BLAdmin users

A standard BMC Server Automation installation also creates two built-in users:
RBACAdmin and BLAdmin.
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.
In the RBAC Manager folder the Authorizations node lets you set up system and
command authorizations.
A system authorization is a permission to perform a specific class of actions in BMC

Server Automation. For example, the DepotGroup.Create authorization lets you
create depot groups while the DepotGroup.* authorization lets you perform any
type of action related to depot groups. For a full listing of all possible system
authorizations, see System authorizations on page 1477. In the RBAC Manager

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.
A command authorization is a permission to perform a specific Network Shell or

nexec command. An nexec command is a command that is not native to Network
Shell. Commands linked to nexec are described using the format (nexec) command
such as (nexec)arp. A standard BMC Server Automation installation includes default
nexec commands. You can also can add and delete custom nexec commands. A
custom nexec command can consist of actions that can be executed using the
Network Shell nexec command, including scripts stored on remote servers.
To set up authorizations
1 Using the Authorization node, you can perform the following procedures:
Adding or modifying an nexec command on page 178
Deleting an nexec command on page 179
Defining audit trails on page 179
Adding or modifying an nexec command

Use this procedure to add an nexec command to those managed with RBAC or to
modify an existing nexec command.
To perform this procedure, you must have, at minimum, the Authorization.Create

system authorization.
To add or modify an nexec command
1 In the RBAC Manager folder, expand Authorizations.
2 Under Authorizations, select Commands.
Create an nexec command by right-clicking and selecting New => Nexec

Command from the pop-up menu. The Command Creation wizard appears.
Modify an existing nexec command by selecting the command in the contents

pane of the RBAC administration console, right-clicking, and selecting Open
from the pop-up menu. The Command Information view opens. It provides the
same fields as the Command Creation wizard.

4 For Name, enter the name you are assigning to the nexec command. Do not
include nexec. RBAC automatically attaches nexec to the command.
5 Optionally, for Description, enter a description of the command.
6 To close the wizard and save your changes, click Finish.
Deleting an nexec command

You can delete a custom nexec command from the RBAC Manager folder.
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.
To perform this procedure, you must have, at minimum, the Authorization.Delete

system authorization.
To delete a custom nexec command
2 Under Authorizations, select Commands.
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.
Defining audit trails

An audit trail is a record of those who seek authorization for specific actions in BMC
Server Automation.
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.
To define audit trail preferences, your role must be granted the

Authorization.Modify authorization.

Creating an authorization profile
To define an audit trail
2 Under Authorizations, expand System Authorizations.
All possible system authorizations in BMC Server Automation are displayed

under the System Authorizations node.
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.
5 To set up notifications that are sent when an authorization is successfully

requested or when an authorization request fails, under Success or Failure, do
any of the following:
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
sysadmin@bmc.com;sysmgr@bmc.com.
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.

An authorization profile is a group of system and command authorizations.
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.
You can use authorization profiles in the following contexts:
Defining authorizations for roles (see Creating roles on page 210).

Granting permissions to individual system objects (see Defining permissions for a

system object on page 231).
Specifying authorizations in an ACL template (see Creating an ACL template on

page 184).
Assigning authorizations to an ACL profile (see Creating an ACL policy on page

189).
To create an authorization profile
You can use the following procedure to create an authorization profile.
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.
1 In the RBAC Manager folder, select Authorization Profiles.
2 Create a new authorization profile by right-clicking and selecting New =>

Authorization Profile from the pop-up menu. The Authorization Profile Creation
wizard appears.
3 Provide information for the authorization profile, as described in the following

sections:
Authorization profile Authorizations on page 181
Authorization profile Permissions on page 182
4 To close the wizard and save your changes, click Finish at any time.
Authorization profile Authorizations

The Authorizations panel lets you identify an authorization profile and select the
system and command authorizations to include.
Field definitions
Name
Identifying name.
Description

SystemCommand
In the list under Available Authorizations, do any of the following:
To assign individual system authorizations, click the System tab at the

bottom of the Available Authorizations list. Then, select system
authorizations.
To assign individual command authorizations, click the Commands tab at

the bottom of the Available Authorizations list. Then, select commands.
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.
Authorization profile Permissions

The Permissions list is an access control list (ACL) granting roles access to objects
created in the system, such as jobs, servers, or depot objects.
this object.
you want to add.



Modifying authorization profiles

You can modify an authorization profile.
To modify an authorization profile
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.

Creating an ACL template

An ACL template is a set of authorizations that are not associated with any system
object.
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).
Granting permissions for an individual system object (see Defining permissions

for a system object on page 231).
Updating permissions for a group of system objects (see Updating permissions for
one or more system objects on page 235).
Defining another ACL template.
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:
1 You create an ACL template that grants AuditJob.* to Current Role.
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.

To create an ACL template
1 In the RBAC Manager folder, select ACL Templates.
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:
ACL template General on page 185
ACL template Template Access Control List on page 185
ACL template Permissions on page 187
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.
ACL template General

Use the General panel to provide a name and description for the ACL template.
Field Definitions
Name
Identifying name.
Description
ACL template Template Access Control List

The Template Access Control List panel lists roles that are granted a particular
system authorization, command authorization, or authorization profile. You can also
assign authorizations using ACL policies.
Use this panel to perform the following tasks:
Adding authorizations for a role on page 186
Adding predefined permissions to a role on page 186

Applying ACL policies on page 187
Deleting an entry on page 187
Adding authorizations for a role

You can add a set of authorizations for a role.
To add authorizations for a role
1 Click Add Entry . The Add New Entry window opens.

to a server.
Use Shift-click or Control-click to select multiple authorizations. Click the right

4 Click OK.
5 To add authorizations for another role, repeat steps 1 through 4.
Adding predefined permissions to a role

To add a predefined set of permissions to one or more roles, use an ACL template.
To add predefined permissions to a role
1 Click Use ACL Template . The Select ACL Template dialog box appears.
2 Select one or more ACL templates from the dialog box.

3 To set the contents of the selected ACL templates so they replace all entries in the
set of permissions with the contents of an ACL template is particularly useful for
promoting a system object between roles.
4 Click OK.
Applying ACL policies

You can apply ACL policies (sets of permissions that are centrally managed).
1 Click Use ACL Policy . The Select ACL Policy dialog box appears.
2 Select one or more ACL policies on the dialog box.
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.
set of permissions with the contents of an ACL template is particularly useful for
4 Click OK.
Deleting an entry
You can delete an entry.
To delete an entry
1 Select the entry and click Delete Entry .
ACL template Permissions


this object.
you want to add.



Creating an ACL policy
Modifying ACL templates

You can modify an existing ACL template.
To modify an ACL template
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.
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.

Use an ACL policy to manage a group of authorizations in one location that
automatically applies to multiple system objects.
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.
To create an ACL policy
1 In the RBAC Manager folder, select ACL Policies.
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:

ACL policy General on page 190
ACL policy Policy Access Control List on page 190
ACL policy Permissions on page 194
ACL policy General

Use the General panel to provide a name and description for the ACL policy.
Field Definitions
Name
Identifying name.
Description
ACL policy Policy Access Control List

The Policy Access Control List panel provides a list of roles that are granted a
particular system or command authorization, and enables you to specify time
periods or maintenance windows.
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.
Use this panel to perform the following tasks:
Adding authorizations for a role on page 191
Adding predefined permissions to a role on page 191
Creating and modifying a maintenance window on page 192
Deleting an entry on page 193

Adding authorizations for a role

You can add a set of authorizations for a role.
To add authorizations for a role
1 Click Add Entry . The Add New Entry window opens.
of the Available Authorizations list. Then, select the system authorizations to
make available to the role you chose in the previous step.

authorizations to make available to the role you chose in the previous step. The
Commands tab is only available when you are assigning permissions to a server.
Available Authorizations list. Then, select the authorization profiles that should
be available to the role you chose in the previous step.
Use Shift-click or Control-click to select multiple authorizations. Click the right

4 Click OK.
5 To add authorizations for another role, repeat steps 1 through 4.
Adding predefined permissions to a role

You can use an ACL template to add a predefined set of permissions to one or more
role.
To add predefined permissions to a role
1 Click Use ACL Template . The Select ACL Template dialog box opens.
2 Select one or more ACL templates on the dialog box.
3 To set the contents of the selected ACL templates so they replace all entries in the

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
4 Click OK.
Creating and modifying a maintenance window

A maintenance window, or time window, is an RBAC object that describes the
frequency, start time, duration, and permissions for providing time-based access to
an object. For example, you could set a specific time period each Friday to make a set
of servers available for software deploy jobs.
To create or modify a maintenance window for a server
1 On the Policy Access Control List panel, click Add under the Time Windows
section.
The Time Window panel is displayed.
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.
Description Optionally provide descriptive text.
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:
Once (specify the date)
Daily
Weekly (specify which days of the week)
Monthly (specify which days of the months) - for example, entering

1,15,30 sets the window for the first, fifteenth, and thirtieth of the
month
Time zone Select your time zone from the drop-down list.
3 Complete the fields in the Permissions tab. Do the following:
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.
4 To close the window, click OK.
5 To finish creating the policy, click OK.
ACL Policies can contain a number of maintenance windows.
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
1 Select the entry and click Delete Entry .

ACL policy Permissions

this object.
you want to add.



Creating automation principals
Modifying ACL policies

You can modify an existing ACL policy.
To modify an ACL policy
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.
any of properties, permissions, or audit trail information that apply to this ACL
policy.

You can create an automation principal, which defines a user credential that can be
used for accessing external systems.
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.
Agent installationAccess servers where you want to run agent installations.
Atrium OrchestratorIntegrate Workflow Jobs with Atrium Orchestrator.
LDAP server accessAccess an LDAP server such as an Active Directory server.
This procedure lets you map multiple roles to an automation principal.

Alternatively, you can also map a particular role to an automation principal (see
Role Agent ACL on page 213). Rather than mapping automation principals to
roles, you can accomplish the same mapping on a server-by-server basis using server

properties. For information, see Using server properties to map automation

principals for Windows user mapping on page 200.
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.
Before you begin
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.
To create an automation principal
1 In the RBAC Manager folder, select Automation Principals.
2 Create a new automation principal by right-clicking and selecting New =>

Automation Principal from the pop-up menu. The Automation Principal
Creation wizard appears.
3 Provide information for the automation principal as described in the following

sections:
Automation principal General on page 197
Automation principal Role Associations on page 198
Automation principal Properties on page 198
Automation principal Permissions on page 199

Automation principal General

Use the General panel to provide user credential information for the automation
principal you are defining.
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.
If you are using an automation principal for agent installation, additional

configuration may be required for the account you specify here. For more
information, see Troubleshooting agent installation on page 316.
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
Enter the passphrase needed to authenticate the automation principal. Then

enter the passphrase again for Confirm.

Automation principal Role Associations

The Role Associations panel lets you specify roles that should be mapped to this
automation principal.
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
Show Unassigned Roles
Click to have the Available Roles list show only roles that are not currently
associated with automation principals or properties.
Show All Roles
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.
Automation principal 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.
Modifying a property value

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 .
Automation principal Permissions

this object.
you want to add.



Modifying automation principals

You can modify an existing automation principal.
To modify an automation principal
1 Open the RBAC Manager folder, expand the Automation Principals node, and
navigate to an existing automation principal.
To modify information defining user credentials for the automation principal,

right-click the automation principal and select Open from the pop-up menu.
The content editor displays a tab showing details for this automation principal.
For more information about these options, see Automation principal General
on page 197.)
any of properties, permissions, or audit trail information that apply to this
Using server properties to map automation principals for

Windows user mapping
Typically, after you define an automation principal for Windows user mapping, you
map a role to that automation principal. In this way, when a role connects to an
agent on a Windows server, the role is automatically mapped to the user defined in
the 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.

Creating an LDAP connection
To use server properties to map automation principals
1 Create an automation principal.
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.
If your system is set up to use BMC Server Automations default set of

permissions, you must be logged on as BLAdmin to perform this step. For more
information about creating properties, see Adding or modifying properties on
page 152.
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.

To synchronize an RBAC user database with an LDAP-based user registry, you must
establish a connection with an LDAP server.

Before you begin
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.
To create an LDAP connection
1 In the RBAC Manager folder, select LDAP Synchronization => LDAP

Connections.
2 Create a new LDAP connection by right-clicking and selecting New => LDAP
Connection.
The New Connection wizard appears.
3 Provide information for the LDAP connection, as described in the following

sections:
LDAP Connection General on page 202
LDAP Connection Properties on page 204
LDAP Connection Permissions on page 204
4 Click Finish at any time to close the wizard and save your changes.
LDAP Connection General

The General panel lets you identify the LDAP server to which you want to connect.
It also lets you specify the certificate needed to establish a connection between the
Application Server and the LDAP server.
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.
Verify host name when establishing a secure connection
Validates the identify of the LDAP server.
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.
Certificates identified in this way will be imported into the Application

Servers trust store.
For more information about obtaining the certificate, see Obtaining a

certificate used to trust the LDAP server on page 203.
After you have specified the certificate, you can click Details to show
detailed information about the certificate.
Obtaining a certificate used to trust the LDAP server

To create an LDAP connection, you must identify the certificate used to trust the
connection between the Application Server and the LDAP server. The certificate
should reside in the Application Servers trust store.
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 import a certificate using blcred
1 Using the blcred utility, run the following command:
blcred -x certStore.pem cert -add -host LDAPServer:389 -protocol ldap
LDAP Connection Properties

In this list you can modify the value of any properties that are defined as editable.

inherited.
Property .
LDAP Connection Permissions


this object.
you want to add.


Modifying LDAP connections

You can modify an existing LDAP connection.

Creating an LDAP query
To modify an LDAP connection
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.)
LDAP connection.

To synchronize an RBAC user database with an LDAP-based user registry, you must
run queries on the LDAP server. These queries identify the groups and users in the
LDAP registry that you want to synchronize with RBAC.
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.
To create an LDAP query
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.
The LDAP Query Creation wizard appears.
3 Provide information for the LDAP query, as described in the following sections:
LDAP Query General on page 207
LDAP Query Properties on page 208
LDAP Query Permissions on page 209

LDAP Query General

The General panel lets you define the terms of an LDAP query. You can define as
many queries as you need.
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
Base Distinguished Name
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
The query you want to use
Typically, a filter for groups of users would be (objectClass=group). A

typical filter for users would be (objectClass=user).
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.
LDAP query basics

There are some basic concepts for creating LDAP queries.
LDAP queries typically include three parts:
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

CN=Users,DC=us,DC=sso,DC=bmc,DC=com. This DN corresponds to the Users

name in domain us.sso.bmc.com.
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.
Query components Query results

Name: ADsyncTestGroup query Queries for all subgroups of the group
Base DN: ADsyncTestGroup
CN=ADsyncTestGroup,OU=automation,OU=junit,
DC=us,DC=sso,DC=bmc,DC=com
Filter: objectClass=group
Attribute: member
Name: ADsyncTestGroup users query Queries for all users of the groups identified in the
Base DN: leave blank associated query. If paired with the group query
shown above, this query would obtain user
Filter: objectClass=user information from ADsyncTestGroup and all of its sub-
Attribute: userPrincipalName groups.
LDAP Query Properties


inherited.

Property .
LDAP Query Permissions

this object.
you want to add.



Creating roles
Modifying LDAP queries

You can modify an existing LDAP query.
To modify an LDAP query
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.)
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

Creating roles
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
1 In the RBAC Manager folder, select Roles.
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:
Role General on page 212
Role Agent ACL on page 213
Role Users on page 216
Role Summary on page 216
Role Properties on page 216
Role Permissions on page 217

Creating roles
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.
In addition to granting individual authorizations for system authorizations and

commands, you can assign one or more authorization profiles to a role. An
authorization profile is a collection of system and command authorizations. For
more information about creating authorization profiles, see Creating an
authorization profile on page 180.
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

Creating roles
Object Permissions Template
Click Browse to select an ACL template that will be used to define

permissions that are automatically granted to objects created by this role.
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
Under Available Authorizations, do any of the following:
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 grant the role individual command authorizations, click the

Commands tab at the bottom of the Available Authorizations list. Then,
select the commands 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.
Role Agent ACL

The Agent ACL panel lets you enter information that determines how a user
establishes a connection to an RSCD agent on a remote server.
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.

Creating roles
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.

Creating roles
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:
User MapDefine a user name to which incoming connections on a server should be

mapped by doing one of the following:
Select Map to and enter a user name.
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
Automation PrincipalSelect an automation principal that should be mapped to this

role or select None. For more information about automation principals, see Automation
principals and server management on page 171. The Automation Principal option is
only available on the WINDOWS tab.
Note that if you create a role by copying an existing role and that role includes an
automation principal, the newly created role does not include the automation principal.

Creating roles
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


Creating roles
inherited.
Property .
Role Permissions
this object.
you want to add.


Creating roles

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.
To see or modify any of properties, permissions, or audit trail information that

apply to this role, select the Properties, Permissions, or Audit Trail tab group.
For more information, see Properties, Permissions, and Audit Trail tab group
on page 115.

Creating roles
Role Group Mappings

The Group Mappings panel lets you identify the LDAP queries used for obtaining
user information from an LDAP registry so that information can be associated with
the current role.
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
The connection to an LDAP server
Automation Principal
An automation principal that has the logon credentials needed to access

the LDAP server.
Group Query
A query that obtains group information from the LDAP server.
User Query
A query that obtains user information from the LDAP server.
Existing user options
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:

Creating users
Delete users not found
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.
Disable users not found
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.
Remove users not found from the role
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.
If a user already exists in RBAC, is enabled for participation in the synchronization

process, and is included in the LDAP users being added as part of the
synchronization, the existing RBAC user is modified as follows:
The user is enabled for Active Directory/Kerberos authentication.
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.

Creating users
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
1 In the RBAC Manager folder, select Users.
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:
User General Information on page 221
User Role Selection on page 224
User Properties on page 225
User Permissions on page 225
User General Information

The General Information panel lets you identify and disable users, specify certain
logon requirements, and it lets you choose the authentication mechanisms available
for the user.
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.

Creating users
Character Encoding
% %25
, %2c
: %3a
# %23
space %20
tab %09
Field Definitions
Name
Identifying name.
Description
User is disabled
To disable a user, check 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.
User participates in directory synchronization
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.
If a user is created through a synchronization process, this option is

automatically checked. For more information, see Synchronizing users with
LDAP servers on page 227. If a user is created using the New User wizard,
this option is automatically cleared.
Allow Secure Remote Password Authentication
Enables the user to authenticate using SRP. If you check this option you must
fill in the SRP Authentication Options listed below.
Allow Active Directory/Kerberos Authentication
Check this option if you want to enable the user to authenticate using AD/
Kerberos or Domain Authentication.

Creating users
Allow LDAP Authentication
Check this option if you want to enable the user to authenticate using LDAP.
Allow SecurID Authentication
Check this option if you want to enable the user to authenticate using RSA
SecurID.
Allow PKI Authentication
Check this option if you want to enable the user to authenticate using public
key infrastructure.
Automatically disable account if inactive
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.
You cannot disable the BLAdmin and RBACAdmin users.
SRP Authentication Options
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 specify that a users password never expires, check Password never

expires.
Clearing Password never expires means a users password expires after
the period of time specified by the Application Servers MaxPasswordAge
option. To set a value for that option, use the Application Server
Administration console (that is, the blasadmin utility). For more
information, see BMC technical documentation at https://docs.bmc.com/
docs/display/bsa82/Setting+logon+requirements.

Creating users
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.
User Role Selection

The Role Selection panel lets you assign one or more roles to a user.
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.
Default Network Shell Role
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.

Creating users
User Properties

inherited.
Property .
User Permissions
this object.
you want to add.

Creating users


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.

Synchronizing users with LDAP servers
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.
To see or modify any of properties, permissions, or audit trail information that

apply to this user, select the Properties, Permissions, or Audit Trail tab group.
on page 115.

Most large organizations rely on external systems such as LDAP servers to manage
user accounts. BMC Server Automation lets you synchronize users maintained in
specific LDAP groups with users in the RBAC database by mapping one or more
LDAP groups and subgroups to an RBAC role.
Currently, BMC Server Automation only supports synchronization with Active

Directory.
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.
This procedure is typically performed by the RBACAdmins user. To perform this

procedure using a role with a minimal set of authorizations, see Minimum
authorizations for synchronizing users on page 229.
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:
RBACRole syncUsers roleName
To synchronize users
1 Ensure that the LDAP server has a certificate installed for secure LDAP
communication.

2 Create an automation principal that represents the credentials required to access

the LDAP server.
For more information about creating an automation principal, see Creating

automation principals on page 195.
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.
3 Set up an LDAP connection to use to connect to the LDAP server.
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.
The procedure for setting up an LDAP connection is described in Creating an

LDAP connection on page 201.
The procedure for obtaining a certificate is described in Obtaining a certificate

used to trust the LDAP server on page 203.
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.
The process for setting up LDAP queries is described in Creating an LDAP

query on page 206.
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.

The process of mapping these values to a role is described in Role Group

Mappings on page 219.
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).
7 Right-click and select Synchronize.
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.
Minimum authorizations for synchronizing users

Synchronizing RBAC with an LDAP server is typically performed by the
RBACAdmins role but you can take this action with a minimum set of permissions.
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-based permissions
Object-level authorizations
Type of object Authorization required Additional information
LDAP connection object LdapConnection.read Required for Active Directory

synchronization.
Currently, you can only manage LDAP
connection objects using the BLCLI.
LDAP query object LdapQuery.read Required for LDAP server synchronization
Automation Principal AutomationPrincipal.read Required for Active Directory
synchronization.
Role Role.Read Required for Active Directory
Role.Modify synchronization.
Role.ManageUsers
User User.* Required for ongoing maintenance of each
user created by the Active Directory
synchronization process.
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.
Assigning permissions to objects in the RBAC Manager folder is the same as

assigning permissions to other system objects. Because you can grant permissions for
roles, users, ACL templates, and authorization profiles in the RBAC Manager folder,
you can delegate authority for managing RBAC functionality to multiple roles.
Several mechanisms exist for granting permissions to an object, including ACL

policies and maintenance windows. Because of this, it can be difficult to grasp the
permissions that are granted to an object at any given time. To view a summary of all
permissions granted to an object, see Viewing an ACL summary on page 236.

See Common issues while using permissions on page 239 for information about
common issues users encounter when defining permissions for system objects.
Defining permissions for a system object

All system objects include permissions in the form of an access control list. The ACL
specifies the roles that have access to the object and the types of actions those roles
are authorized to perform on an object.
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.
To define permissions for a system object
1 Display a list of permissions for a system object by doing any of the following:
Action Minimum permission required
Select an existing system object and then select the objectType.ModifyACL

Permissions view. Example: DeployJob.ModifyACL
Use a wizard to create a system object and display the objectType.CreateACL

Permissions panel of the wizard. Example: DeployJob.CreateACL
Select a system object, right-click, and select Update objectType.ModifyACL

Permissions. Example: DeployJob.ModifyACL
Using the Configuration Object Dictionary, select a objectType.ModifyACL

configuration object, right-click, and select Update Example: DeployJob.ModifyACL
Permissions.
2 Use the access control list on the Permissions tab or panel to take any of the
following actions:
Adding a set of authorizations for a role on page 232
Adding a predefined set of permissions to a role on page 233
Applying ACL policies on page 234
Deleting an entry in the Access Control List on page 234
Deleting an ACL policy on page 234
Adding a set of authorizations for a role

You can add a set of authorizations for a role
To add a set of authorizations for a role
1 Click Add to open a dialog box for defining permissions.

3 Under Available Permissions, take any of the following actions:

to a server.
Click the right arrow to move your selections to the Selected Authorizations list.
4 Click OK.
Adding a predefined set of permissions to a role

Use an ACL template to add a predefined set of permissions to one or more roles.
To add a predefined set of permissions to a role
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.
3 Select one or more ACL templates on the dialog box.
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.
5 Click OK.

Applying ACL policies

You can apply ACL policies (sets of permissions that are centrally managed).
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.
3 Select one or more ACL policies on the dialog box.
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.
5 Click OK.
Deleting an entry in the Access Control List

You can delete an entry in the Access Control List.
To delete an entry in the Access Control List
1 Click Delete .
Deleting an ACL policy

You can delete an ACL policy.
To delete an ACL policy
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.

Updating permissions for one or more system objects

You can change the permissions for one or more system objects.
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.
This procedure is particularly useful if you choose to make widespread changes to

object-based permissions. For example, if you add a role, you must add permissions
for that role to some or all of the system objects throughout BMC Server Automation.
To accomplish this, you can select all the objects in a folder or use a smart group to
group all of those objects. Then, you can define the permissions that are being
changed or appended and apply those permissions to the selected system objects. To
update permissions on all objects, you must repeat this process for each folder.
To change permissions for a system object
1 Select the system objects for which you want to update permissions. To
accomplish this, do any of the following:
In the Servers, Components, Component Templates, Depot, Devices, Jobs, or

RBAC Manager folders, select one or more system objects, devices, groups,
folders, or smart groups.
In the Custom Commands View (available from the Configuration menu),

select one or more commands.
In the Config Object Dictionary View (available from the Configuration

menu), select one or more configuration objects.
In the Property Dictionary View (available from the Configuration menu),

select one or more classes or subclasses.
2 Right-click and select Update Permissions from the pop-up menu.
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.
4 Select one of the following:

Append permissionsAppend the permissions you defined in the previous

step to the existing access control list for each selected item.
Replace permissionsReplace all existing permissions for each selected item

with the list you defined in the previous step.
5 Click OK.
The Update Permissions Progress window opens. It lists the system objects where
ACLs are updated.
6 Click Close to close the Update Permissions Progress window.
Viewing an ACL summary

The ACL Summary view displays the current set of authorizations that are defined
for an object. It can also show effective authorizations by considering permissions
assigned to both objects and roles.
Users sometimes find it difficult to know what authorizations are granted to an

object at any given time. There are various mechanisms for assigning authorizations.
Administrators can grant authorizations to both roles and objects. When granting
authorizations to objects, administrators can use the following approaches:
Granting authorizations directly to an object.
Granting authorizations in ACL policies that are assigned to the object.
Granting authorizations to the object through maintenance windows.
To make viewing ACLs easier, you can use the ACL Summary view. It lets you see
authorizations using two types of views:
ACL SummaryA summary of all authorizations granted to an object. This view

does not reflect role-based authorizations. If an object-based authorization has
been granted to a role to perform an action on this object, that authorization
appears in the ACL Summary view whether or not a role-based authorization has
also been granted to the object.
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.
To display an ACL Summary view
1 Select an object, right-click and select ACL Summary View.
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.
To switch back to a list of object-based permissions, select ACL Summary from

the drop-down list.
To filter information on the ACL Summary view
Using the filters available for every column in the ACL Summary view, you can
restrict the permission information that this view displays.
1 Display the ACL Summary view.
2 Click the filtering information at the top of a column header.
3 Select a filtering option from the drop-down list.
4 Click the filter icon .
The view updates to show information that matches the filtering criteria you have
selected.
To reset all filters
1 Click Reset All Filters .

ACL Summary view filters

The ACL Summary view includes filters to restrict the permission information
displayed.
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.
Opening Time and Closing Time
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.

Common issues while using permissions

BMC Server Automation provides a flexible system of access permissions. However,
subtle dependencies exist between some permissions.
The following are common issues users encounter when assigning permissions to
system objects:
Any authorization that allows you to take an action on an object must be

accompanied by an authorization that lets you read that object. If you cannot read
the object, you cannot see the object in BMC Server Automation. For example, to
execute a job, you must also be able to read the job. Thus, when granting a
permission such as DeployJob.Execute, you must also grant DeployJob.Read. The
same sort of dependency exists when modifying the ACLs of an objectto modify
the object you must be able to read the object. For example, when granting
BLPackage.ModifyACL, you must also grant BLPackage.Read.
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).
Browsing a server is controlled by the Server.Browse authorization. Browsing a

component is controlled by the Component.Browse authorization.
Browsing the contents of a component requires a combination of permissions that

vary depending on your context:

Agent ACL description
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
An uninstall is accomplished using Read and Create authorizations for the

software being uninstalled and Read and Execute authorizations for the uninstall
job. (Remember that an uninstall job is really a Deploy Job that uninstalls rather
than installs a software package.) For example, to uninstall an RPM, you must
have LinuxSoftware.Read and LinuxSoftware.Create authorizations for the RPM
you want to uninstall. Also, you must have DeployJob.Read and
DeployJob.Execute to run the Deploy Job that uninstalls the RPM.
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.

You can use agent ACLs to control access to a server.
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.
In addition to generating role:user entries, BMC Server Automation also creates

another type of users file entry for Network Shell users. Because Network Shell does
not recognize roles, the RBAC Manager folder asks you specify a role that functions
as the default Network Shell role for each user (see User Role Selection on page
224). Using this information, BMC Server Automation generates a users file entry
that does not include role information for each user. A users file entry is not
generated for disabled users.
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.
Administrators can create a users.local file on agents to create a set of user

permissions that are more fine-grained than is possible with the users file entries
that BMC Server Automation automatically generates. For example, with RBAC you
cannot specify some users as read only and others as read/write, but you can easily
accomplish that by manually editing the users.local file. The RSCD agent reads the
users.local file before it reads the users file, and the users.local settings supersede

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.
Windows user mapping and agent ACLs

If you are granting user permissions on Windows servers through Windows user
mapping, all permissions on the server are derived from the local or domain user to
which a role is mapped.
However, configuration files on a managed server can control other capabilities

besides user permissions. Because of that, when you change role or user information,
you should always run an ACL Push Job, even to servers where you are using
Windows user mapping.
Previewing and pushing agent ACLs

You can preview agent ACLs before pushing them to a server.
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.
To preview and push agent ACLs
1 In the Servers folder, select a server.

Creating ACL Push Jobs
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.
To close the window, click Cancel.

You can run an ACL Push Job, which converts the access control list defined for a
server into the users configuration file on that servers RSCD agent.
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:
If no command authorizations are specified on the server and no command

authorizations are specified for a role, no command authorizations for that role
are pushed to the agent. This means the role has full authorization to use any
Network Shell and nexec commands on that server.
If no command authorizations are specified on the server but command

authorizations are specified for a role, those command authorizations are pushed
to the agent. This means the role is authorized to perform those commands on the
agent.

If command authorizations are specified on the server but no command

authorizations are specified for a role, no command authorizations for that role
are pushed to the agent. This means the role has full authorization to use any
Network Shell and nexec commands on that server.
If command authorizations are specified on the server and command

authorizations are specified for the role, the command authorizations common to
both are pushed to the agent. This means the role is authorized to perform only
those commands on the agent.
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.
To create an ACL Push Job
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.
2 Define the ACL Push Job, as 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

ACL Push Job Properties on page 249
ACL Push Job Permissions on page 250
ACL Push Job General

Use the General panel to provide information that identifies an ACL Push Job.
Field Definitions
Name
Identifying name.
Description
Save in
Folder in which to store the object.
Number of targets to process in parallel
Choose one of the following options:
Unlimited: Simultaneously runs the job on as many servers as possible.

Application Server settings control the number of targets the job can access.
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.
Set execution override
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.
Clear execution override
Remove an existing execution override.

ACL Push Job Targets

The Targets panel lets you choose the servers where this job should run. When first
defining and saving a job, you do not have to specify target servers. You can specify
target servers at a later time.
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.
Click the right arrow to move your selections to the right panel.
ACL Push Job Default Notifications

The Default Notifications panel provides options for defining default notifications
that are generated when a job completes. If you have set up notifications for a
particular scheduled job, those notifications are generated instead of default
notifications.
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.
Job Run Notifications

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 sysadmin@bmc.com;sysmgr@bmc.com. After entering email address
information, check the statuses that cause an email to be generated.
Send SNMP trap to
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.
BMC Server Automation provides a management information base (MIB)

that describes its SNMP trap structure. You can use this MIB to create scripts
that integrate traps into your trap collection system. The MIB is located at
installDirectory/Share/BladeLogic.mib.
List failed servers in email notification
Indicates email notifications should list all servers on which a job has failed.
ACL Push Job Schedules

The Schedules panel lets you schedule a job to execute immediately, schedule a job
at a specific time in the future, schedule a job on a recurring basis, and define
notifications that are issued when a job runs.
When scheduling a job, you can perform any of the following tasks:
Scheduling a job that executes immediately
To schedule a job that executes immediately, select Execute job now.
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.

Defining job notifications
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.
ACL Push 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
Send SNMP trap to

ACL Push Job Scheduling

The Schedule tab lets you schedule a job so it can run one time, recur hourly, daily,
weekly, or monthly, or recur at an 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
1 Using the Schedules list, do one of the following actions:
To add a new schedule, click New Schedule .
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.
ACL Push Job Properties


inherited.

Property .
ACL Push Job Permissions

this object.
you want to add.



Using the bladduser utility
Modifying ACL Push Jobs

You can modify an existing ACL Push Job.
To modify an ACL Push Job
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.
To see or modify any properties, permissions, or audit trail information that

apply to this job, select the Properties, Permissions, or Audit Trail tab group.

The BMC Server Automation bladduser utility lets you create users without using
RBAC. It also lets you create users in bulk.
Creating users without using RBAC on page 252
Creating users in bulk on page 252

Creating users without using RBAC

Use the bladduser utility to define a password for the RBACAdmin and BLAdmin
users and any other users you want to create outside of the RBAC Manager folder.
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.
To create a user using bladduser
1 To create a user, do one of the following from the directory where an Application
Server is installed:
(Windows) Enter the following command:

bin\bladduser.exe
(UNIX) Enter the following command:

./bin/bladduser
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
Creating users in bulk

Rather than creating users one-by-one in the RBAC Manager folder, you can use the
bladduser utility to create multiple users by importing a file containing a list of user
names and passwords.

Authorizations for changing job priority
The list must have the following format:
user,password
user,password
user,password
where user is a user ID and password is the password associated with that user ID.
To import a list of users
1 Do one of the following from the directory where an Application Server is

installed:
(Windows) Enter the following command:

bin\bladduser.exe -f filename
(UNIX) Enter the following command:

./bin/bladduser -f filename
where filename is the name of the file containing the list of users you want to
import.

To control the job priority access for each role, you must the set the appropriate
RBAC job authorizations and set the maximum allowed priority for each role as
described in the following sections.
Authorizations related to job priority

To control Job Priority access, define and apply the following authorizations as
described in the table below.
Authorization Permission granted
Jobtype.ModifyPriority Modify the priority at the:
Job type level - which changes the default priority for the
job Type
Job level - changing the priority for that job instance
Job schedule level - changing the priority for each

different job type

Authorization Permission granted
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.
Required Role-level property

You must define the following role-level property:
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.
To change this default value, you must assign the Role.ModifyProperties

authorization in addition to Role.Create (while creating the role) or Role.Modify
(while modifying an existing 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
DeployJob.PauseResumeExecution (which controls the access to the ability to

pause and resume Jobs)
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.
Recommendations for using job priority

To prevent unauthorized users from changing job priorities and affecting
operational performance, make sure that only authorized users have permissions to
change the job priority.
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.

Authorizations for the Configuration menu

The Configuration menu provides access to views and windows that configure the
behavior of BMC Server Automation. The minimum authorizations needed to use
the views and windows vary.
The following table describes the authorizations needed to use the capabilities of the
Configuration menu.
Configuration menu option Minimum authorization needed Additional information
Job Schedule view Read-level authorization is No authorization is required to

necessary for each type of job you open the view.
want to view.
Read-level authorization at the
object level is necessary for each
individual job.
Custom Commands view CustomCommand.Read No authorization is required to
open the view, but authorizations
are required to see and use custom
commands.
Property Dictionary view No authorizations required
Configuration Object Dictionary ConfigFile.Read No authorization is required to
open the view.
To see user-defined configuration
files, you need at least read-level
permission at the object level.
Provisioning Manager ProvisionConfig.Read To see system package
Configurations SystemPackageType.Read information, you need at least read-
level permission at the object level.
Virtualization Configuration VirtualizationConfiguration.*
Provisioning Image Creation ProvisionWinPEImageCreation.Cr
eate
Patch Global Configuration PatchAnalysisConfig.Modify No authorization is required to
open the view.
AO Configuration AOConfig.*
Approval Configuration ApprovalConfig.*
Atrium Integration BL2AtriumCustomization.Browse To use this option, you must first
use the blasadmin utility to run
the EnableAtriumIntegration
command on the Application
Server.
Generate Support Data BL_Administration.Read

Configuration menu option Minimum authorization needed Additional information
Application Server Diagnostics BL_Administration.Read

View
Infrastructure Management BL_Administration.Read


7
Agent installation
This section describes how to install RSCD agents on servers using the BMC Server
Automation Console and add those managed servers to your system.
Agents in BMC Server Automation

Agents are fundamental to the BMC Server Automation system. The BMC Server
Automation Console provides functionality for installing multiple agents
simultaneously or installing agents one at a time.
Agents in BMC Server Automation

BMC Server Automation is primarily a system based on RSCD agents. The RSCD
agent is a small program that must be installed and running on each server that BMC
Server Automation manages. Agents allow you to perform actions on remote servers
and obtain information from those servers.
Installation options
BMC Server Automation provides the following methods for installing agents:
Install individual agents manuallyRun installation programs to install an agent

on a single server. For more information on individual installations, see BMC
Installing.
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.

Agent installation overview
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.
Agent installation overview

This section describes the possible approaches for installing multiple agents
simultaneously. It also outlines the preliminary tasks required for agent installation.
To install multiple agents, the following approaches are possible:
Run the Unified Agent Installer, which creates the many objects needed to install
agents. This approach requires the following steps:
1 Perform the preliminary tasks described in Preliminary tasks for installing

agents on page 261.
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:
1 Perform the preliminary tasks described in Preliminary tasks for installing

agents on page 261.
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:
Can only install agents running version 8.2 or later
Cannot upgrade existing agents
Cannot uninstall agents

Adding a server to the system
Preliminary tasks for installing agents

1 Add agentless devices to the system by:
Adding agentless devices individually. See Adding a server to the system on

page 261.
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.
2 Optionally, specify an alternative staging directory for agentless devices. See

Defining alternative staging directories on page 269.
3 Add agent installers to the Depot as software packages.

See Adding agent installer packages to the Depot on page 269.
Agent installers must use a package type that is native to the target platform. For
example, Red Hat servers requires RPM packages.
4 (Windows) If you are installing agents on Windows servers, install PsExec on a

server that can function as the PsExec server.
See Setting up a PsExec server on page 272.

You can add a server using the BMC Server Automation Console. When you add a
server, you can install an agent on the server at the same time.
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.
To add a server using the console
1 Open the Servers folder.
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.
The Add New Server wizard opens.
3 Provide information for the Add New Server wizard, as described in the
following sections:
Add New Server Properties on page 262
Add New Server Permissions on page 263
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.)
Add New Server Properties

The Properties panel lets you identify the server you want to add and assign
property values to that server. Optionally, you can identify the Agent Installer Job
that installs an agent on the servers being added.
Field Definitions
Name/IP Address
A resolvable host name or an IP address. After entering this information,

click Verify to display the properties already associated with this server.
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.
If agent does not exist, install using Agent Installer Job
Check to instruct the system to install an agent. Then click Browse to

navigate to the Agent Installer Job that installs the agent. For more
information, see Creating an Agent Installer Job on page 303.
Add New Server Permissions

The Permissions panel provides an access control list (ACL) granting roles access to
any objects created in the system, such as jobs, servers, or depot objects. This panel
also lets you preview and push the ACLs assigned to this server.
this object.
you want to add.



Previewing agent ACLs

The ACLs you define on this panel can be assigned to the agent that is installed on
this server. To preview those ACLs, click Agent ACLs Preview. The Agent ACL
Preview window opens. It displays the ACLs defined for this server. ACLs are based
on the authorizations and other information currently defined for the roles granted
access to this server. The Agent ACL Preview window presents this information in
the form of a users configuration file that will be applied to the RSCD agent on this
server. For more information about using this window, see Previewing and
pushing agent ACLs on page 242. For detailed information about agent ACLs, see
Agent ACL description on page 240.
Pushing agent ACLs

You can push the agent ACLs defined for this server by clicking Push agent ACLs.
Selecting this option launches an ACL Push Job after this server has been added to
the system. For more information, see Creating ACL Push Jobs on page 243.

Importing servers into the system

You can add multiple servers to a server hierarchy by specifying a text file that
contains a list of server names and properties assigned to each server. You can also
install agents on those servers at the same time.
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
1 Open the Servers folder and do one of the following:
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.
The Import Servers wizard opens.
2 Provide information for the Import Server wizard, as described in the following
sections:
Import Servers Import Servers on page 266
Import Servers Permissions on page 267
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.
Import Servers Import Servers

The Import Servers panel lets you identify the list of servers to be imported.
Optionally, you can identify the Agent Installer Job that installs agents on the servers
being imported.
File selection tree
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.
Update Intrinsic Properties
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.
If agent does not exist, install using Agent Installer Job
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.
Server import file format

You create your server import text file using a comma-separated values (CSV) format.

Use the following syntax:
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.
Server import file samples
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"
Import Servers Permissions

The Permissions panel provides an access control list (ACL) granting roles access to
servers you are importing. This panel also lets you push ACLs to those servers.

this object.
you want to add.


Pushing agent ACLs

To push the agent ACLs defined for the imported servers, select Push agent ACLs to
successfully imported servers. Selecting this option launches an ACL Push Job after
servers have been successfully added to the system. For more information, see
Creating ACL Push Jobs on page 243.

Defining alternative staging directories
Defining alternative staging directories

In some situations you might want to use a different staging directory on a remote
host when installing an agent.
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.
Adding agent installer packages to the Depot

Add an installer package to the Depot for any type of agent that you want to install
automatically using an Agent Installer Job.
Before you begin
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:
Target platform Package to add to Depot

AIX RSCD<version>-AIX32.bff
Linux 32-bit RSCD<version>-LIN32.rpm

Target platform Package to add to Depot

Linux 64-bit RSCD<version>-LIN64.rpm
Linux 64-bit S390 RSCD<version>-LIN64-S390.rpm
Solaris 8/9 SPARC RSCD<version>-SOL8-SPARC-LOCAL.gz
Solaris 8/9 x86 RSCD<version>-SOL8-X86-SPARC-LOCAL.gz
Solaris 10/11 SPARC RSCD<version>-SOL10-SPARC-LOCAL.gz
Solaris 10/11 x86 RSCD<version>-SOL10-X86-SPARC-LOCAL.gz
Windows 32-bit RSCD<version>-WIN32.msi
Windows 64-bit RSCD<version>-WIN64.msi
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.
To add agent installer packages to the Depot
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.
Upload source to File
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.
Additional information for Windows installation packages

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.
Additional information for Linux installation packages
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.
Additional information for Solaris installation packages
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:
Edit the _INSTALL_ADMINFILE parameter to point to the location of a valid

admin file. On a Solaris server, you can obtain an admin file from /var/sadm/
install. The following is a sample admin file that you can customize and use:
#
# Copyright 2004 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
# ident "@(#)default 1.7 04/12/21 SMI"
#
mail=
instance=unique
partial=quit
runlevel=quit
idepend=nocheck
rdepend=nocheck
space=quit
setuid=nocheck
conflict=nocheck
action=nocheck
networktimeout=60
networkretries=3
authentication=quit
keystore=/var/sadm/security
proxy=
basedir=default
Edit the _INSTALL_RESPONSEFILE parameter to point to the location of a

valid response file. The response file consists of a single character: y. The
following is a sample response file:

Setting up a PsExec server
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.
Additional information for AIX installation packages
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.
Setting up a PsExec server

To use the Agent Installer to install agents on Windows servers, you must first set up
a PsExec server on a Windows server. A PsExec server functions as a proxy to
execute psexec requests on agentless Windows hosts during agent installation.
To set up a PsExec server
1 Using a Windows host, install an RSCD agent, version 8.2 or later.
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.
You can download PsExec from http://technet.microsoft.com/en-us/

sysinternals/bb897553.
PsExec must be version 1.98 or later.
5 Install PsExec according to the instructions from Microsoft.
PsExec must be installed in a directory that is specified in the agent's path

environment variable when the agent is started on the PsExec server.
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.

Running the Unified Agent Installer
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.
For more information about defining automation principals, see Creating

automation principals on page 195.
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.

Use the Unified Agent Installer to perform the tasks necessary to install agents on
servers.
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.
BMC Server Automation provides an alternative process for installing agents,

described in Creating objects for agent installation on page 287. The alternative

process requires you to create the necessary objects before you can create and
execute an Agent Installer Job, which actually installs agents.
Before you begin
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.
To run the Unified Agent Installer
1 Select the root Servers folder and do one of the following:
Right-click and select Unified Agent Installer.
Select File => Unified Agent Installer.
2 Provide information for the Unified Agent Installer, as described in the following
sections:
Unified Agent Installer Introduction on page 277
Unified Agent Installer Agent Bundle Platform Selection on page 277
Unified Agent Installer Agent Bundle Installer Selection on page 278
Unified Agent Installer Agent Bundle Configuration on page 278
Unified Agent Installer Remote Host Authentication (non-Windows) on

page 280
Unified Agent Installer Remote Host Authentication (Windows) on page

281
Unified Agent Installer Remote Host Authentication Rule on page 282
Unified Agent Installer Agent Installer Job Options on page 283
Unified Agent Installer Agent Installer Job Targets on page 284
Unified Agent Installer Required Properties on page 286
Unified Agent Installer Summary on page 286

3 Click Finish after completing the last step of the wizard.
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).
Authorizations for the Unified Agent Installer

To launch and run the Unified Agent Installer, your role must be granted a variety of
permissions.
Minimum permissions to run the Unified Agent Installer

To launch the Unified Agent Installer, your role must be granted the following
minimum authorizations:
AgentBundle.Create
AgentBundle.Read
AgentInstallerJob.Create
AgentInstallerJob.Read
DepotFolder.Read
DepotFolder.Write
JobFolder.Read
JobFolder.Write
BL_Administration.Read
RemoteHostAuthentication.Read
RoutingPolicy.Read
AutomationPrinicpal.Read, if you do not have AutomationPrincipal.Create
AutomationPrincipal.Create, if you do have AutomationPrincipal.Read or there

are no automation principals defined in the system
RemoteHostAuthentication.Create, if there are no remote host authentications

defined in the system

RoutingPolicy.Modify, if there are no remote host authentication rules defined in

the system
Permissions for performing operations

To perform certain operations in the Unified Agent Installer, your role must be
granted the following minimum authorizations. If you are not granted these
permissions, some functionality available from the Unified Agent Installer is
disabled, although you are still able to run the Unified Agent Installer.
ServerGroup.Read, Server.ReadTo assign job targets
Server.ReadTo pick a PsExec server
WindowsSoftware.Read, AIXSoftware.Read, LinuxSoftware.Read,

SolarisSoftware.ReadTo select target platforms
AutomationPrinicpal.ReadTo reuse an existing automation principal
AutomationPrincipal.CreateTo create an automation principal while creating a

remote host authentication
RemoteHostAuthentication.CreateTo create a remote host authentication
RoutingPolicy.ModifyTo create a remote host authentication rule
AgentInstallerJob.ExecuteTo execute an Agent Installer Job
DepotFolder.CreateTo create a depot folder rather than selecting an existing

folder
JobFolder.CreateTo create a job folder rather than selecting an existing folder
Object permissions
The following permissions must be assigned to objects used by the Unified Agent
Installer:
DepotFolder.Read, DepotFolder.Write on the depot folder used to store an agent

bundle
DepotFolder.Read on the depot folders containing agent installers
WindowsSoftware.Read, AIXSoftware.Read, LinuxSoftware.Read,

SolarisSoftware.Read on the selected agent installers
AutomationPrincipal.Read on any existing automation principal that is referenced

JobFolder.Read, JobFolder.Write on the job folder used to store the Agent Installer
Job
Server.Read on any server used as a PsExec server
ServerGroup.Read on any server group selected as a job target
Server.Read on any server selected as a target for the job, either directly or
through a group
Server.ModifyProperties 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)
Unified Agent Installer Introduction

The Introduction panel describes the Unified Agent Installer and specifies a naming
prefix.
Field Definitions
Name
Provides a prefix that is prepended to the name of all objects that Unified
Agent Installer creates.
Unified Agent Installer Agent Bundle Platform Selection

The Agent Bundle Platform Selection panel specifies the platforms on which you
want to install agents.
Field Definitions
Platform list
Select the platforms on which agents can be installed.

Agent bundle folder
Specifies the depot folder where agent bundles are stored.
Related agent installation object

The Unified Agent Installer uses the information you provide on this panel to create
an agent bundle. For detailed information about this type of object, see Creating an
agent bundle on page 296.
Unified Agent Installer Agent Bundle Installer Selection

The Agent Bundle Installer Selection panel lets you map an agent installer package
to each platform on which agents should be installed.
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.

Unified Agent Installer Agent Bundle Configuration

The Agent Bundle Configuration panel optionally defines configuration file
settings for each platform on which agents should be installed. If you do not make
any changes for a platform, agents are assigned default values for configuration files.
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.

users.localSets values that override permissions defined in the users file.

Typically, the values specified in the users file are automatically generated to
implement decisions made in RBAC.
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.

Defining configuration file settings

The Modify Agent Bundle Configuration window gives you the option of defining
settings for agent configuration files.
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.
To define configuration file settings
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.
To remove all text, click Reset.

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.
Unified Agent Installer Remote Host Authentication (non-

Windows)
The Remote Host Authentication (non-Windows) panel specifies the communication
protocol and the automation principal needed to authenticate to a remote non-
Windows host on which an agent has not yet been installed. The automation
principal provides the credential needed for authentication on the remote host.
The Remote Host Authentication (non-Windows) panel only displays if you have
chosen to install agents on a platform other than Windows.
Click Add to open the Add Remote Host Authentication (non-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 (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.
Protocol for accessing servers Select one of the following:
SSH (Non-Windows)Executes commands directly on an agentless host using

the credentials defined in an automation principal that you specify on this panel.
SSH + SUDO (Non-Windows)Executes commands directly on the agentless

host using the credentials defined in an automation principal that you specify
on this panel. The "sudo" command is attached as a prefix to all commands. If
sudo requests a password, the password associated with the automation
principal is used.
SSH + SU (Non-Windows)Executes commands directly on the agentless

on this panel. The automation principal credentials are used to access the
agentless host. The credentials provided in a superuser automation principal
are used to issue the "su" command to gain elevated privileges.

Select or create an automation principalSelect one of the following:
Select existing automation principalSelect this option then click Browse

to navigate to an existing automation principal.
Create new automation principal Select this option. Then, provide a user
name and password for the automation principal.
Select or create a super user automation principalSelect one of the following.

This option only becomes available when you select SSH + SU as the protocol for
accessing servers.
Select existing automation principalSelect this option and then click Browse
to navigate to an automation principal that should be used for the superuser.
name and password for the automation principal that should be used for the
superuser.

remote host authentications for non-Windows agentless devices. For detailed
information about this type of object, see Specifying or modifying information for
remote host authentication on page 288.
Unified Agent Installer Remote Host Authentication

(Windows)
The Remote Host Authentication (Windows) panel specifies the communication
protocol and the automation principal needed to authenticate to a remote Windows
host on which an agent has not yet been installed. The automation principal
provides the credential needed for authentication on the remote host.
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
Select or create an automation automation principalSelect one of the following:
Select existing automation principalSelect this option and then click Browse
to navigate to an automation principal.
name and password for the automation principal. Optionally, you can identify
a domain for the user.
PsExec server Identify a live Windows server where PsExec is installed.

Multiple remote host authentication definitions can use the same 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.
An RSCD agent running version 8.2 or later must be installed on the PsExec server.
For more information about the PsExec server, see Setting up a PsExec server on
page 272.

remote host authentications for Windows agentless devices. For detailed information
about this type of object, see Specifying or modifying information for remote host
authentication on page 288.
Unified Agent Installer Remote Host Authentication Rule

The Remote Host Authentication Rule panel lets you create rules that match remote
host authentication definitions with agentless devices.
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:
Remote host authentication rule Rule Definition on page 295

Remote host authentication rule Remote Host Authentications on page 296
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.*
RoutingPolicy.Read
RoutingPolicy.Modify

remote host authentication rules. For detailed information about this type of object,
see Creating or modifying rules for remote host authentication on page 293.
Unified Agent Installer Agent Installer Job Options

The Agent Installer Job Options panel specifies actions that can occur after an agent
is installed on a server.
Agent Options
If an agent is successfully installed, the actions you select below are performed.
Update Server Properties
Update the system with properties from the target servers on which you are
installing agents.
Update Configuration Objects Registration
Register any configuration objects that are found on the agent and defined in
the Configuration Object Dictionary.
Push Agent ACLs
Push agent ACLs to the servers that this job targets.

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
Specifies whether information copied to a staging area on a target server

during installation should be preserved if the installation fails. By default,
when the system has finished installing an agent, it automatically deletes all
files in the staging area.
Agent Installer Job Folder

Identifies the folder to store the Agent Installer Job that is created by the Unified
Agent Installer.

an Agent Installer Job. For detailed information about this type of object, see
Creating an Agent Installer Job on page 303.
Unified Agent Installer Agent Installer Job Targets

The Agent Installer Job Targets panel lets you specify the servers on which you
want to install agents. It also lets you specify that the Agent Installer Job that is
created by the Unified Agent Installer should run immediately.
Field definitions
Available Servers
By Group, By Name

servers.
Execute job now

Schedules a job that executes immediately when you click Finish.
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.

an Agent Installer Job. For detailed information about this type of object, see
Creating an Agent Installer Job on page 303.

Unified Agent Installer Required Properties

The Agent Installer Job Required Properties panel provides values for required
properties that do not have a default value.
The Required Properties panel only appears in the following situation:
A user-created property exists for one of the following types of objects:
Agent bundles
Agent Installer Jobs
Automation principals
The property is required
A default value is not defined for the property
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:
Click in the field and enter a value.
Insert a parameter by entering a value bracketed with double question mark

delimiters (for example, ??MYPARAMETER??), or click Select Property .
Unified Agent Installer Summary

The Summary panel lists all the objects that the Unified Agent Installer is set up to
create. It also specifies whether the job should run immediately.

Creating objects for agent installation

This section outlines the tasks for creating the objects required for agent installation.
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 begin
Before you can perform the tasks listed below, you must perform preliminary tasks,
as described in Preliminary tasks for installing agents on page 261.
To create the objects needed for agent installation
1 Create automation principals.
An automation principal defines a set of user credentials that can be used to

access an external system. To install agents from the console, the system must
access agentless devices. Automation principals store the credentials needed to
access those devices.
BMC Server Automation can use several mechanisms to execute commands on

agentless devices. BMC calls these mechanisms command execution protocols. Some
types of command execution protocols require both an automation principal and
a superuser automation principal. The superuser automation principal provides
the credentials necessary to gain elevated privileges on a host.
See Creating automation principals on page 195.
2 Create remote host authentications.
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
3 Create remote host authentication rules.
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.
4 Create an agent bundle.

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.
5 Create an Agent Installer Job.
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.
Typically, the system automatically determines the operating system of target

devices. You can optionally specify the operating system for devices where agents
are being installed by entering a value for the AGENT_PLATFORM* property for
each target. If the system cannot automatically determine the operating system of
a target device, you must specify one using the AGENT_PLATFORM* property.
For more information, see Operating system detection and the
AGENT_PLATFORM* property on page 313.
Specifying or modifying information for remote host

authentication
To enable agent installation, you must specify how to authenticate to a remote host
on which an agent has not yet been installed. The information you provide defines
the mechanism and the user credential needed to access the remote host.
If you are installing on multiple platforms, you typically define at least one set of
In addition to providing remote host authentication information, you must also

define rules that specify which remote host authentication to use for each agentless
device. See Creating or modifying rules for remote host authentication on page
293.
See modify the information you provide for a remote host authentication, see To
modify existing information for remote host authentication on page 291.

Before you begin
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.
When installing agents on Windows systems, set up a PsExec server, which

functions as a proxy to execute psexec requests on agentless hosts. For more
information, see Setting up a PsExec server on page 272.
To create a remote host authentication, your role must be granted the following
authorizations:
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
To specify information for remote host authentication
1 Select Configuration => Infrastructure Management.
2 In the Infrastructure Management window, right-click the Remote Host

Authentications node. Then select New Remote Host Authentication. The New
Remote Host Authentication window opens.
3 Enter the following information for authenticating to a remote host:
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
(Optional) Descriptive text about the authentication information.
Command Execution Protocol
Specifies the mechanism for accessing an agentless device. Select one of the
following:

PSEXEC (Windows Only)Specifies that a PsExec server is used as a proxy to

execute psexec requests on an agentless Windows host. This protocol is
required when installing agents on Windows servers. Authentication on
agentless hosts uses credentials defined in an automation principal that you
specify on this panel.


principal is used.
SSH + SU (Non-Windows)Executes commands directly on the agentless host

using the credentials defined in an automation principal that you specify on
this panel. The automation principal credentials are used to access the
PsExec Server
Identifies a live Windows server where PsExec is installed. This option is

only required when authenticating to Windows servers. Multiple remote host
authentication definitions can use the same PsExec server.
The PsExec server must:
Run a Windows operating system
Have PsExec installed
Have an RSCD agent, version 8.2 or later, installed and running
Be added to the Servers folder in the BMC Server Automation Console
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.

Maximum Execution Parallelism
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.
Identifies the automation principal to be used when authenticating to a

remote host. An automation principal defines user credentials that can be
used to access the remote system. For more information about automation
principals, see Creating automation principals on page 195.
Super-user Automation Principal
Identifies an automation principal that provides credentials for a superuser

account on a UNIX system. Only the SSH + SU command execution protocol
requires a superuser automation principal.
4 Click Finish. The Infrastructure Management window lists the remote host
authentication you created.
To modify existing information for remote host authentication
2 In the Infrastructure Management window, expand the Remote Host

Authentications node. Right click the remote host authentication you want to
modify and select Properties. The Modify Remote Host Authentication window
opens.
3 Enter the following information for authenticating to a remote host:
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
(Optional) Descriptive text about the authentication information.

Command Execution Protocol
Specifies the mechanism for accessing an agentless device. Select one of the
following:
PSEXEC (Windows Only)Specifies that a PsExec server is used as a proxy to

execute psexec requests on an agentless Windows host. This protocol is
required when installing agents on Windows servers. Authentication on
agentless hosts uses credentials defined in an automation principal that you
specify on this panel.


principal is used.
SSH + SU (Non-Windows)Executes commands directly on the agentless host

using the credentials defined in an automation principal that you specify on
this panel. The automation principal credentials are used to access the
PsExec Server
Identifies a live Windows server where PsExec is installed. This option is

only required when authenticating to Windows servers. Multiple remote host
authentication definitions can use the same PsExec server.
The PsExec server must:
Run a Windows operating system
Have PsExec installed
Have an RSCD agent, version 8.2 or later, installed and running
Be added to the Servers folder in the BMC Server Automation Console
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.
Maximum Execution Parallelism
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.
Identifies the automation principal to be used when authenticating to a

remote host. An automation principal defines user credentials that can be
used to access the remote system. For more information about automation
principals, see Creating automation principals on page 195.
Super-user Automation Principal
Identifies an automation principal that provides credentials for a superuser

account on a UNIX system. Only the SSH + SU command execution protocol
requires a superuser automation principal.
4 Click Finish. The Infrastructure Management window lists the remote host
authentication you created.
Creating or modifying rules for remote host authentication

Remote host authentication rules match remote host authentication definitions with
agentless devices.
Before you begin
Provide information used for remote host authentication. See Specifying or

modifying information for remote host authentication on page 288.
To create, modify or delete remote host authentication rules, your role must be
granted the following authorizations:

RoutingPolicy.Read
RoutingPolicy.Modify
To create a remote host authentication rule
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.
3 Complete the New Rule Wizard, as described in the following sections:
Remote host authentication rule General on page 294
4 Click Finish to close the wizard.
To modify an existing remote host authentication rule
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.
Remote host authentication rule General

The General panel provides identifying information for remote host authentication
rules.

Field definitions
Name
Enter a name for the remote host authentication rule.
Description
Optionally provide descriptive text for the rule.
Remote host authentication rule Rule Definition

The Rule Definition panel lets you create a remote host authentication rule. Remote
hosts that match the criteria specified in this rule are accessed using the remote host
authentication definitions, specified in another panel in this wizard.
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.
To create a remote host authentication rule
1 Click Add Property Condition . A window opens.
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:
TARGET*.FQ_HOSTFully qualified name of the target device.

TARGET*.IP_ADDRESSIP address of the target device.
TARGET*.FQ_NAMEName of the target device.
In addition, you can also use any custom properties that you have defined.
3 In the next drop-down box to the right, select a comparison-operator, such as

contains, equals, does not equal, or starts with.
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)
Remote host authentication rule Remote Host

Authentications
The Remote Host Authentications panel lets you select remote host authentication
definitions that should be used for agentless devices that match this remote host
authentication rule.
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.
Creating an agent bundle

An agent bundle maps target platform types to their corresponding agent installers.
An agent bundle is a depot object that:
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).

When you create an agent bundle, it is stored in the file server.
Multiple agent bundles
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.
Before you begin
To create and use agent bundles, your role must be granted the following
authorizations:
DepotFolder.Read on the folder where the agent bundle is stored
DepotFolder.Write on the folder where the agent bundle is stored
DepotFolder.Read on the folders where agent installers are stored
WindowsSoftware.Read, AIXSoftware.Read, LinuxSoftware.Read, or

SolarisSoftware.Read, to access the appropriate agent installer
AgentBundle.Read
AgentBundle.Create
Familiarity with exports, users.local, and secure files (optional)
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.

To create an agent bundle
1 Open the Depot folder. Select a sub-folder, right-click and select New => Agent
Bundle.
The New Agent Bundle wizard opens.
2 Define the agent bundle, as 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
Agent Bundle Properties on page 301
Agent Bundle Permissions on page 301
Agent Bundle General

The General panel provides information that identifies an agent bundle.
Field Definitions
Name
Identifying name.
Description
Save in
Agent Bundle Default Configuration

The Default Configuration panel lets you optionally specify the contents of the
exports, users.local, and secure files for all platforms.

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.
Using installer package defaults
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.
File Default contents
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
Overriding global settings
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.
Agent Bundle Configuration

The Bundle Configuration panel lets you map agent installer packages you added to
the Depot to platforms where you want to install agents. You can also optionally
override global configuration information for platforms.
Agent Installers list
You can use the Agent Installers list to:

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
.
Add Agent Installer window
Platform
Click the drop-down menu and select one of the following target platforms:
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
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.
Agent Bundle Summary

The summary panel lets you review the installers in the bundle.
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.
If you need to make changes, click Back to modify your choices.
Agent Bundle Properties

inherited.
Property .
Agent Bundle Permissions



this object.
you want to add.


Modifying agent bundles

You can modify an existing agent bundle.
To modify an agent bundle
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.

apply to the agent bundle, select the Properties, Permissions, or Audit Trail
tab group.
Creating an Agent Installer Job

You use an Agent Installer Job to install agents on servers.
An Agent Installer Job specifies:
The agent bundle on which the job is based.
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:
Can only install agents running version 8.2 or later
Cannot upgrade existing agents
Cannot uninstall agents
Before you begin
Do the following:
Set up remote host authentications. See Specifying or modifying information for

Set up remote host authentication rules. See Creating or modifying rules for
Create an agent bundle. See Creating an agent bundle on page 296.
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.
To create an Agent Installer Job
1 Perform any of the following actions:.
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.
2 Define the Agent Installer Job, as 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
Agent Installer Job Properties on page 312
Agent Installer Job Permissions on page 312
Authorizations for the Agent Installer Job

To create and run an Agent Installer Job, your role must be granted a variety of
permissions.
Required permissions for creating an Agent Installer Job
To create Agent Installer Jobs, your role must be granted the following authorizations:
JobFolder.Read on the folder where the job is stored
JobFolder.Write on the folder where the job is stored
AgentBundle.Read on the agent bundle referenced by the job
DepotFolder.Read on the folder where the agent bundle is stored
AgentInstaller.Create
AgentInstaller.Read

Required permissions for executing an Agent Installer Job
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
DepotFolder.Read on the folders where agent installers are stored
WindowsSoftware.Read, AIXSoftware.Read, LinuxSoftware.Read, or

SolarisSoftware.Read, to access the appropriate agent installers
AutomationPrincipal.Read, to access any automation principal referenced in the

remote host authentication
Server.Read on the PsExec server, if you are specifying a remote host

authentication for Windows
ServerGroup.Read on any server group selected as a target for the job
Server.Read on any server selected as a target for the job
Server.ModifyProperties 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 defined the job to push ACLs to the target)
AgentInstallerJob.Read on the job to be executed
AgentInstallerJob.Execute on the job to be executed
AgentBundle.Read on the referenced agent bundle
RoutingPolicy.Read
Agent Installer Job General

The General panel provides information that identifies an Agent Installer Job.

Field Definitions
Name
Identifying name.
Description
Save in

Agent Installer Job Options

The Options panel indicates the agent bundle on which the Agent Installer Job is
based and various other settings.
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
If an agent is successfully installed, the actions you select are performed.
Update Server Properties
Update the system with properties from the target servers on which you are
installing agents.
Update Configuration Objects Registration
Register any configuration objects that are found on the agent and defined in
the Configuration Object Dictionary.
Push Agent ACLs
Push agent ACLs to the servers that this job targets.
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
Specifies whether information copied to a staging area on a target server

during installation should be preserved if the installation fails. By default,
when the system has finished installing an agent, it automatically deletes all
files in the staging area.
Agent Installer Job Targets

The Targets panel lets you specify the servers on which you want to install agents.
Field definitions
Available Servers
By Group, By Name

servers.
Agent Installer Job Default Notifications

notifications.
Send email to
Send SNMP trap to


Agent Installer Job Schedules

Scheduling a job
daily, weekly, or monthly, or recur at some arbitrary interval.
a scheduled job runs.
Agent Installer Job Scheduled Job Notifications
completes.
Send email to
Send SNMP trap to


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.
To schedule jobs
Mean Time.
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
approval. The Execute on Approval field appears when you:
Create a schedule for a job that you are creating
Schedule an existing job for execution
Set a schedule in an execution task
page 617.
Agent Installer Job Properties

inherited.
Property .
Agent Installer Job Permissions



this object.
you want to add.

Operating system detection and the AGENT_PLATFORM*

property
Using the AGENT_PLATFORM* property, you can manually specify the operating
system of devices on which you want to install an agent using the Agent Installer.

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.
Process for determining a device's operating system
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.

Scenarios for installing agents
Modifying Agent Installer Jobs

You can modify an existing Agent Installer Job.
To modify an Agent Installer Job
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
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.

Scenarios for installing agents

You can install agents while you are adding servers to the system, or after you have
added servers.
There are two approaches to installing agents:
Installing agents as an integrated process while adding or importing servers on

page 315
Running the Unified Agent Installer or an Agent Installer Job after you add
servers on page 316
Installing agents as an integrated process while adding or

importing servers
1 Start the Add New Server wizard or the Import Servers wizard.
(For more information, see Adding a server to the system on page 261 or
Importing servers into the system on page 265.)

Troubleshooting agent installation
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.
Running the Unified Agent Installer or an Agent Installer

Job after you add servers
1 Start the Add New Server wizard or the Import Servers wizard.
(For more information, see Adding a server to the system on page 261 or
Importing servers into the system on page 265.)
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.

Use the following information to solve issues you may encounter while installing
agents from the console.
Access denied errors occur during install on Windows

targets
When installing agents on Windows targets, the user specified in the automation
principal for remote host authentication must have access to the admin shares of the

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.
To resolve this issue:
Use the default administrator account
Use a domain administrator account that has permissions for the target device
Create the following registry DWORD value and set it to 1.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
\System\LocalAccountTokenFilterPolicy
/etc/sudoers cannot be configured to accept only a root

password
It is possible to configure SUDO so that it requires you to give it the root password.
For many SUSE installations, the /etc/sudoers file is configured in this way.
However, agent installation does not work with this type of configuration. If the /etc/
sudoers file is configured to only accept the root password than the job will fail.
To resolve this issue, configure /etc/sudoers so it accepts passwords other than the
root password.


8
Managing servers
In BMC Server Automation, the Servers folder gives you a variety of utilities for
managing the servers in your system.
Servers folder overview

Using the Servers folder, you can perform various management tasks on the servers.
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

Properties and servers
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.

When you perform many actions in BMC Server Automation, you can use server
properties to specify information that is likely to change from server to server.
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.

Editable intrinsic properties for servers

Intrinsic properties are always associated with managed servers. You can edit many
intrinsic properties.
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:
Packages until they are applied during a deployment.
Network Shell scripts until they are run during a Network

Shell Script Job.
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.
Server properties: update concepts

Over time, you may need to update the server properties shown within the BMC
Server Automation system.
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.

There are two ways to do this:
Updating one servers properties, as described in Updating one servers

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
Updating one servers properties

You can update intrinsic properties for one server.
To update one servers properties
2 Navigate to the server whose properties you want to update.
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.
Properties for vCenter servers and IBM frames

To access the virtual infrastructure of a VMware vCenter (formerly Virtual Center)
server or IBM frame, the Application Server must communicate with a web service
in the case of the vCenter server, or the IBM hardware management console (HMC),
in the case of an IBM frame.
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.
Renaming a server using its properties

You can change the name of a server. Performing this procedure changes the name
of the server in the BMC Server Automation database.
Note
There are many caveats you should understand before performing this procedure.
See BMC technical documentation at https://docs.bmc.com/docs/display/bsa82/
Renaming+a+server for a full discussion of issues relating to server renaming.
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.
In the BLCLI, the command Server:renameServerFindByName can also rename a

server. See the BLCLI help for more information about this command.
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.
3 Enter a new name for the server.
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.

Creating Update Server Properties Jobs
5 In the Servers folder, refresh the folder holding the renamed server.

The Update Server Properties Job lets you automatically update intrinsic server
property values for a list of targeted servers.
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.
To create an Update Server Properties Job
1 To create a new Update Server Properties Job, do one of the following:
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.
The New Update Server Properties Job wizard opens.
2 Provide information for the Update Server Properties Job, as 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
Update Server Properties Job Properties on page 330
Update Server Properties Job Permissions on page 331

Update Server Properties Job General

The General panel lets you provide basic information that identifies an Update
Server Properties Job.
Field Definitions
Name
Identifying name.
Description
Save in
Date types updated
Check any of the following:
Update Server PropertiesUpdates properties on target servers.
Update Configuration Objects RegistrationRegisters any configuration

objects defined in the Configuration Object Dictionary that are not
currently registered on target servers.
An Update Server Properties Job always updates the status of a target

servers RSCD agent.


Update Server Properties Job Targets

Field definitions
Available Servers
By Group, By Name
servers.

Update Server Properties Job Default Notifications

notifications.

Send email to
Send SNMP trap to

Update Server Properties Job Schedules


Scheduling a job
Update Server Properties Job Scheduled Job Notifications

completes.
Send email to
Send SNMP trap to


Update Server Property Job Scheduling

To schedule jobs
Mean Time.
Update Server Properties Job Properties



inherited.
Property .
Update Server Properties Job Permissions

this object.
you want to add.



Modifying Update Server Properties Jobs

You can modify an existing Update Server Properties Job.
To modify an Update Server Properties Job
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.


Server organization concepts
Server organization concepts

Using the Servers folder, you can organize servers into groups.
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:
Smart server groups

Using smart server groups, you can organize servers dynamically by defining a
set of conditions for membership in a group. Any server with properties meeting
those conditions is automatically added to the group. When you provision a new
server, it can be automatically added to smart server groups. For example, you
can create a group for servers running Windows 2003. Servers with that version of
the Windows operating system are automatically added to the smart group.
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:
Cutting and pasting server groups.
Copying, cutting, and pasting smart server groups.
Copying, cutting, and pasting servers from one server group to another.
Deleting server groups, smart server groups, and servers.
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.
Assigning servers to server groups

After you create a server hierarchy, you must populate the server groups with the
servers you want to manage. The same server can appear in multiple server groups.

Assigning servers to server groups
BMC Server Automation provides several ways to organize servers in a server

hierarchy:
To assign servers to groups
Assign a server to a server group (see Assigning a server to a server group on

page 334).
Move existing servers between server groups (see Moving or copying a server
between server groups on page 335).
Assigning a server to a server group

You can assign a server to a specific server group.
To assign a server to a server group
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:
Click Next or Previous to display the next or previous page of servers.
Click First or Last to display the first or last page of servers.
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.

Decommissioning a server
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.
Moving or copying a server between server groups

You can move or copy existing servers between server groups.
To move or copy a server between groups
2 Navigate to the server you want to move.
3 Right-click the server and select Cut (to move the server) or Copy (to copy the
server).
4 Navigate to the new server group.
5 Right-click the server group name and click Paste. The server is now included in
the new server group.
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.
Decommissioning a server lets you reprovision or repurpose the server. For

example, you may want to install a different operating system and different
applications on the same physical hardware. To do this, you need to decommission
the server, repurpose it, and then add the newly configured server back into the

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 navigate to a server you want to decommission.
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.
2 Right-click and select Administration Task => Decommission Server.
The Decommission Servers dialog box appears.
3 Click OK to confirm that you want to decommission the servers listed in this
dialog.
A background process decommissions the server or servers. Depending on how you

have specified behavior for background processes, either a dialog box appears 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 information
about the dialog box and background operations, see Running background
operations on page 77.
About decommissioning servers

This topic provides details about decommissioning a server and its effects on jobs
and components associated with the server.
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:
If a decommissioned server is the target of a Snapshot Job or an Audit Job,

then the job result associated with the server is marked for deletion in the
database and no longer appears in the console.
If the last server associated a Snapshot Job or an Audit Job is
decommissioned and the last job result associated with that
decommissioned server is marked for deletion, then the job run is also
marked for deletion in the database and no longer appears in the console.
For example, suppose you execute a Snapshot Job against two servers
(Server A and Server B). If you decommission Server A, the job results
associated with Server A are marked for deletion in the database; however,
the job run is not marked for deletion. If you then decommission Server B,
the job results associated with the Server B are marked for deletion in the
database and the job run is marked for deletion in the database and no
longer appears in the console.
If a decommissioned server is used as a Master in an Audit Job, then the

Audit Job is marked as having broken dependencies.
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.

Server browse options
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.
If a job run includes components associated with decommissioned servers as well

as servers that are not decommissioned, the job run is not marked for deletion.
However, job results related to components associated with the decommissioned
servers are marked for deletion in the database and no longer appear in the console.
If a component associated with a decommissioned server is used as a Master in an

Audit Job, then the Audit Job is marked as having broken dependencies.

You can browse any server in the Servers folder by right-clicking the server and
selecting Browse.
A tab showing the servers name opens in the content editor. At the bottom of the
tab, there are four sub-tabs:
Live BrowseShows a hierarchical tree consisting of multiple nodes. Each node

represents a type of server object found on that server. The tree also shows any
components and extended objects associated with the server. You can expand any
node in the Live Browse list to see a list of server objects, such as Hotfixes or
RPMs. For a list of all the objects you can browse, see Contents of the Live node on
page 339.
Note
In earlier releases, BMC Server Automation referred to custom configuration
objects as custom server objects.
If an extended object is associated with an operating system, that extended object

appears as a child of the Extended Object node. If an extended object is not
associated with a particular operating system, the extended object appears at the
same level in the hierarchical tree as the Extended Object node. In other words,
the object is a sibling of the Extended Object node.
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.
Contents of the Live node

The contents of the Live node vary by operating system.
Virtual environments contain specialized Live node children, which are described in
Browsing virtual inventory on page 857.
Operating System Server Objects

IBM AIX
BLPackages
Components
Configuration
Daemons
Extended Objects
File System
Hardware Information
Packages
Patches
Processes
System Info
UNIX Groups
UNIX Users
HP-UX
BLPackages
Bundles
Components
Configuration
Daemons
Extended Objects
File System
Patches
Processes
Products
System Info
UNIX Groups
UNIX Users


Linux
BLPackages
Components
Configuration
Daemons
Extended Objects
File System
Processes
RPMs
System Info
UNIX Groups
UNIX Users
Oracle Solaris
BLPackages
Components
Configuration
Daemons
Extended Objects
File System
Packages
Patches
Processes
System Info
UNIX Groups
UNIX Users


Microsoft Windows
.NET Global Assemblies
Active Directory
Applications
BLPackages
Complus
Components
Configuration
Event Logs
Extended Objects
File System
Hotfixes
Local Groups (shows no data if server is
domain controller)
Local Users (shows no data if server is
domain controller)
Metabase (if Microsoft IIS is installed)
Registry
Security Settings (some limitations apply
see Limitations for Windows security
settings on page 753)
Services
System Info
The following list provides additional information about nodes that are children of
the Live node:
Active DirectoryProvides a hierarchical listing of the groups, shared folders,

and users associated with Active Directory domains and sub-domains on a
Windows server.
BLPackagesShows all BLPackages that have been deployed to a server. For

more information about using this object, see Tracking BLPackage deployments
on page 772.
ComponentsShows components associated with a server. Components are

objects representing a higher level of abstraction than server objects. Using a
component, you can manage an application rather than the server objects that
make up the application. For more information, see Components and component
templates on page 351.
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

Server objects: management concepts
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.
Extended ObjectsShows custom objects that consist of information after it is

parsed by a BMC Server Automation grammar file (see Grammar files supported
by BMC Server Automation on page 570) so it can be presented in a standard
format. Extended objects can deliver information not included in a standard BMC
Server Automation installation, such as local user account data or network
settings. For more information, see Creating an extended object on page 577.
File SystemProvides a hierarchical listing of the servers files and directories.

When browsing a file system, you can traverse symbolic links to files and directories.
Hardware InformationProvides information about a servers hardware

configuration.
Note
Different operating systems, especially in virtual environments, expose
different levels of details relating to hardware information. The level of detail
provided by the hardware information object typically varies for different
platforms.

You can perform a variety of actions on server objects.
Here are the most common actions you perform on server objects:
BrowseUsing the hierarchical tree in the Servers folder, expand servers to

examine the server objects they contain. For more information about server
objects, see Server browse options on page 338.
SnapshotCreate Snapshot Jobs that record the configuration of server objects.

For more information, see Snapshot overview on page 649.
AuditCreate Audit Jobs that compare server object configurations on multiple

servers to a master configuration in the form of a snapshot, component, or live
server. For more information, see Audit Jobs on page 677.
ComplianceCreate Compliance Jobs that determine whether one or more

servers satisfy collections of compliance rules. For more information, see
Creating Compliance Jobs on page 439.

DeployDeploy software and packages of server objects to other servers. For

more information, see Software and BLPackage Deploy Job overview on page
713. To deploy files, you can also use a File Deploy Job (see File Deploy Job
overview on page 773).
The Servers folder also lets you perform the following administrative tasks while
managing server objects:
Copying and pasting files and directories on page 343
Deleting files and directories on page 344
Starting and stopping services on page 344
Viewing server objects on page 344
Copying and pasting files and directories

From the Servers folder you can copy and paste files and directories within a server
or between servers. This utility does not allow you to copy and paste symbolic links
or drives.
To copy and paste files and directories
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.
2 Select one or more files and directories in the content editor.
3 Right-click and select Copy from the pop-up menu.
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.

Deleting files and directories

From the Servers folder you can delete files and directories.
To delete files and directories
menu. Then, select the Live node and select the File System server object type.
2 Select one or more files and directories in the contents pane.
3 Right-click and select Delete from the pop-up menu. A dialog box prompts you to
confirm the deletion.
4 Click OK. The selected files and directories are deleted.
Starting and stopping services

From the Servers folder you can start and stop Windows services.
To start and stop services
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.
Viewing server objects

From the Servers folder, you can view the properties and security information for
many types of server objects.
To view server objects
View server object properties, as described in Viewing server object properties

on page 345.
View security information, as described in Viewing security information for

files and registry keys on page 345.

Viewing server object properties

From the Servers folder, you can view properties for server objects.
To view server object properties
menu. Then, use the Live node to select one of the following server object types:
.NET Assemblies Windows
Event logs Windows
Files and directories Windows and UNIX (including VMware VMFS file
systems)
Hotfixes Windows
Local groups Windows
Local users Windows
Registry keys Windows
Security settings 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.
3 To close the Properties dialog box, click Close.
Viewing security information for files and registry keys

From the Servers folder, you can view security information for registry keys and files
on Windows servers using NTFS.
This procedure lets you view discretionary ACLs (DACLs) and system ACLs
(SACLs) for a selected file or registry key.

To view security information
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.
2 To view detailed information about permissions granted to users, select a user

and click View Details . A dialog box displays the permissions granted or
denied for this file to the selected user. Click Close to close the dialog box.
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.

Executing custom commands
4 To view information about permissions causing an event to fail or succeed, select

an event type, such as failures for Administrator on a particular machine, and
then click View ACL Details . A dialog box shows the permissions that cause
events to be logged to the Windows system event log. Click Close to close the
dialog box.
5 Click Close to close the dialog box.

A custom command allows you to take a variety of actions.
You can:
Launch a script or executable program on a target server. If necessary, the script

or program can execute against a file or directory on the target server.
Launch an application that resides on the users local computer.
Scripts, programs, or applications can execute in a command line interface, a

graphical user interface, or a tabular format like a spreadsheet that is displayed
within a separate tab in the BMC Server Automation console. Custom commands
allow you to perform many functions from within the system that might otherwise
require you to launch command line interfaces, such as Network Shell, or other
external applications.
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.
For information about creating custom commands, see Custom commands on

page 977.
To execute a custom command
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.
One of the following occurs:
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 a server group to select all servers within the group.
Click one or more servers, if necessary expanding 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.
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.
If the command is defined so you cannot modify the commands arguments,

the Command Options field is not shown. Instead the command and its
arguments all appear in the Server Command field, which is not editable.
8 Click Execute and the remote command runs on the servers you have specified.
Configuration for Network Shell Proxy Server traffic

When using the custom command NSH Here, some configuration is necessary to
ensure that Network Shell traffic is routed through a Network Shell Proxy Server.
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.


9
Components and component
templates
This chapter describes how to use component templates and components in BMC
Server Automation.
Components and component template

overview
A component is a collection of configuration settings that encapsulates a business or
infrastructure service, application, or security policy.
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.
To create a component, you must first define a component template, which

establishes rules and provides necessary information for the component, and then
associate the template with a server. A component template consists of the following:
Template partsServer objects that constitute the component. You can

parameterize template parts to accommodate variations between servers,
departments, and networks.
SignatureA set of conditions that must be satisfied on a server for a component

template to be associated with that server. A Component Discovery Job compares
a signature to the configurations of designated servers. When the Component
Discovery Job finds that a server satisfies a component signature, the job
associates the component template with the server and creates a component.

Component usage and capabilities
Allowed operationsDecisions about what operations can be performed using

this component, such as browsing, snapshots, audits, deployments, and discovery.
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.
Local propertiesA set of properties that are assigned to the component

template. Using local properties, you can define multiple instances of a
component on the same server.
Component usage and capabilities

Typically an expert user defines a component template and then uses the template to
discover components on servers.
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.
Using components, users with any level of sophistication can:
Deploy custom applications as a single unit of information to multiple servers.
Determine component-level compliance to policies rather than compliance at the

server object level.
Make controlled changes to multiple servers by translating changes in a single

component to changes on multiple target machines.
Perform baseline analyses by comparing the configuration captured in a

component to other servers.
BMC Server Automation recommends a standard methodology for using

components, as described in Process for using components on page 353. Following
these recommendations can help you implement components efficiently and achieve
the greatest benefit from them.

Process for using components

While the BMC Server Automation Console offers a flexible user interface that
allows multiple approaches to a single problem, BMC Server Automation suggests a
standard process for using components.
The process consists of the following phases:
Establishing requirements (see Component requirements on page 353)
Designing components (see Component design on page 353)
Discovering components (see Component discovery on page 356)
Implementing usage of components (see Component usage implementation on

page 357)
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:
Software modelsDefining and maintaining policies about infrastructure services

and applications. At the infrastructure level, components are commonly used to
manage implementation of application and database servers like WebLogic and
Oracle. At the application level, components can encapsulate complex programs
such as web servers, backup agents, monitoring agents, and business service
management systems.
Compliance policiesDefining and maintaining collections of configuration

policies, such as required settings for password lengths, password expiration
periods, and lockout rules.
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.
When defining component templates, many configurations settings vary between

environments. For example, settings may change between servers, networks, or
departments. A component template lets you accommodate these differences using
parameters. A parameter can resolve to a different value on each server. For
example, the path to a directory can include parameters such as ??
TARGET.SYSTEMROOT??/rsc. In this example, ??TARGET.SYSTEMROOT?? can
have different values on different target servers, such as /c or /d. Similarly, a path
such as /usr/??TARGET.DEPLOYPATH?? could resolve to values like /usr/DEV, /usr/
QA, or /usr/PROD. A deploy path like this allows a component to be discovered in
different locations on servers used by different departments.
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:
Allowable OperationsDetermines whether a component as a whole can be

used for browsing, snapshots and audits, discovery, deployments, and
compliance. If a component is subject to compliance, you must also determine
whether its configuration can be remediated when compliance failures occur.
Template PartsDefines the collection of configurations on which you can

operate. For example, template parts can be collections of files, properties, and
registry values or a group of security settings.
A component template does not have to include only those parts used by an
application. A part can be used for other purposes, such as component discovery
and compliance. Some users include a part that should not exist and test for its
presence when discovering the component. If the part is present, the component is
not discovered.
When defining component template parts you can choose the types of operations
that each part is used for, such as compliance, browsing, snapshots, and audits.
SignatureSpecifies the set of conditions that a server must satisfy for a

component to be created. A signature can be a very simple test, such as verifying
the existence of a single server part, or it can be much more sophisticated,
specifying multiple mandatory conditions.
Signatures must be based on template parts and properties. You can specify that a
part must exist or that it must exist and satisfy a list of additional criteria in the
form of part characteristics. When evaluating part characteristics, you can use
many types of operators, such as equivalence, inequality, membership in a list, or
inclusion in a range of values. Similarly, you can specify that a part cannot exist.
You can also specify that either a part does not exist or, if it does, it must satisfy a

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.
BrowseSpecifies the individual template parts that can be browsed after a

component has been associated with a 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.
ComplianceSpecifies a subset of the component template parts and defines

compliance rules that these parts must satisfy. Each compliance rule can include a
set of instructions explaining what actions to take if a rule is not satisfied. One
possible action is the deployment of a BLPackage to correct the problematic
configuration.
After a component template is complete, you can run a Compliance Job to
monitor the configuration of component. For each component, the Compliance Job
examines the template parts specified in the compliance rules, comparing them to
the rules that you have defined. When a component fails to satisfy the compliance
rules and remediation is enabled, you can deploy a BLPackage to correct the issue.
Remediation can occur automatically, as part of a Compliance Job, or you examine
Compliance Job results and manually remediate compliance rule failures.
Local PropertiesSpecify properties you can assign directly to a component

template. Local properties let you discover multiple instances of the same
component on the same server. For example, on a single machine you may want
to create two versions of the same componentone for development and one for
QA. In such a case, you can use two instances of a local property, with each
instance defined to the values you need. A Component Discovery Job will
automatically discover a component for each of those local property instances.
Local Configuration ObjectsAllow you to create configuration objects (that is,

configuration files or extended objects) that only apply to this component
template. When defining a local configuration object, you can specify a path to
that object using local properties as parameters. Setting up properties in this way,
you can create one definition of a configuration object that applies to multiple
components on the same server.

Install/UninstallAllows you to install and uninstall components and

applications by associating Batch Jobs with component templates. The installer
Batch Job runs a series of jobs that deploy all parts necessary to create a
component. The uninstaller Batch Job can remove component parts and invalidate
an existing component. Similarly, if you have the BMC Application Automation
product installed, you can run Batch Jobs that install and uninstall applications.
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.
When components are successfully discovered on a server, BMC Server Automation

creates a representation of that component in the Servers and Component Templates
folders. In the Servers folder, the component is associated with the appropriate
server when you browse the server. In the Component Templates folder, the
component is associated with the appropriate component template. You can also
organize and manually display components in the Components folder.
Note
Discovering components does not actually change the physical configuration of a
server. It simply associates a higher-level object with a server.
BMC Server Automation also provides a mechanism for manually associating a

component with a server, as described in Adding components to servers manually
on page 425. This procedure is mainly useful as a way to quickly add a single
component to a server. Manual creation of components lets you define exceptions to
compliance rules. This can be valuable if you know a server cannot satisfy
compliance rules but you want to associate a component with it nonetheless.
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.
Component installs and uninstalls

BMC Server Automation lets you install and uninstall components by associating
Batch Jobs with component templates.
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.
Component usage implementation

After you have discovered components, you can begin to implement their use.
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).

Organization of components and component templates
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.
Organization of components and component

templates
BMC Server Automation provides two folders for creating and using components:

Creating a component template
Component Templates folderUsed for creating and storing component

templates, organizing components based on component templates, running
Component Discovery Jobs, and launching other types of jobs that are based on a
component template.
Components folderUsed for organizing components that have already been

discovered.
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.
Cut and paste component template folders.
Delete components, component templates, folders, groups, and smart groups.
For a description of any of the procedures listed above, see Folder content
organization on page 104.

You can create a component template, which, at its most basic, is the definition of the
parts that make up a component.
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.
To create a component template
1 Open the Component Templates folder, right-click a component templates

folder, and select New => Component Template from the pop-up menu. The
Create New Component Template wizard opens.
2 Define the component template on the wizard panels, as described in the

following sections:
Component Template General on page 360
Component Template Parts on page 361

Component Template Properties on page 370
Component Template Permissions on page 370
A dialog box prompts you to edit the component template.
4 Click OK to begin editing the component template. To save the component

template without editing it, click No.
Component Template General

The General panel lets you provide identifying information for a component
template, and it lets you choose the types of operations that can be based on this
component template, such as browsing, snapshots, audits, and compliance.
Field definitions
Name
An identifying name for the component template.
Description
(Optional) Descriptive text for the component template.
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
The operations that can be performed using any component discovered

based on this component template. Any of the following:
DiscoverRun Component Discovery Jobs on servers to identify

components matching this component template signature.
BrowseBrowse components that have been discovered using this

component template.

SnapshotRun Snapshot Jobs on any components that have been

discovered using this component template.
AuditRun Audit Jobs on any components that have been discovered

using this component template. You can also use this component as part of
the master for any Audit Job.
DeployDeploy packages to components that have been discovered

using this component template. If you do not check this option, you
cannot use Deploy Jobs to target components.
ComplianceRun Compliance Jobs on components that have been

discovered using this component template. A Compliance Job determines
whether a component satisfies the compliance rules defined for the
component template. If you check the Compliance option, you can also
check any of the following:
Allow RemediationLets you deploy a BLPackage to correct a

discrepancy when a compliance rule is not satisfied.
Allow Auto-remediationLets you choose to deploy a BLPackage

automatically to correct a discrepancy when a compliance rule is not
satisfied. Selecting this option does not mean a Compliance Job
automatically remediates. Instead, it allows you to choose auto-
remediation when you define compliance rules. When you select Allow
Auto-remediation, the Allow Remediation option is checked
automatically.
Component Template Parts

The Parts panel lets you specify the server objects that make up the component
template. You can skip this panel when you are creating a new component template.
The Parts panel is optional:
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.

Adding template parts

When you specify template parts, you can insert parameters into their paths.
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.
To add a template part to a component template
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.
3 Click OK to close the Add Parts window.
The template parts you defined appear in the Parts list.
4 To include an entire hierarchy when adding a hierarchical server object (such as a

directory):
1 Select the top level server object in the Parts list.
2 Check Recurse subfolders at the bottom of the Includes/Excludes list.

This option includes all folders subordinate to the selected server object.
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.
On target Windows servers, if a drive is not specified for a part, the Windows
RSCD agent supplies a default drive, which is the value in the SystemDrive
environment variable.
Updating a template part

Through the Parts panel, you can update any of the parts included in the component
template.
To update a template part
1 On the Parts list, select a part and then click Update .
The Update Part window opens.
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.

4 To include an entire hierarchy when updating a hierarchical server object (such as

a directory):
1 Select the top level server object in the Parts list.
2 Check Recurse subfolders at the bottom of the Includes/Excludes list.

This option includes all folders subordinate to the selected server object.
Defining includes and excludes for a part

The Includes/Excludes section lets you include or exclude some server objects from
those that 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.
To define includes and excludes for a part
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.
Select an existing include or exclude and click Modify . 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 .
2 Depending on what you are specifying, click Include or Exclude.
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:
Files and directories

COM+
Metabase
Registry
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
* Match multiple characters including zero-length

strings. This pattern does not match a separator
character in a path, such as /.
? Match any single character.
[] Match any single character if it is included in the
bracketed characters. A range of characters can be
specified using a hyphen between the start and end
of the range, such as [a-z].
The following table shows examples of wildcard matches.
Matching Pattern Explanation
*.html Match server objects ending in .html in the current

directory
??? Match server objects that contain exactly three
characters

Matching Pattern Explanation
foo.[ch] Match a server object called foo.c or foo.h

*.[a-z] Match all server objects in the current directory that
have a one-letter lower case extension
web Match server objects called web
[Ww]eb Match server objects called either Web or web
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.
Specifying snapshot and audit options

The Snapshot/Audit Options section of the Template Parts panel lets you make
choices controlling the behavior of snapshots and audits that are based on a component.
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.
To specify snapshot and audit options for a template part
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
Compare the status of user accounts.
ACL Owner
Compare the owner of a file or registry key.
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
Compare users language of choice.
Contents
Compare file content when performing an audit based on a snapshot of file

content.
Effective Setting as String Value
Compare the effective value of security settings.
Full Name
Compare users full names.

Group members
Compare the groups belonging to a Local Group.
Group owner
Compare a files group ID.
Home Directory Drive
Compare the home directories of user accounts.
Home Path
Compare the home paths of user accounts.
Inherit Auditing ACL
Compare whether an object inherits access control entries in the System

Access Control List (SACL) from its parent object.
Inherit Permission ACL
Compare whether an object inherits access control entries in the

Discretionary Access Control List (DACL) from its parent object.
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.
Local Setting as String Value
Compare the value of security settings defined for each server.
Login Script
Compare the login script for user accounts.
Logon Server
Compare users logon server.
Max Size
Compare the maximum size of event logs.

Member of
Compare the groups to which users belong.
Permission ACL
Compare 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.
Permissions
Compare the permissions assigned to files.
Privilege Level
Compare the privilege level for user accounts.
Profile Path
Compare user profile paths.
Retention
Compare the amount of time event logs are kept.
Size
Compare the sizes of files.
User Expire Date
Compare the dates when user accounts expire.
User members
Compare the users belonging to a Local Group.
User owner
Compare a files user ID.
Version
Compare file version information for DLL, EXE, and other types of files.

Component Template Properties


inherited.
Property .
Component Template Permissions

this object.
you want to add.

Editing a component template



When you create a component template using the Create New Component Template
wizard, you typically define the parts that make up the template. Later, you refine
the component template during an editing process.
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).
To edit a component template
1 In the Component Templates folder, navigate to the component template that

you want to edit. Right-click the component template and select Open.
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:
General tab for a component template on page 373
Parts tab for a component template on page 374
Discover tab for a component template on page 375
Browse tab for a component template on page 381
Snapshot/Audit tab for a component template on page 382
Compliance tab for a component template on page 384
Local properties for a component template on page 412
Local Configuration Objects tab for a component template on page 414
3 After editing the component template, click Save to save your changes.

General tab for a component template

The General tab lets you choose the types of operations that can be based on this
component template.
The General tab contains the following fields and screen elements:
Allowed Operations
The operations that can be performed using any component discovered

based on this component template. Any of the following:
DiscoverRun Component Discovery Jobs on servers to identify

components matching this component template signature.
BrowseBrowse components that have been discovered using this

component template.
SnapshotRun Snapshot Jobs on any components that have been

discovered using this component template.
AuditRun Audit Jobs on any components that have been discovered

using this component template. You can also use this component as part of
the master for any Audit Job.
DeployDeploy packages to components that have been discovered

using this component template. If you do not check this option, you
cannot use Deploy Jobs to target components.
ComplianceRun Compliance Jobs on components that have been

discovered using this component template. A Compliance Job determines
whether a component satisfies the compliance rules defined for the
component template. If you check the Compliance option, you can also
check any of the following:
Allow RemediationLets you deploy a BLPackage to correct a

discrepancy when a compliance rule is not satisfied.
Allow Auto-remediationLets you choose to deploy a BLPackage

automatically to correct a discrepancy when a compliance rule is not
satisfied. Selecting this option does not mean a Compliance Job
automatically remediates. Instead, it allows you to choose auto-
remediation when you define compliance rules. When you select Allow
Auto-remediation, the Allow Remediation option is checked
automatically.
Notes
Additional information about the component template.

Parts tab for a component template

The Parts tab lets you add and update the parts that make up a component template.
In addition, parts that you reference in rules on the Discover or Compliance tabs are
automatically added to the Parts tab.
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.
Adding template parts on page 362
Defining includes and excludes for a part on page 364
Specifying snapshot and audit options on page 366
Updating a part for an existing template on page 374
Updating a part for an existing template

Through the Parts tab, you can update any of the parts included in the component
template that you are editing.
To update an existing template part
1 On the content editor, click the Parts tab.
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.
4 Under Included Operations, check any of the following:
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.
ComplianceRun Compliance Jobs on this part in any components that have

been discovered using this component template.
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.
Discover tab for a component template

The Discover tab lets you create and test a component signature through a Rule
Editor. A signature defines conditions that must be satisfied for a component to be
associated with a server.
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:
Creating a component signature on page 376

Testing a component signature on page 379
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.
Creating a component signature

The Discover tab lets you can create a single component signature, which contains
the conditions that must be satisfied for a component to be associated with a server.
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.
The component signature can contain the following types of conditions:
Basic conditions, which perform the following tasks:
Check for the existence or number of occurrences (cardinality) of a configuration

object, such as a service or a certain type of installed software.
Compare configuration object properties or component properties with defined

values or with other such properties.
Conditional constructs, which organize multiple conditions in an if-then-else logical

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

To create or edit a signature that associates a component with a server
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.
2 In the Rule Definition area, do one of the following:
To create a new signature, click the Add icon on the right.
To edit an existing signature, click the Edit icon.
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.
3 In the Rule Editor, do one of the following:
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.
Basic Condition for a basic condition
If Then End, Elseif, or Else for a conditional construct or block within it
To add a new condition to a signature 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 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:
To view keyboard shortcuts on page 94
To define a conditional construct on page 399
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.
Add parentheses to a selected line.
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 .
8 To test the signature, see Testing a component signature on page 379
Testing a component signature

Before you run the Discovery Job, you can test whether servers satisfy the signature
conditions that you specified on the Discover tab of the component template.
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.
To test a component signature
1 On the Discover tab of the component template, click the Edit icon on the
right.
2 In the Rule Editor, click Test the Rule .
The Test Signature window opens.
3 In the Target Selection area on the left, click Add Servers .
The Add Servers window opens.
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.
5 Click OK to close the Add Servers window.
The selected servers appear in the Target Selection area. To view the list, you
might need to expand the Servers tree.
To remove a server, select it and click Remove Item .
6 Click Run Test to test the signature on all selected servers.

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.
8 In the top pane, select a condition within the signature.
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.
10 Click Close to close the Test Signature window.
Browse tab for a component template

The Browse tab lets you identify the component parts that can be browsed after a
component template has been discovered on a server and limit browsing capabilities
to that group of parts. By default, all component template parts can be browsed.
For instructions on how to select component parts for browsing, see Specifying parts
available for browsing on page 381.
Specifying parts available for browsing

You can limit the browse capability to a specified group of parts. The default is that
all parts are available for browsing.
To limit browsing capability to a group of component parts
1 On the content editor, click the Browse tab.
2 Click Add Parts . The Select Parts window opens.
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.

4 Click OK to close the Select Parts window.
Required permissions for browsing component parts

To live-browse the contents of a discovered component part, a user role requires
read permission on the component, the component template, and the server.
Browsing the contents of a component requires a combination of permissions that

vary depending on your context. The following table describes the minimum
permissions needed.
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
Snapshot/Audit tab for a component template

The Snapshot/Audit tab lets you identify the component parts on which you can run
Snapshot and Audit Jobs after this component template has been discovered on a
server.
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:
Specifying parts to include in snapshots and audits on page 382
Specifying Snapshot/Audit options on page 383
Specifying parts to include in snapshots and audits

You can specify the component template parts on which you can run Snapshot and
Audit Jobs.

To specify parts for snapshots and audits
1 On the content editor, click the Snapshot/Audit tab.
2 Click Add Parts . The Select Parts window opens.
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.
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.
Specifying Snapshot/Audit options

The Snapshot/Audit Options section of the Snapshot/Audit tab lets you specify
information associated with server objects to be included in snapshots or audits.
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.

To specify snapshot and audit options for an existing component template
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 attributes, click Select All next to Snapshot.
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.
Compliance tab for a component template

The Compliance tab lets you define compliance rules for analysis on a collection of
component template parts (also referred to as compliance parts).
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.
If a component template has a broken dependency on a deleted BLPackage, the

Compliance tab may include broken compliance rules. These are marked with a red
X superimposed on a corner of the compliance rule icon. If a component template
includes broken compliance rules, you can correct them by editing the rule,
specifying an existing BLPackage as the correct compliance package, or removing the
broken rule. You cannot edit and save a component template that includes a broken
compliance rule.
The Compliance tab lets you perform the following procedures:
Adding compliance parts, as described in Understanding the compliance parts

list on page 385
Adding a compliance rule group on page 387
Adding or editing a compliance rule on page 387
Commenting out and uncommenting a compliance rule on page 411
Copying, cutting, and pasting a compliance rule on page 411
Understanding the compliance parts list

The top portion of the Compliance panel lists the component template parts that are
used or are available for use in compliance rules.
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.
To add or remove parts for association with Compliance Jobs
1 On the content editor, click the Compliance tab.
2 Click Add Parts to open the Select Parts window.
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.
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.
Adding a compliance rule group

You can create any number of compliance rule groups to contain the various
compliance rules that you define. Organizing compliance rules in groups can make it
easier to re-position compliance rules.
To add a compliance rule group
2 Click Add New Rule Group .
The Add Compliance Rule Group window opens.
3 For Name, enter an identifying name for the rule group. For Description, you can
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.
Adding or editing a compliance rule

You can add a new compliance rule or edit an existing compliance rule.

To add or edit a compliance rule
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 add a new compliance rule, click Add New Compliance Rule .
To edit an existing compliance rule, select the rule and click Edit Selected Item
.
The Compliance Rule Editor panel opens.
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:
Defining general rule settings in the Rule Editor on page 388
Defining a rule in the Rule Editor on page 389
Defining remediation options in the Rule Editor on page 410
5 Click Save after you have finished defining the rule.
6 Switch back to the component template editor and click Save to save the
component template.
Defining general rule settings in the Rule Editor

The General tab in the Compliance Rule Editor lets you provide identifying
information for a compliance rule.
To define the general settings of a compliance rule
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.

3 To temporarily disable this compliance rule, check Comment Out.
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.
Defining a rule in the Rule Editor

You can define a rule in the Rule Editor.
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:
basic conditions that use various comparison operators to
check for the existence or number of occurrences of a configuration object (a

cardinality condition)
compare configuration object properties or component properties with defined

values or with other such properties
conditional constructs for organizing conditions in an if-then-else logical sequence
loops for iterative analysis 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 create or edit a rule
1 On the Rule Definition tab, do one of the following:
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.
If Then End, Elseif, or Else for a conditional construct or block within it
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:
Defining a basic condition on page 395
Defining a conditional construct on page 398
Defining a loop on page 400
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.
Add parentheses to a selected line.
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 .
6 To test the rule, see Testing a compliance rule on page 407.
Using wildcards in compliance rules

The compliance rules editor supports wildcards for matching objects. Wildcards can
apply to asset path names, extended object values, and configuration file entries.
Table 1: Wildcard Summary
* Matches multiple characters, but not path separator characters, such as /.

Consequently, this wildcard does not cause recursive matching.
** Matches multiple characters, including path separator characters, recursing
through:
Subfolders in asset path names
Entries in configuration files and extended objects
? Matches any single character.

[character sequence ] Matches any single character included in the bracketed characters.

Using the * wildcard
The * wildcard matches multiple characters, but not path separator characters, such
as /. Consequently, this wildcard does not cause recursive matching.
In path names
In a path name, * does not recurse through lower directories.
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:
foo value1 value2

foo1 value1 value2
but not
foo/foo1 value1 value2
The following compliance rule matches all objects beginning with the phrase "discard":
<description>Ensure that service Discard is disabled</description>

<notes>Insecure and unnecessary services, unless required for business
purpose, should be disabled to reduce the risk of system compromise using
these services. These service may pose risk to system due to inherent risks
associated with such services.</notes>
- <expression>
- <![CDATA[
foreach "Extended Object Entry:Unix Services//discard*"
"Value1 as String (All OS)" equals "disabled"
end

]]>
</expression>
In configuration files
In configuration files, * does not recurse through the entries in the file.
For example:
somefile.conf//*ABC*
finds the following entries inside somefile.conf:
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:
"Configuration File Entry:/etc/inet/inetd.conf//ftp-*" exists AND

foreach "Configuration File Entry:/etc/inet/inetd.conf//ftp-*"
"Value6 as String (All OS)" equals "in.ftpd" AND
"Value8 as String (All OS)" equals "-d" AND
"Value9 as String (All OS)" equals "-l"
end
Using the ** wildcard
The ** wildcard matches multiple characters, including path separator characters.
In path names
In a path name, the ** wildcard recurses through lower directories.
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:
foo value1 value2

foo/foo1 value1 value2
bar value1 value2
The following compliance rule recurses to match multiple tty entries:
<description>Ensure that login: prompts on serial ports are disabled.</

description>
<notes>Make security-related technology resistant to tampering, and can
not be compromised by unauthorized users.</notes>
- <expression>
- <![CDATA[
foreach "Extended Object Entry:BL-LXO Disable login: prompts on serial ports//
tty**"
"Value3 as String (All OS)" contains "x"
end
]]>
</expression>
In configuration files
In configuration files, the ** wildcard recurses through the entries in the file.
For example:
somefile.conf//**ABC**
finds the following entries inside somefile.conf:
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:
<description>Ensure .rhosts Support in /etc/pam.conf is disabled.</

description>
<notes>Make security-related technology resistant to tampering, and can
not be compromised by unauthorized users.</notes>

- <expression>
- <![CDATA[
foreach "Configuration File Entry:/etc/pam.conf//**"
"Value3 as String (All OS)" does not contain "rhosts_auth"
end
]]>
Using the ? wildcard
The ? wildcard matches any single character.
For example:
/usr/org?/*
finds
/usr/org1/mary
/usr/org2/john
but not
/usr/org10/mary
Using the [] wildcard
The [ ] wildcard matches any single character included in the bracketed characters.
For example:
log*201[12]
matches:
logJanuary52011
logJanuary52012
but not:
logJanuary52010
Defining a basic condition

Basic conditions perform analyses on configuration objects. Using basic conditions,
you can check for the presence, absence, or number of occurrences (the cardinality) of
a configuration object. In addition, you can evaluate configuration object properties
or component properties by comparing them with constant values or with other
properties.

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.
To define a basic condition
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.
2 Define the LHS operand through the displayed selection box.
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.
Branch How to use
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
To check for the presence or number (cardinality) of the configuration

object, click the string that represents the configuration object.
To analyze a property of the configuration object, select one of the

properties listed below the configuration object.
To select a configuration object or configuration object property that was

recently used in the rule, either click the branch of the specific
configuration object or expand that branch and click one of the properties
listed below it.

Branch How to use

2.b
Loop Iterator Properties For a basic condition within a loop, expand this branch to select a
property for the configuration object specified in the current loop. For
more about loops, see Defining a loop on page 400. Note that this branch
appears only within a loop.
2.a
Configuration Object Types Use this branch to specify a property of the configuration object based on
its object type. First expand this branch and select an object type from the
full list of object types. Then manually enter the full path to the
configuration object directly into the LHS operand field, as described in
Step 3 on page 397.
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.
b Loops are used in compliance rules but not in a discovery signature.
Your selection appears in the LHS operand field.
A configuration object appears as a string with the following syntax:

"objectType:objectPath" (for example: "File:/C/a.log"). A property of the
configuration object is appended to this string after a period (for example: "File:/
C/a.log".size").
A component property appears as a string with delimiting pairs of question

marks both before and after the property name (for example: ??PATH??).
For a nested property, the typical syntax for the property string is ??
propertySubclass.propertyName?? (for example: ??GROUP.GROUP ID??.
Note
If the field already contained a textual string, the new component property is
inserted at the current cursor point or replaces selected text, but does not
replace the full textual string.
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:
* 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.

** Match multiple characters, including path separator characters. Using this wild
card allows a path to recurse through lower directories.
? Match any single character
[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 configuration object, only cardinality operators are availableexists,

does not exist, and the various count operators.
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.
Type in a configuration object property string, component property string, or a

constant or parameterized value or range of values. How you specify a value,
as well as what values are available, depends on your input in the LHS and
operator fields.
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.
Defining a conditional construct

Conditional constructs organize multiple conditions (basic conditions or even loops)
in an if-then-else logical sequence, creating complex expressions for evaluation.

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.
A conditional construct can be combined with basic conditions or nested within a

loop. A conditional construct can also be enclosed within another conditional construct.
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
else
end
To define a conditional construct
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:
a Select the if line.
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
c In the displayed fields, define the condition as discussed in one of the

following sections:

To define a loop on page 401
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.
You can choose from the following types of loops:
Function Typical example Expression returns TRUE if...
Foreach Loop foreach "File:/C/temp/*.log" all configuration objects in the specified

Name starts with "a" group fulfill the conditions defined in the
end
loop body
Exists Loop exists "File:/C/temp/*.log" where at least one configuration object from the
Name starts with "a" specified group fulfills the conditions
end
defined in the loop body
Count Loop count "File:/C/temp/*.log" = 5 where the number of configuration objects in the
Name starts with "a" specified group that fulfill the conditions
end
defined in the loop body complies with the
count condition in the count loop line
Loops can be combined with conditions or nested within conditional constructs.

A loop cannot be nested within another loop.

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:
The configuration object grouptypically an entity that can contain other

objects (such as a directory) or a configuration object string containing a wild card
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)
a constant value or values to which to compare, or, alternatively, a

parameterized, Integer-type configuration object property or component
property
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.
3 Define a condition in the loop body in the following manner:
a Select the loop line.
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.
If Then End for a conditional construct
c In the displayed fields, define the condition as discussed in one of the

following sections:
To define a conditional construct on page 399
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.
Operand data types and operator compatibility

The various operands that are available in conditions are based on a range of data
types. All parts of a conditionLHS operand, operator, and RHS operandmust be
based on the same data type.
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.
Operator Operand data type Expression returns TRUE if...
after Date the date property of the LHS operand is

chronologically after the date specified by
the RHS operand
before Date the date property of the LHS operand is
chronologically before the date specified
by the RHS operand
between the LHS operand value falls within the
Date range defined by two RHS operands
Decimal
Integer
contains the LHS operand contains the string

Long Text defined by the RHS operand
String
contains (case the LHS operand contains the case-

sensitive) Long Text sensitive string defined by the RHS
operand
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
operand equals the value defined by the
RHS operand
count greater than not relevant (cardinality condition) the number of occurrences of the
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
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
operand is one of the values defined by
the RHS operand
count less than not relevant (cardinality condition) the number of occurrences of the
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
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-
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
String
does not match mask FilePermission ACE the LHS operand does not match the mask
does not start with the LHS operand does not start with the
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
ends with the LHS operand ends with the string

String

ends with (case the LHS operand ends with the case-
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
greater than or equal the LHS operand value is greater than or

to Decimal equal to the value defined by the RHS
operand
Integer
has ACE matching the LHS operand has an ACE mask

mask FileAudit ACE matching the one defined by the RHS
operand
FilePermission ACE
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

has no ACE the LHS operand has no ACE mask

matching mask FileAudit ACE matching the one defined by the RHS
operand
FilePermission ACE
RegistryAudit 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
instance of String the LHS operand has an instance of the

string defined by the RHS operand
is not one of all data types the LHS operand is not one of the items
is not substring of the LHS operand is not a substring of the
String
is not substring of the LHS operand is not a case sensitive

(case sensitive) Long Text substring of the string defined by the RHS
operand
String
is one of all data types the LHS operand is one of the items
is substring of the LHS operand is a substring of the
String

is substring of (case the LHS operand is a case sensitive

sensitive) Long Text substring of the string defined by the RHS
operand
String
less than the LHS operand value is less than the

Decimal value defined by the RHS operand
Integer
less than or equal to the LHS operand value is less than or

Decimal equal to the value defined by the RHS
operand
Integer
matches the LHS operand matches the string

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
String
starts with(case the LHS operand starts with the case

operand
String
Testing a compliance rule

You can test whether a component satisfies a compliance rule in the Compliance
Rule Editor.

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.
To test a compliance rule
1 On the Compliance panel, select the rule you want to test and click Edit.
The Compliance Rule Editor opens.
2 On the Rule Definition tab in the Compliance Rule Editor, click Test the Rule .
The Test Compliance Rule window opens.
3 In the Component Selection area on the left, click Add Components .
The Add Components window opens.
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.
To remove a component or server, select it and click Remove Item .
6 Click Run Test to test the rule on all selected components.

Note
To stop the test run before it completes running, click Stop Test .
7 Expand server and component branches to view test results.
A green success or red failure icon appears beside each component.
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.
9 In the top pane, select a basic condition within the rule.
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 ().
top pane.
not reached.
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.
for a target component by doing the following:
permissions.

11 Click Close to close the Test Compliance Rule window.
Defining remediation options in the Rule Editor

The Remediation panel lets you specify the actions to take for a compliance rule.
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.
For an example demonstrating how to ensure application compliance using

compliance rule remediation and other component-related functionality, see Using
component templates to ensure compliance for multiple instances of an application
on page 472.
To define remediation options for a compliance rule
1 Under Specify Remediation Action on the Remediation tab, select one of the
following:
Do not remediate this rule (ignore failure)The failure is ignored and no

remediation is performed for this rule on this component.
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.
Deploy the following BLPackageA BLPackage that you specify is deployed

to the target server to correct the rule failure.
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.
b Check Allow Auto-remediation if the BLPackage you identified in the

previous step should be automatically deployed when this compliance rule is

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.
Commenting out and uncommenting a compliance rule

You can comment out or uncomment a compliance rule. Commenting out a
compliance rule temporarily removes it from a component template. Uncommenting
the compliance rule removes the comment and allows the compliance rule to be
included in the component template definition.
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.
To comment out or uncomment a compliance rule
2 Navigate to the compliance rule or rules you want to comment or uncomment.
3 Select one or more compliance rules. Right-click and select Comment Out or
Uncomment from the pop-up menu.
Copying, cutting, and pasting a compliance rule

You can copy and paste or cut and paste a compliance rule. These actions let you
copy or move a compliance rule within a component template or between
component templates. For compliance rules, you can often save time by copying and
pasting or cutting and pasting an existing rule.
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.
To copy, cut, or paste a compliance rule
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.
If you are pasting a rule in a different component template, open the

component template. Click the Compliance tab. 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.
Local properties for a component template

When editing a component template, you can assign properties directly to the
component template.
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.
Assigning local properties to a component template allows you to discover multiple

instances of the same component on the same server. To accomplish this you must
create sets of local properties defined to the values you need. For example, suppose
you wanted two instances of an Apache server component on the same machine.
Using multiple instances of local property sets, you can define different locations for
the components encapsulating the Apache server. When you run a Component
Discovery Job, it will examine the different sets of local properties and create a
component for each set.
The Local Properties tab lets you perform the following procedures:
Adding or modifying local properties on page 413

Adding or modifying instances of a local property set on page 413
Adding or modifying local properties

You can add a local property to a component template or modify an existing local
property.
Note
You cannot delete a local property if it is referenced by any component part,
signature condition, compliance rule, or other local property, and there are no
instances of a local property set where a value is defined for the local property you
want to delete.
To add or modify a local property in a component template
1 On the content editor, click the Local Properties tab.
2 Use the Definition tab to add a local property to the component template or
modify an existing local property.
Adding or modifying instances of a local property set

You can add a local property set to a component template or modify values of local
properties in an existing local property set.
To add or modify an instance of a local property set
1 On the content editor, click the Local Properties tab.
2 Click the Instances tab and do one of the following:
To create a new instance, click Add New Property Set Instance .
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.
.
property class. The Value Source column shows the property class from which
the value is inherited.
from an enumerated list, or selecting a date. To insert a parameter, click Select
Property .
6 Click OK.
Local Configuration Objects tab for a component template

The Local Configuration Objects tab lets you create and manage local configuration
objects associated with a component template.
A local configuration object is a configuration file or extended object that only

applies to the specific component template. When defining a local configuration
object, you can specify a path to that object using local properties as parameters.
Using properties in this way, you can create one definition of a configuration object
that applies to multiple components on the same server.
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.
For another example demonstrating how to ensure application compliance using

local configuration objects and other component-related functionality, see Using
component templates to ensure compliance for multiple instances of an application
on page 472.

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.
The procedures for creating or modifying a local configuration object or extended

object are almost identical to procedures available from the Configuration Object
Dictionary. See Identifying additional configuration files on page 574 and Creating
an extended object on page 577.
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.
Install/Uninstall tab for a component template

The Install/Uninstall tab lets you associate Batch Jobs with a component template.
After you make these associations, you can run the Batch Job to create a component
or application on a target device or to delete a component or application.
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

Creating Component Discovery Jobs
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.
Installer Batch Job
Identifies the Batch Job to use to install components or applications.
Uninstaller Batch Job
Identifies the Batch Job to use to uninstall components or applications.

A Component Discovery Job associates one or more components with a server.
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.
Discovering a component merely determines that a server satisfies the signature of a

component template. It does not ensure that all component template parts actually
exist on a server. Ideally, component signatures should be so discriminating that
successful discovery indicates the components template parts are indeed all present.
However, to ensure that the correct component parts are present on a server, you can
also set up compliance rules for a component template (see Compliance tab for a
component template on page 384) and then run a Compliance Job (see Creating
Compliance Jobs on page 439).
When you discover a component, by default the component is given a set of

permissions based on the maximum possible authorizations granted to your current
role. For example, if your current role is granted Component.* permissions, the new
component is granted Component.* permissions.
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.

Although the Component Discovery Job is designed to associate components with

servers based on a precise set of criteria, you can also use it as an inventory tool. First
you define a signature that indicates a software package is installed. For example,
the signature may require the presence of a particular DLL. Then you run the
Component Discovery Job against all servers of interest to you. The job creates
components on servers where it finds the DLL in the specified location. In this way,
you can quickly determine how many instances of a software package are installed.
To create a Component Discovery Job
1 To create a new Component Discovery Job, do one of the following:
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.
The New Component Discovery Job wizard opens.
2 Define the Component Discovery Job, as described in the following sections:
Component Discovery Job General on page 417
Component Discovery Job Component Templates on page 418
Component Discovery Job Targets on page 420
Component Discovery Job Default Notifications on page 420
Component Discovery Job Schedules on page 421
Component Discovery Job Properties on page 423
Component Discovery Job Permissions on page 424
Component Discovery Job General

The General panel lets you provide information that identifies a Component
Discovery Job.

Field Definitions
Name
Identifying name.
Description
Save in

Component Discovery Job Component Templates

The Component Templates panel lets you select the component templates that you
want to discover.
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.
Basing discovery on a shared set of custom property values

To create multiple instances of one or more component templates, you can discover
those component templates using a single custom property.
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).
The Evaluate All Instances of Selected Property section of the Component

Templates panel lets you use this approach for discovering components.
To set up a custom property class as the basis for component discovery
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.
5 In the Evaluate All Instances of Select Property section of the Component

Templates panel, check the local property that refers to the custom property class
that you want to use to discover component templates on target servers. This is
the local property that you created in Step 2 on page 419.

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.
Component Discovery Job Targets

The Targets panel lets you select the servers and server groups on which component
discovery should occur.
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.
Component Discovery Job Default Notifications

that are generated when a job completes. If you set up notifications for a particular
scheduled job, those notifications are generated instead of default notifications.


Send email to
Send SNMP trap to

Component Discovery Job Schedules

Scheduling a job
information, see Component Discovery Job Scheduling on page 422.
a scheduled job runs. For more information, see Component Discovery Job
Scheduled Job Notifications on page 422.

Component Discovery Job Scheduled Job Notifications

completes.
Send email to
Send SNMP trap to

Component Discovery Job Scheduling


To schedule jobs
Mean Time.
Component Discovery Job Properties


inherited.
Property .

Component Discovery Job Permissions

this object.
you want to add.



Adding components to servers manually
Modifying Component Discovery Jobs

Use this procedure to modify an existing Component Discovery Job.
To modify an existing Component Discovery Job
To modify the definition of an existing Component Discovery Job, open the

Jobs folder and navigate to an existing job. Then 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:
Component Discovery Job General on page 417
Component Discovery Job Component Templates on page 418
Component Discovery Job Targets on page 420
Component Discovery Job Default Notifications on page 420
Component Discovery Job Schedules on page 421
These tabs correspond to panels in the New Component Discovery Job wizard.
Use them to modify the job definition.
any of the properties, permissions, or audit trail information that apply to this
job.

You can add a component to a single server without running a Component
Discovery Job.
This procedure is useful as a way to quickly add a single component, particularly if

the discovery operation is not activated for a component template.
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.
To manually create a component
1 In the Component Templates folder, right-click the component template that you
want to use to create the component. Then select New => Component.
The New Component wizard opens.
2 Define the new component on the wizard panels, as described in the following
sections:
Component General on page 426
Component Properties on page 427
Component Permissions on page 428
Component Compliance exceptions on page 429
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.
This panel contains the following fields and screen elements:
Name
An identifying name for the component.
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
(Optional) Descriptive text for the component.
Component Template
The component template that forms the basis of this component.

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.
Property Set Instance
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
The server where you want to create this component.
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

inherited.

Property .
Component Permissions
this object.
you want to add.



Component Compliance exceptions

The Compliance Exceptions panel lets you specify compliance rules that a
component does not have to satisfy.
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.
About compliance exceptions

Typically, you use compliance rules that provide enough latitude to validate most
components.
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:
/etc/passwd exists AND

/etc/passwd//* is one of ["Admin", "SupportLevel2"]
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.
Defining compliance exceptions for a component

You can specify exceptions to compliance rules in a single component. When you
define compliance rule exceptions, you group them. Each group can have a different
expiration date.
To define compliance exceptions for a component
1 On the Compliance Exceptions panel of a component, either click Add New

Exception or select a condition and click Edit Selected Exception .
Depending on which action you take, the Add Compliance Exception or the Edit
Compliance Exception window opens.
2 On the General tab, enter the following information:
Name
An identifying name for the compliance rule exception.
Description
(Optional) Descriptive text for the compliance rule exception.
Reference Number
An identifier needed to synchronize this exception with some external system.

Duration
Whether to limit how long the exception lasts.
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
Additional information about the compliance rule exception.
3 Click the Associated Compliance Rules tab.
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

Modifying components
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.
4 On the Edit Ignored Paths dialog box, click OK.
5 On the Select Compliance Rules dialog box, click OK.
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
1 Using the Component Templates, Components, or Servers folders, navigate to

the component that you want to modify. (In the Servers folder, first browse the
relevant server.) Right-click the component and select Properties (if accessed
through the Servers folder) or Exceptions (if accessed through the Component
Templates or Components folder).
The Edit Component window opens. It includes a series of tabs, which are
Component General on page 426
Component Properties on page 427
Component Permissions on page 428
Component Compliance exceptions on page 429

Validating a component
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.
2 Click OK to save your revisions to the component.
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.
To validate a component based on its signature
1 Through the Component Templates, Components, or Servers folder, navigate to

the component that you want to validate, right-click it, and select Validate.
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.
3 In the top pane, select a condition within the signature.
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.

Setting multiple components as exceptions to compliance rules
Note
In the top pane, condition operands that are very long are truncated and end with
an ellipsis ().
top pane.
not reached.
Setting multiple components as exceptions to

compliance rules
Use this procedure to excuse multiple components from compliance rules for a
component template.
For more information about compliance exceptions and when you would want to
define them, see About compliance exceptions on page 429.
To set multiple components as compliance exceptions
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:
Right-click, and select Set Exception from the pop-up menu.
Select multiple components in the content editor, right-click, and select

Exceptions from the pop-up menu.
In the Component Templates folder, navigate to a component template that

has multiple components associated with it. Select Window => Show
View => Group Explorer. In the Group Explorer view, select multiple
components. Right-click and select Exceptions from the pop-up menu.

In the Components folder, navigate to a group that has multiple components

associated with it. Select Window => Show View => Group Explorer. In the
Child Explorer view, select multiple components. Right-click and select
Exceptions from the pop-up menu.
2 Define exceptions for the component, as described in the following sections:
Set Component Exceptions General on page 435
Set Component Exceptions Associated Compliance Rules on page 436
Set Component Exceptions Components on page 437
The components that you specified are excused from the selected compliance rules.
Set Component Exceptions General

The General panel lets you provide identifying information for a component
exception. It also lets you specify a duration for the exception.
Name
Description
Reference Number
An identifier used to synchronize this exception with some external system.
Duration
Indicates whether to limit how long the exception lasts.
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

Set Component Exceptions Associated Compliance Rules

The Associated Compliance Rules panel lets you define compliance rule exceptions.
Define compliance rule exceptions by clicking Add Compliance Rule , which

opens the Select Compliance Rules dialog box.
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.
4 On the Edit Ignored Paths dialog box, click OK.
5 On the Select Compliance Rules dialog box, click OK.
Name
Description
Reference Number
An identifier needed to synchronize this exception with some external system.

Adding components to a component group
Duration
Indicates whether to limit how long the exception lasts.
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
Set Component Exceptions Components

The Components panel lets you choose the components to excuse from compliance
rules.
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.
Adding components to a component group

You can group components together in groups or smart groups, regardless of
whether the components have been discovered or manually created. Use the
following procedure to add components to an existing component group.
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.
To add components to a component group
1 Open the Components folder and navigate to a component group.
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.
The Available Components list shows all components, organized by component

template. To move a component between lists, select the part and click the left or

Installing or uninstalling a component
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.
The selected components are assigned to the component group.
Installing or uninstalling a component

You can install or uninstall a component by running a Batch Job that is associated
with the component template.
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.
Before you begin
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.
To install or uninstall a component
1 In the Component Templates folder, navigate to a component template.
2 Right-click the component template and select Install or Uninstall.

Creating Compliance Jobs
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.

When you define a component template, if you have enabled Compliance
operations, you can set up compliance rules. A compliance rule is a group of part
and property conditions that must be satisfied by a subset of the components parts.
The parts in that subset are known as compliance parts. To determine whether a
component satisfies its compliance rules, you run a Compliance Job.
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)
To create a Compliance Job
1 To create a new Compliance Job, do one of the following:
Compliance Job.
In the Components, Component Templates, or Servers folder, navigate to a

component (in the Servers folder, first browse the relevant server), right-click,
and select Compliance.
In the Component Templates folder, navigate to a component template, right-

click, and select Compliance.

The New Compliance Job wizard opens.
2 Define the Compliance Job on the wizard panels, as described in the following
sections:
Compliance Job General on page 440
Compliance Job Component templates for filtering on page 441
Compliance Job Components on page 441
Compliance Job Autoremediation on page 442
Compliance Job Default Notifications on page 452
Compliance Job Schedules on page 454
Compliance Job Properties on page 456
Compliance Job Permissions on page 457
Compliance Job General

The General panel lets you provide information that identifies a Compliance Job and
provides some options for how the job should execute.
Field Definitions
Name
Identifying name.
Description
Save in


Continue despite compliance data collection errors
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.
Compliance Job Component templates for filtering

The Component Templates for Filtering panel lets you identify component templates
that form the basis of a Compliance Job. Any components based on the selected
templates can be included in the Compliance Job.
To select or remove component templates, you move templates between the

Available Templates list and the Selected Templates list using the arrows. If you
opened the Compliance Job wizard by right-clicking a component template, that
component template already appears in the Selected Templates list.
Compliance Job Components

The Components panel lets you choose the components that must satisfy compliance
rules established for the component template. Each component is compared to the
compliance rules defined for its component template.
You can select or remove components, component groups, or smart component

groups on which the Compliance Job should run. You can also select one or more

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.
Compliance Job Autoremediation

The Autoremediation panel lets you enable automatic remediation of any
compliance rule failures that a Compliance Job discovers.
Some typical uses for autoremediation are:
Fixing noncompliance Each compliance rule definition can specify a BLPackage

to deploy if a component fails the rule and remediation is required. When you
enable autoremediation, BMC Server Automation automatically collects and
deploys the BLPackages needed to correct compliance rule failures. You can select
the component templates to automatically remediate.
Initial server provisioning After installing an operating system on a new server,

you can install mandatory software by running a Compliance Job. The job
compares the new machine to an ideal master. The Compliance Job then
automatically deploys the software packages needed to make the new machine
match the master.
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:

Remediate after compliance analysis completes
Enables automatic remediation of compliance rule failures.
Remediation name
A name for the remediation job.
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.
Save remediation/deploy job in
The job group where you want to store any Deploy Jobs (and potentially a
Batch Job) that this procedure generates.
Template
A list of component templates for which autoremediation is enabled at the

template level (on the General tab of each individual component template).
From this list, you can select the component templates to automatically
remediate.
Keep each local property name unique in remediation package
Indicates whether the remediation package can include duplicate property

names for individual compliance rules that fail.
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.
Use servers as remediation target
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.

About remediation packages and remediation jobs

When you remediate a Compliance Job failure, BMC Server Automation creates a
remediation package containing the BLPackages required to remediate each failed
compliance rule.
When checking compliance for multiple components, BMC Server Automation

creates a separate remediation package for each distinct set of compliance rules that
a component fails. If multiple components fail the same set of compliance rules,
BMC Server Automation optimizes by creating only one remediation package to
correct all of those failures.
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.
After creating remediation packages, BMC Server Automation automatically creates

a Deploy Job to deploy each remediation package. A single Deploy Job may act upon
a single target component or it may act upon multiple components if more than one
component fails the same set of compliance rules. If this procedure creates multiple
Deploy Jobs, the system combines those Deploy Jobs into a Batch Job so the entire
remediation can be launched as one job.
Remediating a Compliance Job is different from synchronizing Audit Job results. An

audit is always based on a master server or a snapshot of a server. Using equality
and limited parameterization, it compares one server configuration to another. After
running an Audit Job, you can build a BLPackage from the audit results. A
Compliance Job, on the other hand, is based on rules. It uses comparison operations
and parameterization. The complicated logic that is possible when defining
compliance rules (for example, strings or clauses and ranges of acceptable values)
makes it impossible to automatically generate a BLPackage that can synchronize a
server to a component template. For this reason, if you want to remediate a
compliance rule failure, you must manually define a BLPackage that can repair
failures. The BLPackage must be defined and associated with a compliance rule
before you attempt remediation.
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.
Setting deploy options for remediation jobs

You can set up options for Deploy Jobs that are automatically created when you
automatically or manually remediate Compliance Job results.
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.
To set deploy options for remediation jobs
1 Using the Property Dictionary, create an instance of the DeployOptions built-in

property class.
2 When defining the DeployOptions instance, define values according to your

needs for all properties with an entry of DeployOptions in the Value Source
column. These values control the settings for a group of automatically generated
Deploy Jobs. For more information about these properties, see DeployOptions
properties for controlling Deploy Job behavior on page 446.
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.
When you use a Compliance Job to automatically remediate compliance failures

(see Compliance Job Autoremediation on page 442) or you use Compliance Job
results to manually remediate non-compliant components (see Manually
remediating compliance results on page 467), the Deploy Jobs that are
automatically created use the settings specified in the DeployOptions instance. If
you do not specify an instance for the

DEPLOY_OPTIONS_INSTANCE_FOR_REMEDIATION property, Deploy Jobs

are created using default values for all properties.
DeployOptions properties for controlling Deploy Job

behavior
The following table describes the DeployOptions properties that control the behavior
of automatically generated Deploy Jobs.
For more about setting these options, see Setting deploy options for remediation jobs
on page 445.
Property Name Type of Data Description
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.
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:
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. This
option is set to Basic by default.
AdvancedProvides full flexibility when defining the job. For

advanced BLPackage Deploy Jobs, you can choose to control
the flow of the job by server or by phase and schedule
execution of each job phase. If the job fails to complete, you
can re-execute it on a server-by-server and phase-by-phase
basis rather than have the job automatically reset.
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:
ByPhaseThe job completes a phase on all servers before it

proceeds to the next phase. This option is useful when you
want a deployment to be completely successful, such as when
you are updating a web application. This option is set to
ByPhase by default.
ByServerThe job proceeds as far as it can for each server.

When one server fails, the job continues on other servers.
When all servers have completed a phase (either by
succeeding or failing), the job continues to the next phase for
all servers that successfully completed the previous phase.
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.
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:
Use item defined reconfigure settingInstructs 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
IS_RECONFIGURE_REBOOT.
Ignore item defined reconfigure settingInstructs 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
IS_RECONFIGURE_REBOOT. 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.
LOGGING_LEVEL Enumerated Specify the amount of logging information that the Deploy Job
generates by choosing one of the following:
Errors onlyOnly errors are displayed and output to a log.
Errors and warningsErrors and warnings are displayed and

output to a log.
All informationAll messages, including errors and

warnings, are displayed and output to a log.
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.

REBOOT_OPTIONS Enumerated Specify reboot behavior by choosing one of the following:
Use item defined reboot settingCauses a target to reboot

after an object in the BLPackage is processed if the instructions
for that object call for a reboot. If the reboot setting for an
object is By end of job, and a reboot is not scheduled for this
job, then a reboot occurs at the end of the job.
Ignore item defined reboot settingPrevents a server from

rebooting no matter how a package is defined unless the object
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).
Use item defined reboot settings and reboot at end of job

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.
Ignore item defined reboot settings and reboot at end of job

Prevents a server from rebooting during a job no matter how a
package is defined unless the object being deployed includes
an out-of-band reboot (that is, a reboot is built into the object
and is not part of the BLPackage instructions). At the end of
the job, the server reboots.
Consolidate reboots until end of jobPrevents 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.

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,
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:
Use item defined user mode settingWhen processing each

object being deployed, this Deploy Job will use the user mode
setting (single- or multi-user) defined for that object.
Ignore item defined user mode settingPrevents a server

from entering single-user mode no matter how individual
objects in the package are defined.
Use single-user mode without rebootThis 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.
Reboot into single-user modeThis 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.
Compliance Job Default Notifications

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


Send email to
Send SNMP trap to

Compliance Results Notifications

Send email to
Lists email addresses of the accounts to notify about compliance results.

Separate email addresses with spaces. Notification can occur when results are
consistent, inconsistent, or both.
Append compliance results to email
Indicates emailed notifications should include compliance results.
Limit email body size
Limits the size of email that is generated by appending compliance results.

Enter the maximum size, in kilobytes, in the text box.
Send SNMP trap to
Provides name or IP address of the server to notify about compliance results.

After entering server information, check the results that should cause an
SNMP trap to be generated. For example, if you select Inconsistent and a
Compliance Job indicates that two components are inconsistent, an SNMP
trap is sent.

Compliance Job Schedules

Scheduling a job
information, see Compliance Job Scheduling on page 455.
a scheduled job runs. For more information, see Compliance Job
Compliance Job Scheduled Job Notifications

completes. It also lets you send notifications that indicate whether the target
components have compliant configurations, non-compliant configurations, or both.
Send email to
Send SNMP trap to


Compliance Results Notifications
Send email to
Lists email addresses of the accounts to notify about compliance results.

Separate email addresses with spaces. Notification can occur when results are
consistent, inconsistent, or both.
Append compliance results to email
Indicates emailed notifications should include compliance results.
Limits the size of email that is generated by appending compliance results.

Enter the maximum size, in kilobytes, in the text box.
Send SNMP trap to
Provides name or IP address of the server to notify about compliance results.

After entering server information, check the results that should cause an
SNMP trap to be generated. For example, if you select Inconsistent and a
Compliance Job indicates that two components are inconsistent, an SNMP
trap is sent.
Compliance Job Scheduling

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

To schedule jobs
Mean Time.
Compliance Job Properties

In this list, you can modify the value of properties that are defined as editable.

inherited.
Property .

Compliance Job Permissions

this object.
you want to add.



Compliance results
Modifying Compliance Jobs

You can modify an existing Compliance Job.
To modify a Compliance Job
To modify the definition of an existing Compliance Job, open the Jobs folder
Compliance Job General on page 440
Compliance Job Component templates for filtering on page 441
Compliance Job Components on page 441
Compliance Job Autoremediation on page 442
Compliance Job Default Notifications on page 452
Compliance Job Schedules on page 454
These tabs correspond to panels in the New Compliance Job wizard. Use them
to modify the job definition.
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:
Remediation ViewShows the result of the remediation job launched

automatically by this Compliance Job run.
Rules ViewOrganizes information according to the compliance rules defined for

each component template.

Compliance results
Server ViewOrganizes information according to the components found on each

server.
Selecting nodes below the Rules View or Server View nodes displays additional
details about a portion of the hierarchical tree.
The possible compliance statuses of compliance rules are described in Compliance

statuses of compliance rules on page 460.
To view Compliance Job results, any of the following procedures are possible:
Viewing compliance results by rule on page 461
Viewing compliance results by server on page 461
Viewing the results of a compliance rule on page 462
Viewing and using autoremediation results on page 466
To use Compliance Job results, any of the following procedures are possible:
Viewing and using autoremediation results on page 466
Undoing autoremediation on page 466
Defining exceptions for components on page 464
Manually remediating compliance results on page 467
Creating a remediation package on page 469
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).

Compliance results
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.
Compliance statuses of compliance rules

BMC Server Automation evaluates each compliance rule and classifies it as one of
the following:
CompliantThe component satisfies the rule.
Compliant with exceptionsThe component satisfies the rule because one or

more exceptions have been granted to the component.
Non-compliantThe component does not satisfy the rule.
FailureThis rule cannot be evaluated for this component.
IndeterminateConditions on the component cannot be classified as compliant or

non-compliant. This includes the situation when
an asset being tested in a rule is undefined on the target 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.
Non-compliant if the symbolic links starts with a character other than A.
Indeterminate if the symbolic link does not exist.

Compliance results
Viewing compliance results by rule

Use this procedure to see which components satisfy the compliance rules for the
component template.
To view compliance results by rule
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.
4 To determine which components satisfy a compliance rule, select a rule.
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.
Viewing compliance results by server

You can determine if components on servers satisfy compliance rules.
To view compliance results by server

Compliance results
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.
4 To determine whether the component satisfies various compliance rules, select a

rule group.
The Compliance column in the right pane shows the compliance status for each
rule within the rule group.
Viewing the results of a compliance rule

You can view how a particular component satisfies a compliance rule for a
component template.
To view the results of a compliance rule
Compliance Job, and do one of the following:

Compliance results
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.
3 In the top pane, select a basic condition within the rule.
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.
top pane.
not reached.
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:

Compliance results
a Click View Exceptions. The View Associated Exceptions dialog box opens.
b To view more information about an exception, select the exception in the

Compliance Exceptions list and click View Selected Exception . The View
Compliance Exception 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.
d Click Close to close the View Compliance Exception dialog box.
e Click Close to close the View Associated Exceptions dialog box.
For information about defining compliance rule exceptions, see Defining

exceptions for components on page 464.
for a target component by doing the following:
permissions.
Defining exceptions for components

In some situations, it is useful to define one or more components as exceptions to
certain compliance rules.
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.
To flag a single component as an exception to compliance rules

Compliance results
Compliance Job, and navigate to any single component listed under the Server
View or Rules View node.
3 Right-click the component and select Exceptions.
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.
To flag multiple components as exceptions to compliance rules
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.
The Set Component Exceptions wizard appears.
3 Use the Set Component Exceptions wizard to define compliance exceptions. For
more information about this procedure, see Component Compliance exceptions
on page 429.

Compliance results
Viewing and using autoremediation results

You can view autoremediation results. BMC Server Automation shows these results
on two tabs: Deploy Status and Log Messages.
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.
To view and use autoremediation 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.
3 Use the Deploy Status tab to do any of the following:
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
To show log messages generated when a job executes a particular phase on a

server, select the cell representing that server and phase. The Log Messages
pane at the bottom of the window shows messages generated during that phase
on the selected server.
Undoing autoremediation
You can undo packages that are committed to target servers as part of a Deploy Job
that automatically remediated Compliance Job results.

Compliance 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.
Manually remediating compliance results

You can manually remediate the configuration of components that have failed a
Compliance Job.
A compliance rule definition can specify a BLPackage that should be deployed if a

component fails the rule and remediation is required. This procedure uses
Compliance Job results to deploy BLPackages that correct compliance rule failures
for target components. Rather than perform this procedure, you may want to define
a Compliance Job so it automatically remediates failed components (see Creating
Compliance Jobs on page 439).
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.

Compliance results
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.
To manually remediate compliance results
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.

Compliance results
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.
If you are remediating a single component or BMC Server Automation has

created one remediation package that applies to multiple components, a
Deploy Job appears.
Creating a remediation package

You can create a remediation package for a component that has failed a Compliance
Job. This procedure creates a BLPackage that consolidates all remediation actions
specified in the compliance rules that the target component has failed.
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).
To create a remediation package

Packaging and deploying a component
Compliance Job, and do any of the following:
Under the Rules View node, select any component.
Under the Server View node, select any component or select one or more rule
groups or rules.
3 Right-click and select Create Remediation Package to open the Create

Remediation Package window.
Note
The Create Remediation Package 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 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.
BMC Server Automation creates a remediation package for the targeted

component and stores it in the Depot.
Packaging and deploying a component

You can package a component as a BLPackage and then run a Deploy Job to deploy
the package. This procedure is used to automate the packaging of software models
as part of BMC Application Automation.
To package and deploy a component
1 Using the Components, Component Templates, or Servers folder, navigate to a

component (in the Servers folder, first browse the relevant server), right-click it,
and select Package and Deploy.
The Create BLPackage wizard opens.
2 Use the Create BLPackage wizard to define the packaged component, as

described in Adding a BLPackage to the Depot on page 509.

Exporting compliance results
3 Click Finish to complete the BLPackage.
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.
Exporting compliance results

You can export the results of a Compliance Job, in either HTML or CSV format.
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.
To export compliance results
1 Access the results of a Compliance Job.
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.
3 Right-click and select Export Compliance Results.
The Export Results dialog box is displayed.
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:
Print-friendly version (HTML format)Saves results in an HTML format so

they can be printed or viewed in a web browser. Use this option for easy
viewing of exported results.
Analysis version (CSV format)Save results in a comma-separated value

format so they can be imported into databases or spreadsheets. If you import
the resulting CSV file into a spreadsheet, you must adjust column widths and
set line wrapping to make the spreadsheet easily readable.
5 From File encoding, select the type of character encoding for the exported data,
such as UTF8 or UTF16.
6 On the Export Results dialog box, click Save.

Using component templates to ensure compliance for multiple instances of an application
Using component templates to ensure

compliance for multiple instances of an
application
A BMC Server Automation system offers many tools for ensuring compliance with
organizational standards for application configurations.
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:
The following procedure is a generalized description. Each step describes a BMC

Server Automation procedure you can perform. Most steps include a reference to
more detailed information about that procedure.
To ensure compliance for multiple instances of an application
1 Create a component template that encapsulates Oracle compliance and focuses on

port configurations. Call the template Oracle Security. After using the
component template to create an empty template, edit the template by doing the
following:
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 Add the listener.ora configuration file to the component template as a part.

Use the following path to identify the component template part:
/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.
f Save the component template.
2 Using the Oracle Security component template, run a Component Discovery

Job on the server where the two instances of Oracle are installed. Using the
criteria in the component template, the job should discover two components that
match the signature.
For more information about Component Discovery Jobs, see Creating Component
Discovery Jobs on page 416.
3 Create a BLPackage called Oracle_port that contains a version of the listener.ora

configuration file that has the correct portthat is, some port other than 1521. To
accomplish this, do the following:
a Identify a version of the listener.ora configuration file that contains the

appropriate listening port. This port can be anything other than port 1521.
b Add this version of the listener.ora configuration file to the Depot as a

BLPackage.
c Open the BLPackage for editing.
d Create a local property for the BLPackage called ORACLE_PATH.
e Save the BLPackage

For more information about creating BLPackages, see Adding a BLPackage to

the Depot on page 509.
4 Open the Oracle Security component template and create a compliance rule
called Allowed Oracle Ports by doing the following:
a Provide a definition for the compliance rule that says:
A Configuration Entry using the /d/??ORACLE_PATH??/product/10.1.0/

network/ADMIN/listener.ora//**/DESCRIPTION/ADDRESS/PORT path
must exist, and Value1 (the first entry in the configuration file) cannot equal 1521.
For more information about creating compliance rules, see Compliance tab for
a component template on page 384.
b For remediation, select the Oracle_port BLPackage, created in Step 3 on page

473.
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.
d Save the 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.


10
Creating packages and other
depot objects
This section describes how to add objects to the Depot folder, including software
packages, BLPackages, Network Shell scripts, and files. The Depot folder is often
referred to as "the Depot."
Depot object overview

BMC Server Automation lets you create packages and other types of objects that you
can store in the Depot. After you create these objects, you can use jobs to deploy the
objects on multiple servers.
You can create the following types of objects and store them in the Depot:
SoftwareWindows or UNIX executables. For information about creating

software packages, see:
Software package overview on page 478
Adding software to the Depot on page 482
Adding a hotfix to the Depot on page 496
BLPackagesAggregations of many types of server objects. Use BLPackages to

deploy complex server configurations. For information about creating or
modifying BLPackages, see:
BLPackage overview on page 480
Adding a BLPackage to the Depot on page 509
BLPackage Editing on page 517
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.

Software package overview
FilesFiles that can be stored as depot objects and then added to BLPackages. See
Adding files to the Depot on page 556.
Virtual Guest PackagesDefinitions for a virtual guest configuration. Virtual

Guest Packages can be used to deploy a new VMware virtual machine on a
VMware vCenter server. See Deploying virtual systems using a Virtual Guest
Package on page 868.
Patch catalogsTools for managing patch collections. See Creating a patch

catalog on page 1076.
System packagesCollections of all the instructions necessary to provision a

server with an operating system and perform additional configuration by running
a job. See Creating a system package on page 1214.
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.

When you package software, you identify a source file and provide the necessary
commands to install and uninstall that software unattended on remote hosts. If an
install or uninstall command references additional files, those files are also included
in the software package.
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.
Operating System Supported Software Types

Microsoft Windows
Operating system service packs
MSI packages
InstallShield packages

Operating System Supported Software Types

Oracle Solaris
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
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.
Methods for creating BLPackages

You can create a BLPackage in the following ways:
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.
Bundling files and other server objects contained in a component.
Bundling the results of an audit to synchronize a target server with a master

configuration.
For a description of how to create BLPackages, see Adding a BLPackage to the

Depot on page 509.
When you create a BLPackage, you store it in the Depot.
Contents of BLPackages
BLPackages can consist of either Windows or UNIX server objects. A BLPackage
cannot mix Windows and UNIX server objects.
For Windows, a BLPackage can include the following:
Applications
BLPackages (an object used for tracking BLPackages)
COM+/MTS settings
Configuration files
Event logs
Hotfixes

BLPackage overview
Local groups
Local users
Metabase objects
Registry values
Security settings (local)
Services
External commands (that is, commands that can be issued on a command line
interface)
Virtual machine configurations
For UNIX systems, a BLPackage can include the following:
IBM AIX packages and patches
BLPackages (an object used for tracking BLPackages)
Configuration files
RPMs
Daemons
Processes
UNIX users
UNIX groups
Virtual host server and virtual machine configurations
Oracle Solaris packages, patches, and patch clusters
HP-UX product, patches, and bundles
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

Adding software to the Depot
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.

You can add a software package to the Depot, which you can then deploy to servers.
A software package consists of all the files necessary to perform an unattended
installation of a software executable.
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

definition of a software package on page 505) or the contents of the software

package (see Modifying the contents of a software package on page 505).
To add software to the Depot
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.
2 Provide information for the wizard, as described in the following sections:
Add Depot Software Add Software on page 484
Add Depot Software Properties on page 494
Add Depot Software Permissions on page 495
A background process saves the software package 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.

Add Depot Software Add Software

The Add Software panel lets you choose the software items you want to package.
You can specify multiple software items, if necessary.
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 Select Installable Sources dialog box is displayed, proceed to Step 2 on

page 485.
The Select Installable Source dialog box appears if you did not select source
files to begin this procedure (as described in Adding software to the Depot
on page 482).
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.
2 Using the Select Installable Sources dialog box, do the following:
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.
b Do one of the following:

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:
Copy to Agent at stagingThe Application Server copies the source files to

a staging directory on the agent during the staging phase of a Deploy Job.
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 of RSCD, NFS, or
SMB. For details about the required syntax, see URL syntax for network data
transmission on page 492.

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.
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.
e Click OK to close the Select Installable Sources dialog box.
The files you have selected display in the left pane of the Add Depot Software
window.
3 To identify a depot folder where software packages 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 software
packages. Then click OK.
4 If you are adding custom software to the Depot, do the following:
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.
BMC Server Automation provides prepackaged support for many types of

common software. If you are packaging software that does not appear in this
list, select Custom Software and the window appears a generic install and
uninstall command.
5 In the left pane, select a software item for which you want to provide information
and do the following:
a Check Do NOT copy source to undo directory during deployment if you do

not want to copy source files to a directory where they can be used for rolling
back this deployment.
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.
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 in which software is stored in the package being deployed. The
following table describes parameters in default install and uninstall
commands. If a command includes a parameter not shown in the following
table, the parameter must reference a server property and associated target
servers must have a value defined for the property. If a software package is
encapsulated in a BLPackage, parameters can reference local properties for the
BLPackage.
Parameter in command Description of use Applies to:
??DEPLOYPATH?? Path to a subdirectory in a staging Typically used with support

directory on a target server. The files but can be used with any
subdirectory is named for the package type of file required for
being deployed. The subdirectory deployments or rollbacks.
contains files used for deployments
and rollbacks.
??INSTALL_RESPONSEFILE?? Response file used by the installable. InstallShield packages

Solaris packages
??INSTALL_ADMINFILE?? Admin file used by the installable. Solaris packages
??PACKAGEFILE?? Deploy path followed by the name of HP-UX products

the installable. HP-UX patches
??PACKAGENAME?? Name of the installable. RPMs
??PATCHID?? Identifier used in the uninstall Solaris patches

command.

Parameter in command Description of use Applies to:
??SOURCE?? Directory holding the software in the OS service packs

package to be deployed. InstallShield packages
If the source is a zip file, the file name MSI packages
extension is not used when resolving
Solaris patches
this parameter. For example,
install_dir.zip resolves to install_dir. Solaris patch clusters
RPMs
IBM AIX patches
IBM AIX packages
Custom software
??SOURCEORPARENTDIR?? Source file to be deployed if the Solaris packages

installable is a file; otherwise, the
parent directory if the installable is a
directory.
??SUBPACKAGES?? Subpackages you want to install or Solaris packages

uninstall. AIX packages
HP-UX products
HP-UX bundles
??SUBPATCHES?? Subpatches you want to install or AIX patches

uninstall. HP-UX patches
HP-UX bundles
??UNINSTALL_ADMINFILE?? Admin file used to uninstall the Solaris packages

installable.
??UNINSTALL_RESPONSEFILE?? Response file used to uninstall the InstallShield packages

installable.
??WINDIR?? Environment variable representing the OS service packs

Windows directory, such as /c/winnt.
An install command can reference a support file by including the string ??

_supportFile??, where supportFile can be any name. For example, you can
reference a response file by entering a string such as ??_RESPONSEFILE??.
References created this way appear in the Support Files table at the bottom of
the window. To remove a file from the Support Files table, delete the string
referencing the file in the install command.
Square brackets within an install command enclose optional information, such

as [-a "??_INSTALL_ADMINFILE??"].
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.
f For Uninstall command, enter the command, including arguments, that

invokes the uninstall. This field automatically displays the default uninstall
command for the type of software you plan to package. To apply the command
to all installables listed in the left pane, click Apply to All.
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.

URL syntax for network data transmission

To identify a source file that can be deployed from a remote location to another
remote location without making a local copy, you must create a URL using a special
syntax that incorporates a protocol and a network location.
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.
The following list explains all components in a URL:
Protocolspecifies how to put or get files and directories to or from the

specified Host. For the local host, the default approach is to use direct access to
the file system. For remote hosts, the following protocols are supported:
rscdUse the Network Shell protocol. This is the default approach.
fileUse the local file system.
nfsUse UNIX file sharing.
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 software package, you cannot instruct a Deploy Job to

mount an SMB server using more than one set of connection information.
This could occur, for example, when you use one set of connection
information to access source files and another set of connection
information to access support files. In situations like this a Windows
limitation causes the job to fail. This limitation only applies when you
select Agent mounts source for direct use at deployment when
specifying a source file location; this limitation does not apply if you
select Copy to Agent at staging.
When defining a URL for Windows patch payloads, you can only use the
smb protocol.

DomainThe Windows domain that provides user accounts. A domain is only

necessary for the SMB protocol. When providing Windows user information, if
you do not provide a domain, the user is presumed to be a user local to the host.
UserThe identity that should be used to access a device. A user is only

necessary for the SMB protocol. The default value for User is the identity of the
user who invoked the Deploy Job.
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.
ShareNameThe name under which a directory is exported via Windows file

sharing. This optional component should only be specified for the SMB protocol.
Internally, BMC Server Automation converts the directory specified with
ShareName into a UNC location and associates connection information (Domain,
User, and Password) that can be used to access the UNC location.
Note that for NFS, BMC Server Automation consults the NFS server to determine
which initial sub-string in the path is exported. BMC Server Automation combines
this sub-string with the absolute path defined using the Path component.
PathThe path to a file or directory. Use forward slashes / as path delimiters.
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

# Use an NFS mount of hp11dev export
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.
Add Depot Software Properties


inherited.
Property .
Properties and dependencies when packaging

The property called DEPENDENCY_LIST lets you specify dependencies a software
package may have on other software packages. This property lets you select as a
value one or more other software packages in the Depot. For example, if you are
deploying a package called Patch_A, and it depends on another package called
Patch_B, you can use the DEPENDENCY_LIST property to specify Patch_B as a
dependency. A BLPackage containing these software packages orders them
automatically according to their dependencies. (In other words, Patch_B is
positioned before Patch_A in the BLPackage.) You can also manually instruct a
BLPackage to order its contents according to dependencies. Note that if the Depot
includes multiple software packages named identically, a dependency is based on
the particular software package you specify using the DEPENDENCY_LIST 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.
Add Depot Software Permissions

this object.
you want to add.


Adding a hotfix to the Depot


Adding a hotfix to the Depot adds all files necessary to perform an unattended
installation of that hotfix.
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.
The Add Depot Software wizard opens.
Add Depot Software (Hotfix) Add Software on page 497
Add Depot Software (Hotfix) Properties on page 503
Add Depot Software (Hotfix) Permissions on page 504
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.
Add Depot Software (Hotfix) Add Software

The Add Software panel lets you choose the patches or service packs you want to
package as hotfixes. You can specify multiple patches and service packs, if necessary.
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 .
2 Using the Select Installable Sources dialog box, do the following:
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.
b Do one of the following:
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:
Copy to Agent at stagingThe Application Server copies the source files to

a staging directory on the agent during the staging phase of a Deploy Job.
data transmission, including a data transmission protocol of RSCD, NFS, or
SMB. For details about the required syntax, see URL syntax for network data
transmission on page 492.
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.
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.
e Click OK to close the Select Installable Sources dialog box.
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.
b Check Do NOT copy source to undo directory during deployment if you do

not want to copy source files to a directory where they can be used for rolling
back this deployment.
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:
For Bulletin, enter the bulletin number of the patch.
For Patch Name, enter a patch name.

When the system automatically completes the Patch Name field, it provides
a unique name. If you are adding a patch and you have manually specified
the source file for the patch, you must ensure that you enter a value for Patch
Name if you are also using an uninstall command that includes the
parameter ??HOTFIXNAME??. See Step 4.f on page 502 for more
information about install and uninstall commands.
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.
Option Description of Use
??HOTFIXNAME?? The name assigned to the patch or service pack.
??SOURCE?? The directory where the patch or service pack is stored.

If the source is a zip file, the file name extension is not used when
resolving this parameter. For example, install_dir.zip resolves to
install_dir.
??WINDIR?? The environment variable representing the Windows directory, such

as /c/winnt.
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.

Add Depot Software (Hotfix) Properties


inherited.
Property .
Properties and dependencies when packaging

The property called DEPENDENCY_LIST lets you specify dependencies a software
package may have on other software packages. This property lets you select as a
value one or more other software packages in the Depot. For example, if you are
deploying a package called Patch_A, and it depends on another package called
Patch_B, you can use the DEPENDENCY_LIST property to specify Patch_B as a
dependency. A BLPackage containing these software packages orders them
automatically according to their dependencies. (In other words, Patch_B is
positioned before Patch_A in the BLPackage.) You can also manually instruct a
BLPackage to order its contents according to dependencies. Note that if the Depot
includes multiple software packages named identically, a dependency is based on
the particular software package you specify using the DEPENDENCY_LIST 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.

Add Depot Software (Hotfix) Permissions

this object.
you want to add.



Modifying the definition of a software package
Modifying the definition of a software package

The procedure for modifying the definition of a software package or hotfix has
minor differences from the procedure for defining a new software package or hotfix.
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.
To modify the definition of a software package
1 Take any of the following actions:
To modify the definition of an existing software package or hotfix, open the

Depot folder and navigate to an existing software package or hotfix. Right-click
the object and select Open from the pop-up menu. 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. For more information
about these options, see any of the following:
Add Depot Software Add Software on page 484 (for software packages)
Add Depot Software (Hotfix) Add Software on page 497 (for hotfixes)

apply to this software package or hotfix, select the Properties, Permissions, or
Audit Trail tab group.
Modifying the contents of a software package

To modify the contents of a software package, you must copy the contents of an
existing package from the Depot to another location, where you can edit them. Then
you can copy the revised contents back into the software package.
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.
You cannot use this procedure to modify the contents of a hotfix.

Modifying the contents of a software package
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.
To modify the contents of a software package
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.
2 On the Software Properties Panel, next to Installable source, click Copy To .

The Select Copy Location dialog box opens. Use this dialog box to specify a
location to which the contents of the software package should be copied.
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.
4 On the Software Properties Panel, next to Installable source, click Browse to

open the Select Installable Sources dialog box. Using that dialog box, you can
identify the modified software package.
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 .
The Set File Parameters dialog box appears.
b Next to File location, click Copy To.

Matching software with depot items
The Select Copy Location dialog box opens.
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 Select Matching Software window lets you match depot items with software that
you are trying to deploy, uninstall, or package into BLPackages.
The following situations require you to match depot items with software:
Adding software to a BLPackage
Deploying or uninstalling software listed under the Live node of a server
Deploying software included in snapshot results
Deploying software when using audit results to synchronize servers
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.
To match software with depot items
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:

Adding a BLPackage to the Depot
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 bundles configuration changes so they can be deployed to remote hosts.
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.

To add a BLPackage to the Depot
Using the Depot folder, right-click the depot folder where you want to add the
BLPackage. From the pop-up menu, select New => BLPackage.
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 Component Templates, Components, or Servers folder, select a

component. Right-click and select Package and Deploy 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.
Create BLPackage Package Type on page 511
Create BLPackage Select Server Objects on page 512
Create BLPackage Components on page 512
Create BLPackage Snapshots on page 512
Create BLPackage Depot files on page 513
Create BLPackage Software on page 513
Create BLPackage Master Snapshot on page 513
Create BLPackage Package Item Options on page 514
Create BLPackage Properties on page 515
Create BLPackage Permissions on page 516
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.
If you accessed the Create BLPackage wizard by selecting a component to deploy,

the New Deploy Job wizard opens automatically.
Create BLPackage Package Type

The Package Type panel asks you to identify the package and choose a method for
creating the package.
Package name
Name of the BLPackage you are creating.
Save in
Click Browse and navigate to the depot folder where you want to save
the BLPackage.
Create Package From
Select one of the following methods for creating a BLPackage:
Live server objectsBundle server objects you select from a live server.
ComponentsBundle some or all of the server objects that constitute a

component.
SnapshotsBundle server objects you select from a snapshot.
Depot filesBundle files you select from the Depot.
Depot softwareBundle software you select from the Depot.
DeltaBundle the server objects on a live server that are different from
the corresponding server objects in a snapshot designated as the master.
Empty packageGenerate an empty BLPackage.

Create BLPackage Select Server Objects

The Select Server Objects panel lets you select live server objects for a BLPackage.
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.
Includes and Excludes
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
Select to recursively select all subfolders in a folder.
Create BLPackage Components

The Components panel lets you select components for a BLPackage.
Click Add Components to open the Select Components dialog. Use it to select
the components you want to include in the BLPackage.
Create BLPackage Snapshots

The Snapshots panel lets you select snapshots for a BLPackage.

Click Add Snapshot to open the Select Snapshots dialog. Use it to select the
snapshots you want to include in the BLPackage.
Create BLPackage Depot files

The Depot files panel lets you select files stored in the Depot that should be included
in a 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.
Create BLPackage Software

The Software panel lets you select software packages stored in the Depot that should
be included in a 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.
To choose individual parts of a software package to include in the BLPackage, select

a software package in the Depot Software list. Then, in the Selected Software Parts
list, check the parts you want to bundle. To check all parts, click Select all parts .
To clear all parts, select Deselect all parts .
Create BLPackage Master Snapshot

If you have chosen the delta method to create a BLPackage, the Master Snapshot
panel lets you identify a snapshot, which BMC Server Automation compares to the
same live server included in the snapshot. The resulting BLPackage will consist of
any differences between the snapshot and the current live state of that server.
Click Browse to specify the snapshot on which packaging is based.
Create BLPackage Empty Package

Selecting the Empty package option on the Package contents panel generates an
empty 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.
Create BLPackage Package Item Options

The Package Item Options panel lets you make decisions about how to create a
BLPackage.
Depot Asset Options

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
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.
Copy file contents
Copy the contents of all files included in the BLPackage.

Collect access control list (ACL) attributes
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
Instructs the BLPackage to gather ACLs for Windows registry entries.
This option is dimmed unless you are packaging registry information.
Component Options
Local Property Name Conflicts
When you create a BLPackage from components or you add components to

an existing BLPackage, the components can have local properties with the
same name. Also, the components can have properties with names that
conflict with local properties assigned to the BLPackage itself. Select one of
the following mutually exclusive choices to resolve conflicts between
properties with the same name.
This option is dimmed unless you are packaging components.
Fail packaging if property values do not matchCreates a package but

generates errors if the components you are packaging include properties
with the same name but different values. This option is the default value.
Ensure newly imported property name is uniqueGenerates a unique

name for all properties with the same name. The system generates a
unique name by appending a number to the property name for all but the
first property it encounters.
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.
Create BLPackage Properties



inherited.
Property .
Create BLPackage Permissions

this object.
you want to add.


BLPackage Editing

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.
BLPackage editor interface

The interface for the BLPackage editor appears in its own tab. You can open multiple
BLPackages, each on a separate tab, and edit them concurrently.
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

BLPackage Editing
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.
BLPackages and custom configuration objects

If you are editing a BLPackage that references a custom configuration object and a
more recent version of that object exists, a third tab called Version Warnings appears
when the BLPackage cannot be automatically upgraded to refer to the new object. In
cases where the BLPackage is automatically upgraded to the new version, the
console displays a message informing you of that fact. When you save the
BLPackage, the upgrade to the new version of the custom configuration object is
finalized.

BLPackage Editing
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.
Procedures related to editing BLPackages

When editing a BLPackage, you can perform any of the following procedures:
Opening a BLPackage to edit on page 520
Changing object attributes in a BLPackage on page 521
Adding a local property to a BLPackage on page 532
Moving an object within a BLPackage on page 533
Cutting and pasting in a BLPackage on page 534

BLPackage Editing
Ordering software within a BLPackage by dependency on page 535
Deleting an object in a BLPackage on page 535
Providing password information in a BLPackage on page 535
Finding and replacing text in a BLPackage on page 536
Adding content to a BLPackage on page 539
Creating an RPM group on page 544
Creating an asset group on page 545
Commenting out assets on page 548
Verifying assets in a BLPackage on page 548
Closing the BLPackage editor on page 549
Opening a BLPackage to edit

To edit a BLPackage, you must first open the package.
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.
To open a BLPackage to edit
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.
A new tab with the name of the selected BLPackage appears.
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.

BLPackage Editing
Changing object attributes in a BLPackage

A common task when editing a BLPackage is to change the attributes of an object in
the package.
To change object attributes in a BLPackage
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.
When changing attributes of objects in BLPackages, be aware of the following:
Some attributes provide a drop-down list from which you can choose a value.
Attributes listed in italics are not editable.
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:

BLPackage Editing
AddAdds a new local user account.
ModifyAlters an existing local user account.
DeleteDeletes an existing local user account.
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.
For additional information about changing attributes of objects in a BLPackage,

see the following:
Working with soft-linked objects on page 522
Setting single-user mode for an object on page 523
Setting a reboot for an object on page 525
Setting action on failure on page 526
Changing file ownership attributes on page 528
Windows multi-value registry entries in BLPackages on page 529
Windows security settings in BLPackages on page 530
Note
For a discussion of the rules that apply when entering paths to server objects,
see Rules for entering paths on page 56.
Working with soft-linked objects

When you create a BLPackage using depot objects or objects specified using network-
based URLs, you have the option of specifying whether the contents of the
BLPackage should be soft-linked.
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

BLPackage Editing
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.
To work with soft-linked objects
1 In the hierarchy view, select an object that is soft-linked.
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:
a Click Edit Link Source at the bottom of the right pane.
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.
3 To remove an objects soft-linked setting, do the following:
a In the right pane, for IsSoftLinked, select No.
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.
b On the confirmation dialog box, click Yes.
Setting single-user mode for an object

Single-user mode is a minimal UNIX environment typically used when installing or
removing software. In a BLPackage, you can specify that an object be deployed in single-
user mode.

BLPackage Editing
Single-user mode requires only basic system functionality. If a target system is in a

different user mode when you deploy a BLPackage that calls for single-user mode,
the target system stops all processes that should not be running in single-user mode.
In some situations, a target may need to be rebooted (for Oracle Solaris) or shut
down (for other UNIX platforms) so it can restart in single-user mode. When the
BLPackage needs to switch out of single-user mode, the target system restarts all
necessary processes. When a server is in single-user mode, BMC Server Automation
cannot communicate with the agent on that server.
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.
To set single-user mode for an object
1 In the hierarchy view, select an object included in the BLPackage.
2 In the right pane, for Single-User Mode, select one of the following:
Single-user mode without reboot/shutdownInstructs a Deploy Job to

process this object in single-user mode without first rebooting or shutting down
the target. If the job is not currently in single-user mode, the job takes note of
the current user mode before switching modes. When the object being
deployed no longer requires single-user mode, the job reverts to the previous
mode.
Reboot/shutdown into single-user modeInstructs a Deploy Job to reboot or

shut down a target so that it starts in single-user mode. If the job is not
currently in single-user mode, the job takes note of the current mode before

BLPackage Editing
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.
Setting a reboot for an object

Using the BLPackage editor, you can specify a reboot for an object in a package.
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.
To set a reboot for an object
1 In the hierarchy view, select an object included in the BLPackage.
2 In the right pane, for Reboot, select one of the following:
Not requiredNo reboot is required. This is the default setting.
After item deploymentReboot after this object is deployed. You can override
this setting using Deploy Job options.
After item deployment with reconfiguration (Solaris ONLY)After this

object is deployed, perform a Solaris reconfiguration reboot. If the target server

BLPackage Editing
is not a Solaris machine and you select this option, a normal reboot occurs. You
can override this setting using Deploy Job options.
Out-of-bandThis object includes instructions for a reboot, but that reboot is

not included in the instructions for a Deploy Job. When deploying a software
package, if an out-of-band reboot does not occur, the job will complete
successfully but will generate warnings. If you select this option, any Deploy
Job used to deploy this package will automatically be defined to use single-job
mode. Also, rollback information will be created for this object, assuming
rollback is enabled.
By end of jobA reboot is required, but not immediately. The reboot

requirement is satisfied the next time a target server reboots. If no reboots occur
before the end of the job, the server reboots then.
By end of job with reconfiguration (Solaris ONLY)A Solaris reconfiguration

reboot is required, but the reboot should not occur immediately. Instead, the
next time the target server needs to reboot, a reconfiguration reboot is
performed. If no reboots are required before the end of the job, the server
performs a reconfiguration reboot then. If the target server is not a Solaris
machine and you select this option, a normal reboot occurs. You can override
this setting using Deploy Job options.
Setting action on failure

Using the BLPackage editor, you can use object attributes to specify how a Deploy
Job reacts to a failure when installing a software package or executing an external
command.
The options for a software package or external command are:
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.

BLPackage Editing
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.
To set action on failure
1 Right-click in the hierarchy view and select a software package or external

command.
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:
Abort Ignore Continue
Changing network-based software deploy options

Using the BLPackage editor, you can modify options for network-based
deployments of software packages.
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.
To change network-based software deploy options
1 In the hierarchy view, select a software package included in the BLPackage. The
right pane shows the attributes associated with that object.
2 In the right pane, do any of the following:
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).

BLPackage Editing
Select Staging and then click in the Value column. A drop-down list appears.
Select one of the following:
Copy to Agent at stageThe Application Server mounts/maps the device

specified in the URL and copies all source files from this network location to
the staging directory on the agent during the staging phase of a Deploy Job.
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.
Changing file ownership attributes

Using the BLPackage editor, you can specify whether to apply or ignore file owner
attributes during a deployment or a rollback.
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.

BLPackage Editing
To change file ownership attributes
1 In the hierarchy view, select any file included in a BLPackage.
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.
For PermissionsOption, select Apply to apply this files permissions during

deployment or rollback. Select Ignore to ignore this files permissions.
Windows multi-value registry entries in BLPackages

Using the BLPackage editor, you can edit Windows multi-value registry entries.
When editing a Windows registry value of type REG_MULTI_SZ (a value that

accepts multiple entries), each entry is displayed as a separate child node beneath
the node for the registry value itself. For each child node, you can edit the name and
change the Add or Delete action for that node.
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.

BLPackage Editing
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.
Windows security settings in BLPackages

When editing a Windows security setting in a BLPackage, the choices you make can
yield an array of possible results when deploying or rolling back that package.
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.
Action Replace Full or Empty Single or Deployment Rollback

Value Multiple
Values
Add or Modify Yes or No Value is Single Replaces the single Writes an Add or
For keys that provided value currently in the Modify (depending
can only have file with the value on the original
one value, the passed in. command) using the
Replace option original single value.
is ignored. On rollback, that
value replaces the
new value.

BLPackage Editing

Value Multiple
Values
Add or Modify Yes or No Empty value Single Replaces the single Writes an Add or
For keys that value currently in the Modify (depending
can only have file with a blank on the original
one value, the value. This action command) using the
Replace option effectively performs a original single value.
is ignored. delete. It is useful On rollback, that
when you need to value replaces the
empty a value, and blank entry.
you do not know
how that value is set
on all targets.
Add or Modify No Values are Multiple Adds new entries to Writes a Delete
provided the list of possible command to remove
values. However, if only those entries
an entry being added that did not exist
already exists in the before the command
targets Value list, was run.
that entry is skipped
and the rest of the
entry values are
processed.
Add or Modify No Empty value Multiple No action occurs. Writes a Delete
command with a list
of blank values. In
effect, this command
performs a rollback
in which no action
occurs other than
making a record of a
rollback.
Add or Modify Yes Values are Multiple Replaces the existing Writes an Add or
provided list of multiple values Modify (depending
with new values that on the original
are passed in. command) using the
original list of values.
On rollback, those
value replace the
new values.

BLPackage Editing

Value Multiple
Values
Add or Modify Yes Empty value Multiple Replaces the existing Writes an Add or
list of multiple values Modify (depending
with a blank entry. on the original
This action command) using the
effectively deletes all original list of values.
entries. It is useful On rollback, those
when you need to values replace the
empty a value and blank entry.
you do not know
how that value is set
on all targets.
Delete Yes or No Value is Single If the target is set to a Writes an Add
The Replace provided value, this action command to change
setting is deletes that value the deleted value
ignored for all and renders the entry back to its original
Delete blank. setting.
commands.
Delete Yes or No Empty value Single No action occurs. Writes a Delete
The Replace command for the
setting is single empty value,
ignored for all which essentially
Delete results in no action.
commands.
Delete Yes or No Values are Multiple If the target has Writes an Add
The Replace provided entries in a value list, command that adds
setting is this action removes only those values
ignored for all those entries. that were deleted
Delete from original list.
commands.
Delete Yes or No Empty value Multiple No action occurs Writes a Delete
The Replace command for a list
setting is with multiple empty
ignored for all values, which
Delete essentially results in
commands. no action.
Adding a local property to a BLPackage

When editing a BLPackage, you can assign local properties directly to the package.
These properties only apply to the BLPackage; they are not available globally like
properties created in the Property Dictionary.

BLPackage Editing
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.
In earlier releases of BMC Server Automation, a parameter in a BLPackage could

only refer to property values that were assigned to target servers where the package
was deployed. You can continue to use parameters in this way. To do so, you insert a
property that references the target server. These properties are all subordinate to the
TARGET property. For example, you could insert a parameter called ??
TARGET.DEPLOYPATH??.
To add a local property to a BLPackage
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.
Moving an object within a BLPackage

Using the BLPackage editor, you can move an object within a package.
You cannot move an object to a higher level in the hierarchy, in effect changing the
parent of that object.
To move an object within a BLPackage
1 In the hierarchy view, select the object you want to move.
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.
Move to TopThe selected object moves to the top of the hierarchy.
Move to BottomThe selected object moves to the bottom of the hierarchy.

BLPackage Editing
Order of COM+ items in a BLPackage

When creating a BLPackage that contains COM+ objects, there may be special
considerations for ordering items in the package.
COM+ objects often contain items identified as Components/name (where name is

a variable). Often these components also contain collections called Components/
name/InterfacesForComponents.
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.
Cutting and pasting in a BLPackage

Using the BLPackage editor, you can cut and paste objects within a package or
between multiple BLPackages.
To cut and paste within a BLPackage
1 In the hierarchy view of the BLPackage editor, select an object. Right-click and
select Cut from the pop-up menu.
2 Select the location in a BLPackage where you want to paste.
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.
3 Right-click and select Paste.
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.

BLPackage Editing
Ordering software within a BLPackage by dependency

Using the BLPackage editor, you can order software packages according to their
dependencies.
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.
To specify a dependency for a software package, use the software packages

DEPENDENCY_LIST property to specify other software packages already stored in
the Depot on which the package is dependent.
To order software by dependency
1 In the hierarchy view, select the BLPackage or any software package included in
the BLPackage.
2 Right-click and select Order by Dependencies from the pop-up menu.
All software packages in the BLPackage are ordered according to their

dependencies.
Deleting an object in a BLPackage

Using the BLPackage editor, you can delete an object in a package.
To delete an object
1 In the hierarchy view, select the object you want to delete.
2 Right-click and select Delete from the pop-up menu.
Providing password information in a BLPackage

In certain situations while using the BLPackage editor, the Password Required
window may display and ask you for password information.
The Password Required window appears when you do any of the following:
Edit the password field for a Windows service or COM+ object.

BLPackage Editing
Perform a procedure that requires password access to a Windows service or COM

+ object, such as when you attempt to verify a package that contains a service.
Add a Windows local user.
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.
Modify the password for a Windows local user.
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.
To provide password information in a BLPackage
1 In the Password Required dialog, do one of the following:
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.
Finding and replacing text in a BLPackage

Using the BLPackage editor, you can find text and optionally replace text.

BLPackage Editing
Searching for and replacing text can be particularly useful when editing large
BLPackages.
To find and replace text
1 In the hierarchy view, select an object, right-click, and take one of the following
actions:
Select Find to find text.
Select Replace to find and replace text.
The Find dialog appears. Contents of the dialog vary depending on whether
you are finding text or finding and replacing text.
2 Use the options in the Find dialog to narrow your search.
Find what
Enter the text string you are searching for.
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
Check any of the following:
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.

BLPackage Editing
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.
Whole packageSearches the entire BLPackage.
Object Property Scope
Specify the object properties you want to search by doing one of the following:
Select Any to search all object properties.
Select the text box and enter the object property you want to search, such as
FILELOCATION or UNIQUEFILENAME.
3 Do one of the following to find and optionally replace text:
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:
Find NextSearches for another instance of the text string.
CancelCancels the search.
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:
ReplaceReplaces the highlighted text string and searches for another

instance of the text string.
SkipIgnores the current match and searches for another instance of the
text string.
Replace AllReplaces all instances of the text string.
CancelCancels the search.

BLPackage Editing
Adding content to a BLPackage

Using the BLPackage editor, you can add different types of content to a package.
You can take the following actions to add content:
Importing assets into a BLPackage on page 539
Adding an external command to a BLPackage on page 539
Adding a custom action to an asset on page 541
Adding files to a BLPackage on page 541
Adding payloads to custom configuration objects on page 543
Replacing file content on page 543
Importing assets into a BLPackage

Using the BLPackage editor, you can add assets to a package.
You can also add assets to a package by adding files. See Adding files to a
BLPackage on page 541.
To import assets into a BLPackage
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.
Adding an external command to a BLPackage

Using the BLPackage editor, you can add an external command to a package. An
external command is any type of command that can be issued on a command line
interface.

BLPackage Editing
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.
An external command can be positioned in a BLPackage so it executes at the time

items in the BLPackage are processed. For example, you can create one external
command positioned at the beginning of a BLPackage that stops Windows services
before the BLPackage is installed. Then you can create a second external command
positioned at the end of the BLPackage that starts Windows services after the
BLPackage is installed.
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.
To add an external command
1 Right-click in the hierarchy view and select Add => External Command from the
pop-up menu.
2 In the right pane, enter a value for any of the following:
Nameoptionally provides a name for the command.
Cmdprovides the command or script to be executed when the BLPackage is

deployed.
UndoCmdprovides the command or script to be executed when the

BLPackage deployment is undone.
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.

BLPackage Editing
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.
3 If necessary, enter a value for ActionOnFailure (see Setting action on failure on

page 526).
4 Move the external command to the correct position in the BLPackage (see Moving
an object within a BLPackage on page 533).
Adding a custom action to an asset

Using the BLPackage editor, you can add an asset that includes a custom action to a
BLPackage.
To add a custom action
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.
Adding files to a BLPackage

When editing a BLPackage, you can add files to the package.

BLPackage Editing
You can also add files to a package by importing assets. See Importing assets into a
BLPackage on page 539.
To add files to a BLPackage
1 In the BLPackage hierarchy, select the top node or select an existing directory.
2 Right-click and select Add => File.
The Select file window opens.
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:
Reorder Select the file, right-click, and select reordering options.
Delete Select the file, right-click, and select Delete.
Cut and paste Select the file, right-click, and select Cut. After cutting it, you
can select another node, right-click, and select Paste.

BLPackage Editing
Adding payloads to custom configuration objects

When editing a BLPackage that includes a custom configuration object that is
designed to accept payloads, you can designate the contents of files that should be
added as payloads to the custom configuration object. This capability allows you to
add information to agentless managed objects, which are managed as custom
configuration objects.
For payloads, you can add the contents of any type of file, including binary files.
To add payloads to custom configuration objects
1 In the BLPackage hierarchy, navigate to a custom configuration object. Select any

node in the hierarchy of the custom configuration object.
2 Right-click and select Add => File.
The Select file window opens.
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:
Reorder Select the payload, right-click, and select reordering options.
Delete Select the payload, right-click, and select Delete.
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.
Replacing file content

When editing a BLPackage, you can replace the contents of an existing file or custom
configuration object payload. For the replacement contents, you can select a local file
or a file on a server where an agent is installed.

BLPackage Editing
To replace file content
1 In the BLPackage hierarchy, select an existing file or custom configuration object

payload with contents you want to replace.
2 Right-click and select Replace File Content.
The Select Replacement File window opens.
3 Navigate to a file with the contents you want to use.
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.
Creating an RPM group

Using the BLPackage editor, you can create a group of RPMs that are installed using
a single command.
This capability is necessary when deploying a BLPackage containing multiple RPMs

that are dependent on each other. A BLPackage can install the contents of an RPM
group using one command that analyzes dependencies between RPMs and
establishes an order for their installation.
To create an RPM group
1 Add RPMs to the BLPackage, as described in Importing assets into a BLPackage

on page 539.
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.

BLPackage Editing
Creating an asset group

Using the BLPackage editor, you can group certain items in a custom configuration
object. BMC calls these asset groups. A Deploy Job processes all of the items in an
asset group together rather than individually.
For more information about asset groups, see Asset group concepts on page 546.
To create an asset group
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:
Define attributes for the group

The attributes you can define include the group's name and its
ActionOnFailure setting. For more information, see Changing object attributes
in a BLPackage on page 521.
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.

BLPackage Editing
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.
Cut and paste assets

Select a first-level asset in an asset group, right-click, and select Cut or Paste as
described in Cutting and pasting in a BLPackage on page 534.
Pasting in asset groups can behave differently than pasting other types of
objects in a BLPackage. If you cut:
Items in an asset group, you must paste them into:
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 group concepts

Custom configuration objects can be defined so that some or all of their assets can be
grouped within a BLPackage. BMC calls these asset groups.
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.

BLPackage Editing
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
Deployments of items in an asset group can be rolled back if necessary. When a

Deploy Job processes items in an asset group during the Commit phase, the job
generates rollback information for each item. Processing an asset group during a
rollback is the same as processing an asset group during the Commit phasenone of
the rollback actions take effect until all of the items in the asset group are processed.
However, note that during rollback, items in an asset group are processed in the
reverse order of their processing during the Commit phase.

BLPackage Editing
Commenting out assets

Using the BLPackage editor, you can comment out objects or other assets included in
a BLPackage. Commenting allows you to temporarily remove an asset from a
BLPackage and then replace it at a later time.
To comment out assets
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
Verifying assets in a BLPackage

The BLPackage editor lets you confirm that the structure of the BLPackage contains
no inherent errors. A verification checks for referenced files that are not included in
the BLPackage and assets that are ordered incorrectly.
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.
To verify assets in a BLPackage
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.
Double-clicking a message displays the text of the message in the Verification

Messages section of the tab. Click Close to close the panel.

Adding a Network Shell script
Closing the BLPackage editor

When you close the BLPackage editor, you are prompted about saving the contents
of the BLPackage. If you save, your edits completely replace the existing version of
the BLPackage.
To close the BLPackage editor
Click the X on the tab representing the BLPackage you are editing.
Right-click the tab and select Close.
If you have made changes to the BLPackage, you are prompted to save your changes.

You can create Network Shell scripts and store them in the Depot. After you add a
Network Shell script to the Depot, you can run the script using a Network Shell
Script Job.
To add a Network Shell script to the Depot
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.
The Add NSH Script to Depot wizard opens.
2 Using the wizard, define the script, as described in the following sections:
Add NSH Script Script Options on page 550
Add NSH Script Parameters on page 551
Add NSH Script Properties on page 553
Add NSH Script Permissions on page 553
3 Click Finish to close the wizard and save your changes.

For information about creating a job that runs the script you have added, see
Creating Network Shell Script Jobs on page 791.
Add NSH Script Script Options

The Script Options panel lets you provide identifying information for the Network
Shell script.
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
Optional descriptive text
Save in
Folder where you want to store this object.
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 separately against each hostThe script executes

repeatedly from the Application Server, each time running on a different
server. This option uses theNetwork Shell runscript program, which can
run the same script on multiple machines. The script uses environment
variables local to the Application Server.
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.
Add NSH Script Parameters

The Parameters panel lets you define parameters that are replaced with server
property values when a script runs.
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.
To add a parameter, click Add Parameter . To modify an existing parameter,

select it in the Script Parameters list and then clicking Update Parameter . Either

of these actions displays the Add parameter dialog box, which has the following
options:
Name
Identifying name.
Description
Flag
Enter a flag if the parameter requires one.
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.
Parameter flag required at runtime
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
Check if the flag can accept a 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 remove a parameter, select the parameter and click Delete .
Add NSH Script Properties


inherited.
Property .
Add NSH Script Permissions


this object.
you want to add.


Modifying a Network Shell script

The procedure for modifying a Network Shell script that you have already added to
the Depot has minor differences from the procedure for creating new Network Shell
script.

To modify a Network Shell script
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:
Add NSH Script Script Options on page 550
Add NSH Script Parameters on page 551
Script on page 555
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.

apply to this Network Shell script, select the Properties, Permissions, or Audit
Trail tab group.
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.

Adding files to the Depot

You can use the Depot to store files.
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.
To add files to the Depot
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.
2 Provide information for the file, as described in the following sections:
Add File General on page 556
Add File Properties on page 557
Add File Permissions on page 557
3 Click Finish to close the wizard and save your changes.
Add File General

The General panel lets you provide identifying information for the file you are
adding to the Depot.
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
Folder where you want to store this object.
File encoding
Type of character encoding that is used for the script, such as UTF8 or UTF16
Add File Properties


inherited.
Property .
Add File Permissions


this object.
you want to add.



11
Configuration objects
BMC Server Automation provides tools for managing custom configuration objects,
extended objects, and configuration files. Collectively, BMC refers to these objects as
Configuration objects overview

BMC Server Automation provides tools for managing custom configuration objects,
extended objects, and configuration files.
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.
An extended object is similar to a custom configuration object, but it provides less

functionality. In particular, an extended object cannot be deployed like a custom
configuration object.
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.
Managing configuration objects at the Application Server

All configuration objects are managed at the Application Server level using the
Configuration Object Dictionary. The following sections describe procedures for
adding configuration objects to the Configuration Object Dictionary:
Adding a custom configuration object on page 567
Identifying additional configuration files on page 574
Creating an extended object on page 577

Configuration Object Dictionary
Job for managing custom configuration objects

The following sections describe jobs BMC Server Automation provides for
distributing custom configuration objects to servers as well as updating and
deregistering those objects:
Creating or modifying a Distribute Configuration Objects Job on page 583
Creating or modifying an Upgrade Model Objects Job on page 590
Creating or modifying a Deregister Configuration Object Job on page 597
Standard custom configuration objects

A standard installation of an agent on a server includes several types of custom
configuration objects. A standard installation of an Application Server includes
additional custom configuration objects, which you can optionally deploy to agents.
For more information about the standard custom configuration objects, see Custom
configuration objects on page 561.
Configuration Object Dictionary

The Configuration Object Dictionary provides a central location where you can view,
create, and manage configuration objects in BMC Server Automation. The
Configuration Object Dictionary shows all built-in server objects as well as all
custom configuration objects, extended objects, and configuration files.
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:

Custom configuration objects
Adding a custom configuration object on page 567
Creating an extended object on page 577
Deleting a custom configuration object on page 569
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.

BMC Server Automation provides a set of custom configuration objects that are
available on all Application Servers and managed servers running the current release.
Custom configuration object distribution

BMC Server Automation provides the following methods for gaining use of custom
configuration objects:
Standard agent installationSome custom configuration objects are automatically

installed when you install an agent. These objects allow you to obtain information
from managed servers.
Requires distributionSome custom configuration objects are available in the

Configuration Object Dictionary but must be manually distributed to managed
servers before you can use them. See Creating or modifying a Distribute
Configuration Objects Job on page 583.
There are special considerations for custom configuration objects when upgrading
agents to a later version. See Upgrading custom configuration objects on page
566.
Custom object servers

A process called the custom object server manages actions on the agent for some
types of custom configuration objects. See Custom configuration object list on
page 562 for a list of custom configuration objects that use the custom object server.

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:
The server is running a Windows operating system.
Agent ACLs have been pushed to the server.
A role defined in BMC Server Automation is mapped to a Windows user on the

server.
The Windows user is not a member of the server's Administrators group.
Custom configuration object list

The following table lists all standard custom configuration objects. If you are using
associated products, such as BMC Application Automation, other custom
configuration objects may be installed or available as part of that product.
Object type Available as part of Requires distribution Uses custom object server
agent installation
BLPackages yes; on all operating

systems
Daemons yes; on UNIX platforms
Hardware Information yes; on all operating
systems
Processes yes; on UNIX platforms
UNIX Groups yes; on UNIX platforms
UNIX Users yes; on UNIX platforms
Active Directory yes
Global Zone yes
IBM Configuration yes
Microsoft SCVMM yes
RHEL KVM yes yes

Object type Available as part of Requires distribution Uses custom object server
agent installation
VMware vCenter yes yes

Server
Citrix XenServer yes yes
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.
Actions with UNIX objects

A standard installation of an agent on any UNIX platform includes custom
configuration objects that let you take the following actions:
Kill UNIX processes
Set UNIX passwords and password states
Stop, start, restart, and reload UNIX daemons (including a start with
dependencies for Solaris 10)
Custom configuration object versions

Custom configuration objects are versioned.
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.
Deployable actions for UNIX objects

When server objects are packaged and deployed, BMC Server Automation can
usually roll back those deployments. However, the actions you can deploy for UNIX
objects cannot be undone because BMC Server Automation cannot always know the
objects original state.
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.

UNIX Object Action

UNIX User Update Password
Set Password State
Note: If you attempt to undo the Set Password State
action for a UNIX User, the undo will appear to
succeed, but the log will include a warning that it
was not possible to undo this action.
Daemon Stop
Start
Start with dependencies (for Oracle Solaris 10)
Restart
Reload
Setting up an Active Directory object

The Configuration Object Dictionary for any Application Server includes the Active
Directory object, which is capable of collecting data from Active Directory 2003. To
use this object, you typically must distribute it to one or more Windows servers.
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:
Distributing the Active Directory object to a domain controller is the easiest

approach. For most environments, if the Active Directory object is distributed to
an agent running on any domain controller in the forest, then no automation
principal is needed.
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 choose to distribute the Active Directory object to a non-domain controller,

you must set up an automation principal. The Active Directory configuration
determines what credentials you must provide. Typically using an account with
Domain User or Domain Admin privileges works, but remember that you may
need to use this account from the top-most domain. You must also make sure the
account is authorized to access the machine and that the account is granted the
Windows Logon as a batch job privilege. To access this setting, use the Control
Panel and go to Administrative Tools\Local Security Policy\Local Policies\User
Rights Assignment

If you have additional questions about access requirements for Active Directory,
consult your domain administrator.
To set up an Active Directory object
1 Distribute the Active Directory custom configuration object by running a

Distribute Configuration Objects Job.
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.
2 Create an automation principal that defines user credentials with privileges to

browse the Active Directory domain.
For more information, see Creating automation principals on page 195.
3 Associate the automation principal with a role that should have access to Active
Directory information.
For more information, see Role Agent ACL on page 213.
Upgrading custom configuration objects

For custom configuration objects to work reliably, the version of the custom object
should match the version of the agent.
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.
To upgrade 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.

Adding a custom configuration object
2 Run a Distribute Configuration Objects Job to distribute the latest version of

custom configuration objects stored in the Configuration Object Dictionary.
The job should target agents that you have upgraded. The system prevents you
from distributing custom configuration objects to agents running an incompatible
version.
For more information, see Creating or modifying a Distribute Configuration

Objects Job on page 583.
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.
You must maintain a version match between component templates, BLPackages,

Snapshot Jobs, and Audit Jobs and custom configuration objects and agents. The
objects that you copy in this step are the objects that you can use to maintain the
version match.
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.

A standard installation of BMC Server Automation provides a wide range of server
and configuration objects for many operating systems. In addition, you can add
custom configuration objects to the Configuration Object Dictionary.

Note
This procedure is not typically used. In most situations custom configuration

objects are either automatically imported or installed by means of an installation
program.
BMC Server Automation also refers to custom configuration objects as custom

server objects.
To add a custom configuration object
1 Obtain a ZIP file for the custom configuation object you want to add.
2 Select Configuration => Config Object Dictionary View.
The Configuration Object Dictionary opens.
3 Click Add Configuration Object .
The New Configuration Object wizard opens.
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.

Deleting a custom configuration object
Deleting a custom configuration object

You can delete a custom configuration object from the Configuration Object Dictionary.
Before you begin
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.
To delete a custom configuration 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
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.
Parsing configuration files

BMC Server Automation uses a system of grammar files to parse configuration files.
Typically the BMC Server Automation grammars examine each line in a

configuration file, and if the line matches rules set up in the grammar, the grammar
generates a configuration file record. When defining a grammar file, an option exists
for creating configuration file records from multiple lines, which is required for some
types of 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.
For more information, see:
Grammar files supported by BMC Server Automation on page 570
Grammar files supported by BMC Server Automation

BMC Server Automation supports a variety of grammar files capable of parsing data
presented in a prescribed format. After it is parsed, that data can be generated in a
format consistent with other information in BMC Server Automation so you can then
browse, snapshot, audit, and deploy that information.
Although BMC Server Automation provides many grammar files, the following are
the basic types:
CSVParses files consisting of comma-separated entries
HTTPDParses httpd.conf files.

Configuration files
name = valueParses files with single name/value pairs connected by an equal

sign (=)
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.
RegularParses all other configuration files.
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.
Grammar Type Name Associated Grammar Description

File
/etc/auto_* file auto.gm Parses files with lines made up of a varying number of tab-
delimited entries; the first entry is the unique key.
/etc/group file group.gm Parses files with four colon-delimited values in each line;
the first value is the unique key.
/etc/inittab file inittab.gm Parses files with four colon-delimited values per line; the
first value is the unique key.
/etc/pam file pam.gm Parses files with lines made up of a varying number of tab-
delimited entries; uses the entire line as the unique key.
/etc/passwd file passwd.gm Parses files where each line consists of seven colon-
delimited fields; the first value is the unique key.
/etc/resolv.conf file resolv.gm Parses files with a varying number of space- or tab-
delimited entries on each line; the unique key is generated
by a combination of all entries.
/etc/shadow file shadow.gm Parses files with lines of nine colon-delimited values; the
first value is the unique key.
AIX /etc/security/* aix_security.gm Parses all /etc/security files in IBM AIX that have a header
file on one line followed by name/value pairs connected by an
equal sign (=); the first value is the unique key.
audit control file audit_control.gm Parses fields separated by colons, using the first field as the
key. This grammar is used to parse /etc/security/
audit_control files on Oracle Solaris.

Configuration files

File
audit files audit.gm Parses fields separated by colons, using the second field as
the key. This grammar is used to parse /etc/security/
audit_class and /etc/security/audit_event files on Solaris.
config.xml config.xml.gm Parses WebLogic config.xml files.
console_perms console_perms.gm Parses /etc/security/console.perms files on Linux.
context.xml context.xml.gm Parses Tomcat context.xml files.
crontab file crontab.gm Stores five time-based values and one ambiguous command
value per line; the command is the unique key.
csv file csv.gm Parses files consisting of lines of a varying number of comma-
separated entries; uses the entire line as a unique key.
fstab mount file fstab.gm Parses files where each line consists of six tab-delimited
entries; the first entry is the unique key.
grub.conf grub.gm Parses /etc/grub.conf files on Linux.
hosts file hosts.gm Parses files with lines consisting of a varying number of space-
delimited entries; the first entry is the unique key.
httpd.conf file httpd.gm Parses formats similar to a simple XML format.
init.ora file init.ora.gm Parses records with a name and one value and treats
comments as values.
lilo.conf lilo.gm Parses /etc/lilo.conf files on Linux.
Linux /etc/yp.conf ypconf.gm Parses a complex format specific to /etc/yp.conf files on Linux.
file
Machine Config XML machine.config.xml.g Parses machine.config XML files used for IIS and .NET
file m applications. This grammar is specifically designed for
machine.config XML files that may include multiple nodes
with identical names and the same parent node.
name = multi values nvp.gm Parses records with a name and multiple values, such as
name = value1 value2 value3.
name = value nsvp.gm Parses files with single name/value pairs connected by an
equal sign (=); uses the name before the equal sign as a
unique key.
name space value nsvp_space.gm Parses data where the format is "PROPERTY VALUE". The
separator is white space instead of an equal sign (=). This
grammar is used to parse /etc/login.defs files on Linux and /
etc/hosts.deny and /etc/ssh/sshd_config files on Solaris.
NIS /etc/group file nis-group.gm Parses files for /etc/group and Network Information Server
(NIS) /etc/group on UNIX platforms.
nsswitch.conf on nsswitch.gm Parses formats using an initial key followed by a colon with
UNIX a varying number of space-delimited values after the colon.
Oracle config files ora.gm Parses tnsnames.ora and listener.ora files in Oracle.

Configuration files

File
running-managed- running-managed- Parses Tomcat running-managed-servers.xml files.
servers.xml servers.xml
single unique value single_val.gm Parses files where each line contains one value that does not
per line contain a space, equal sign (=), or pound sign (#).
Solaris /etc/system system.gm Uses a complicated grammar to parse Solaris /etc/system files.
file
Solaris inetd.conf file inetd.gm Parses Solaris files with lines consisting of a varying number
of tab-delimited entries; all entries make up the unique key.
split line into fields line.gm Parses generic records separated by spaces; all fields
participate in the key. Used as an alternative to generic.gm,
this grammar is used to parse /etc/init.d/netconfig, /etc/
security/audit_startup, and /etc/ftpd/ftpaccess files on
Solaris.
ssh_config ssh_config.gm Parses /etc/ssh/ssh_config files on Linux.
sshd_config sshd_config.gm Parses /etc/ssh/sshd_config files on Linux.
tomcat-server.xml tomcat-server.xml.gm Parses Tomcat server.xml files.
tomcat-users.xml tomcat-users.xml.gm Parses Tomcat users.xml files.
UNIX /etc/ syslog.gm Parses /etc/syslog.conf files on UNIX.
syslog.conf file
users and exports file users.gm Parses files using the format of the BMC Server Automation
users and exports configuration files. For a discussion of
those files, see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Setting+up
+configuration+files. The first entry is the unique key.
vfstab mount file vfstab.gm Parses files where each line consists of seven tab-delimited
entries; uses the first entry as the unique key.
web.xml web.xml.gm Parses J2EE web.xml files.
Web Config XML file web.config.xml.gm Parses web.config XML files used for IIS and .NET
applications. This grammar is specifically designed for
web.config XML files that may include multiple nodes with
identical names and the same parent node.
whole line as record generic.gm Parses files by treating a complete line as a single field; uses
the entire line as a unique key. This grammar can be used
for parameter substitution during Deploy Jobs.
Windows INI file ini.gm Parses Windows INI formats with a bracket-enclosed
header and subsequent name-value pairs; the first entry is
the unique key.
xinetd.conf file xinetd.gm Parses xinetd.conf files on Linux.
XML file xml.gm Uses an XML library to parse XML files.

Identifying additional configuration files

You can identify additional configuration files that should appear under the
Configuration object of a server in the Servers folder.
Before you begin
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 identify additional configuration files for a server
Select Configuration => Config Object Dictionary. The Config Object

Dictionary opens.
When editing a component template, click Local Configuration Objects on the

shortcut bar to display the Local Configuration Objects panel. It provides the
same options as the Configuration Object Dictionary.
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
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
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
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.
5 For File path, do one of the following:
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.
6 From File encoding, do one of the following:
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.
BMC Server Automation supports a variety of grammar files. For more

information, see Grammar files supported by BMC Server Automation on page
570.
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.

Extended objects
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.
Provide information about local user accounts on a server.
Show data stored in a SQL database.
Integrate with third party solutions to provide information about agent-less

devices, including routers, switches, and storage area networks (SAN).
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.
For more information, see Creating an extended object on page 577.
Creating an extended object

When you create an extended object in the Configuration Object Dictionary, all users
in your role can access it. The extended object becomes available under the Extended

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.
Before you begin
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 create an extended object
Select Configuration => Config Object Dictionary. The Config Object

Dictionary opens.
When editing a component template, click Local Configuration Objects on the

shortcut bar to display the Local Configuration Objects panel. It provides the
same options as the Configuration Object Dictionary.

To create an extended object, click Add Configuration Object . The New

Configuration Object wizard opens. Select Extended Object and click Next. The
Extended Object Definition panel of the wizard appears.
To modify an existing extended object, select that object and click Edit
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
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
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 .
Using parameters, you can enter a path such as /??TARGET.WINDIR??/system32
/$$TARGET.SCRIPT_DIR??/script.bat. When the script runs, the system replaces

the parameters with the value of the server properties WINDIR and SCRIPT_DIR.
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.
;&|><()
7 Choose one of the following:
Central ExecutionExecutes the script or program on the Application Server.

The script or program must be available in the path or explicitly qualified with
the path so that the Application Server can successfully invoke it.
Remote ExecutionExecutes the script or program on a remote server using a

Network Shell nexec (or equivalent) command. The script or program must be
available in the path or explicitly qualified with the path so that the agent on
the remote server can successfully invoke it.
8 From Character encoding, do one of the following:
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.
Defining custom icons

A custom icon can help you quickly identify an extended object when browsing
extended objects in the Servers folder.
Use this procedure to create a set of custom icons that you can associate with
extended objects.
Before you begin
When selecting a custom icon, the image must be in a GIF format, and its resolution
must be 16 by 16 pixels.
To define a custom icon
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.

Jobs to manage custom configuration objects
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
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.

BMC Server Automation provides several jobs for distributing custom configuration
objects to servers as well as updating and deregistering those objects.
Distribute Configuration Objects JobDistributes implementation files to servers

for a new custom configuration object. You should run this job after you add a
custom configuration object to the Configuration Object Dictionary if the
implementation files for the object do not already exist on servers. For more
information, see Creating or modifying a Distribute Configuration Objects Job on
page 583.
Upgrade Model Objects JobUpgrades policy-based objectsthat is, component

templates, BLPackages, and server object-based Snapshot and Audit Jobsso they
reference a new version of a custom configuration object. You must run this job
after you add a new version of a custom configuration object to the Configuration
Object Dictionary if you want policy-based objects to reference that new version.

For more information, see Creating or modifying an Upgrade Model Objects Job
on page 590.
Deregister Configuration Object JobRemoves custom configuration objects from

servers. You must run this job before you can delete a custom configuration object
from the Configuration Object Dictionary. For more information, see Creating or
modifying a Deregister Configuration Object Job on page 597.
Creating or modifying a Distribute Configuration Objects Job

The Distribute Configuration Objects Job lets you distribute implementation files for
a new custom configuration object to the managed servers where you want to use
the object.
You cannot distribute a custom configuration object to a server where the version of
the agent is incompatible.
To create a Distribute Configuration Objects Job
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.
The New Distribute Configuration Objects Job wizard opens.
2 Provide information for the Distribute Configuration Objects Job, as described in

Distribute Configuration Objects Job General on page 584
Distribute Configuration Objects Job Selected Configuration Objects on

page 585
Distribute Configuration Objects Job Targets on page 586
Distribute Configuration Objects Job Default Notifications on page 586
Distribute Configuration Objects Job Schedules on page 587

Distribute Configuration Objects Job Properties on page 588
Distribute Configuration Objects Job Permissions on page 589
To modify an existing Distribute Configuration Objects Job
1 To modify the definition of an existing Distribute Configuration Objects Job, open

the Jobs folder and navigate to an existing job. Right-click the job and select Open
Distribute Configuration Objects Job General on page 584
Distribute Configuration Objects Job Selected Configuration Objects on page

585
Distribute Configuration Objects Job Targets on page 586
Distribute Configuration Objects Job Default Notifications on page 586
Distribute Configuration Objects Job Schedules on page 587
These tabs correspond to panels in the New Distribute Configuration Objects Job
2 To see or modify any properties, permissions, or audit trail information that

Distribute Configuration Objects Job General

The General panel lets you provide basic information that identifies a job.
Name
Identifying name.
Description
Save in


Distribute Configuration Objects Job Selected

Configuration Objects
The Selected Configuration Objects panel lets you choose the custom configuration
objects you want to distribute to target servers.
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.
3 In the Available Configuration Objects list, select one or more custom

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.

Distribute Configuration Objects Job Targets

The Targets panel lets you choose servers that are the target of this job.
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.
Distribute Configuration Objects Job Default Notifications

notifications.
Send email to
Send SNMP trap to


Distribute Configuration Objects Job Schedules

Scheduling a job
information, see Distribute Configuration Objects Job Scheduling on page
588.
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
completes.
Send email to
Send SNMP trap to


Distribute Configuration Objects Job Scheduling
To schedule jobs
Mean Time.
Distribute Configuration Objects Job Properties


inherited.
Property .
Distribute Configuration Objects Job Permissions


this object.
you want to add.


Creating or modifying an Upgrade Model Objects Job

BMC Server Automation lets you decide whether you want to upgrade policy-based
objectsthat is, component templates, BLPackages, and server object-based
Snapshot and Audit Jobswhen you add a new version of a custom configuration
object to your BMC Server Automation system.
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.
For more information about upgrading custom configuration objects, see

Upgrading custom configuration objects on page 566.
To create and run an Upgrade Model Objects Job
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.
The New Upgrade Model Objects Job wizard opens.
2 Provide information for the Upgrade Model Objects Job, as described in the
following sections:
Upgrade Model Objects Job General on page 591

Upgrade Model Objects Job Selected Objects on page 592
Upgrade Model Objects Job Default Notifications on page 593
Upgrade Model Objects Job Schedules on page 593
Upgrade Model Objects Job Properties on page 595
Upgrade Model Objects Job Permissions on page 596
To modify an existing Upgrade Model Objects Job
Do any of the following:
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:
Upgrade Model Objects Job General on page 591
Upgrade Model Objects Job Selected Objects on page 592
Upgrade Model Objects Job Default Notifications on page 593
Upgrade Model Objects Job Schedules on page 593
These tabs correspond to panels in the Upgrade Model Objects Job wizard. Use
them to modify the job definition.

Upgrade Model Objects Job General

The General panel lets you provide basic information that identifies a Upgrade
Model Objects Job.
Field definitions
Name
Identifying name.

Description
Save in

Upgrade Model Objects Job Selected Objects

The Selected Objects panel lets you choose the component templates, BLPackages,
and server-object based Snapshot Jobs and Audit Jobs that you want to upgrade so
they use the current version of custom configuration objects.
Selecting objects to upgrade
1 From Available Objects, select one or more component templates, BLPackages,

and server-object based Snapshot Jobs and Audit Jobs.
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.

Upgrade Model Objects Job Default Notifications

notifications.
Send email to
Send SNMP trap to

Upgrade Model Objects Job Schedules


Scheduling a job
information, see Upgrade Model Objects Job Scheduling on page 594.
a scheduled job runs. For more information, see Upgrade Model Objects Job
Upgrade Model Objects Job Scheduled Job Notifications
completes.
Send email to
Send SNMP trap to

Upgrade Model Objects Job Scheduling

To schedule jobs
Mean Time.
Upgrade Model Objects Job Properties


inherited.
Property .
Upgrade Model Objects Job Permissions


this object.
you want to add.


Creating or modifying a Deregister Configuration Object Job

To remove custom configuration objects from servers, create and run a Deregister
Configuration Object Job. This job removes all implementation files associated with a
custom configuration object.
To create a Deregister Configuration Object Job
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.
The New Deregister Configuration Object Job wizard opens.
2 Provide information for the Deregister Configuration Object Job, as described in

Deregister Configuration Objects Job General on page 598
Deregister Configuration Objects Job Selected Configuration Objects on

page 599
Deregister Configuration Objects Job Targets on page 600
Deregister Configuration Objects Job Default Notifications on page 600

Deregister Configuration Objects Job Schedules on page 601
Deregister Configuration Objects Job Properties on page 603
Deregister Configuration Objects Job Permissions on page 603
To modify Deregister Configuration Object Jobs
Do any of the following:
1 To modify the definition of an existing Deregister Configuration Object Job, open

the Jobs folder and navigate to an existing job. Right-click the job and select Open
Deregister Configuration Objects Job General on page 598
Deregister Configuration Objects Job Selected Configuration Objects on

page 599
Deregister Configuration Objects Job Targets on page 600
Deregister Configuration Objects Job Default Notifications on page 600
Deregister Configuration Objects Job Schedules on page 601
These tabs correspond to panels in the Deregister Configuration Object Job


Deregister Configuration Objects Job General

The General panel lets you provide basic information that identifies a job.
Name
Identifying name.
Description
Save in


Deregister Configuration Objects Job Selected

Configuration Objects
The Selected Configuration Objects panel lets you choose the custom configuration
objects you want to deregister from target servers.
Field definitions
Show all configuration object versions
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.
Remove any version of selected configuration objects present on servers
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.
Available Configuration Objects
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.
Deregister Configuration Objects Job Targets

The Targets panel lets you choose servers that are the target of this job.
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.
Deregister Configuration Objects Job Default Notifications

notifications.
Send email to
Send SNMP trap to


Deregister Configuration Objects Job Schedules

Scheduling a job
information, see Deregister Configuration Objects Job Scheduling on
page 602.
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
completes.
Send email to

Send SNMP trap to

Deregister Configuration Objects Job Scheduling
To schedule jobs
Mean Time.

Deregister Configuration Objects Job Properties

inherited.
Property .
Deregister Configuration Objects Job Permissions


this object.
you want to add.



12
Managing jobs
This section presents general information about job management for all types of
BMC Server Automation jobs.
Basic concepts for jobs

A job is a set of instructions for performing a task on one or more servers.
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:
The job must be one of the following types:
Batch Job
basic Deploy Job
File Deploy Job

Job management tasks
Network Shell Script 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.

Various tasks in BMC Server Automation enable you to manage your jobs, whether
at the creation and definition stage, the execution stage, while jobs are running, or
after they have finished running.
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:
Table 2: Job types available in BMC Server Automation
Job type Description
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.

Organization of jobs
Job type Description
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.)
Cut and paste folders.
Copy, cut, and paste jobs and smart job groups.
Delete jobs, job folders, and smart job groups.
Note
When you copy and paste a job, all scheduling information is removed from the job
that is pasted.

Properties and jobs
Properties and jobs

When defining jobs, you can use properties to assign characteristics to those jobs. For
example, you might want to associate a trouble ticket number with jobs. Or, you
might want to flag certain Audit Jobs as being those from which BMC BladeLogic
Decision Support for Server Automation obtains data. Such properties are stored in
the Job built-in property class in the Property Dictionary.
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.
About job priorities

You can use the PRIORITY* property to mark a job, or a class of jobs, with a
relatively higher priority to ensure they are executed first in case of resource contention.
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.
However, it is important to note that Job Priority is not an absolute execution

ordering mechanism, but rather a resource allocation strategy between jobs; it
ensures that in case of resource constraints and conflicts a job with a higher priority
would be initiated first.
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

Managing jobs through the Jobs or Servers folder
various places in the BMC Server Automation Console where you can see the job
priority level.
Table 3: Viewing Job priority
Level Where to see priority

Job Type Property Dictionary view and Job Extended Property list
To view and modify the priorities globally for all jobs, refer to the
(extended) PRIORITY* property for Job class
Individual Job Property Dictionary view and Job Extended Property list
The priority of individual jobs can be overridden from its inherited
default by modifying the PRIORITY* property for a specific jobs
Property Set Instance.
Scheduled Job Schedule tab
Change the Priority field of a Job Schedule while creating the Schedule
and while editing an existing Schedule.
Running Job Tasks in Progress view
View the assigned priority level in the Job Priority column.
Click the Modify Runtime Priority to change the execution priority

for a running Job selected from the Progress Status panel.
Job Results Job Results panel
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.
Considerations for a MAS environment

If you have implemented a multiple Application Server environment, see BMC
technical documentation at https://docs.bmc.com/docs/display/bsa82/Working
+with+multiple+Application+Servers for a discussion of job distribution and job
priority in a MAS environment.
Managing jobs through the Jobs or Servers

folder
In the Jobs and Servers folders, you can take the following actions on jobs:

Open a job
Execute a job
Execute a job against specific targets
Execute a job against failed targets
Define a job execution override for a role and user
Execute a job with BMC Remedy ITSM approval
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
1 Find the job by doing one of the following:
Using the Jobs folder, 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 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.
Before you begin
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
2 Right-click the job and select Execute.
Executing a job against specific targets

When executing a job, you can decide that you want the job to execute against a
group of servers that differ from the targets that were specified for the job when it
was defined. Performing this procedure does not modify the existing definition of a
job.
Note
You cannot use this capability to execute a Batch Job if the Batch Job is set up so it
uses target servers defined in individual jobs.
Executing against specific targets is not relevant and cannot be performed for the
following types of jobs: Atrium Import Job, Provision Job, UCS Provision Job,
Upgrade Model Objects Job, Virtual Guest Job, and Virtual Infrastructure Discovery
Job. Advanced Deploy Jobs are also not supported for executing against specific targets.

Before you begin
Ensure that you have, at minimum, Read, Execute, and ModifyTargets

authorizations for the job. For example, to execute an Audit Job, you must have, at
minimum, AuditJob.Read, AuditJob.Execute, and AuditJob.ModifyTargets.
To execute a job against specific targets
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.
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.
4 Click OK to execute the job immediately.
Executing a job against failed targets

Use this procedure to execute a job against servers where a job has previously failed.
Performing this procedure does not modify the existing set of targets in a job
definition. Instead, it lets you rapidly choose servers where errors or warnings (or
both) have occurred and then run the job again on that group of targets. Using this
procedure, you can iteratively perform a job and correct issues with target servers
until the job succeeds on all target servers.
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.
Before you begin
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.
To execute a job against failed targets
Using the Jobs folder, navigate to a job, right-click it, and select Show Results.

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.
3 From Servers, select one of the following:
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.
Defining a job execution override for a role and user

BMC Server Automation lets you give other role:user combinations the ability to
execute a job as if your own role and user were actually executing the job. This
capability is particularly useful if you want to set up a job that includes functionality
that other roles and users should not normally be granted permission to perform.
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.
If an execution override is already defined for a job and another role:user

combination makes updates to the job, the override is removed. (A message warns
you before the execution override is removed.) For example, suppose a role:user
combination of BLAdmins:BLAdmin sets up a job and then sets up an execution
override so that when the job executes, it executes as BLAdmins:BLAdmin. If
another role:user combination such as BLAdmins:JrAdmin modifies the job, after the
job is saved, when BLAdmins:JrAdmin schedules the job, it executes as
BLAdmins:JrAdmin. If the job requires the permission of BLAdmins:BLAdmin for
successful completion, the job will fail.
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.

To define a job execution override
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.
To clear an existing override, click C lear Execution Override.

In the future, the job will execute as the role:user combination that schedules
the job.
Alternatively, if you modify a job on which an execution override has been
previously set and you do not set up another execution override, the existing
execution override is removed.
Executing a job with BMC Remedy ITSM approval

The BMC Server Automation administrator may have specified that a given job type
requires BMC Remedy ITSM approval prior to execution. When you create a job
requiring approval, you are prompted to select the approval type and enter the
approval parameters when you configure the schedule.
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.
To specify approval type for BMC Remedy ITSM
1 Access the appropriate dialog box box or panel for specifying approval type. This
happens in the following scenarios:

When triggering immediate execution of a job, regardless of how you choose to

execute the job (for example, by selecting the Execute Now check box in a job
creation wizard or by right-clicking an existing job and selecting Execute ), if
BMC Remedy ITSM approval is required, the Enter approval information
dialog box box is displayed.
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.
Table 4: Approval types for BMC Remedy ITSM
Option Use when
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.
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.
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.
3 Enter the additional information that is used in the change request.
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 Create new Change Ticket.
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:
an approved but unused change ticket
a change ticket with a task that contains the required operational

categorizations and is approved in BMC Remedy ITSM. In this case, ensure
that the task has the following organizational tiers:
Organizational tier 1: Operator Initiated Change
Organizational tier 2: BMC BladeLogic
These categorizations are required for BMC Atrium Orchestrator to process

the alert generated by the ticket. If you are using the default change and task
templates that are installed by the BMC Atrium Orchestrator Content
Installer or as part of the BMC Continuous Compliance for Server
Automation solution, the categorization tiers are set automatically.
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.
Where to go from here
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.
Verifying a job with BMC Remedy ITSM approval

After the definition of a job with BMC Remedy ITSM approval is completed, BMC
Server Automation schedules the job and requests that a new change request be
created in BMC Remedy ITSM. The new change request is created using a specific
change template and includes one task, even if the job has multiple targets. The
change request ID and task ID are sent to the BMC Server Automation system and
the values are attached to the job schedule. The servers that have been specified as
targets are associated to the change and task requests as configuration items (CIs).
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.
To check job schedule through the job definition
1 Right-click the job in the Jobs folder, and select Open.
2 Click the Schedule tab.
The job schedule log makes it easy to see:
when the job has been approved and is waiting to run
if the attempt to schedule the job has failed (for example, failed to create or
update the change ticket)

Managing jobs in progress
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:
Specified change request ID or task ID do not exist
Specified change request ID or task ID are not related
Status of the change request or task in BMC Remedy ITSM is set to Closed or
Completed

The Tasks in Progress view lets you see and manage jobs that are currently
executing. All jobs execute in the background. While they are executing, you can use
the Tasks in Progress view to view, obtain information about, and cancel or abort
jobs. If a job fails, the Tasks in Progress view shows the failed job until you delete it.
Double-clicking on the job shows any error messages.
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.
Before you begin
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.
To cancel or abort jobs in progress
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 .
3 In the displayed message, click either Cancel or Abort.

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.
To pause and resume jobs in progress
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 the other non-critical jobs
pause your Deploy Job and change the runtime priority to HIGH
resume your Deploy Job
resume the other jobs after your job has completed
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 .
3 If desirable, click Modify Runtime Priority to change the execution priority

for the job.
4 When ready, click Resume Execution to resume the job.

To close the Tasks in Progress view
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.
Information in the Task in Progress view

The Tasks in Progress view provides various information about the jobs that are
executing in the background.
Table 5 on page 623 presents the information provided in the Tasks in Progress
view for each task in progress.
Table 5: Information in the Tasks in Progress view
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.

Execution Tasks for managing job runs
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.

An Execution Task is a job-management object that you can associate with an
individual job to keep track of its multiple job runs. The Execution Task grants you
control over the execution schedule, the choice of target servers, and the values of job
properties for the relevant job runs without modifying the definitions of the original
job.
An Execution Task is especially useful when you want to
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.
Creating an Execution Task while executing a job against

failed targets
You can request the creation of an Execution Task when you execute a job against
failed targets. This method of creating an Execution Task is the most appropriate
when you are resolving problems that caused a job to fail on certain targets and are
working towards successful job execution on all target servers.

An Execution Task created in this manner is automatically associated with the

selected job, which is executed immediately. Target servers for the Execution Task
include only the failed targets of the job, and no additional schedules are defined.
These Execution Task settings can be modified only after the Execution Task has
been created and the job has executed.
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.
Creating and defining an Execution Task manually

Creation of an Execution Task separately from the execution of its associated job
enables you to define all Execution Task settings before execution. This method of
creating an Execution Task is especially useful if you want to define schedules,
choose target servers, or set job property values for the Execution Task that differ
from the original job settings. During the creation of 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. You can
also use recurring schedules to execute the job repeatedly on targets where it failed
until its successful completion on all targets.
Before you begin
Ensure that you have, at minimum, the ExecutionTask.Create authorization.
To create an Execution Task manually

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.
2 Define the Execution Task, as described in the following sections:
Execution Task General on page 626
Execution Tasks Targets on page 627
Execution Tasks Job Properties on page 627
Execution Tasks Schedules on page 628
Execution Tasks Properties on page 632
Execution Tasks Permissions on page 632
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.
Execution Task General

The General panel lets you provide information that identifies an Execution Task.
Field Definitions
Name
Identifying name.
Description
Save in

Job Selection
The job with which to associate the Execution Task.
Click Browse , and select a job in the displayed dialog box.
If you accessed the Create New Execution Task wizard through a specific job,
that job already appears as the associated job.
Execution Tasks Targets

The Targets panel lets you specify the targets for the Execution Task.
Do one of the following:
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.
Execution Tasks Job Properties

In the Job Properties panel you can choose to override job properties with different
values for use by the Execution Task, without affecting the properties of the original
job.
Use the following screen elements to override job properties:
Override the following job properties
Select this check box to enable the overriding of job properties.
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.
Execution Tasks Schedules

The Schedules panel lets you define any number of schedules for running the
Execution Task. These Execution Task schedules do not affect the scheduling of the
original job.
You can use any of the following options:
Request automatic creation of schedules based on the nearest maintenance

windows (defined as ACL policy time windows) for the various servers that you
selected for the Execution Task, by clicking Set to nearest maintenance window
. Note that each of these automatically created schedules will typically be
associated with a different group of target servers. All remaining target servers
with no associated time window are scheduled to execute immediately.
Add a new schedule by clicking New Schedule or modify an existing

schedule by selecting it and clicking Edit Schedule .
In the Add New Schedule window or Modify Schedule window that is displayed,
use the tabs to provide the following categories of information, and then click OK.
Execution Tasks Schedule tab on page 629
Execution Tasks Scheduled Job Notifications on page 631

Execution Tasks Scheduling on page 632
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).
Delete an existing schedule by selecting it in the list and clicking Remove

Schedule .
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.
Execution Tasks Schedule tab

The Schedule tab lets you schedule the job that the Execution Task controls so that it
can run once or recur on an hourly, daily, weekly, monthly, or on an arbitrary time
interval. With the Schedule Till Completion option, 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).
The Schedule tab has the following fields and controls:
Once
One-time scheduling of the job.
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
Recurring schedule based on days of the week.
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
Recurring schedule based on a time interval that you define.
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.
Schedule Till Completion
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
The time zone in which the job should run.
For a recurring schedule, 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.
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.
Send email to
Send SNMP trap to


Execution Tasks Scheduling

The Schedule Servers tab enables you to limit the schedule to a subset group of
target servers (out of all target servers defined in the Execution Task). In this manner
you can define separate schedules for different target servers.
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.
Execution Tasks Properties

The Properties panel provides a list of properties automatically assigned to the
Execution Task. You can modify the value of any properties in this list that are
defined as editable. The default list of properties assigned to an Execution Task is
determined by the Execution Task built-in property class in the Property Dictionary.
inherited.
Property .
Execution Tasks Permissions

Through the Permissions panel you can define permissions for the Execution Task.
The Permissions panel is an access control list (ACL) granting roles access to the
Execution Task.


this object.
you want to add.

Modifying Execution Task definitions

After the creation of an Execution Task, you can modify its definitions at any time.
This is especially useful if the Execution Task was created automatically upon
request during the execution of a job against failed targets.

Before you begin
Ensure that you have, at minimum, the ExecutionTask.Read and the

ExecutionTask.Modify authorizations. Depending on the exact modifications that
you perform on the Execution Task, you might also need the
ExecutionTask.ModifyProperties, ExecutionTask.ModifySchedule, and
ExecutionTask.ModifyTargets authorizations.
To modify execution task definitions
1 Open the Jobs folder and navigate to an existing Execution Task. Then do any of
the following:
To modify the definitions of an existing Execution Task (not including

properties and permissions), right-click the Execution Task and select Open.
The content editor displays the following tabs that correspond to the panels
displayed when creating a new Execution Task. The following sections describe
those tabs:
Execution Task General on page 626
Execution Tasks Targets on page 627
Execution Tasks Job Properties on page 627
Execution Tasks Schedules on page 628
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.
To see or modify any of the properties, permissions, or audit trail information

that apply to this Execution Task, select the Execution Task and then select the
Properties, Permissions, or Audit Trail tab group.
2 To save your revisions to the Execution Task, click Save .

Executing a job through an Execution Task

When you execute an Execution Task, you are actually executing the job with which
the Execution Task is associated at the target servers defined through the Execution Task.
You may want to execute an Execution Task immediately rather than wait for the
next scheduled execution, in which case you can choose between executing the job
against all target servers defined in the Execution Task or executing the job against
failed targets only.
Before you begin
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 a job through an Execution Task
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.
Viewing job run information through an Execution Task

The Execution Task concentrates information about the relevant job runs as they
progress towards the successful completion of the job on all target servers.

To view information for the Execution Task and all its job runs
1 Right-click the Execution Task and select Show Results.
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:
StatusOverall current status of job at this target server
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.

Viewing history for a job
Removing a job run from Execution Task display

You may want to remove a job run from the display of an expanded Execution Task
if the job run does not provide any new information or if early job runs executed
against a large number of target servers and you no longer need information for all
these servers.
To remove a job run from Execution Task display
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.
Viewing history for a job

BMC Server Automation saves a history for each job, with information about each
and every job run.
To view history for a job
Using the Jobs folder, navigate to a job, right-click it, and select Show Results.
Audit Results or Snapshot Results tab to navigate to Snapshot or Audit Jobs
that have run on this server.
2 Expand the job for which you want to view history.
All runs of the job and their outcome display beneath the job.
3 To show the servers affected by a job, expand a job run.

Viewing job activity
Viewing job activity

The Activity node under every server shows jobs that have executed on that server
during a particular period of time. Filtering options allow you to display different
combinations of jobs, such as all Snapshot Jobs run during the last week or Audit
Jobs run during the last 90 days. If needed, the Activity node provides a sequential
view of all jobs run on a server. It also shows a jobs definition and all log messages
pertaining to each job run.
To view job activity
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.
3 If necessary, sort jobs in ascending or descending order by clicking on the header

for any column of information in the content editor.
Viewing the status of a job

After a job has been submitted, you can check the status of the job at any time to see
if the job succeeded, failed, or is waiting to execute.
To check job status
1 Open the Jobs folder.
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
YellowCompleted with Warnings
RedCompleted with Errors
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
Connection Timed Out
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.
Status types for change management approval jobs

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 in the Tasks in Progress view until the
approval notification is received. When the approval is received, the job is executed
automatically (for Execute now) or at the scheduled time (for scheduled jobs).
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 schedule has been rejected by BMC Remedy ITSM.
The job failed to create the BMC Remedy ITSM change ticket when the schedule
was created and saved.

Viewing the job definition of a job run
The job was canceled while in Waiting for approval state.
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.
Viewing the job definition of a job run

You can display the definition of a job that has been run. All data displayed in a job
definition is read-only.
To display the definition of a job run
Audit Results or Snapshot Results tab to navigate to a Snapshot or Audit Job.
Expand the job to display the job runs.
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.

Managing job logs
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.
3 Select tabs on the window to display different panels of information.
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.
Managing job logs

The messages generated by a job are stored in a log that you can access after the job
has run.
You can:
View all messages generated for an entire run of a job or only those messages
pertaining to a specific server.
Filter the log to show specific types of job results.
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.
To view a job log
Audit Results or Snapshot Results tab to navigate to a job. Expand the job to
display the job runs.
2 Select a run of a job, right-click, and select Show Log.

Managing job logs
A window displays log messages generated by the job.
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.
6 Click Close to close the log messages window.
To export a job log
Audit Results or Snapshot Results tab to navigate to a job. Expand the job to
display the job runs.
2 Select a run of a job, right-click, and select Export Log.
The Export Results dialog box opens.
3 Specify the location where you want to store the exported results.
4 For Object Name, provide a file name.
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.

Viewing job schedules
Viewing job schedules

You can view information about jobs scheduled for execution in the future through a
list of scheduled jobs in the Job Schedules view. If you are logged in as BLAdmin,
you can see all jobs for all roles in the BMC Server Automation system. Otherwise,
you see the jobs for which your role has Read permission.
To view job schedules in a list
1 Select Configuration => Job Schedules View.
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
Next run time
Role of user who executed the job
Name of user who executed the job
Defining time-outs for jobs

By defining time-out values for jobs or parts of jobs, you can avoid or resolve issues
that occur if a job encounters an unresponsive or unlicensed server. If you do not use
this procedure to specify a time-out for a job or job part, a slow-running job can
absorb Application Server resources for an extended amount of time, and you may
be unable to determine whether a job is hung.
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.

Defining time-outs for jobs
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.
To define time-outs for a job
In the Jobs folder, navigate to a job, right-click the job and select Show Results.
Audit Results or Snapshot Results tab to navigate to a Snapshot or Audit Job.
2 Right-click the job and select Properties.
The job appears in a tabbed window, in whioch you can view and edit the job
properties.
3 Click the Properties tab.
4 Add time-out properties by doing any of the following:
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.

Setting job priority
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.
For Deploy Jobs, job-level time-out properties only apply to Software

Deploy Jobs, basic BLPackage Deploy Jobs, or advanced BLPackage Deploy
Jobs with phases that run sequentially.
Because undo jobs cannot be scheduled, job-level time-outs do not apply to

undo jobs.
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
Configuring+the+Application+Server.
5 To close the job, click OK or Finish.

Assign job priorities to segregate critical jobs from those which are non-critical, and
to ensure jobs with high priority are given preference during execution.
You can set job priority in the following ways:

Globally for each job type (using the PRIORITY* property)
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.
To set job priority for a job type
1 Select Configuration => Property Dictionary View. The Property Dictionary opens.
2 Expand the job built-in property class.
3 Navigate to the job type for which you want to set the job priority.
4 Select the PRIORITY* property and click Edit Property .
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.
The default value for the PRIORITY* property is NORMAL.
6 Click OK.
To set job priority for a specific job or job instance
1 You can set the priority for a specific job or job instance in any of the following ways.
When creating a job, creating a Job Schedule, or editing an existing Schedule,

you can set the priority for that job using the Priority field on the Schedule tab.
By changing the PRIORITY* property for a job.
By pausing a running job and changing the priority.
To set job priority from the Schedule tab
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.
To set the PRIORITY property for a specific job
1 In the Jobs folder, select a job.
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).
The default value for the PRIORITY* property is NORMAL.
4 Click OK.
To change the priority of a running job
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 .
4 To resume a job, click Resume Execution .

13
Snapshot Jobs
This section describes how to create a Snapshot Job, which records the configuration
of a group of server objects at a point in time.
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.
Using snapshot and change tracking results, you can:
Base an audit on a snapshot.
View changes that occur from one snapshot to another.
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.
Bundle snapshot results into a BLPackage or software package.
Export the snapshot and change tracking results.

Snapshot and audit basics
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.

The types of server objects you can snapshot and audit vary by operating system.
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.
Symbolic links in snapshots and audits

When taking snapshots or performing audits, BMC Server Automation supports
symbolic links at the top level of the file system.
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:
Job definitionInformation such as the job description, schedule, and list of

targeted servers.
Server object informationAttributes of the server objects included in the

snapshot. These server objects are specified by selecting a component template to
use as the basis of a snapshot or manually choosing server objects when you
define the Snapshot Job.
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.

Creating Snapshot Jobs
In short, any change to a Snapshot Job definition or a related component template triggers
rebaselining.

Snapshot Jobs make a record of one or more server configurations at a point in time.
You can base Snapshot Job on components or server objects.
To create Snapshot Jobs based on components
1 To create a new Snapshot Job, do one of the following:
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 Components or Component Templates folder and select a

component. Right-click and select Snapshot.
Snapshot Job.
The New Snapshot Job wizard opens.
2 Define the Snapshot Job, as described in the following sections:
Snapshot Job General on page 653
Snapshot Job Components Templates for Filtering on page 654
Snapshot Job Targets on page 659
Snapshot Job Default Notifications on page 659
Snapshot Job Schedules on page 661
Snapshot Job Properties on page 664
Snapshot Job Permissions on page 664
To create Snapshot Jobs based on server objects
1 To create a new Snapshot Job, do one of the following:

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.

component. Right-click and select Snapshot from the pop-up menu.
Snapshot Job from the pop-up menu.
The New Snapshot Job wizard opens.
2 Define the Snapshot Job, as described in the following sections:
Snapshot Job Server Objects on page 655
Snapshot Job Properties on page 664
Snapshot Job Permissions on page 664
Snapshot Job General

The General panel lets you provide information that identifies a Snapshot Job. It also
lets you select the approach to defining the snapshotby selecting components or
live server objects.
Field definitions
Name
Identifying name.
Description

Save in
Snapshot Job type
Snapshot componentsThe job records information for all components

(specified using templates) which are discovered on the target servers you
specify.
Snapshot server objectsThe job records server objects that you select
from live servers.

Snapshot Job Components Templates for Filtering

The Component Templates for Filtering panel lets you identify the component
templates that form the basis of a snapshot.
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.
Snapshot Job Server Objects

The Server Objects panel lets you identify live server objects that form the basis of a
snapshot. The Server Objects panel is only available when you are basing a snapshot
on live server objects.
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.
Includes and excludes: Specifies server objects to include or exclude from an

audit. 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.
Snapshot/Audit options: Specifies information associated with server objects that

should be compared during an audit. For more information, see Specifying
snapshot options for a server object on page 657.
Selecting server objects

The Server Objects list lets you choose server objects that form the basis of a
Snapshot Job. It also lets you limit the server objects you select, and it lets you choose
the types of object attributes you want to snapshot.
The Server Objects list lets you select any version of a custom configuration object,
Object Dictionary.
To select server objects
1 Using the Server Objects list, perform one of the following actions:
Add a new server object by clicking Add .
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.
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.
The Object appears in the Selected Object list at right.
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.
Specifying includes and excludes

The Includes/Excludes section lets you specify server objects that should be
included or excluded from a collection of server objects.
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.
To specify includes and excludes
1 Select a server object in the Server Objects list and take one of the following
actions:


path.
Select Property .
2 Depending on the content you are specifying, click Include or Exclude.
3 Click OK.
Specifying snapshot options for a server object

The Snapshot/Audit Options section of the Server Objects panel lets you specify
information associated with a server object that should be collected in a snapshot.
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.
To specify snapshot options
1 Select an object in the Server Objects list.
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
information associated with server objects that should be collected during a snapshot.
that may not completely describe their function. There are many additional
attributes that you can select.
ACL Owner
Store the owner of a file or registry key.
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.
Snapshot Job Targets

The Targets panel lets you choose the servers, server groups, components, and
component groups to be included in a Snapshot Job.
If you are basing a snapshot on:
Component templatesThe job takes a snapshot of a component based on those

component templates. For targets, you can select individual components,
component groups, or servers. If you:
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.
Snapshot Job Default Notifications

The Default Notifications panel provides options for defining notifications that are
generated when a job completes.

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

Send email to
Send SNMP trap to

Snapshot Change Notifications

Send email to
Lists email addresses of the accounts to notify if snapshot results change.


sysadmin@bmc.com;sysmgr@bmc.com. After entering email address

Append snapshot change results to email
Indicates emailed notifications should include snapshot changes.
Limits the size of email that is generated by appending audit results. Enter
the maximum size, in kilobytes, in the text box.
Send SNMP trap to
Provides name or IP address of the server to notify about snapshot changes.

After entering server information, check the statuses that cause an SNMP
trap to be generated.
Snapshot Job Schedules

Scheduling a job
information, see Snapshot Job Scheduling on page 663.
a scheduled job runs. For more information, see Snapshot Job Scheduled
Snapshot Job Scheduled Job Notifications

The Scheduled Job Notifications tab lets you generate emails and SNMP traps when
a scheduled job completes. Any notifications defined here override default job
notifications.

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
Send SNMP trap to

Snapshot Change Notifications
Send email to
Lists email addresses of the accounts to notify if snapshot results change.

sysadmin@bmc.com;sysmgr@bmc.com. After entering email address
Append snapshot change results to email
Indicates emailed notifications should include snapshot changes.

Send SNMP trap to
Provides name or IP address of the server to notify about snapshot changes.

After entering server information, check the statuses that cause an SNMP
trap to be generated.
Snapshot Job Scheduling

To schedule jobs
Mean Time.

Snapshot Job Properties


inherited.
Property .
Snapshot Job Permissions

this object.
you want to add.

Modifying Snapshot Jobs


Modifying Snapshot Jobs

The procedure for modifying Snapshot Jobs has minor differences from the
procedure for creating new Snapshot Jobs.
To modify Snapshot Jobs

Snapshot and change tracking results
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 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)
These tabs correspond to panels in the New Snapshot Job wizard. Use them to
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.


After running a Snapshot Job, you can display the snapshot and change tracking
results in tabs in the content editor. The Change Tracking tab only appears if the
Snapshot Job has been run more than once.
Understanding the appearance of snapshot and change

tracking results
The content editor contains a hierarchical tree on the left and the Snapshot and
Change Tracking tab group on the right. The hierarchy tree shows results for each
run of the job. Each run is labeled with the job name, date, and time of each job run.
Each run displays results for each server where the job ran and for the types of
server objects included in the snapshot. You can also view Snapshot Job results when
you browse a server and select the Snapshot Results tab for that server.
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.
Change Tracking provides different types of information, depending on whether

you are using the object view or the server view.
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
Change Tracking provides the following levels of information:
Information level Information displayed
Server view
Component names.
External changes.
Number of failed changes.
Number of changes not attempted.
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 view component Total number of changes, including the number of

items added, the number of items modified, and the
number of items deleted by server object.

Information level Information displayed
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.
Differentiating between internal and external changes

BMC Server Automation attempts to differentiate between changes caused by BMC
Server Automation actions and those caused by external actions. Change Tracking
examines the changes that occur between snapshots. If the changes occur during a
period when Deploy, NSH Script, or File Deploy Job attempts are made, the changes
may be caused by BMC Server Automation activities or by external actions.
However, if no BMC Server Automation activities have occurred during the period,
the changes detected are considered external changes.
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.
Using snapshot and change tracking results

To view snapshot and change tracking results, see Viewing snapshot and change
tracking results on page 669.
After you have displayed snapshot and change tracking results, you can use them to
perform the following tasks:
Differentiate between BMC Server Automation changes and changes made

externally to BMC Server Automation. (See Differentiating between internal and
external changes on page 668.)
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.)
Bundle snapshot results as a BLPackage. (See Bundling snapshot results into a

BLPackage on page 671.)
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.)
Viewing snapshot and change tracking results

The results of a Snapshot Job show the contents of a snapshot. If a Snapshot Job has
run more than once, Snapshot Job results can show change tracking information.
To view snapshot and change tracking results
1 To view snapshot and change tracking results, do one of the following:
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.
Backing out changes

The system lets you remove external changes or all changes, depending upon where
the changes are made.
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.
To back out changes
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.
Viewing changes using the Compare Editor

Using the Compare Editor, you can compare files in a current snapshot to files in a
previous snapshot to see changes. The changes are color-coded to make them easy to
identify.
To view changes using the Compare Editor
1 Right-click a snapshot result and select Compare.
Showing deploy-related job activity

Change Tracking lets you view the File Deploy, Network Shell Script, and Deploy
Job attempts that may have caused changes detected by the current Snapshot Job run.

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.
To show deploy-related job activity
1 Select the Server view, Server view component, Server view component part, or
delta asset level.
2 Right-click and choose Show Deploy Activity.
Bundling snapshot results into a BLPackage

When viewing snapshot results, you can bundle them into a BLPackage.
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.
To bundle snapshot results into a BLPackage
1 Use the Jobs folder to display the results of a snapshot, as described in Snapshot
and change tracking results on page 666.
2 Expand the results of a job run.
3 Expand the Server View node and do one of the following:
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.
Create BLPackage Package Type on page 672
Create BLPackage Package Item Options on page 672
Create BLPackage Package Type

The Package Type panel asks you to identify the BLPackage.
Field Definitions
Package name
Enter a name for the BLPackage you are creating.
Save in
Create BLPackage Package Item Options

BLPackage.
Depot Asset Options
this panel.
definition.

software package.
Note
File Options
Copy file contents
System (NTFS).
Registry Options
Component Options





Adding software to the Depot from snapshot results

When viewing the results of a Snapshot Job, you can easily add software that was
included in the snapshot to the Depot.
To add software to the Depot from snapshot results
1 Use the Jobs folder to display the results of a snapshot, as described in Snapshot
and change tracking results on page 666.
2 Expand the results of a job run.
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.
The Add Depot Software window appears.
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

Exporting results of an audit or snapshot

When viewing Snapshot or Audit Job results, you can export the results to an HTML
or CSV format. For snapshots, you can export both snapshot and change tracking
results.
The export procedure gives you two formatting options:
HTML format, which is suitable for printing or viewing with a web browser
Comma-separated value (CSV) format, which can be imported into databases or

spreadsheets.
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.
To export results of an audit or snapshot
1 Access audit, snapshot, or change tracking results.
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.
3 Right-click and select one of the following:
Export Snapshot Results
Export Change Tracking Results
Export Results (for Audit Job results)
The Export Results dialog box appears.
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.

14
Audit Jobs
Audit Jobs allow you to compare servers or snapshots to determine if their
configurations match a standard configuration.
Audit Job overview

Audit Jobs allow you to compare servers or snapshots to determine whether their
configurations match a standard configuration.
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.
Creating Audit Jobs

Audit Jobs allows you to compare components, servers, or snapshots to determine
whether their configurations match a standard configuration. You can base audits on
components or server objects.
Performing an audit based on components requires you to identify a masterthat is,

one or more components or snapshots that act as a master.

Creating Audit Jobs
To create an Audit Job based on components
1 Begin defining an Audit Job by doing any of the following actions:
Open the Servers folder and select a server. Right-click and select Audit from
the pop-up menu.

component. Right-click and select Audit from the pop-up menu.
Open the Jobs folder, right-click a job folder, and select New => Audit Job
2 Define the Audit Job, as 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 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
3 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.
To create an Audit Job based on server objects
1 Begin defining an Audit Job by doing any of the following actions:
Open the Servers folder and select a server. Right-click and select Audit from
the pop-up menu.

component. Right-click and select Audit from the pop-up menu.
Open the Jobs folder, right-click a job folder, and select New => Audit Job
2 Define the Audit Job, as described in the following sections:

Creating Audit Jobs
Audit Job Server Objects on page 681
Audit Job General

The General panel lets you provide information that identifies an Audit Job. It also
lets you choose the basis for the Audit Jobeither components or live server objects.
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.

Creating Audit Jobs

Audit Job Component Templates for Filtering

The Component Templates for Filtering panel lets you identify the component
templates that form the basis of an audit.
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.

Creating Audit Jobs
Audit Job Masters

The Masters panel requires you to choose a component or snapshot that will
function as a master. If the Audit Job consists of multiple component templates, you
must choose a master (either a component or snapshot) for each template.
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.
To use a component as a master, select an instance of a component on a server.
To use a snapshot as master, expand an instance of a component, then expand the

Snapshots node, and finally select the run of a snapshot job that should serve as a
master.
Click OK. The Master Entries list shows the master you have selected for a particular
component template.
Audit Job Server Objects

The Server Objects panel lets you identify live server objects that form the basis of an
audit. It also lets you limit the server objects you select, and it lets you choose the
types of object attributes you want to audit.
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.

Creating Audit Jobs
Server objects
Specifies the server objects that should be audited. For more information, see
Selecting master and server objects on page 682.
Includes and excludes
Specifies server objects that should be included or excluded from an audit.

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.
Snapshot/Audit options
Specifies information associated with server objects that should be compared

during an audit. For more information, see Specifying audit options for a
server object on page 684.
Selecting master and server objects

The Master option lets you choose the mastereither a live server or snapshoton
which you are basing an audit. After choosing a master, you can select the server
objects you want to audit.
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,
Object Dictionary.
To select master and server objects
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:
Add a new server object by clicking Add .
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.

Creating Audit Jobs
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.
New . The New Server Object dialog box opens. Use the dialog box to
specify a server object by browsing or entering its path.
The object appears in the Selected Object list at right.
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.
Specifying includes and excludes

The Includes/Excludes section lets you specify server objects that should be
included or excluded from a collection of server objects.
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.
To specify includes and excludes
1 Select a server object in the Server Objects list and take one of the following
actions:


Creating Audit Jobs

path.
Select Property .
2 Depending on what you are specifying, click Include or Exclude.
3 Click OK.
Specifying audit options for a server object

information associated with a server object that should be included in an audit.
To specify audit options
1 Select an object in the Server Objects list.
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
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.

Creating Audit Jobs
that may not completely describe a function. Many additional attributes can be
selected besides the attributes listed below.
Account Disabled
Compare the status of user accounts.
ACL Owner
Compare the owner of a file or registry key.
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
Compare users language of choice.
Contents
Compare file content when performing an audit based on a snapshot of file

content.
Effective Setting as String Value
Compare the effective value of security settings.
Full Name
Compare users full names.
Group members
Compare the groups belonging to a Local Group.
Group owner
Compare a files group ID.

Creating Audit Jobs
Home Directory Drive
Compare the home directories of user accounts.
Home Path
Compare the home paths of user accounts.
Compare whether an object inherits access control entries in the System

Access Control List (SACL) from its parent object.
Compare whether an object inherits access control entries in the

Discretionary Access Control List (DACL) from its parent object.
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.
Local Setting as String Value
Compare the value of security settings defined for each server.
Login Script
Compare the login script for user accounts.
Logon Server
Compare users logon server.
Max Size
Compare the maximum size of event logs.
Member of
Compare the groups to which users belong.
Permission ACL
Compare 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.

Creating Audit Jobs
Permissions
Compare the permissions assigned to files.
Privilege Level
Compare the privilege level for user accounts.
Profile Path
Compare user profile paths.
Retention
Compare the amount of time event logs are kept.
Size
Compare the sizes of files.
User Expire Date
Compare the dates when user accounts expire.
User members
Compare the users belonging to a Local Group.
User owner
Compare a files user ID.
Version
Compare file version information for DLL, EXE, and other types of files.
Audit Job Targets

The Targets panel lets you choose the servers, server groups, components, and
component groups to be included in an Audit Job.
If you are basing an audit on:
Component templatesThe job audits components based on those component

templates. For targets, you can select individual components, component groups,
component templates, servers, or snapshots based on the component templates. If
you:

Creating Audit Jobs
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.
Audit Job Default Notifications

notifications. Default notifications can also provide information about Audit Job
results.
that are generated based on the results of an Audit Job. You can send notifications
when targets have consistent configurations, inconsistent configurations, or both.

Send email to

Creating Audit Jobs
Send SNMP trap to

Audit Results Notifications

Send email to
Append audit results to email
Indicates emailed notifications should include audit results.
Send SNMP trap to
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.
Audit Job Schedules


Creating Audit Jobs
Scheduling a job
daily, weekly, or monthly, or recur at an interval. For more information, see
Audit Job Scheduling on page 691.
a scheduled job runs. For more information, see Audit Job Scheduled Job
Notifications on page 690.
Audit Job Scheduled Job Notifications

completes. It also lets you send notifications that indicate whether the targets being
audited have consistent configurations, inconsistent configurations, or both.
Send email to
Send SNMP trap to


Creating Audit Jobs
Audit Results Notifications
Send email to
Append audit results to email
Indicates emailed notifications should include audit results.
Send SNMP trap to
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.
Audit Job Scheduling

To schedule jobs

Creating Audit Jobs
Mean Time.
Audit Job Properties


inherited.
Property .

Creating Audit Jobs
Audit Job Permissions

this object.
you want to add.



Modifying Audit Jobs
Modifying Audit Jobs

The procedure for modifying Audit Jobs has minor differences from the procedure
for creating new Audit Jobs.
To modify an Audit Job
To modify the definition of an existing Audit Job, open the Jobs folder and
following sections:
Audit Job Component Templates for Filtering on page 680
Audit Job Masters on page 681
Audit Job Server Objects on page 681
These tabs correspond to panels in the New Audit Job wizard. Use them to
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.

Audit Job results

Audit results compare the master (which can be a server, snapshot, or component) to
other hosts, including hosts in other snapshots.

Audit Job results
Displaying audit results

After running an Audit Job, you can display results in a tab in the content editor. The
tab contains a hierarchical tree that shows results for each run of the job. Each run
displays results for each server where the job ran and the types of server objects
included in the audit. You can also view Audit Job results when you browse a server
and select the Audit Results tab for that server.
You can view audit results in the following ways:
Viewing audit results by object on page 697
Viewing audit results by server on page 698
Viewing differences between text files on page 701
Understanding the layout of audit results

The left side of the audit results tab displays a hierarchical listing of the contents of
the audit. You can select nodes labeled Object View and Server View to view audit
results from different perspectives.
If you expand the:
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.

Audit Job results
Using audit results

Using audit results you can do any of the following:
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.
Package audit results. (See Packaging audit results on page 706.)

The BLPackage that this procedure generates includes an XML instruction file
specifying which server objects need to be added, replaced, or deleted on the
target server. The BLPackage also includes all necessary server objects.
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.)
Caveats about audit results

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.
To ensure that servers have consistent patch configurations, BMC recommends

you use the systems built-in patch analysis capabilities (see Patch management
on page 1019). If you choose to run an Audit Job on Windows hotfixes, be aware
of the following:
Audit results of Windows hotfixes can be misleading if you are auditing

dissimilar servers, such as servers running different operating systems or
servers configured with different software applications. For example, if an
application such as SQL Server is installed on the master but not on the target,
the master server shows the presence of patches for SQL Server that are not
present on the target server.

Audit Job results
If a service pack is missing from a target servers recommended patch

configuration, audit results show a missing service pack for that target server
even though the master server might also be missing the same service pack.
Viewing audit results by object

Audit Job results can let you see which servers have a configuration that is
inconsistent with server objects on the master server.
For example, you can select the Services server object and see which servers have
Windows services configured inconsistently with the master server.
To view audit results by object
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
Name Name of the Audit Job and the master server.
Compliant Total number of servers that are consistent with the

master.
Non-compliant Total number of servers that are inconsistent with

the master.
Failed Total number of objects for which the attempt to

evaluate consistency failed on at least one target.
Not Attempted Total number of objects for which consistent

evaluation was not attempted on at least one target.
Changes Total number of objects that have differing

characteristics between the master and at least one
target.
Extra Total number of objects that are not present on the

master but are present on at least one target.

Audit Job results
Column Description
Missing Total number of objects that are present on the

master but are missing on at least one target.
3 To view object-by-object summaries, expand the tree under Object View and
select a component.
If you are performing a server-object based audit, components are named

according to the name of the Audit Job.
The right panel shows summary results for the component, as described in the
following table.
Column Description
Name Name of the component or Audit Job on which the

audit is based.
# of Consistent Targets Total number of servers for which this object is

consistent with the master.
# of Inconsistent Targets Total number of servers for which this object is

inconsistent with the master.
# of Failed Targets Total number of servers for which the attempt to

evaluate consistency for this object failed.
# of Not Attempted Targets Total number of servers for which no attempt was
made to evaluate the consistency of this object.
4 To see a server-by-server listing showing the consistency for a particular object,

expand the tree under Object View and select a server object.
The right panel lists all the targets for the job and indicates whether they are
consistent.
Viewing audit results by server

Audit Job results can let you determine if a server object is consistent with a
corresponding server object on the master server.
For example, you can select a directory to see files in the directory that are
inconsistent with the master server.

Audit Job results
To view audit results by server
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
Name Name of the Audit Job and the master server.
Compliant Total number of objects on all targets that are not

compliant with the master.
Non-compliant Total number of objects that are inconsistent between

the master and at least one target.
Failed Total number of objects for which the attempt to

evaluate consistency failed on at least one target.
Not Attempted Total number of objects for which consistent

evaluation was not attempted on at least one target.
Changes Total number of objects that have differing

characteristics between the master and at least one
target.
Extra Total number of objects that are not present on the

master but are present on at least one target.
Missing Total number of objects that are present on the

master but are missing on at least one target.
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
Name Name of the job and the master.

Audit Job results
Column Description
Changes Total number of objects present on both the master

and this target but for which there are some
differences in characteristic values.
Extra Total number of objects present on this target but not

on the master.
Missing Total number of objects present on the master but

missing on this target.
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
Name The name of the object.
Changes If the value is nonzero, the object is present on both

the master and target but there are some difference
in characteristic values.
Extra If the value is nonzero, the object is present on this

target but not on the master.
Missing If the value is nonzero, the object is present on the

master but missing on this target.
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.

Audit Job results
7 Depending on the type of server objects you are auditing, you may be able to do
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.
If you are comparing registry values of type REG_MULTI_SZ (values that

accept multiple entries), you can compare those entries by selecting the registry
value and then clicking the Values tab in the detail pane. The tab provides
information comparing master and host entries for the selected registry value.
Viewing differences between text files

Audit Job results can let you display the differences between a text file on the master
and a target.
For example, you can select a directory to see if files in that directory are inconsistent
with the master server.
Before you begin
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.
To view differences between text files
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.

Using audit results to synchronize servers
Differences between the files are highlighted. The colors used for highlighting are
determined by setting user preferences.
The comparison uses the following graphical aides:
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.
A highlighted line in the target shows the location of an addition.
4 Using the buttons on the Audit Compare window, display the first, last, next, or
previous difference detected between files.
Audit results for configuration files

In some situations, when auditing configuration files that contain multiple name/
value pairs with the same name, the system may treat each name/value pair as a
separate entry if it cannot clearly define the entrys primary key.
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.

Audit Job results can be used to synchronize the configuration of audited servers to
match the configuration of the master.
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.

After creating the BLPackages or software packages, the system automatically

creates one Deploy Job to deploy each unique collection of files or applications. If a
synchronization creates multiple Deploy Jobs, this procedure automatically
consolidates those Deploy Jobs into one Batch Job so the entire synchronization can
be launched as one job.
To use audit results to synchronize servers
1 Display the results of an audit using the Server View.
For more information, see Viewing audit results by server on page 698.
2 Using the Server View, take one of the following actions:
Synchronize all target servers by right-clicking the master server and selecting
Sync all targets with master.
Synchronize one server by navigating to that server, right-clicking, and

selecting Sync 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.
A wizard for synchronizing target servers appears.
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.
Sync Sync Details on page 704
Sync Package Item Options on page 705

If the job requires software executables to be installed, uninstalled, or both, and

there are no matching software packages for those executables stored in the
Depot, the Select Matching Software window appears.
5 If the Select Matching Software window is displayed, match each software

executable listed in that window to software stored in the Depot. If necessary, you
can add software packages to the Depot with this process.
For more information, see Matching software with depot items on page 507.
One of the following results occurs:
If you are synchronizing multiple servers and multiple BLPackages or software

packages are being deployed, a New Batch Job wizard appears. The Batch Job is
defined to run all the Deploy Jobs needed to synchronize the target servers.
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.
Sync Sync Details

The Sync Details panel asks you to give the synchronization job a name and to
specify where to store the BLPackages and jobs that the wizard generates.
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.
Save sync/deploy job in
Click Browse and navigate to the job group where you want to store the
Deploy Jobs and the Batch Job generated by this procedure.

Sync Package Item Options

BLPackage.
Depot Asset Options

this panel.
definition.
software package.
Note
File Options
Copy file contents
System (NTFS).

Packaging audit results
Registry Options
Component Options




Audit Job results can be used to create a BLPackage containing the differencesor
deltabetween a target server and a master configuration. For each target server,
you can package the delta for a particular component or server object or for all
components and server objects included in the audit.
To package audit results
1 Display the results of an audit using the Server View.

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.
A wizard for packaging audit results apperars.
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.
Package Delta Package Type on page 707
Package Delta Package Item Options on page 708
Package Delta Package Type

The Package Type panel asks you to identify the BLPackage.
Field Definitions
Package name
Enter a name for the BLPackage you are creating.
Save in

Package Delta Package Item Options

BLPackage.
Depot Asset Options

this panel.
definition.
software package.
Note
File Options
Copy file contents
System (NTFS).

Grouping noncompliant servers
Registry Options
Component Options



Grouping noncompliant servers

Audit Job results let you group servers with configurations that do not comply with
an audit.
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.

To group noncompliant servers
1 Display the results of an audit using the Object View.
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
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.

When viewing Snapshot or Audit Job results, you can export the results to an HTML
or CSV format. For snapshots, you can export both snapshot and change tracking
results.
The export procedure gives you two formatting options:
HTML format, which is suitable for printing or viewing with a web browser
Comma-separated value (CSV) format, which can be imported into databases or

spreadsheets.
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.
To export results of an audit or snapshot
1 Access audit, snapshot, or change tracking results.
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.
3 Right-click and select one of the following:
Export Snapshot Results
Export Change Tracking Results
Export Results (for Audit Job results)
The Export Results dialog box appears.
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.


15
Software and BLPackage Deploy
Jobs
This section describes Software Deploy Jobs and BLPackage Deploy Jobs. You can
use these types of jobs to deploy software packages or BLPackages to one or more
target servers or components. BMC documentation uses the generic term Deploy Job
to describe functionality that applies to both Software and BLPackage Deploy Jobs.
Software and BLPackage Deploy Job overview

BMC Server Automation provides two types of jobs for deploying packages.
Software Deploy JobDeploys software packages to one or more target servers or

components.
BLPackage Deploy JobDeploys a BLPackage to one or more target servers or

components.
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 uninstall software packages, create an uninstall job, which is a Software Deploy

Job that pushes a software package to servers where the uninstall should occur and
then runs an uninstall command. (The software package does not necessarily have to
include source files for the software if you have defined a network-based location for
those source files.) You can control the flow of an uninstall job just as you would a
Software Deploy job, and you can retry and undo an uninstall job.
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.

Phases of a Deploy Job

A BLPackage Deploy Job has three phases: Simulate, Staging, and Commit. A
Software Deploy Job only has two phases: Stage and Commit.
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.
The contents of a packaging directory are:
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
where agentInstallDirectory is the directory where the agent is installed, Transactions

is a directory used to store rollback information, and rollback is a directory created for
a particular job. For each instruction that acts on a target, the Deploy Job makes a
copy in the rollback directory of the original object that the job acts on. For example,
for each file that is replaced, the Deploy Job copies the original file to the rollback
directory. These copies are used to roll back the Deploy Job and restore the server to
its original state. For software packages, a Deploy Job provides the choice of not
storing rollback files, as they are not always needed to undo a deployment. Rollback
files remain on a target server until you actually roll back a deployment or you
manually remove them.
Files in the Transactions directory can become large. BMC Server Automation
provides a mechanism for storing most transaction information in an alternate

Deploy Job states
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.
Deploy Job states

When a Deploy Job executes, the system classifies each run of a job as being in a
particular state.
A Deploy Job can be classified as having any of the following states:
SuccessThe job has been applied to all target servers or components.
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.
ResetA state that can be assigned to an incomplete job so it can be executed

again. When you revise the definition of a job that is in an Incomplete state, the
job is automatically changed to a Reset state.
RunningProcesses relating to the job are running.
FailedThe job failed due to unusual circumstances, such as a server crash. A job
in a Failed state can be re-executed or reset.
Deployments to agentless managed objects

BMC Server Automation can support objects that do not have an RSCD agent
installed, such as an IBM frame. BMC Server Automation calls these objects agentless
managed objects (AMOs).
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.

Basic and advanced BLPackage Deploy Jobs
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.
When running Deploy Jobs on agentless devices, be aware of the following:
Deploy Jobs ignore reboots on agentless devices.
Deploy Jobs ignore pre- and postcommands on agentless devices.
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.
Only a custom configuration object that is used to communicate with agentless

devices should be used in packages deployed to agentless devices. Including more
than one such custom configuration object in a job causes the job to fail.
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.
Basic and advanced BLPackage Deploy Jobs

When you begin defining a BLPackage Deploy Job, you must choose a basic or
advanced approach.

Creating a Deploy Job
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.

You can create a Software Deploy Job, which deploys Windows or UNIX software
packages to one or more target servers or components. You can also create a
BLPackage Deploy Job, which deploys a BLPackage to one or more target servers or
components. Both are referred to as Deploy Jobs.
Before you begin
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.
To create a BLPackage Deploy Job
1 To create a BLPackage Deploy Job, do one of the following:
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.
Using the Component Templates, Components, or Servers folder, select one or

more components. Right-click and select Deploy as Target from the pop-up

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:
Deploy Job General on page 722
Deploy Job Package on page 724
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
Deploy Job Properties on page 750
Deploy Job Permissions on page 752
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 create a Software Deploy Job
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.
1 To create a Software Deploy Job, do one of the following:
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.
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.

executable listed in the window to software stored in the Depot. If necessary, you
can add software packages to the Depot with this process. For more information,
see Matching software with depot items on page 507.
3 Provide information for the Deploy Job, as described in the following sections:
Deploy Job Software on page 724

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.
Caveats for deploying BLPackages

When deploying a BLPackage, there are many issues you should consider first.
To deploy a BLPackage, 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:
information about Windows user mapping, see Creating automation
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.
When deploying to an agent that is running an earlier release of BMC Server

Automation, the Deploy Job can complete successfully even though the agent may
not recognize the server objects being deployed. This typically happens when a

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 a BLPackage is based on an audit of Windows local user information, you

cannot deploy values for the last logon date and last password change date.
Limitations exist when deploying BLPackages based on Windows security

settings. For more information, see Limitations for Windows security settings
on page 753.
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.
When deploying a BLPackage to a server using SELinux, the server must be

configured to allow deployment commands. When you install an RSCD agent on
Linux machines, the installation program gives you the option of setting up the
appropriate SELinux configuration. If you did not choose this configuration
during installation, deployment of BLPackages will fail. See BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Installing for
details on the specific commands needed to enable asset deployment.
Deploy Job General

The General panel lets you provide information that identifies a Deploy Job.
Field Definitions
Name
Identifying name.
Description
Save in



Note
If you are running an advanced Deploy Job and you are executing Phases of a
Deploy Job on page 714 separately, the job uses the most recent override settings
when each phase executes. For example, consider this scenario:
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).
3 UserA clears the execution override.
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).

Deploy Job Software

The Software panel lets you select the parts of a software package you want to
deploy. You can also change the order in which packages are deployed.
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 .
Deploy Job Package

The Package panel lets you identify the BLPackage you want to deploy. If the
BLPackage includes its own local properties, the Package panel lets you edit them.
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:
Setting a value that always applies for this local property.
Choosing a component property. When the job deploys a BLPackage to a target

component, the job uses the value of the component property as the value for this
local BLPackage property. If you have defined instances for a component
property, the property values set in each instance determine the property values
for each component. Those, in turn, are used to replace the value of local
BLPackage property. For a detailed example showing how to map BLPackage
properties to component properties, see Using properties to deploy multiple
versions of an application to the same server on page 726.
Automatically mapping the local property on the BLPackage to a component

property. For automatic mapping to occur, the name of the local property on the
BLPackage must exactly match the name of the property defined for a component.
If you choose this option and you have defined instances for a component
property, the property values set in each instance determine the property values

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.
AdvancedProvides full flexibility when defining the job. For advanced

BLPackage Deploy Jobs, you can choose to control the flow of the job by server or
phase and schedule execution of each job phase. If the job fails to complete, you
can re-execute it on a server-by-server and phase-by-phase basis rather than have
the job automatically reset.
Field definitions
Package
Choose the package to be deployed by clicking Browse . The Select Depot

Object dialog box opens. Use it to select a package from the Depot.
Properties
To set a value that always applies for a property when deploying the
package to a server, do both of the following:
In the Assignment Type column, select Value from the list.
In the Name/Value column, enter a value. If necessary you can click

Reset property to default value to enter the default value for the
property.
To set a specific value that applies when deploying this package to a

component, do all of the following:
In the Assignment Type column, select Component Property Name

from the list.
In the Name/Value column, enter the name of the component property

that should be used to determine the value for this BLPackage local

property. Alternatively, you can click Browse to open the Component

Property Name Selector. Using it, you can navigate to a component
property.
Required column in Properties table
Set to True if a value for this property is required.
When creating a BLPackage, you can specify if a value for a property is

required. If it is not required at the package level, you can specify if it is
required for this Deploy Job.
If any property in the list requires a value, you must provide the value before
you can complete the panel.
Select Deploy Job Type
Select Basic or Advanced.
Using properties to deploy multiple versions of an

application to the same server
Properties let you deploy multiple versions of an application to the same server.
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.
To manage situations like this, organizations typically set up each instance of an

application as a component. You can define a Deploy Job that applies changes to all
of these applications because one job can be targeted at multiple components.
Setting up your system to deploy to multiple components involves many areas of

functionality in BMC Server Automation. The following example provides a
generalized description of how to set up a component template, discover
components, and then deploy a BLPackage to all of those components.
This example shows how to deploy a configuration file to three instances of an

application at the following locations:
D:\app1
D:\app2
D:\app3

To use properties when deploying multiple version of an application to the

same server
1 Create a component template that encapsulates the application. To accomplish

this, do the following:
a Use the Component Template wizard to create a component template. On the

General panel of the wizard, check the Deploy option so you can deploy
objects to any components based on this component template.
For more information, see Creating a component template on page 359.
b In the component template, create a local property that can be used to define
the path to each instance of the application.
For example, the property might be called TPL_APP_PATH.
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.
For example, the path to the file might be D:\??TPL_APP_PATH??\config.
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.
f Save the component template.
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.
3 Create a BLPackage called app_configuration that contains the configuration file

you want to deploy. To accomplish this, do the following:
a Add the configuration file to the Depot as a BLPackage called

app_configuration.
b Open the BLPackage for editing.
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.
e Save the BLPackage.
For more on creating BLPackages, see Adding a BLPackage to the Depot on

page 509.
4 Create a Deploy Job to deploy the app_configuration BLPackage you created. To

accomplish this, do the following:
a Open a BLPackage Deploy Job.
b On the Package panel, specify the BLPackage being deployed as

app_configuration.
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.
e Execute the Deploy Job.

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.
Deploy Job Targets

The Targets panel lets you choose the servers or components to which software
packages and BLPackages should be deployed.
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.
Deploy Job Default Notifications

notifications.

Send email to

Send SNMP trap to

Deploy Job Phases and Schedules

The Phases and Schedules panel lets you choose the deployment phases that should
occur during deployment of a software package or BLPackage. It also lets you
schedule the execution of a job.
The Phases and Schedules panel prompts you for the following categories of
information:
Phase selection on page 732
Phase scheduling/Execution on page 733
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.

During staging, a package is copied to a staging directory, which stores a package

until it is applied to a server during the Commit phase. Each servers STAGING_DIR
property identifies the staging directory for that server. By default the staging
directory on Windows is \temp\stag e. On UNIX it is /var/tmp/stage. Using a local
directory on a target server eliminates the need for moving data through a network
during the Commit phase and thus shortens the maintenance window needed for
committing a package to a server.
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.
Phase Selection options
Simulate
Perform a test run of a deployment without deploying a package. A test run

lets you review job results, see the server objects that are changed during
deployment, and determine the actions that cause the deployment to fail (that
is, to generate a nonzero return code).
Note
Although you can select the Simulate option when deploying software
packages, Software Deploy Jobs do not currently perform any meaningful
simulation.
Commit
Apply the package to a target.

If you select Commit, you can choose how to stage deployment by selecting
Stage direct
Deliver the package to a target.
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.
Execute job now
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.
Execute job on Approval
Instructs the job to execute when approval information is provided. Click

Browse to display the Enter Approval information dialog box box, where
you provide the approval information. For more information, see Deploy
Job Execute on approval and Approval type settings on page 737.
This option is only available when your system has been configured to
require approval for this type of job.

Do not execute
Indicates you do not want to schedule this job.
After you define a Deploy Job, you can always select the job and execute it
interactively.
Execute selected phases sequentially
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
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.
Execute individual phases as specified below
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 do not want to schedule this phase, select Not scheduled.
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.
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 staging to follow simulation, select Start immediately after

simulation is complete. Do not select this option if you have not checked
Simulate under Phase Selection.
If you want to schedule the staging phase, select Start staging at. Then, to
hh:mm, or click Browse, which displays the Add New Schedule Dialog.
Notifications. Use them to define a schedule for the job.
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
hh:mm, or click Browse, which displays the Add New Schedule Dialog.
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.

To schedule jobs
1 Using the Schedules tab, specify the date and time when the job or phase of a job
should run.
Mean Time.
Deploy Job Scheduled Job Notifications
completes.
Send email to
Send SNMP trap to


Deploy Job Execute on approval and Approval type settings
page 617.
Deploy Job Job Options

The Job Options panel lets you customize the behavior of a Deploy Job.
There are many interactions to consider when specifying job options. For a
description of the procedure necessary to define job options, see Specifying job
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

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.
Specifying job options

Job options let you customize the behavior of a Deploy Job.
To specify job options
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.

All informationAll messages, including errors and warnings, are displayed

and output to a log.
2 If you are defining an advanced BLPackage Deploy Job, do the following:
a Under Flow Control, select one of the following:
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.
By phaseThe job completes a phase on all servers before it proceeds to the

next phase. This option is useful when you want a deployment to be
completely successful, such as when you are updating a web application.
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.
3 Under Parallel Job Options, do any of the following:
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
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 a network loss occurs because of a reboot/shutdown and the duration of the

connection loss exceeds the time specified in this step, the job cannot continue
on the target server after the reboot/shutdown. You must restart the job on
that 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:
Use item defined user mode setting
When processing each object being deployed, this Deploy Job uses the user
mode setting (single- or multi-user) defined for that object.
Ignore item defined user mode setting
Prevents a server from entering single-user mode no matter how individual

Use single-user mode without reboot
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.
Reboot into single-user mode
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:

Use item defined reboot setting
Causes a target to reboot after an object in the BLPackage is processed if the

instructions for that object call for a reboot. If the reboot setting for an object
is By end of job and a reboot is not scheduled for this job, then a reboot
occurs at the end of the job.
Ignore item defined reboot setting
Prevents a server from rebooting no matter how a package is defined unless

the object 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).
Use item defined reboot setting and reboot at end of job
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.
Ignore item defined reboot setting and reboot at end of job
Prevents a server from rebooting during a job no matter how a package is

defined unless the object being deployed includes an out-of-band reboot (that
is, a reboot is built into the object and is not part of the BLPackage
instructions). At the end of the job, the server reboots.
Consolidate any After item deployment reboots until end of 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:
Use item defined reconfigure setting
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.
Ignore item defined reconfigure setting
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.
For a complete description of the interactions between reboot settings, see

Interactions between reboot settings on page 743.
Interactions between reboot settings

The interaction between reboot settings can be complex, resulting in many possible
combinations.
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.
Is Reboot Required Reboot Option Use reconfiguration Reconfigure Reboot Description

for Item in Selected in Deploy reboot for reboot at Option Selected in
Package? Job end of job? Deploy Job
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
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


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

Deploy Job Phase Options

For all types of Deploy Jobs, you can use the Phase Options panel to make choices
that control how the Simulate, Stage, and Commit phases of a job behave. You can
also modify job behavior when undoing a deployment.
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:
Choosing simulate and stage options on page 746
Choosing commit and undo options on page 746
Defining pre/post commands on page 749
Choosing simulate and stage options

Simulate and Stage Options let you determine if sufficient disk space exists on the
target for staging, simulation, or both.
To choose simulate and stage options
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.
2 Select one of the following:
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.
Simulate and StageA check is made to determine if sufficient disk space

exists for both the simulation and staging phases of the Deploy Job.
Choosing commit and undo options

Commit and Undo Options let you customize the behavior of a Deploy Job during its
Commit phase and during the undo of a deployment.

To choose commit options
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.
Rollback files reside under agentInstallDirectory /Transactions. For UNIX, by

default this location is /opt/bmc/BladeLogic/ NSH/Transactions. For Windows,
the default is C:\Program Files\BMC Software\BladeLogic\ RSCD
\Transactions.
BMC Server Automation provides a mechanism for storing rollback information

in an alternate location. For details, see Configuring the location of the
transactions directory on page 770.
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.

4 Check Overwrite read-only files to instruct a server to overwrite read-only files

when read-only files are encountered during the Commit phase.
5 If you are deploying to Windows machines, check any of the following under
Windows-only Options:
Ignore presence of copy on boot files
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.
Copy locked files (do not treat locked files as error)
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.
Register COM components
Commit Phase
Registers COM objects during the Commit phase. When a deployment

adds a file with an extension of DLL, EXE, or OCX, the job determines if
the file is a COM object. If it is, the deployment registers the new object
during the 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.
Unregister COM components on delete
Commit Phase
Unregisters COM objects during the Commit phase. When a deployment

removes 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 unregisters the
object during the 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.
Defining pre/post commands

The Pre/Post Commands dialog box lets you execute commands on a target
directory before and after a package is deployed to a server. It also lets you execute
commands on a target directory before a deployment is undone and after it is undone.
A pre- or postcommand can consist of a number of commands that can be executed

by the native operating system of a remote host. After you define pre- and
postcommands, 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 postcommands. When you
execute a precommand, the target directory is first created (if it does not already
exist) and then the precommand is executed in the target directory. Postcommands
are executed in the target directory.
You can create pre- and postcommands by entering commands in the text box or
importing text from a file on any managed server.
To define pre/post commands
1 Click Pre/Post Commands. The Pre/Post Commands dialog box opens.
2 To define pre- and postcommands, click one of the following:
Deploy tabDefine pre- and postcommands for a package deployment.
Undo tabDefine pre- and postcommands for undoing a package deployment.
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.
By default, commands are written to /tmp.
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.
5 Click OK to close the Pre/Post Commands dialog box.
Deploy Job Properties


inherited.
Property .

Time-outs for simulate and staging phases

Deploy Jobs include two properties that let you set time-out values for actions
performed during the Simulate and Staging phases of a job. These properties are
unique to Deploy Jobs.
By defining time-outs for these properties, a job can be set up so a deployment

returns an error or the job fails if the Simulate or Staging phases take too long to
complete. Without time-outs, a Deploy Job may wait indefinitely to complete
preliminary phases.
To define time-outs, enter values for one or both of the following Deploy Job properties:
DEPLOY_JOB_NSH_CMD_TIMEOUTSets a time-out value in seconds for agent

commands used to determine file system sizes and capacities during the Simulate
and Staging phases of a Deploy Job
DEPLOY_JOB_URL_COPY_TIMEOUTSets a time-out value in seconds for any

copying of payload files that occurs during the Staging phase. This option is only
applicable if you are deploying a package of patches or software and the package
is defined to use the Copy to Agent staging option.
Note
For Deploy Jobs, job-level time-out properties only apply to Software Deploy
Jobs, basic BLPackage Deploy Jobs, or advanced BLPackage Deploy Jobs with
phases that run sequentially. Because job-level time-outs only apply to jobs that
are scheduled, job-level time-outs do not apply to undo jobs, which you cannot
schedule.
Controls for the number of simultaneous processes

Using Deploy Job properties, you can control how many Deploy Job processes and
connections run on a target at one time.
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
COMMIT_MAX_PARALLEL_TARGETS Maximum number of targets running the Commit
UNDO_MAX_PARALLEL_TARGETS Maximum number of targets running an undo of the
Deploy Job
Deploy Job Permissions

this object.
you want to add.



Limitations for Windows security settings

When you deploy or browse local Windows security settings, many factors influence
the behavior of BMC Server Automation.
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.

Modifying Deploy Jobs
Modifying Deploy Jobs

The procedure for modifying Deploy Jobs has minor differences from the procedure
for creating new Deploy Jobs.
To modify Deploy Jobs
To modify the definition of an existing Deploy Job, open the Jobs folder and
following sections:
Deploy Job Software on page 724 (for Software Deploy Jobs)
Deploy Job Package on page 724 (for BLPackage Deploy Jobs)
These tabs correspond to panels in the New Deploy Job wizard. Use them to
any of properties, permissions, or audit trail information that apply to this job.
on page 98.
Assigning default values for Deploy Jobs

You can define default values for the options available in all newly created Deploy
Jobs.
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.

To assign default values
1 Open the Property Dictionary by selecting Configuration => Property

Dictionary.
2 Expand Built-in Property Classes.
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.
DeployOptions properties for controlling Deploy Job behavior

The following table describes the DeployOptions properties that can be set to define
values for newly created Deploy Jobs.
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.
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.
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:
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. This
option is set to Basic by default.
AdvancedProvides full flexibility when defining the job. For

advanced BLPackage Deploy Jobs, you can choose to control
the flow of the job by server or by phase and schedule
execution of each job phase. If the job fails to complete, you
can re-execute it on a server-by-server and phase-by-phase
basis rather than have the job automatically reset.
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:
ByPhaseThe job completes a phase on all servers before it

proceeds to the next phase. This option is useful when you
want a deployment to be completely successful, such as when
you are updating a web application. This option is set to
ByPhase by default.
ByServerThe job proceeds as far as it can for each server.

When one server fails, the job continues on other servers.
When all servers have completed a phase (either by
succeeding or failing), the job continues to the next phase for
all servers that successfully completed the previous phase.
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.
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:
Use item defined reconfigure settingInstructs 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
IS_RECONFIGURE_REBOOT.
Ignore item defined reconfigure settingInstructs 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
IS_RECONFIGURE_REBOOT. 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.
LOGGING_LEVEL Enumerated Specify the amount of logging information that the Deploy Job
generates by choosing one of the following:
Errors and warningsErrors and warnings are displayed and

output to a log.
All informationAll messages, including errors and

warnings, are displayed and output to a log.
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.

REBOOT_OPTIONS Enumerated Specify reboot behavior by choosing one of the following:
Use item defined reboot settingCauses a target to reboot

after an object in the BLPackage is processed if the instructions
for that object call for a reboot. If the reboot setting for an
object is By end of job, and a reboot is not scheduled for this
job, then a reboot occurs at the end of the job.
Ignore item defined reboot settingPrevents a server from

rebooting no matter how a package is defined unless the object
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).
Use item defined reboot settings and reboot at end of job

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.
Ignore item defined reboot settings and reboot at end of job

Prevents a server from rebooting during a job no matter how a
package is defined unless the object being deployed includes
an out-of-band reboot (that is, a reboot is built into the object
and is not part of the BLPackage instructions). At the end of
the job, the server reboots.
Consolidate reboots until end of jobPrevents 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
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.

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,
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,
the job run being undone, the file being removed is unregistered.

Uninstalling software
USER_MODE_OPTIONS Enumerated Specify user mode behavior (only applicable to UNIX target
_UNIX_ONLY systems) by choosing one of the following:
Use item defined user mode settingWhen processing each

object being deployed, this Deploy Job will use the user mode
setting (single- or multi-user) defined for that object.
Ignore item defined user mode settingPrevents a server

from entering single-user mode no matter how individual
Use single-user mode without rebootThis 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.
Reboot into single-user modeThis 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.
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
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.
An uninstall option is not available for all Windows hotfixes.
Before you begin
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
1 To create an uninstall job, do one of the following:
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
The New Uninstall Job wizard opens. If software must first be added to the
Depot, the Select Matching Software dialog box opens.

executable listed in the window to software stored in the Depot. If necessary, you
can add software packages to the Depot with this process.

Deploy Job results
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:
Deploy Job Software on page 724
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.
Deploy Job results

Using Deploy Job results, you can perform actions on the job or on particular servers
included in the job. You can also undo Deploy Jobs or reboot Windows 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

Deploy Job results
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:
Job Status Icon

In progress
Completed successfully
Completed with errors
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:
Performing actions on a job on page 765
Performing actions on a server or phase on page 767
Undoing a Deploy Job on page 768
Rebooting servers on page 769
Performing actions on a job

Using Deploy Job results, you can take a number of actions on the overall job.
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.
To perform actions on a job
1 In the Jobs folder, right-click a Deploy Job and do any of the following:

Deploy Job results
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.
Resuming a failed Deploy Job

In certain situations, an advanced Deploy Job run may display an icon indicating the
job is in a paused state.
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.
To resume a failed Deploy Job
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.

Deploy Job results
Performing actions on a server or phase

Using Deploy Job results, you can take a number of actions when a job is in an
incomplete state, and you want to take actions so the job succeeds or fails.
To take action on a job as a whole, see Performing actions on a job on page 765.
To perform actions on a server or phase
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.
3 Click the Deploy Status tab and do any of the following:
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.
Show log messages generated when a job executes a particular phase on a

target by selecting the cell representing that target and phase.
The Log Messages pane at the bottom of the window shows messages
generated during that phase on the selected target.
4 To show messages generated for the entire job run that is currently selected, click
the Log Messages (run level) tab.

Deploy Job results
Undoing a Deploy Job

Using Deploy Job results, you can undo packages that are committed to targets as
part of a Deploy Job.
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.
To undo a Deploy Job
1 Display job results by selecting a job, right-clicking, and selecting Show Results
2 Select the most recent run of a Deploy Job.
To undo all committed packages, select the most recent job run and select Undo
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.

Server properties controlling Deploy Job behavior
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.
Server properties controlling Deploy Job

behavior
BMC Server Automation lets you use server properties to control some behavior of
Deploy Jobs on a server-by-server basis.
Using server property definitions, the following procedures are possible:
Designating servers that cannot be targeted by Deploy Jobs on page 770
Configuring the location of the transactions directory on page 770
Using NFS to mount a location while running single-user mode on page 771

Designating servers that cannot be targeted by Deploy Jobs

Using server properties, you can temporarily designate a server as not being subject
to a Deploy Job. To accomplish this, you set a value for the IS_DEPLOYABLE server
property.
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.
A Deploy Job checks the value of a servers IS_DEPLOYABLE property when it

begins each phase of the job on that server. If the property is set to False, that phase
and all subsequent phases of the job cannot run. For job results, the job issues a
warning for those phases of the job and the overall job. However, these are only
warnings, and the job can still complete successfully with these warnings.
To designate servers that cannot be targeted by Deploy Jobs
1 To designate a server that cannot be targeted by a Deploy Job, set the

IS_DEPLOYABLE property for that server to False.
For details on how to define a property value, see Setting values for system
object properties on page 161.
Configuring the location of the transactions directory

Using server properties, you can store deploy transaction information at a location
on the target server other than the RSCD agents default location.
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.
To configure the location of the transactions directory
1 To define an alternate location for storing a target servers transaction

information, specify a value for the TRANSACTIONS_DIR server property. The
value you specify should be a local path to an alternate location on the target
server.
Using NFS to mount a location while running single-user mode

Using server properties, you can allow an agent on a target server running in single-
user mode to mount a source location using the NFS data transmission protocol.
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.
This procedure requires you to set a value for the

DEPLOY_ALLOW_NFS_DURING_SUM server property. By default this server
property is set to false, which means the agent on a target server running in single-
user mode cannot mount a source location using NFS.
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.
To use NFS to mount a location while running single-user mode
1 To allow the agent on a target server running in single-user mode to mount a

source location using NFS, set the DEPLOY_ALLOW_NFS_DURING_SUM server
property to True.

Tracking BLPackage deployments
Tracking BLPackage deployments

Each servers agent stores information about BLPackages deployed to that server.
You can view this information using the BLPackages object on each server.
The BLPackages object is a custom configuration object that is automatically installed

on every agent running version 8.1 or later. Agents running earlier releases will not
show the BLPackages object on a server. For agentless managed objects, BLPackage
information resides on the proxy server used to manage the agentless object.
The time stamp shown in the Deployment Time column reflects the local time for the
server.
Click Refresh to update BLPackage information.
When you undo a deployment of a BLPackage, the BLPackages object no longer

shows the BLPackage that was un-deployed.
To track BLPackage deployments
1 Using the Servers folder, select a server, right-click, and select Browse.
A new tab displays information for the server.
2 In the tab, select the BLPackages object.
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.

16
File Deploy Jobs
This section describes how to create File Deploy Jobs, which you let deploy multiple
files and directories to one or more servers.
File Deploy Job overview

File Deploy Jobs let you deploy (or push) multiple files and directories to one or
more servers. When you deploy a directory, the contents of the directory are copied
recursively, meaning that all sub-directories and their contents are also deployed.
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.
Creating a File Deploy Job

File Deploy Jobs let you deploy one or more files or directories to one or more servers.

Note
If you deploy a symbolic link, an equivalent symbolic link is created on the

remote host. You do not deploy whatever the symbolic link points to. In other
words, if you deploy a symbolic link that points to a directory, the directory is not
copied; only the link is copied.
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:
information about Windows user mapping, see Creating automation
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
Setting+up+configuration+files.
To create a File Deploy Job
1 To create a new File Deploy Job, do one of the following:
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.
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:
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
File Deploy Job Properties on page 788
File Deploy Job Permissions on page 789
File Deploy Job General

The General panel lets you provide information that identifies a File Deploy Job. It
also lets you identify the source and destination of the files copied in a File Deploy job.
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.
Preserve source file paths
To preserve source file paths, check Preserve source file paths.
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.


File Deploy Job Targets

Field definitions
Available Servers
By Group, By Name
servers.
File Deploy Job Options

The Options panel lets you provide options that control a file deployment.
You can provide the following categories of information:
Sync Push on page 778
Indirect Push Using Repeaters on page 779

Backup Options on page 781
Global Deploy Options on page 782
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
Available only if you checked Sync Push.
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.
Indirect Push Using Repeaters

You can copy a file or directory directly to destination hosts (a direct push) or you
can identify one or more machines that serve as repeaters (an indirect push). After
files or directories are pushed to a repeater, the repeater pushes it to multiple hosts.
By default, files or directories are copied using a direct push.
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
Indirect Push Using Repeaters
Check Indirect Push Using Repeaters to indicate that intermediate hosts

should serve as repeaters when copying files and directories to multiple
destination hosts.
Clearing Indirect Push Using Repeaters indicates the deployment occurs

using a direct push.
Staging directory
Available only if you checked Indirect Push Using Repeaters.
The directory on a repeater to which files are copied. During an indirect

push, files are copied from the staging directory to target servers.
Clean up staging after push
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.
Synchronize push to repeaters
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.
In a synchronized push, you can specify criteria that qualify a file to be

copied, and you can specify how that copy will be performed. However,
these options are only available if you check Sync Push, as described in Sync
Push on page 778. Selecting a synchronized push can minimize the amount
of data carried over the network.
Parallel pushes
Specify the amount of parallelism you want when copying files to

intermediate hosts. The default value is to update the repeater hosts one after
the other, but they can also be updated in parallel by entering a value
between 2 and 100. For example, if you enter 2, the system will update two
remote machines at a time.

Backup Options
When deploying a file or directory, you can take precautions to back up the files that
are overwritten.
Field definitions
Backup Options
Check Backup Options to define backup provisions.
Clearing Backup Options indicates you want to make no backup provisions.

By default, Backup Options is cleared.
Save with suffix
Available only if you checked 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
Enter the suffix you want to use, such as bak.
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

Directory called log and a Name of June-20-2001, the backup directory is

named as follows:
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
A name that identifies this backup.
Global Deploy Options

The Global Deploy Options section allows you to define block level updates and
minimum disk space.
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
Min. file size
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.
Update block size
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.
Although smaller values require more block comparisons, when a change is

detected, a smaller amount of data is sent to perform the update. Larger
values require fewer comparisons but large amounts of data are sent on the
network to perform only a small number of changes. In general, use smaller
numbers for files with a greater number of changes. Use larger values for
files with fewer changes.
Minimum disk free
To specify a minimum amount of disk space for a destination directory, enter

a value (in kb) for Minimum disk free.
Preserve File Source Characteristics
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.
Delete existing target file(s) before copy
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.
File Deploy Job Advanced Options

The Advanced Options panel lets you customize a File Deploy Job using pre-
commands and post-commands.

Pre- and post-commands allow you to execute commands on a target directory

before a job begins or after a job ends. A pre- or post-command can consist of any
number of commands that can be executed by the native operating system of a
remote host.
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.
If a precommand must execute successfully for the job to complete, check

Must have 0 exit status. This option is not available when undoing the
deployment of a BLPackage or installable software package.
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.
Minimum disk free
To specify a minimum amount of disk space for a destination directory, enter

a value (in kb) for Minimum disk free.
File Deploy Job Default Notifications

notifications.


Send email to
Send SNMP trap to

File Deploy Job Schedules

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
information, see File Deploy Job Scheduling on page 787.
a scheduled job runs. For more information, see Snapshot Job Scheduled
Providing approval information
The Approval information tab lets you provide required approval

information. This tab only appears when your system has been configured to
require approval information for this job type. For more information, see
File Deploy Job Execute on approval and Approval type settings on page
788.
File Deploy Job Scheduled Job Notifications

completes.
Send email to
Send SNMP trap to


File Deploy Job Scheduling

To schedule jobs
Mean Time.

File Deploy Job Execute on approval and Approval type

settings
page 617.
File Deploy Job Properties


inherited.

Property .
File Deploy Job Permissions

this object.
you want to add.



Modifying File Deploy Jobs
Modifying File Deploy Jobs

The procedure for modifying File Deploy Jobs has minor differences from the
procedure for creating new File Deploy Jobs.
To modify a File Deploy Job
To modify the definition of an existing File Deploy Job, open the Jobs folder
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.


17
Network Shell Script Jobs
This section describes how to create Network Shell Script Jobs, which let you deploy
and execute a Network Shell (NSH) script that you have previously saved in the Depot.
Creating Network Shell Script Jobs

Network Shell Script Jobs let you run a Network Shell script on one or more servers.
Before you begin
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.

To create Network Shell Script Jobs
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.
new Network Shell Script Job. Right-click the job folder and select New =>
NSH Script Job from the pop-up menu.
The New NSH Script Job wizard opens.
2 Provide information for the Network Shell Script Job, as 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
Network Shell Script Job Properties on page 799
Network Shell Script Job Permissions on page 800
Network Shell Script Job General

The General panel lets you provide basic information that identifies a Network Shell
Script Job. It also includes options defining how the job is deployed to servers.
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.

Execute Asynchronously
Enable asynchronous script execution for the job.
This option is useful in larger scale environments, as it enables you to execute

more scripts simultaneously. This option would be useful for any script that
executes for a period of time with limited output, such as a monitor script
that reboots a machine and waits for the machine to come back online.
However, note that this option is not recommended for scripts that generate
medium to large amounts of output to stdout/stderr.

Network Shell Script Job Targets

Field definitions
Available Servers
By Group, By Name
servers.
Network Shell Script Job Parameters

The Parameters panel lets you review and modify values for parameters that are
used when the script runs.
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.
For each parameter listed on this panel, do the following:
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:
UseThe job uses the parameter flag.
IgnoreThe job does not use the parameter flag.
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:
UseThe job uses this parameter value.
IgnoreThe job does not use this parameter value.
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.

Network Shell Script Job Default Notifications

notifications.

Send email to
Send SNMP trap to

Network Shell Script Job Schedules


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
information, see Network Shell Script Job Scheduling on page 798.
a scheduled job runs. For more information, see Network Shell Script Job

Network Shell Script Job Execute on approval and Approval type settings
on page 799.
Network Shell Script Job Scheduled Job Notifications

completes.
Send email to

Send SNMP trap to

Network Shell Script Job Scheduling

To schedule jobs
Mean Time.

Network Shell Script Job Execute on approval and

Approval type settings
page 617.
Network Shell Script Job Properties


inherited.

Property .
Network Shell Script Job Permissions

this object.
you want to add.



Modifying Network Shell Script Jobs

The procedure for modifying Network Shell Script Jobs has minor differences from
the procedure for creating new Network Shell Script Jobs.
To modify Network Shell Script Jobs
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
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.



18
Batch Jobs
This section describes the Batch Job, which is a concatenated series of jobs.
Batch Job overview

A Batch Job is a concatenated series of jobs. Batch Jobs are useful when
administrators must perform multiple discrete jobs.
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.
Creating a Batch Job

A Batch Job is a group of concatenated jobs of any type, including other Batch Jobs.
Note
In the BLCLI, the corresponding createBatchJob command enables you to perform
the same procedure. See the BLCLI help for more information about this command.
To create a Batch Job
1 Select a job folder in the Jobs folder, right-click, and select New => Batch Job
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 modify the list of jobs, do any of the following:
To delete a job, select the job and click Delete .
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.
To provide information for the Batch Job, do the following:
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
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
3 Click OK to save the Batch Job.
Batch Job Options

The Batch Job Options panel lets you define how a Batch Job functions.
Using the Batch Job Options panel, you can
identify a Batch Job
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.
Execute jobs sequentially
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.
Execute jobs in parallel
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.
Enable Rolling Execution
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.

Servers/Server Groups
Select one of the following:
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.
Batch Job Default Notifications

notifications.

Send email to


Send SNMP trap to

Batch Job Schedules

Note
The batch job is responsible for the scheduling of the child jobs included within it.
However, you can also schedule any child job independently of the batch job. To
avoid problems, ensure that child jobs are not scheduled to execute independently of
the batch job at the same time and on the same targets as scheduled through the
batch job.
Enter Approval Information dialog box.
Scheduling a job


require approval information for this job type.
Batch Job Scheduled Job Notifications

completes.
Send email to
Send SNMP trap to


Batch Job Scheduling

To schedule jobs
Mean Time.
Batch Job Execute on approval and Approval type settings


create a schedule for a job that you are creating
schedule an existing job for execution
set a schedule in an execution task
page 617.
Batch Job Properties


inherited.
Property .
Batch Job Permissions


this object.
you want to add.



Modifying a Batch Job
Modifying a Batch Job

The procedure for modifying Batch Jobs has minor differences from the procedure
for creating new Batch Jobs.
To modify a Batch Job
To modify the definition of an existing Batch Job, open the Jobs folder and
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
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 modify the list of jobs, do any of the following:
To delete a job, select the job and click Delete .
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.

Viewing Batch Job results

apply to this Batch Job, select the Properties, Permissions, or Audit Trail tab
group.

After running the Batch Job, you can view a history of job results for all runs of the
Batch Job and the various jobs contained within it.
To view Batch Job results
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.
Further hierarchical organization and display of information depends on Batch

Job settings (as defined on the Batch Job Options panel) and on the type of each
individual job within the Batch Job. For more information, see Effect of execution
settings on display of results on page 814.
2 Select the root job node or any of the job run nodes to display basic information in
tabular form on the right.
Effect of execution settings on display of results

The display of Batch Job results differs, depending on whether you enabled a rolling
execution for the Batch Job and depending on the mode of execution that you chose
for the individual jobs contained within the Batch Job (sequentially, in parallel, or by
server).
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.

Table 6: Display of batch job results based on execution settings
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.
Figure 1: Example of Batch Job running by server with rolling execution

Figure 2: Example of Batch Job running by server without rolling execution


19
Workflow Jobs
This chapter describes how to use Workflow Jobs to manage BMC Atrium
Orchestrator workflow processes through the BMC Server Automation Console.
Workflow Job objectives

The Workflow Job enables you to manage a BMC Atrium Orchestrator workflow
process that belongs to any BMC Atrium Orchestrator run book module through the
Using the Workflow Job in BMC Server Automation, you can
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.

Requirements and preparatory tasks for Workflow Jobs
Requirements and preparatory tasks for

Workflow Jobs
Before you can create Workflow Jobs that integrate with BMC Atrium Orchestrator
processes, ensure that the following requirements are met:
BMC Atrium Orchestrator 7.6.04 or later is installed.
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
Configuring input parameters in a process on page 820
BLCLI commands for inclusion in a process on page 837
In addition, you must perform the following preparatory configuration tasks

through the BMC Server Automation Console:
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.
Configuring input parameters in a process

Any BMC Atrium Orchestrator process that you choose to associate with your BMC
Server Automation Workflow Job will usually have input parameters defined
through its Start activity. These input parameters are passed on to your Workflow

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.
This can be accomplished in either of the following ways:
Include metadata within the names of input parameters according to a special

naming convention (see Including metadata in input parameter names on page
821).
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.
The method of including a block of XML code in process properties is more

flexible. As opposed to the other method, the XML method enables you to
define enumeration-type parameters that have sets of possible values.
specify default values for list and XML parameters.
specify allowed job types for limiting Job or List_Job parameter values.
sequence pages and groups.
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.
Including metadata in input parameter names

In most cases, the BMC Atrium Orchestrator process that you choose to associate
with your Workflow Job already has input parameters defined through its Start
activity. Use the following procedure to modify the existing input parameters so that

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.
For an example, see Example of modified parameter names on page 824.
To modify input parameters to include metadata
1 In the BMC Atrium Orchestrator Development Studio, double-click the Start

Activity of the process to display the Property panel.
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:
a Remove any underscore characters included in the original parameter name.
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.
Table 7: Optional metadata elements for parameter name
Optional element Description Example parameter name including the element
description A description for the parameter. string_Super User_description A user with

This description is displayed in a administrative privileges
tooltip when you hover over the (dataType_parameterName_description value)
parameter field on the Workflow
Job panel.
required An indication that input for the string_Name_required

parameter is required. The element (dataType_parameterName_required)
does not need a value.
On the Workflow Job panel, the
label for the parameter field
appears in bold characters and you
cannot leave the panel until you
enter a value.

Optional element Description Example parameter name including the element
default A single default value for the string_Server Host_default localhost

parameter.
(dataType_parameterName_default value)
This value appears in the parameter
field on the Workflow Job panel.
2.c.i
Do not use this element with the

job, list_job, or serverGroup
data type.
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:
string_User Name_group Login Info
password_Password_group Login Info
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
numeric_Risk_group Change Info_page AR

Info
string_Status_group Change Info_page AR

Info
job_Job to Execute_page BladeLogic Job Info
list_target_Target Servers_page BladeLogic

Job 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.
Example of modified parameter names

The following figures present an example of input parameters in BMC Atrium
Orchestrator modified to include metadata that can be used by the BMC Server
Automation Workflow Job.
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.
Figure 3: Parameters in BMC Atrium Orchestrator defined to include metadata

Figure 4: Resulting panels for example modified parameter names

Defining input parameter information through XML code

By introducing a special block of XML code into the properties of the BMC Atrium
Orchestrator process associated with your BMC Server Automation Workflow Job,
you can include additional information about the input parameters and their
organization during the configuration of the Workflow Job.
To insert an XML for the definition of workflow input parameters
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.
2 In the BMC Atrium Orchestrator Development Studio, double-click a blank area

in the process canvas of the relevant process to open its Edit Process Properties
dialog box.
3 Paste your XML text into the Description field (replacing any text that might
already be there), and then click OK.
XML code for workflow definitions

The XML code that you create for defining input parameters for the Workflow Job
contains information about all the input parameters defined for the BMC Atrium
Orchestrator process, as well as information for organizing these parameters on the
Workflow Job panels.
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:
Table 8: Basic elements in the XML code for workflow definitions
Basic element Resulting screen element during Workflow Job configuration
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>
</group>
</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.
Parameter attributes and child elements
Table 9 on page 828 lists the parameter attributes that you can include for each
parameter that you define in your XML code.
Table 9: Parameter attributes in the XML code for workflow definitions
Attribute or element Description Display in Workflow Job panels
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).

Attribute or element Description Display in Workflow Job panels
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).
Example workflow definitions

The following example XML code defines two pages of input parameters for a
Workflow Job that runs a BMC Server Automation job pending BMC Remedy
approval.
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>
</defaultValue>
</parameter>
<parameter name="Risk level" type="numeric">
<defaultValue>
<value>1</value>
</defaultValue>
</parameter>
<parameter name="Urgency" type="enum">
<possibleValues>
<value>Low</value>
<value>High</value>
</possibleValues>
<defaultValue>
</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>

Figure 5: Resulting panel for first page in XML
Figure 6: Resulting panel for second page in XML

Copy of WorkflowDefinition.xsd for XML validation

You can use the following copy of the WorkflowDefinition.xsd to validate your
XML code after you finish authoring it.
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.bmc.com" xmlns="http://www.bmc.com"
elementFormDefault="qualified">


<xs:element name="workflow">
<xs:complexType>

<xs:sequence>
<xs:choice minOccurs="1">
<xs:element name="page" type="page" />
<xs:element name="group" type="group" />
<xs:element name="parameter" type="parameter" />
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="parameter">
<xs:all>
<xs:element name="defaultValue" type="defaultValue"
maxOccurs="1" />


<xs:element name="possibleValues" type="possibleValues"
maxOccurs="1" />

<xs:element name="allowedJobTypes" type="allowedJobTypes"
maxOccurs="1" />
</xs:all>
<xs:attribute name="name" type="xs:string" use="required" />
<xs:attribute name="description" type="xs:string"
use="optional"
default="" />
<xs:attribute name="prompt" type="xs:string" use="optional"
default="" />
<xs:attribute name="type" type="dataType" use="optional"
default="string" />
<xs:attribute name="isRequired" type="xs:boolean" use="optional"
default="false" />
</xs:complexType>
<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:enumeration value="list_datetime" />

<xs:enumeration value="list_password" />
<xs:enumeration value="list_file" />
<xs:enumeration value="list_directory" />
<xs:enumeration value="list_job" />
<xs:enumeration value="list_target" />
</xs:restriction>
</xs:simpleType>
<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="possibleValues">
<xs:all>
<xs:element name="value" type="xs:string" minOccurs="1" />
</xs:all>
</xs:complexType>
<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 name="group">
<xs:all>
<xs:element name="parameter" type="parameter" minOccurs="1" />
</xs:all>
<xs:attribute name="description" type="xs:string" use="optional"
default="" />
</xs:complexType>


<xs:complexType name="page">
<xs:sequence>
<xs:choice minOccurs="1">
<xs:element name="group" type="xs:string" />
<xs:element name="parameter" type="xs:string" />
</xs:choice>
</xs:sequence>

<xs:attribute name="description" type="xs:string" use="optional"
default="" />
</xs:complexType>
</xs:schema>
Data types for input parameters of a Workflow Job

Various data types are available for you to associate with input parameters that are
transferred from the BMC Atrium Orchestrator process to the BMC Server
Automation Workflow Job.
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.
Table 10: Input parameter data types
a
Data type for a single value Data type for multiple values Description of value
string list_string A string of characters

numeric list_numeric A number
boolean list_boolean A value of either true or false
datetime list_datetime Date and time
Values entered on the Workflow
Job panel are returned to the BMC
Atrium Orchestrator process in the
EEE MMM d HH:mm:ss Z yyyy
format.
password list_password A password
On the Workflow Job panel the
entered value is masked. The
value is returned to the BMC
Atrium Orchestrator process as
clear text.

a
file list_file The full path to a file (for example:

C:\log.txt)
directory list_directory The path to a directory (for
example: C:\temp)
job list_job A BMC Server Automation job
The value returned to the BMC
Atrium Orchestrator process is the
job ID.
target list_target A BMC Server Automation target
server
ID of the target server.
serverGroup none A BMC Server Automation server
group or smart group
group ID.
enum none A closed list of possible values
(enumerated values), from which
the user chooses a single value
This data type is available for use
only within XML code that you
introduce into process properties.
It cannot be included as metadata
in input parameter names.
xml none XML code, limited to 2000
characters
jobRunId none The Workflow Job ID, for transfer
to a child BMC Server Automation
job
A parameter with this data type is
not displayed on the Workflow Job
panels.
Note: When defining a parameter
of the jobRunId type through XML
code, position it at the end of the
page and do not include it in a
group.

a
a List types are returned to the BMC Atrium Orchestrator process with commas separating between values.
Figure 7: Example panel with fields for non-list data types

BLCLI commands for inclusion in a process
Figure 8: Example panel with fields for list data types
BLCLI commands for inclusion in a process

Several BLCLI commands that are related to Workflow Jobs are available for
inclusion in the BMC Atrium Orchestrator process through a Call Adapter activity,
which calls the BMC Atrium Orchestrator Application Adapter for BMC Server
Automation and runs the BLCLI command.
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:
The executeWorkflowChildJob and executeWorkflowChildJobId commands

enable the execution of a child BMC Server Automation job by the Workflow Job.

Enabling the AO integration
The updateWorkflowJobRunLog command enables you to update the Workflow

Job run log with a message issued at a specific point during the execution of the
BMC Atrium Orchestrator process.
The updateWorkflowJobRunStatus command enables you to set the Workflow

Job run status to reflect the status of the underlying BMC Atrium Orchestrator
process. For example, you can have the Workflow Job fail if its associated BMC
Atrium Orchestrator process ended with errors.
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.

Before you can create Workflow Jobs, you must enable the integration between BMC
Server Automation and BMC Atrium Orchestrator.
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.
Setting up the connection to BMC Atrium Orchestrator

Through the BMC Server Automation Console, you must add the configuration
information required to connect to BMC Atrium Orchestrator.
Note
The integration between BMC Server Automation and BMC Atrium Orchestrator
supports connections to a single grid only.
The connection with BMC Atrium Orchestrator is established through the
Configuration Distribution Peer (CDP) or through a High Availability CDP
(HACDP). Other types of peers are not supported.
Before you begin
Ensure that your role is granted the AOConfig.* and the AutomationPrincipal.*
authorizations.

To configure the connection with BMC Atrium Orchestrator
1 Select Configuration => AO Configuration.
2 On the AO Configuration dialog box, click Add.
3 On the Add new AO configuration dialog box, enter the configuration

information required to connect to BMC Atrium Orchestrator, and then click OK.
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).
Primary AO Whether to specify this CDP as the primary instance.

In a high-availability environment with multiple CDP instances, ensure that you
select the correct CDP, as defined in BMC Atrium Orchestrator.
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.
4 If you want to add additional CDP connections to BMC Atrium Orchestrator, to

ensure high availability, repeat Step 2 on page 674 and Step 3 on page 839 for
every additional CDP instance of the same grid.
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).
5 Click Close on the AO Configuration dialog box.

Enabling HTTPS support for the AO connection

If you want to secure the communication of data between BMC Server Automation
and BMC Atrium Orchestrator, you must enable an HTTPS connection on both
products.
To enable HTTPS support on BMC Atrium Orchestrator
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.
2 Enable HTTPS on Tomcat by completing the following steps:
a Open the server.xml file.
b Uncomment the following block of configuration information and add two

attributes (shown in bold text).
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="C:\.keystore"
truststoreFile="C:\Program Files\Java\jdk1.5.0_13\jre\lib
\security\cacerts" />
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.
3 Restart the BMC Atrium Orchestrator CDP.
To enable HTTPS support for BMC Atrium Orchestrator on BMC Server

Automation
1 If BMC Atrium Orchestrator is installed on a different machine, copy the C:

\.keystore file from the BMC Atrium Orchestrator CDP system to the system
where the BMC Server Automation application server is installed.
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

Choosing modules for Workflow Jobs
In the command shown above, note the following:
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.
alias is the name used to distinguish certificates.
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
where C:\Program Files\BMC Software\BladeLogic is the default installation

path of BMC Server Automation. Change the path if BMC Server Automation was
installed in a different location.
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
5 Restart the BMC Server Automation Application Server.
Choosing modules for Workflow Jobs

Before you create Workflow Jobs and select BMC Atrium Orchestrator processes in
Workflow Jobs, you must perform an initial selection of the BMC Atrium
Orchestrator modules that you plan to use.
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.
Before you begin
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).
Ensure that your role is granted the WorkflowJob.Configure authorization.

Creating Workflow Jobs
To select modules for Workflow Jobs
1 Select Configuration => Workflow Job Configuration.
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.

A Workflow Job defines the management of a BMC Atrium Orchestrator process.
Workflow Jobs are stored in the Jobs folder.
For information about managing and organizing jobs, as well as performing other
actions such as deleting jobs, see Managing jobs on page 605.
Before you begin
Ensure that your role is granted, at the minimum, the WorkflowJob.Read and
WorkflowJob.Create authorizations.
To create a Workflow Job
1 In the Jobs folder, right-click a job folder and select New => Workflow Job.
The Workflow Job Creation wizard opens.
2 Define the Workflow Job through the wizard panels, as described in the following
sections:
Workflow Job General on page 843
Workflow Job AO Process on page 843
Workflow Job Workflow Input Parameters on page 844
Workflow Job Default Notifications on page 844
Workflow Job Schedules on page 845

Workflow Job Properties on page 848
Workflow Job Permissions on page 849
Note
The Workflow Input Parameters panel is not displayed if no input parameters
have been defined in the associated BMC Atrium Orchestrator process.
Workflow Job General

Through the General panel, you provide basic information that identifies the
Workflow Job.
This panel contains the following fields and screen elements:
Name
Enter an identifying name for the job.
Description
(Optional) Descriptive text for the job.
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.
Workflow Job AO Process

The AO Process panel enables you to select the BMC Atrium Orchestrator process
against which to run the Workflow Job from a hierarchical tree of BMC Atrium
Orchestrator modules and processes.

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.
Workflow Job Workflow Input Parameters

The Workflow Input Parameters panel enables you to specify values for the input
parameters defined for the selected process.
Note
To ensure that you have use of the full range of BMC Server Automation input types
and to organize the input parameters on multiple pages of this panel, you can
modify the original process in BMC Atrium Orchestrator as described in
Configuring input parameters in a process on page 820.
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.
Workflow Job Default Notifications

notifications.


Send email to
Send SNMP trap to

Workflow Job Schedules

Enter Appoval Information dialog. For more information, see Workflow Job
Execute on approval and Approval type settings on page 847.

Scheduling a job
information, see Workflow Job Scheduling on page 847.
a scheduled job runs. For more information, see Workflow Job Scheduled

Workflow Job Execute on approval and Approval type settings on page
847.
Workflow Job Scheduled Job Notifications

completes. It also lets you send notifications that indicate whether the targets being
audited have consistent configurations, inconsistent configurations, or both.
Send email to
Send SNMP trap to


Workflow Job Scheduling

To schedule jobs
Mean Time.
Workflow Job Execute on approval and Approval type

settings

page 617.
Workflow Job Properties


inherited.
Property .

Workflow Job Permissions

this object.
you want to add.



Modifying Workflow Jobs
Modifying Workflow Jobs

After creating and saving a Workflow Job, you can modify the existing Workflow
Job at any time.
To modify a Workflow Job
To modify the definition of an existing Workflow Job, open the Jobs folder and
following sections:
Workflow Job General on page 843
Workflow Job Workflow Input Parameters on page 844
Workflow Job Default Notifications on page 844
Workflow Job Schedules on page 845
These tabs correspond to panels in the New Workflow Job wizard. Use them to
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.


Viewing Workflow Job results and logs

You can view a history of job results from all runs of a Workflow Job through the
Jobs folder. For any job run in the job results you can also display a log that contains
all the messages generated for the job run.
Note
A Workflow Job run cannot be undone.
To view a history of job run results
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.
To view the log for a Workflow Job run
1 Select a job run in the display of Workflow Job results, right-click, and select
Show Log.
A window displays log messages generated by the job.
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.

2 Click Close to close the log messages window.

20
Working with virtual environments
BMC Server Automation enables IT Operators to perform basic ad-hoc actions on
virtual assets in their environment (such as starting and stopping virtual machines),
as well as more complex management tasks such as deploying virtual assets and
controlling virtualization sprawl.
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:
view the entire virtual inventory from one console.

See Browsing virtual inventory on page 857.
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.
verify that virtual inventory configurations meet corporate standards (using

Audit and Compliance Jobs).
See Monitoring compliance in the virtual environment on page 892.
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.

Overview of virtualization support
Note
The BMC Server Automation administrator must install and configure the virtual
environment. For more information, see BMC technical documentation at https://

This topic provides an overview of the types of BMC Server Automation console
management tasks you can perform in each of the supported virtual environments.
Table 11 on page 854 lists the types of BMC Server Automation console
management tasks you can perform in each supported virtual environment.
Table 11: Support for virtual environments
Virtual environment Supported actions
VMware vSphere
Live Browse a virtual node inventory (vCenter, virtual host, and virtual
machine)
Snapshot on all nodes of clusters, inventory, hosts, templates and virtual

machines
Audit on all nodes of clusters, inventory, hosts, templates and virtual

machines
Compliance on all nodes of clusters, inventory, hosts, templates and virtual

machines
Support for Live Browse and use of VMware templates
Deploy for VMware virtual machines and ESX host configurations
Creation of VMware virtual machine, using existing virtual machine
Creation of VMware virtual machines, using a repeatable process (using the

Virtual Guest Package and Virtual Guest Job)
Discover virtual machines with Virtual Infrastructure Discovery Job
Discover templates and create Virtual Guest Packages automatically using

the Virtual Guest Template Enrollment Job.

Solaris Zones
Live Browse a virtual node inventory (nonglobal zone, projects and resource
pools)
Snapshot on all nodes of nonglobal zone, projects and resource pools
Audit on all nodes of nonglobal zone, projects and resource pools
Compliance on all nodes of nonglobal zone, projects and resource pools
Creation of nonglobal zone, using a repeatable process (using the Virtual

Guest Package and Virtual Guest Job)
BLPackage Deploy on nonglobal zone
Discover local zones with Virtual Infrastructure Discovery Job
IBM PowerVM
Live Browse a virtual node inventory (LPARs, VIO servers, pools)
Snapshot of Frame Configuration, LPARS, VIO servers, pools
Audit of Frame Configuration, LPARs, VIO servers, pools
Compliance of frame configuration, LPARs, VIO servers, pools
Creation of LPAR or VIO server, using a repeatable process (using the

Virtual Guest Package and Virtual Guest Job)
BLPackage Deploy of frame configuration, LPARs, VIO servers, pools
Discover LPARS with Virtual Infrastructure Discovery Job

Hyper-V
Live Browse for virtual node inventory (clusters, host, and virtual machine)
Snapshot of virtual machine, host, or cluster
Audit of virtual machine or host
Creation of virtual machines, using a repeatable process (using the Virtual

Deploy for virtual machine configurations using a BLPackage:
Ability to modify memory, CPU, and power state (power state

modification is supported only for VMs in the Running and Stopped states)
Ability to add and delete VM disks and NICs using a BLPackage

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).
Live Browse a virtual node inventory (hosts, guests)
Snapshot on host configuration
Audit on host configuration
Compliance on host configuration
Creation of guests, using a repeatable process (using the Virtual Guest

Package and Virtual Guest Job)
Deploy for RHEV virtual guest configurations (modify memory, CPU, add
new disk or NIC to a virtual machine)

Browsing virtual inventory
Red Hat KVM

Live Browse a virtual node inventory (hosts, guests)
Snapshot on host configuration
Audit on host configuration
Compliance on host configuration
Creation of guests, using a repeatable process (using the Virtual Guest

Package and Virtual Guest Job)
BLPackage Deploy for guests
Citrix XenServer
Live Browse a virtual node inventory (hosts, virtual machines, custom
templates, XenServer templates, pools, storage repositories)
Snapshot on XenServer configuration
Audit on XenServer configuration
Compliance on XenServer configuration
Creation of virtual machines, using a repeatable process (using the Virtual

BLPackage Deploy on virtual machines

Note

You can browse a virtual system to review a variety of server objects (such as cluster,
host and configuration information) related to the virtual system. Depending on the
virtual environment, the Live node contains the following specialized child nodes.

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
Table 12: Contents of the Live node by virtual environment
Virtual Child Node Server Objects

Environment
VMware VMware vCenter

vSphere Server Inventory: Shows the dynamic tree under a vCenter (this is the
equivalent of the VMware Infrastructure clients Hosts &
Clusters view). This tree shows hierarchical organization and
configuration information.
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.
Templates: Lists the available vCenter templates.
Virtual Machines: Lists all the virtual machines in the vCenter, in

alphabetical order and the power status for each.
VC Configuration: Lists various configuration information

related to the vCenter server, such as underlying operating
system details, vCenter server name, and version.


Environment
IBM PowerVM IBM

Configuration Configuration: Shows information about the frames hardware,
software, and connections.
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.
Pools: Lists information about the frames IO pools and shared

processor pools.
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.
Solaris Zones Global Zone

Non-global Zones: Lists all the zones in the global zone, with an
indication of each zones state. You can browse each zone to view
information about its hardware, options, storage, and general
settings.
Projects: Lists each project and its attributes.
Resource Pools: Lists the processor sets and resource pools

available to this global zone.
Microsoft Hyper- Microsoft VMM

V Clusters: Shows all the clusters in the Microsoft System Center
Virtual Machine Manager (VMM).
Hosts: Shows all the hosts configured under the VMM, and their
Properties.
Virtual Machines: Lists all the virtual machines in the VMM, in

alphabetical order, and the status of each.


Environment
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.
Domains: Lists all the domains on the host, with an indication of

each domains state. You can browse each domain to view
information about its hardware, options, storage, and general
settings.
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:
Networks: Lists each network connected to the host server.
Storages: Lists all of the storage domains available to this host.
Data Centers: Shows the data centers to which the RHEV

Manager belongs.
Hosts: Shows all the hosts configured under the RHEV Manager,
and their Properties.
Templates: Lists the available RHEV templates.
Virtual Machines: Lists all the virtual machines in the RHEV

Manager, in alphabetical order, and the status of each.
RHEV-M Configuration: Shows information about the RHEV

Manager version.

Deploying assets to the virtual infrastructure

Environment
Citrix XenServer Citrix XenServer

For hosts: Shows the properties of the host server. For each host,
you can view general information about the host, as well as
information about the NICs, networks, and storage associated
with the host servers.
For resource pools: Shows the properties of the available pools.

For each pool, you can view general information about the pool,
as well as information about the networks, storage, HA (High
Availability) and WLB (Workload Balancing). Also shows
configuration of virtual machines, XenServer templates, custom
templates and storage repositories.

Manually creating and deploying virtual systems takes a great deal of time and
effort. It is also potentially error prone because there are so many steps that must be
repeated during the installation of each virtual system, which varies by
virtualization platform.
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.
About deploying virtual assets

The Virtual Guest Package (VGP) and Virtual Guest Job (VGJ) lets you to create a
new virtual machine according to a specific configuration that you define or from an
existing virtual asset.
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:
Virtual Environment Whats supported

VMware vSphere You can create a new virtual system based on a VMware vCenter template or virtual
machine, or on parameters that you define by creating a VGP in the Depot
workspace. You can then use the VGJ to deploy a new VMware virtual machine on
the VMware vCenter server (which must be a BMC Server Automation managed
server).
IBM PowerVM You can create a new LPAR or VIO based on an existing LPAR or VIO server, or
based on parameters that you define by creating a VGP in the Depot workspace. You
can then use the VGJ to deploy a new LPAR/VIO on the IBM frame server, which
must be a BMC Server Automation agentless managed object (AMO).
BMC Server Automation can support objects that do not have an RSCD agent
installed, such as an IBM frame. BMC Server Automation calls these objects AMOs
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.
Solaris Zones You can create a new non-global zone based on parameters that you define by
creating a VGP in the Depot workspace. You can then use the VGJ to deploy a new
non-Global Zone on the Solaris global zone server (which must be a BMC Server
Automation managed server).
Red Hat Enterprise You can create a new virtual machine based on an existing virtual machine or on
Virtualization parameters that you define by creating a VGP in the Depot workspace. You can then
use the VGJ to deploy a new virtual machine on the RHEV Manager server (which
must be a BMC Server Automation managed server).
Red Hat KVM You can create a new domain based on an existing domain or on parameters that you
define by creating a VGP in the Depot workspace. You can then use the VGJ to
deploy a new domain on the Red Hat KVM server (which must be a BMC Server
Automation managed server).
Citrix XenServer You can create a new virtual machine by creating a VGP in the Depot workspace,
based on a XenServer template, a custom template or a virtual machine. You can
then use the VGJ to deploy a new virtual machine on the XenServer host (which
must be a BMC Server Automation AMO).
Microsoft Hyper-V You can create a new virtual system based on a Microsoft Hyper-V template, or on
parameters that you define by creating a VGP in the Depot workspace. You can then
use the VGJ to deploy a new virtual machine on the Microsoft System Center Virtual
Machine Manager (VMM) server (which must be a BMC Server Automation
managed server).

Deploying virtual systems based on existing virtual systems

To deploy a virtual system that is based on the characteristics of an existing virtual
system, you create a BLPackage that is based on an existing virtual system, edit the
BLPackage to describe the new virtual system, then deploy the BLPackage to the
host server.
Note
Note that the newly created VM will not have an operating system installed on it.
However, a VM deployed on a Citrix XenServer may have the operating system
cloned from the source VM, depending on how you configure the BLPackage.
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.
To deploy a virtual system based on an existing system
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.

3 Browse to an individual instance of the virtual system, for example

VirtualMachineX.
In the case of Citrix XenServer, you can clone only those VMs which are in the
Halted state.
4 Right-click the instance and select Add To Depot As > BLPackage.
The Create BLPackage wizard opens. In addition to whatever other BLPackage

options you choose, make sure to include the following selections:
Panel Selection
Package Type Create Package From: Live server objects
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.
6 Deploy the BLPackage:
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.
Note the following considerations when creating a BLPackage based on an

existing virtual system.

Virtual Environment Notes
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.

Virtual Environment Notes
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)
Note that rollback of a deleted disk is not supported in a RHEV environment.
Citrix XenServer Note the following considerations when creating a BLPackage that is based
on an existing virtual machine:
There must be a valid virtual machine named in the VM Name attribute

of the General node under the virtual machine.
You cannot clone a virtual machine from a virtual machine that is

currently running. The source virtual machine must be shut down prior to
creating the new virtual machine. Citrix XenServer does not support
cloning from a running virtual machine.
You cannot rename a virtual machine by deploying a BLPackage. You

must use the Rename right-click ad-hoc action.
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)
Add or delete disk
Add or delete NIC

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:
LPAR and all its child nodes
VIO and all its child nodes, except the adapter mappings and physical IO
child nodes
Solaris Zones: Non-global zone and all its 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
Citrix XenServer: Virtual machine and all its child nodes
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.
Deploying virtual systems using a Virtual Guest Package

You can build a repeatable process for deploying new virtual systems by using a
Virtual Guest Package (VGP). The VGP describes the new virtual system you want
to add.
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.
A VGP bundles configuration changes so they can be deployed to hosts/clusters

using a Virtual Guest Job. A VGP 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. 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.
You can create VGPs in the following ways:
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.
For VMware, Microsoft Hyper-V, Citrix Xenserver, and RHEV Manager

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. See Automatically creating a Virtual
Guest Package on page 873.
Before you begin
Best practice
Do not include any static IP addresses in the configuration of the VGP.
Do not include any information that is instance-specific, such as a hard-coded

host name.
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.
To create the Virtual Guest Package manually
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).
2 On the Virtual Guest Package dialog box, enter the following:
Field Description
Name Enter a name for the package.
Description Enter a brief description of the package.

Field Description
Member of Browse to the folder in the Depot where you want the VGP to be created.

Field Description
VM Guest Package type

For VMware, choose VMware Virtual Machine to configure the
package and create a new virtual machine, or select VMware
Virtual Machine/Template Clone to base it on an existing template.
For Microsoft Hyper-V, choose HyperV Bare Metal to configure the

package and create a new virtual machine, or select HyperV
Template Based to base it on an existing template.
If you selected the template based option, perform the following steps:
1 Click the Browse button to choose a template on which to base

the new virtual machine.
2 Select the server that contains the template.
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.
For Citrix XenServer, perform the following steps:
1 Click the Browse button to choose a Citrix XenServer template,

custom template, or virtual machine on which to base the new
virtual machine.
2 On the Select Citrix XenServer Template dialog box box, select

the server that contains the template or virtual machine.
3 Select the virtual machine or template type, either a XenServer-

provided template, custom template, or virtual machine.
4 Select the virtual machine or template from the displayed list,

and click OK.
For RHEV Manager, choose Baremetal to configure the package and

create a new virtual machine, or select Template Based to base it on
an existing template.

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.
4 On the Permissions panel, enter the permissions for the VGP.
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.
Virtual Guest Package permissions

Ensure that your role has the required permissions to create a VGP for a specific
platform.
The following table lists the permissions required to create a VGP for each of the
supported platforms.
Table 13: Virtual Guest Package permissions, by platform
Virtual Environment Permission
VMware vSphere VirtualGuestPackage.*

IBM PowerVM VirtualGuestPackageLpar.*
Solaris Zones VirtualGuestPackageSolaris.*
Citrix XenServer VirtualGuestPackageCitrixXen.*
Red Hat Enterprise Virtualization VirtualGuestPackageRHELKVM.*
or
VirtualGuestPackageRHEV.*
Microsoft Hyper-V VirtualGuestPackageHyperV.*

Automatically creating a Virtual Guest Package

You can use a Virtual Guest Template Enrollment Job to automatically discover
operating system templates on VMware, Microsoft Hyper-V, RHEV Manager, and
Citrix XenServer 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.
Note the following considerations for the job:
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.
Before you begin
The BMC Server AutomationAdministrator:
Must use the Virtualization Configuration panel to configure OS level default

values for the VGPs prior to executing the job.
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.
To create a Virtual Guest Package automatically
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
New Virtual Guest Template Enrollment Job - General on page 972
New Virtual Guest Template Enrollment Job - Targets on page 973

3 Optionally, click Next to display the following panels and specify options.
New Virtual Guest Template Enrollment Job - Notifications panel on page

974
New Virtual Guest Template Enrollment Job - Schedule on page 975
New Virtual Guest Template Enrollment Job Properties on page 975
New Virtual Guest Template Enrollment Job - Permissions on page 976
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.
To create default configuration settings for Virtual Guest Packages:
1 Select Configuration => Virtualization Configuration.
2 Click Add .
The Add Customization Information window opens.
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.
5 Click OK to save your configuration settings.

Add Customization Information window
The Add Customization Information window lists the available operating system-
specific settings that you can specify as default settings for Virtual Guest Packages
created by the Virtual Guest Template Enrollment Job.
Specify the following fields:
Required fields
OS Name - Select an operating system from the drop-down list.
User Name - Enter the user name for the virtual machine.
Organization - Specify an organization name for the user associated with

the virtual machines created from the VGP. For example, Development,
Customer Service, and so on.
Administrator Password and Confirm Password - Enter the local

administrators password, and then enter it again in the Confirm
Password field.
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.
When you finish adding or editing settings, click OK.

Editing a Virtual Guest Package

You can view a Virtual Guest Package (VGP) and review or change the predefined
parameters to edit the configuration of the new virtual system (for example, VM,
LPAR, non-global zone) that will be created from the package.
Depending on the Virtual Guest Type, you will see different configuration panels in
the package editor.
To edit the Virtual Guest Package
1 Select the package, right-click and choose Open.
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:
VMware specific panels on page 935
IBM specific panels on page 939
Solaris specific panels on page 947
RedHat KVM-specific panels on page 953
Red Hat Enterprise Virtualization-specific panels on page 956
Citrix XenServer specific panels on page 951
Microsoft Hyper-V-specific panels on page 958
3 Click the close icon ( ) and click OK to save the changes.
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.
Creating a Virtual Guest Job

You use a Virtual Guest Job, based on a previously created Virtual Guest Package, to
deploy a virtual machine to a target host server.

You can create a Virtual Guest Job for any of the following virtualization platforms:
VMware
IBM AIX
Solaris zones
Red Hat KVM
Red Hat Enterprise Virtualization
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.
To create a Virtual Guest Job
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.
The Virtual Guest Job wizard opens.
2 Define the Virtual Guest Job appropriate for your virtualization environment, as
Creating a Virtual Guest Job for VMware environments on page 878
Creating a Virtual Guest Job for IBM environments on page 879
Creating a Virtual Guest Job for Solaris environments on page 880
Creating a Virtual Guest Job for RedHat KVM environments on page 881
Creating a Virtual Guest Job for RedHat Enterprise Virtualization

environments on page 883
Creating a Virtual Guest Job for Citrix XenServer environments on page 884

Creating a Virtual Guest Job for Microsoft Hyper-V environments on page

886
Creating a Virtual Guest Job for VMware environments

You use a Virtual Guest Job, based on a previously created Virtual Guest Package
(VGP), to deploy a virtual machine to a target host vCenter server.
To create a Virtual Guest Job for VMware environments
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.
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
Virtual Guest Job - General on page 933
Virtual Guest Job - Virtual Guest Package Selection on page 934
3 Define the platform-specific Virtual Guest Job settings, as described in the

following sections:
VMware - Config on page 936
VMware - Settings on page 936
VMware - Network Connections on page 938

If you have chosen to customize the operating system for the new virtual guest,
the following panels are also displayed:
VM Basic Config - Microsoft Windows on page 961
VM Computer Settings on page 962
Virtual Guest Job - Schedule on page 963
Virtual Guest Job - Default Notifications on page 964
Virtual Guest Job - ACL Wizard on page 964
Virtual Guest Job - Server ACL on page 964
Virtual Guest Job - Instance Properties on page 965
Virtual Guest Job - Server Properties on page 965
Creating a Virtual Guest Job for IBM environments

(VGP), to deploy a partition to a target IBM frame.
Note
To deploy partitions, BMC Server Automation recommends that you have the
appropriate privileges on the IBM frame to which you are deploying the new partition.
To create a Virtual Guest Job for IBM environments
menu.
pop-up menu.


following sections:
IBM - General Settings on page 940
IBM - Storage on page 942
IBM - Network on page 944
IBM - Advanced on page 946
Creating a Virtual Guest Job for Solaris environments

(VGP), to deploy a nonglobal zone to a target Solaris host server.
Note
To deploy a nonglobal zone, BMC Server Automation recommends that you have
the appropriate privileges on the Solaris server to which you are deploying the new
nonglobal zone.
To create a Virtual Guest Job for Solaris environments

menu.
pop-up menu.

following sections:
Solaris - Basic on page 947
Solaris - Network Settings on page 949
Solaris - File Systems /Datasets/ Devices Settings on page 949
Solaris - Advanced on page 950
Creating a Virtual Guest Job for RedHat KVM environments

(VGP), to deploy a domain to a target RedHat server.

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
menu.
pop-up menu.

following sections:
RedHat KVM - General Settings on page 954
RedHat KVM - Storage/Network Settings on page 954

Creating a Virtual Guest Job for RedHat Enterprise

Virtualization environments
(VGP), to deploy a domain to a target RedHat server in a RedHat Enterprise
Virtualization environment.
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 in a RHEV environment
menu.
pop-up menu.

following sections:
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

Creating a Virtual Guest Job for Citrix XenServer

environments
(VGP), to deploy a virtual machine to a target Citrix XenServer host.
Note
To deploy virtual machines, BMC recommends that you have the appropriate
privileges on the host server to which you are deploying the new virtual machine.

To create a Virtual Guest Job for Citrix XenServer environments
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
Citrix XenApp on Windows
Other Install Media
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:
C:\Windows\setupapi.log (logs driver installations)
C:\Windows\setupact.log (logs installation actions)
C:\Windows\setuperr.log (logs install errors)
C:\Windows\Debug\netsetup.log (logs domain joins)
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.
pop-up menu.
2 Enter a description of the Virtual Guest Job and select the appropriate VGP, as

following sections:

Citrix XenServer - General/Memory/ Processor Settings on page 952
Citrix XenServer - Storage/Network Settings on page 953
Creating a Virtual Guest Job for Microsoft Hyper-V

environments
(VGP), to deploy a virtual guest to a target Microsoft System Center Virtual Machine
Manager (VMM) server in a Microsoft Hyper-V environment.
To deploy a domain in a Microsoft Hyper- V environment
Right-click the Job folder and select New Virtual Guest Job from the pop-up
menu.
pop-up menu.


following sections:
Microsoft Hyper-V - Basic on page 959
Microsoft Hyper-V - Storage on page 960
Microsoft Hyper-V - Network on page 960
Microsoft Hyper-V - Advanced on page 961
4 Complete the remaining wizard panels.
Modifying the Virtual Guest Job

You can modify an existing Virtual Guest Job should you need to change any of the
job properties. You can modify Virtual Guest Jobs that were created for VMware,
Solaris, IBM, Citrix XenServer, Red Hat, and Microsoft Hyper-V environments.
See the platform-specific sections below for details.
To modify the Virtual Guest Job for VMware
1 Open the Jobs folder and navigate to a Job folder.
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:

4 Close the Job, and click OK to save your revisions.
To modify the Virtual Guest Job for Solaris
settings:

To modify the Virtual Guest Job for IBM
settings:
To modify the Virtual Guest Job for Red Hat
settings:

Do one of the following, based on the Red Hat environment:
Red Hat KVM:
RedHat
KVM - General Settings on page 954
RedHat
KVM - Storage/Network Settings on page 954
Red Hat Enterprise Virtualization:
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
To modify the Virtual Guest Job for Citrix XenServer
settings:

To modify the Virtual Guest Job for Microsoft Hyper-V
settings:

Monitoring compliance in the virtual environment
Rolling back a deployment

If necessary, you can roll back a BLPackage Deploy Job, using the Undo option from
the Job Results view.
Note
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).
To roll back a deployment
1 From the Jobs folder, navigate to the Deploy Job you used to deploy the BLPackage.
2 Right-click the job and select Show Results.
3 Expand the job.
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 deployment will be rolled back.
Monitoring compliance in the virtual

environment
BMC Server Automation enables IT organizations to manage both physical and
virtual environments from one platform, allowing organizations to achieve the same
level of operational efficiency for both their physical and virtual environments.
The server auditing and compliance capabilities in BMC Server Automation involve:
detecting discrepancies between specific virtual asset configurations against a

baseline configuration through use of an Audit Job.

monitoring and detecting compliance violations between specific virtual asset

configurations against specific rules, through use of a Compliance Job.
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.
Table 14: Auditing and compliance capabilities in BMC Server Automation
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

Running Snapshot, Audit, and Compliance Jobs on virtual

infrastructure
You can run Snapshot, Audit, and Compliance Jobs on a variety of virtual
infrastructure server nodes (including clusters, hosts, AIX LPARS, VIO Servers,
Solaris non-global zones, and so on) to verify that virtual inventory configurations
meet corporate standards.
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
For additional information about remediating problem systems, see Creating a

remediation package on page 469.
Example procedure for virtual environments
You can use the general principles from the following example to perform snapshot
and audit operations on nodes in a virtual environment.
1 Follow the procedures described in Creating Snapshot Jobs on page 652 to

create the Snapshot Job.
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.

Discovering and registering assets in a virtual environment
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.
Discovering and registering assets in a virtual

environment
As an administrator of a virtual infrastructure, you want to know the state of the
virtual machines in your environment at any given time. With BMC Server
Automation, you can discover the virtual infrastructure inventory, and
automatically register each discovered host server and virtual system as a managed
server in BMC Server Automation.
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:
Managing the VM - Having a virtual machine registered in BMC Server

Automation as a managed server enables you to view operating system-specific
information about the virtual machine, and provides the ability to run Snapshot,
Audit, and Compliance Jobs against that information. In addition, you can browse
and manage the operating system and application-specific aspects of the virtual
machine directly through the BMC Server Automation console.
Controlling virtualization sprawl - Using the Virtual Infrastructure Discovery Job,

you can identify any virtual machines that are contributing to virtualization
sprawl. Virtualization sprawl is an uncontrolled growth of virtual systems, which
leads to un-managed virtual systems that consume IT resources without being
productive systems (for example, a virtual machine which is no longer associated
with a host server, but still exists on the datastore).
For details on creating the job, see Creating the Virtual Infrastructure Discovery Job
on page 898.

About the Virtual Infrastructure Discovery Job

You can run a Virtual Infrastructure Discovery Job to query the environment for
existing virtual machines, Solaris zones, or IBM virtual assets.
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)
Extended server properties created or populated by the Job

The Virtual Infrastructure Discovery Job also creates or populates the following
extended server properties:
Table 15: Extended server properties created or populated by the Job
Property type Property Name Supported for
Virtualization class properties created

Property type Property Name Supported for
CPU VIRTUAL_ENTITY_NO_OF_CPUS* VMware

Solaris zones
IBM LPARs
Memory VIRTUAL_ENTITY_MEMORY_IN_MB* VMware
Solaris zones
IBM LPARs
OS VIRTUAL_ENTITY_GUEST_OS* VMware
IBM LPARs
Resource pool VIRTUAL_ENTITY_RESOURCE_POOL* VMware
Solaris zones
Tools installed VMWARE_TOOLS_STATUS* VMware
Datastore VMWARE_DATASTORE* VMware
Cluster VMWARE_CLUSTER* VMware
Server properties populated
IP Address IP_ADDRESS VMware
Solaris zones
IBM LPARs
FQ_HOST FQ_HOST VMware
( Fully Qualified domain IBM LPARs
name of the entity )
Best-practices for setting up the job

When setting up the Virtual Infrastructure Discovery Job, ensure that you have
listed all of the host servers (vCenter servers, global zones, or AIX servers) in your
environment as Targets for the Job. To accurately capture the entire virtual
infrastructure, you must include all of the host servers.
If you have asset management information available for your virtual

infrastructure (for example, you capture specific information about the assets,
such as location or owner), you can leverage that information by creating a
mapping file and employing that mapping file in the Virtual Infrastructure
Discovery Job.
For more information, see Creating the server lifecycle properties mapping file
on page 929.

Creating the Virtual Infrastructure Discovery Job

Create and run a Virtual Infrastructure Discovery Job to automatically discover and
register the virtual machines in your environment.
Before you begin
Note the following about the Virtual Infrastructure Discovery Job:
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.
To create a Virtual Infrastructure Discovery Job
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.
3 Define the Virtual Infrastructure Discovery Job, as described in the following

sections:
Virtual Infrastructure Discovery Job - General on page 966
Virtual Infrastructure Discovery Job - Targets on page 968
Virtual Infrastructure Discovery Job - Destination Selection on page 969
Virtual Infrastructure Discovery Job - Select Lifecycle Properties Mapping on

page 969
Virtual Infrastructure Discovery Job - Notifications on page 970
Virtual Infrastructure Discovery Job - Schedules on page 970
Virtual Infrastructure Discovery Job - Properties on page 971

Virtual Infrastructure Discovery Job - Permission on page 971
Scheduling a Virtual Guest Job or Virtual Infrastructure

Discovery Job
Using the Schedule panel, you can schedule a Virtual Guest Job or Virtual
Infrastructure Discovery Job so that it runs once or recurs on an hourly, daily,
weekly, monthly, or runs on an arbitrary time interval.
To schedule a Virtual Guest Job or Virtual Infrastructure Discovery 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:
Mean Time.

Reviewing the results of the Job

After the Virtual Infrastructure Discovery Job completes, right-click the job and
select Show Results. You can then review the information discussed in the following
topics.
Missing Servers
In the Job Results pane, expand the Missing Servers node.
This view shows servers that are present in BMC Server Automation inventory but
not in virtual environment. This view shows the following information:
Name - Shows the name of the server.
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.
Status - Possible values are Still exist in BladeLogic or Decommissioned.
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
In the Job Results pane, expand the Unregistered Servers node.
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
In the Job Results view, expand the Unregistered Templates node.

Managing virtual environments
This view displays any unregistered templates discovered by the Virtual

Infrastructure Discovery Job. Each entry contains the name of the template, the
entity manager (vCenter name) and the path of the template on the datastore.
Note
The unregistered server node is available only if you selected the Discovered
Unregistered Virtual System Templates job option.
Modifying the Virtual Infrastructure Discovery Job

You can modify the properties of an existing Virtual Infrastructure Discovery Job.
To modify a Virtual Infrastructure Discovery Job
2 Right-click the Job you want to modify and select Open from the pop-up menu.
3 Modify the properties of any of the following tabs:

page 969
4 Save and close the job to complete the modification.

BMC Server Automation helps IT Operators effectively manage virtual systems in a
variety of virtual environments. This topic provides an overview of the types of

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:
Managing a VMware vSphere environment on page 902
Managing a Solaris Zones environment on page 907
Managing an IBM PowerVM environment on page 910
Managing a Microsoft Hyper-V environment on page 914
Managing a Red Hat Enterprise Virtualization environment on page 917
Managing a Citrix XenServer environment on page 923
Managing a VMware vSphere environment

You manage a VMware vSphere environment by adding a vCenter server to BMC
Server Automation. You can then browse the contents of the vCenter server, and
perform a variety of management tasks.
The available management tasks are:
Discovering virtual machines in a VMware environment - see Creating the

Virtual Infrastructure Discovery Job on page 898.
Browsing VMware virtual machines - See Browsing VMware virtual assets on

page 902.
Managing VMware virtual machines - See Executing management tasks on

VMware Virtual Machines on page 905.
Note
All management tasks for VMware hosts and virtual machines are performed
through the vCenter.
Browsing VMware virtual assets

The Live Browse capability makes it easy to see what is in your virtual inventory,
and to verify information such as the number of virtual machines on a host server,
how many are multi-NIC, and so on.

To browse VMware virtual assets
Prior to browsing VMware virtual assets, you must have distributed the vCenter
configuration object on the vCenter server, as described in BMC technical
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
1 In the Servers folder, navigate to a VMware vCenter server.
2 Right-click the server and select Browse.
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.
Table 16: Structure of the VMware vCenter Server object type
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:
configuration information about the clusters created in the vCenter server
specific server properties of the cluster, such as parent datacenter
overall status of the cluster
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 hardware, including the number of virtual processors, virtual machine

memory, CPU limit, and so on
template options, such as guest operating system type, location and name of the
configuration file, power off options, logging enablement, and so on
template server properties, such as the parent datacenter
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:
the hardware configuration, which includes virtual processors, virtual machine

memory, hperthreading sharing mode, and so on
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
resources, such as the resource pool
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.

Executing management tasks on VMware Virtual Machines

You can perform a variety of management tasks on the VMware virtual machine,
such as starting and stopping the virtual machine.
Available management tasks in a VMware vSphere environment
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.
Table 17: Status icons for VMware virtual machines
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.
Table 18: Management tasks for VMware virtual machines
Task Description
Snapshot See Running Snapshot, Audit, and Compliance Jobs on virtual

infrastructure on page 894.
Audit
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.
Suspend Pause a virtual machine that is running.

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.
Snapshotvm See Saving a virtual servers state on page 906.
Delete Delete a virtual machine.
Properties Displays a read-only view of the virtual machine properties, such as

path, power status, connection state, and so on.
Saving a virtual servers state

You can save the state of a virtual server to disk by taking a virtual machine state
snapshot. The snapshot can optionally include the virtual machines memory state.
You can use VMwares Virtual Infrastructure Client to view the snapshot. The
snapshot is stored in the following location:
VMware/Virtual Machines/vmName/Options/General/Snapshot Directory
where vmName is the name of a virtual server.
To create a Virtual Machine state snapshot
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.
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.

Viewing vCenter server properties

After adding a vCenter server to BMC Server Automation, you can view the server
properties of a VM or ESX host on that vCenter server. Using the Parent Host, Parent
Datacenter, and Parent Cluster properties, you can determine the location of virtual
machines and ESX hosts in the vCenter hierarchy.
To view vCenter server properties
1 In the Servers folder, navigate to a vCenter server and expand the Live node.
2 Expand the VMware vCenter Server object type.
3 Browse to a virtual machine or ESX host.
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:
Server Object Properties
Virtual machine
Parent Host
Parent Datacenter
Parent Cluster (if part of a cluster)
ESX host
Parent Datacenter
Parent Cluster (if part of a cluster)
Managing a Solaris Zones environment

You manage a Solaris zones environment by adding a Solaris zones host server to
BMC Server Automation. You can then browse the contents of the Solaris zones
server, and perform a variety of management tasks:
Note
BMC Server Automation supports Solaris zones environments, but does not support
Solaris Logical Domains (LDoms).

For more information, see Browsing Solaris zones on page 908 and Executing
management tasks on Solaris zones on page 909.
Browsing Solaris zones

You can browse a Solaris zones server to review a variety of server objects (such as
project, resource pool, and configuration information) related to the Solaris zones
virtual environment.
To browse a Solaris zones server
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.
1 In the Servers folder, navigate to a Solaris zones server.
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.
Table 19: Structure of the Global Zones object type
View Description
Non-global Zones This view displays all nonglobal zones. For each nonglobal zone, the content editor
displays:
Zone Hardware: Displays information about CPU, devices, memory statistics,

and network configuration.
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.
Projects Displays the settings and attributes for each project.

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.
Executing management tasks on Solaris zones

You can perform a variety of management tasks on the Solaris zones, such as starting
and stopping nonglobal zones.
To execute management tasks on a Solaris zone
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.
Table 20: Status icons for nonglobal zones
Task Description
Running
Configured
Ready
Installed
Incomplete
3 Right-click a nonglobal zone. From the pop-up menu, select any of the
Table 21: Management tasks for nonglobal zones
Task Description

Audit
Install Installs a nonglobal zone.
Uninstall Uninstalls a zone.

Task Description
Halt Halts a zone.
Reboot Halts and then boots a zone.
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.
Incomplete Changes the state of an installed nonglobal zone to "incomplete". If

administrative changes on the system have rendered a zone unusable
or inconsistent, you can change the state of an installed zone to
Incomplete.
Note: Marking a zone as Incomplete is an irreversible action. The only
action that you can perform on a zone marked incomplete is to
uninstall the zone and return it to the configured state.
Delete Deletes the nonglobal zone.
Properties Displays a read-only view of the non-global zone properties, such as

path, zone status, resource pool, and so on.
Managing an IBM PowerVM environment

For IBM PowerVM environments, you configure an AIX server to act as a proxy
server to manage devices which do not have installed RSCD agents, such as an IBM
frame. After the proxy server is configured, you can add an IBM frame object in the
BMC Server Automation console and mange it as you would other top-level server
objects, such a VMware vCenter server.
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.

Browsing IBM PowerVM Virtual Assets

You can browse an IBM frame server to review a variety of server objects (such as
LPAR, pool, and configuration information) related to the IBM frame virtual
environment.
To browse an IBM frame
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.
1 In the Servers folder, navigate to the IBM frame server.
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.
Table 22: Structure of the IBM Configuration object type
View Description
Configuration Shows information about the following characteristics of the frame:
Connections: Displays information about the connection such as IP address,

service processor role and the status of the connection.
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:
Adapter mapping: Displays information about the type of adapters configured

for the VIO server, such as Net Server and SCSI Server adapter mappings
(including information about the virtual target devices).
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 hardware: Memory settings, CPU configuration information, physical

adapters, and virtual adapters.
Profile options: general information such as LPAR name and ID,

environment, LPAR I/O Pool IDs, maximum virtual slots, Work Group ID
and so on.
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).
Hardware: Displays various hardware information for the LPAR, such as

Physical adapters, Physical IO, Virtual adapters, CPU, and Memory.
Other: Displays information such as workgroup ID and power control

information (such as Maximum Power Control).
Server Properties: Displays information about the server, such as managed

system name, partition host name, OS version, IP address, model type, and HMC
version.
Executing management tasks on IBM virtual assets

You can perform a variety of management tasks on the LPARs that are part of the
IBM frame, such as stopping and starting the LPAR.
To execute management tasks on an IBM frame
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.
Table 23: Status icons for LPARs
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.
Table 24: Management tasks for IBM LPARs
Task Description

Audit
Delete Delete the LPAR.
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.
Properties Displays a read-only view of the VM properties, such as path, power

status, connection state, and so on.
Managing a Microsoft Hyper-V environment

You manage a Microsoft Hyper-V environment by adding a Microsoft System Center
Virtual Machine Manager (VMM) server to BMC Server Automation. You can then
browse the contents of the VMM server, and perform a variety of management tasks.
For more information, see Browsing Hyper-V virtual machines on page 915 and
Executing management tasks on Microsoft virtual machines on page 916.

Browsing Hyper-V virtual machines

You can browse a VMM server to review a variety of server objects (such as cluster,
host and configuration information) related to the Hyper-V virtual environment.
To browse a VMM server
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.
1 In the Servers folder, navigate to a VMM server.
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.
Table 25: Structure of the Microsoft VMM 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:
Networks: This item shows network configuration information such as network

name, network bindings, the host access enabled value, and VLAN ID.
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.
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.
Executing management tasks on Microsoft virtual machines

You can perform a variety of management tasks on the Microsoft virtual machine,
such as starting and stopping a virtual machine.
To execute management tasks on a VMM server
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.
VMM server. The icons indicate the status of the virtual machine.
Table 26: Status icons for Hyper-V virtual machines
Task Description
Running
Stopped
Paused

Table 27: Management tasks for Hyper-V virtual machines
Task Description

Audit
Start Starts the virtual machine.
Guest Shutdown Run any power-down scripts and then stop a virtual machine.
Stop Perform an immediate stop of the virtual machine, without running

any power-down scripts.
Suspend Pause the virtual machine.
Resume Starts a paused virtual machine.
SaveState Save the virtual machine's state to hard disk.
DiscardSaveState Discard the saved state from hard disk.
Snapshot virtual machine Create a snapshot for the virtual machine.
Rename Renames the virtual machine.
Delete Deletes the virtual machine.

path and virtual machine status.
Managing a Red Hat Enterprise Virtualization environment

You manage a Red Hat Enterprise Virtualization (RHEV) environment by adding a
host server running RHEV to BMC Server Automation. You can then browse the
contents of the RHEV Manager or RHEL KVM server object type, and perform a
variety of management tasks, such as creating, modifying, and deleting a domain.
BMC Server Automation supports both Red Hat Enterprise Virtualization platforms,
Red Hat KVM and Red Hat Enterprise Virtualization Manager for Servers (RHEV
Manager).
For information about configuring theBMC Server Automation environment for

RHEV, see BMC technical documentation at https://docs.bmc.com/docs/display/
bsa82/Home. For more information about managing the environment, see:
Browsing Red Hat KVM server and RHEV Manager servers on page 918
Executing management tasks on RHEV servers on page 921

Browsing Red Hat KVM server and RHEV Manager servers

You can browse Red Hat KVM servers and RHEV Manager servers to review a
variety of server objects (such as domains, storage pools, and network
configurations) related to the Red Hat Enterprise Virtualization environment.
Note
Live Browse of hosts running Red Hat Enterprise Linux (and the domains or virtual
machines on those hosts) requires that a Red Hat KVM agent or RHEV Manager
agent is installed on the RH KVM Hypervisor or RHEV Manager server, and that the
appropriate configuration objects were distributed to the host system. For more
display/bsa82/Home.
To browse a Red Hat KVM host
1 In the Servers folder, navigate to the server running RedHat KVM.
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.
Table 28: Structure of the RHEL KVM object type
View Description
Networks Lists all the networks connected to the Red Hat KVM host server. For each host
server, you can view:
Network Bridges: Lists various network configuration information for the

network bridge, such as name, bridge name, bridge ID, STP enabled, and interfaces.
Virtual Networks: Lists various network configuration information for the

virtual network, such as name, network name, UUID, network status, network
autostart, bridge name, forward device, forward mode, STP, forward delay, IP
address, netmask, DHCP start, and DHCP end.

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:
Hardware: The hardware configuration, which includes number of CPUs, CPU

type, CPU priority, memory statistics, storage devices, network devices, and so on.
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.
To browse a RHEV Manager server
1 In the Servers folder, navigate to the server running RHEV Manager.
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.
Table 29: Structure of the RHEV Manager 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
Storages available to the host servers
Networks connected to the host servers
Specific server properties of the cluster, such as parent datacenter for the cluster
Basic identifying information, such as cluster name and description
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
Overall status of the data center
Basic identifying information, such as data center name and description
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
Overall status of the host
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.
Network: Displays network configuration information for the virtual machine,

such as network name, MAC address, and adapter type.
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
Memory: Displays the allocated memory for the virtual machine
RHEV-M Shows information about the RHEV Manager version

Configuration
Executing management tasks on RHEV servers

You manage a Red Hat Enterprise Virtualization environment by adding a host
server running Red Hat Kernel-based Virtual Machine (KVM) or RHEV Manager to
BMC Server Automation. You can then browse the contents of the RHEL KVM or
RHEV Manager server object type, and perform a variety of management tasks, such
as creating, modifying, and deleting a domain.
BMC Server Automation supports both Red Hat Enterprise Virtualization platforms,
Red Hat KVM and Red Hat Enterprise Virtualization Manager for Servers (RHEV
Manager).
To execute management tasks on a Red Hat KVM server
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.

Table 30: Status icons for Red Hat KVM domains
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.
Table 31: Management tasks for Red Hat KVM domains
Task Description

Audit
Run Starts a domain.
Pause Pauses the domain.
Resume Starts a domain that is paused.
Shut down Run any power-down scripts and then stop a domain.
Force off Forces the domain offline.
Delete Deletes the domain.
Properties Displays a read-only view of the domain properties, such as path,

UUID, domain status and various start and reboot options.
To execute management tasks on a RHEV Manager server
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.

Table 32: Status icons for RHEV Manager virtual machines
Task Description
Running
Stopped
Paused
Table 33: Management tasks for RHEV Manager virtual machines
Task Description
Snapshot and Audit See Running Snapshot, Audit, and Compliance Jobs on virtual
Start Starts a virtual machine.
Stop Stops a virtual machine.
Guest Shutdown Run any power-down scripts and then stop a virtual machine.
Suspend Pauses a virtual machine.
Snapshot VirtualMachine Takes a snapshot of the configuration of a virtual machine.
Rename Renames a virtual machine.
Delete Deletes the virtual machine

path, UUID, virtual machine status and various start and reboot options.
Managing a Citrix XenServer environment

You manage a Citrix XenServer environment by configuring a RedHat Enterprise
Linux server (version 5.4 or later) to act as a proxy server, creating a Citrix XenServer
host agentless managed object, and adding it to BMC Server Automation as an
Agentless Managed Object.
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:

Browsing Citrix XenServer hosts on page 924
Executing management tasks on Citrix XenServer on page 926
Browsing Citrix XenServer hosts

From the Citrix XenServer agentless managed object, you can browse a Citrix
XenServer host to review a variety of server objects (such as Virtual Machines,
Custom Templates, and XenServer Templates).
To browse a Citrix XenServer host
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://
1 In the Servers folder, navigate to the Citrix XenServer agentless managed object.
2 Right-click the server object and select Browse.
4 Expand the Citrix XenServer server object type to display the nodes.
If your XenServer environment is configured to use resource pools, then a Pool

Configuration object is displayed. If you do not have a pool configuration, then
the display shows a list of hosts.
5 Expand a host. The following table describes the structure of the host server.
Table 34: Structure of the host server object
View Description
Custom Templates Contains the custom templates resident on the host.

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.
Network - Displays network configuration information 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.
6 Expand the XenServer Templates object type.
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.
7 Expand the resource pool object, if available to display information of the

resource pool configuration. The following table describes the structure of the
Pool Configuration object type.

Table 35: Structure of the resource pool object
View Description
Pool Configuration Shows information about the following characteristics of the Pool:
General: Displays general properties for the pool, such as memory

configuration, version information, license information, number of CPUs and
management information.
Pool Storage: Displays information about all of the removable storage, local
storage, and DVD drives that are available under the pool.
Pool Network: Displays network configuration information for the pool.
Pool HA: Displays configuration of the High Availability features configured on

the Pool (if the license providing this feature is applied to the hosts).
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 Custom Contains the custom templates resident in the pool.

Templates
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.
Executing management tasks on Citrix XenServer

You can perform a variety of management tasks when managing a Citrix Xenserver
environment, such as starting, stopping, and renaming a virtual machine.

To execute management tasks on Citrix XenServer
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.
Table 36: Status icons for XenServer virtual machines
Task Description
Running
Halted
Suspended
Rebooted
Snapshot
Table 37: Management tasks for XenServer virtual machines
Task Description
Start Starts a virtual machine.
Shutdown Shuts down theoperating system on the virtual machine (if present),
and then powers off the virtual machine.
Force shutdown Immediately powers off a 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
Convert to template Converts a virtual machine into a custom template.
Suspend Stops a virtual machine.

Managing virtualization sprawl
Task Description
Resume Starts a virtual machine that has been suspended.
Rename Renames the virtual machine. You cannot rename a virtual machine by
deploying a BLPackage. You must use the Rename ad-hoc action.
Delete Deletes the virtual machine.

path, status and various start and reboot options.
4 When you right-click a XenServer Custom Template, you can select the Delete
Template option.
There are no management actions available for a XenServer Template.

As an administrator of a virtual infrastructure, you want to know the state of the
virtual machines in your environment at any given time. With BMC Server
Automation, you can discover the virtual infrastructure inventory, and identify any
virtual machines or zones that are contributing to virtualization sprawl.
Virtualization sprawl is an uncontrolled growth of virtual systems, which leads to un-

managed virtual systems that consume IT resources without being productive
systems (for example, a virtual machine which is no longer associated with a host
server, but still exists on the datastore).
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.
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.

Creating the server lifecycle properties mapping file

To use the Import Lifecycle Properties option on the Virtual Infrastructure Discovery
Job, you must create a properties mapping file for the lifecycle properties.
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.
Before you begin
Note the following considerations when creating the file:
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.
The Name parameter for the VirtualEntityManager element shown in Figure 9 on

page 929 must match the name provided in the CONNECTION_URL of the
Connection property set instance of the virtual entity manager.
Note
If a server has been renamed, you must manually change the Connection
property set instance value to the renamed server name for the Virtual
Infrastructure Discovery Job remediation target and Import Lifecycle options to
execute successfully.
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.
3 Set the isMap attribute for each property.
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.
5 Create the Virtual Infrastructure Discovery Job as described in Creating the

Virtual Infrastructure Discovery Job on page 898, selecting the Import Lifecycle
Properties option, and specifying the mapping file on the Select Lifecycle
Properties Mapping panel.
6 Run the job.

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.
Generating reports for virtualization

Through the BMC BladeLogic Decision Support for Server Automation application,
you can generate web-based reports that summarize the data derived from the
Virtual Infrastructure Discovery Job.
To generate reports for virtualization
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
BMC Server Automation Server Report column Description

Property name
VIRTUAL_ENTITY_ID ID Shows information about the following

characteristics of the frame:
VIRTUAL_ENTITY_TYPE Type The type of Virtual Entity (for example, HMC,

vCenter, ESX Host, global zone, frame, VM, zone,
LPAR).
Number Of Virtual Shows the total of the VIRTUAL_ENTITY_TYPE

Machines property.

Virtual Guest Job Wizard Panels
BMC Server Automation Server Report column Description

Property name
VIRTUAL_ENTITY_ Hypervisor The property set instance of the container of the

CONTAINER virtual entity (for example, ESX host, global zone).
LOCATION Location Location of the server.
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.
RECONCILIATION_ID Reconciliation ID The reconciliation identifier from CMDB.
OWNER Owner The owner of the server.
Ownership Status Returns the ownership status as Has owner or No

owner. This value is determined from the OWNER
property.
EXPIRY_DATE Expiry Date The date when the server is supposed to expire (or
the date when the lease lapses).
Expiry Status Returns the expiration status as Has Expiry or No

Expiry. This value is determined from the EXPIRY
property.
Days To Expiry Shows the number of days remaining until

expiration. This value is calculated from the
difference between the expiration date and the
current date.
Months To Expiry Shows the number of months remaining until

expiration. This value is calculated from the
difference between the expiration date and the
current date, in months.
IS_VIRTUAL Is Virtual Tells whether the server is virtual machine (returns

true or false).
Virtualization Returns whether machine is virtual machine. This

Status value is determined from the IS_VIRTUAL property.

You can create a Virtual Guest Job to deploy a virtual machine to a target host server.

The Virtual Guest Job wizard consists of the following panels:
VMware specific panels on page 935
IBM specific panels on page 939
Solaris specific panels on page 947
Citrix XenServer specific panels on page 951
RedHat KVM-specific panels on page 953
Red Hat Enterprise Virtualization-specific panels on page 956
Microsoft Hyper-V-specific panels on page 958
For more information about the Virtual Guest Job, see Deploying virtual systems
using a Virtual Guest Package on page 868.
Virtual Guest Job - General

The General panel lets you provide information that identifies a Virtual Guest Job.

Field definitions
Name
Identifying name.
Description
Save in

Virtual Guest Job - Virtual Guest Package Selection

The Virtual Guest Package Selection panel lets you choose the virtual guest package
to use for the Virtual Guest Job.
Selecting the virtual guest package

Do the following:
1 Choose the virtual guest package to use for the Job.
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 specific panels

In the Virtual Guest Job wizard and in the Virtual Guest Package editor, there are
some panels that are specific to the VMware/vCenter environment.
The following panels are specific to the VMware/vCenter environment:

VM Basic Config - Linux on page 962
Run Once Script on page 939
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.
Under Virtual Machine Configuration, choose one of the following:
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
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.
Under Guest Operating System, specify the following:
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.

On this panel, you can:
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.
Increase or decrease the memory 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.
Virtual Processor and Memory Configuration
Number of virtual processors - Select the virtual number of virtual

processors that will be dedicated to this virtual machine from the drop-down
list.
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.
Thin Provisioned format - 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 by the VMFS 3 driver 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.
Note
This option is support only for VMFS 3 and higher data stores.
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.
Virtual Disk Configuration
Do not create a disk
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.
VMware - Network Connections

The Network Connections panel lets you specify the network connections and
networking parameters like network port groups and adaptor type. This panel is
available in the Virtual Guest Job wizard and in the Virtual Guest Package.
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
Click Add ( ) to display the Add Network Connection dialog box.
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.
Under Network Connection, add any of the following:
VC Servers - Select a vCenter server from the drop-down list.
Network - Select from the networks attached to the selected vCenter.
Adapter - Choose the adapter type from the drop-down list.
Connect at power on - Enable this option to have the virtual machine

connect to the network when it is powered on.
Under IP Configuration, choose to have the IP address obtained

automatically using Dynamic Host Configuration Protocol (DHCP), or
choose to use a specific IP address by specifying the following:
IP Address

Subnet mask
Default gateway
Under DNS Configuration, choose to have the DNS server obtained

automatically, or to use a specific server by specifying the following:
Primary DNS server
Secondary DNS server
Run Once Script

The Run Once Script panel lets you specify optional RunOnce commands in a
VMware Virtual Guest Package for VMware Windows-based virtual machines
created using a template or from existing Virtual Machines.
To add a RunOnce command to a Virtual Guest Package, do the following:
1 In the Virtual Guest Package editor, select the Run Once Script tab.
2 Click the browse button. The Edit panel is displayed.
Enter the RunOnce command in the edit window.
Click Import to import the command from a script.
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 specific panels

some panels that are specific to the IBM environment.

The following panels are specific to the IBM environment:
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)
IBM - Physical I/O on page 945
IBM - General Settings

The General Settings panel lets you specify identification information, processor
settings, and memory settings for the LPAR.
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:
Minimum processors units
Desired processors units
Maximum processors units
Number of Virtual Processors
Use the following settings to set the range of processors available to the
partition.
Minimum processors
Desired processors
Maximum processors
Shared Processor Pool:
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:
The partition can be capped or uncapped. A capped system has a maximum

amount of CPU from the shared pool that can be allocated to it. An uncapped
system can use more processing units than is currently configured for it if
there is spare capacity in the pool. An uncapped system can use up to 100%
of the number of currently configured virtual processors.
If you specified that the partition is uncapped, enter a number to indicate

how to distribute shared processing power relative to other uncapped
systems. For example, a partition with a weight of 128 would get a greater
percentage of the available processing power than a partition with a weight
of 80.
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
Virtual Fiber Channel Adapters
Virtual Serial Adapters
Click Add ( ) to add any of the following types of virtual adapters:
Virtual adapter type Specify
Virtual SCSI Adapters On the Create Virtual SCSI Adapter dialog, specify:
Remote partition - Select the remote partition from the drop-down

list. If the partition is an LPAR, the remote partition is a VIO server.
If the partition is a VIO server, the remote partition is an LPAR. You
create a mapping from the client partition to the remote partition by
entering the remote adapter ID.
Remote adapter ID - Enter the virtual slot ID for the remote partition.

Virtual adapter type Specify
Virtual Fiber Channel Adapters On the Create Virtual Fiber Channel Adapter dialog, specify:
Select Frame - Select the frame from the drop-down list.
Adapter ID - Enter the ID for the virtual fiber channel adapter.
Adapter type - Shows the type of adapter.

Virtual Serial Adapters On the Create Virtual Serial Adapter dialog, specify:

IBM - Storage (automatic management)

If you selected the Automatically manage storage virtual server adapters option in
the Virtual Guest Package wizard, the Storage panel lets you specify the storage
settings appropriate for the new LPAR.
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:
Add a virtual disk
Add a physical volume
Attach a Fiber Channel HBA port to access SAN LUNs
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.

Storage type Specify
Virtual Disk On the Virtual Disk dialog box, specify:
Name - Enter a name for the virtual disk. You are

not required to enter a name; if a name is not
specified, one is generated automatically.
Location - Browse to a location for the virtual disk.
Size - Enter a maximum size for the disk.
Physical Volume On the Physical Volume dialog box, browse and

select an existing physical volume.
Fiber Channel Port On the Fiber Channel Port dialog box, browse and
select an existing port to attach a SAN LUN to an
LPAR through a fiber channel adapter.
BMC Server Automation supports N_Port ID
Virtualization (NPIV). NPIV provides the capability
to assign a physical fiber channel adapter to multiple
unique worldwide port names (WWPNs). To access
physical storage from a storage area network (SAN),
the storage is mapped to logical unit numbers
(LUNs), which are mapped to the ports of the
physical fiber channel adapters.
IBM - Network
The Network panel lets you select the virtual adapter settings appropriate for the
new LPAR.
Click Add ( ) to add any of the following types of virtual adapters:
Virtual Ethernet Adapter
On the Select Virtual Ethernet Adapter dialog box, specify:
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
VLAN ID - Enter the unique identification of the Virtual Local Area

Network (VLAN), which is a logical network on a physical or virtual switch.
IEEE 802.1q compatible adapter - Select this option to configure the

virtual Ethernet adapter to communicate over multiple VLANs. IEEE
802.1Q is the networking standard that allows multiple bridges networks

to transparently share the same physical network link, without

information being leaked between networks.
Logical Host Ethernet Adapter
Click Add to add one or more LHEAs. On the Select Logical Host Ethernet
Adapter dialog box, specify:
Select Frame - Select a frame from the drop-down list.
Adapter ID - Set the unique identifier for the LHEA.
Physical Port - Select a port from the drop-down list.
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.
IBM - Physical I/O

The Physical I/O panel lets you add the physical devices appropriate for the new
LPAR.
Field definitions
Under Physical IO, click Add ( ) to add one or more physical devices.
On the Select Physical IO panel, do the following:
IO Pool ID
Optionally, specify the I/O pool if you want to assign the physical I/O slot to
an I/O pool.

Add Physical IO to Partition Profile
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.
Select DRC Index
Select the 8-character hexadecimal string that represents the dynamic

reconfiguration connector (DRC) index of the current console adapter from
the DRC Index list at the bottom of the panel. The string you select is
populated into the DRC Index field above the list.
IBM - Advanced
The Advanced panel lets you specify optional settings for the LPAR.
Field definitions
Active Memory Expansion Settings
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:
Primary and Seconday Paging VIOS - Browse to the location of a VIOS

server that will be the primary paging virtual I/O servers (VIOS) for the
partition. Optionally, you can add a secondary paging server. A Paging
VIOSprovides paging services for the shared memory pool and manages
the Hypervisor paging spaces for LPARs using shared memory.
Memory Weight - Use the arrows to specify a number to indicate how to

distribute shared memory, relative to the other LPARs. The higher the

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
Specify any of the following settings:
Enable Connection Monitoring - This option enables the monitoring of

the communication paths between your HMC and the systems that it
manages.
Enable Redundant Error Path Reporting - This option enables a logical

partition to report common server hardware errors and partition
hardware errors to the HMC.
Boot mode - Specify the boot mode for the LPAR.
Workload group - Click browse to specify a workload group for the

partition. A partition workload group identifies a set of partitions that
reside on the same physical system. Assigning the partition to a workload
group enables dynamic allocation of processing power for the partitions
based on the goals defined in the domain policy. Default value: blank.
Solaris specific panels

some panels that are specific to the Solaris environment.
The following panels are specific to the Solaris environment:
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
Select Customize to specify any of the following settings:
Processor Type - Select Capped or Dedicated.
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.
Dedicated allocates a subset of the systems processors for exclusive use

by the zone while it is running. Enter a positive integer, positive
decimal (with two digits to the right of the decimal), or a range in the
Number of CPUs or Range field to represent the number of dedicated
CPUs for the zone.
Number of CPUs or Range - If you specified a CPU range, enter a positive

integer or positive decimal (with two digits to the right of the decimal) in
the Importance field.
Importance - The Importance field defines the relative importance of the

dynamic resource pool.
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
Solaris - Network Settings

The Network Settings panel lets you select the network settings appropriate for the
new zone.
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
Solaris - File Systems /Datasets/ Devices Settings

The File Systems /Datasets/ Devices panel lets you select the storage and physical
devices settings appropriate for the new zone.
Click Add ( ) to add any of the following types of devices:
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
ZFS Data Sets
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
Specify the Zone Type (Sparse Root or Whole Root).
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.
Click Add ( ) to specify additional directories to copy into the zone.
Solaris - Advanced
The Advanced panel lets you specify additional settings for the Zone.
Advanced Settings
Specify any of the following 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.
Limit Privileges - Enter a privilege restriction you want applied to the

zone. For example, enter PRIV_PROC_ZONE to allow a process to trace or
send signals to processes in other zones. 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)
FSS (Fair Share Scheduler)
FX (Fixed Priority)
SYS (System)
RT (Real Time)
Devices
Click Add to specify additional devices on the File Systems/Data Sets/

Devices Settings Dialog panel. Each zone can have devices that are
configured when the zone transitions from the installed state to the ready
state. Specify the path to a device in the Match field to make the device
available and dedicated to the zone.
For example, Match=dev/pts
Resource Controls
Click Add ( ) to specify a zone-wide resource control on the Additional

Configuration Dialog panel. For example, you can specify a maximum
number of LWPs that will be simultaneously available to the task's processes
by entering the following:
Name: name=zone .max-lwps
Value: priv=privileged,limit=100,action=deny
Custom Attributes
Click Add ( ) to specify additional attributes.
Citrix XenServer specific panels

some panels that are specific to the Citrix XenServer environment.
The following panels are specific to the Citrix XenServer environment:

Citrix XenServer - General/Memory/ Processor Settings

The General/Memory/ Processor Settings panel lets you specify identification
information and processor and memory settings for the virtual machine.
Field definitions
General settings
Specify the following:
Virtual Machine Name
Virtual Machine Description
Source VM/Template Name - Read-only field based on the selected VM/

template.
Note
If you select a template with a name that exists both as XenServer and custom
templates, preference is given to the custom template, which is used as a
reference during the deploy operation.
Source VM/Template Description - Read-only field based on the selected

VM/template.
Note
If the template is from a server running XenServer 5.5, the Template
Description shown on this panel may not match the template description
shown in XenCenter.
Processor and Memory Settings
Select the following:
Number of VCPUs
Initial Memory (MB)

Under Boot Settings, specify any advanced boot parameters.
Auto Start - Automatically starts the new virtual machine as soon as the
host is booted.
Citrix XenServer - Storage/Network Settings

The Storage/Network Settings panel lets you specify storage and network settings
appropriate for the new virtual machine.
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:
Server - Select a server from the drop-down list.
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.
RedHat KVM-specific panels

In the Virtual Guest Job wizard and the Virtual Guest Package editor, there are some
panels that are specific the the RedHat KVM environment.

The following panels are specific to the RedHat KVM environment:
RedHat KVM - General Settings on page 954
RedHat KVM - Storage/Network Settings on page 954
RedHat KVM - General Settings

The General Settings panel lets you specify identification information and processor
and memory settings for the domain.
Field definitions
General
Specify a name for the Domain.
Processor/ Memory Settings
Select any of the following:
Number of VCPUs
VM Max Memory (MB)
VM Startup Memory (MB)
CPU Architecture
Boot Automatically
RedHat KVM - Storage/Network Settings

The Storage/Network Settings panel lets you specify storage and network settings
appropriate for the new domain.
Field definitions
Storage Details:
Click Add ( ) to open the Storage Details dialog box, where you can add
Storage Type - Select File Image or Block Partition.

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.
Target Device Type (Disk, CD-ROM, or Floppy)
Target Device Bus (IDE, SCSI, and so on)
Note
For a Target Device Type of CDROM and Floppy, the Target Device Bus must
be IDE.
Network/ Bridge Details:
Click Add to open the Network Details dialog box and add any of the following:
Server
Network Type
Network Name
Auto-generate MAC Address
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.
Use this MAC Address
Device Model

Red Hat Enterprise Virtualization-specific panels

some panels that are specific to the Red Hat Enterprise Virtualization Manager
environment.
The following panels are specific to the Red Hat Enterprise Virtualization environment:
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
Red Hat Enterprise Virtualization - Basic

The Basic panel lets you specify identification information, processor, and memory
settings for the virtual guest.
General Settings
Virtual Guest Name
Virtual Guest Description
Virtual Guest Storage - Use the Browse button to select storage for the
virtual machine.
Source Template - Read-only field based on the selected VM or template.
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.
Processor and Memory Settings
Select the following:
Number of CPU sockets

Cores per socket
Total Cores (Read-only)
Memory (MB)
Power On VM after Creation - Automatically starts the new virtual guest.
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.
Red Hat Enterprise Virtualization - Storage

The Storage panel lets you specify storage settings, such as disk name and storage
key, that are appropriate for the new virtual guest.
Virtual Disk
Click Add ( ) to display the Select Storage dialog box, select a server from
the drop-down list and specify the following::
Size - Enter a disk size, in GB.
Storage - Browse to select a storage location.
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.
Red Hat Enterprise Virtualization - Network

The Network panel lets you specify network settings appropriate for the new virtual
guest.
Virtual Network Interface
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.
Under IP Configuration, choose to have the IP address obtained

automatically using Dynamic Host Configuration Protocol (DHCP), or
choose to use a specific IP address by specifying the following:
IP address
Subnet mask
Default gateway
Under DNS configuration, choose to have the Domain Name System

(DNS) server obtained automatically, or specify the following to use a
specific server:
Primary DNS Server
Secondary DNS Server
Tertiary DNS Server
Red Hat Enterprise Virtualization - Advanced

The Advanced panel lets you specify additional settings, such as disk interface type,
for the new virtual guest.
Advanced Settings
Specify any of the following:
HA Priority - Select a high-availability (HA) failover priority for the

virtual guest. Because an HA service can run on only one cluster node at a
time, select the failover priority for this virtual guest, relative to others.
Select Disabled (the default), if you are not using HA services.
Disk Interface Type - Select the interface type for the guest virtual disk.
Network Adapter Type - Select the adapter type for the guest virtual
network.
Microsoft Hyper-V-specific panels

In the Virtual Guest Job wizard and the Virtual Guest Package editor, there are some
panels that are specific to the Microsoft Hyper-V environment.

The following panels are specific the the Microsoft Hyper-V environment:
Microsoft Hyper-V - Basic

Both the Basic Wizard panel in the Virtual Guest Job wizard and the Basic panel in
the Virtual Guest Package editor 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 Guest Name.
Under General Settings, specify the following:
Virtual Guest Name - Enter a name for the virtual machine.
Virtual Guest Description - Optionally enter a short description of the virtual

machine.
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.
Power On VM after Creation - Automatically starts the new 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).
Microsoft Hyper-V - Storage

The Storage panel lets you specify storage settings, such as disk size and storage key,
that are appropriate for the new virtual guest.
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:
Size - Enter a disk size, in GB.
Storage - Browse to select a storage location.
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.
Microsoft Hyper-V - Network

The Network panel lets you specify network settings appropriate for the new virtual
guest.
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.
Under VLAN ID, enter a Virtual Local Area Network.
Microsoft Hyper-V - Advanced

The Advanced panel lets you specify additional settings, such as network adapter
type, for the new virtual guest.
CPU Priority - Choose high, medium, or low priority
Network Adapter Type - Choose from default, emulated, or synthetic.
VM Basic Config - Microsoft Windows

The VM Basic Config panel lets you specify the guest OS basic configuration
information like computer name, admin password, workgroup and domain
registration-related information for VMware, Citrix XenServer, Microsoft Hyper-V,
and Red Hat Enterprise Virtualization platforms. This panel appears only if the
Virtual Guest Package is based on a template.
The fields you see on this panel depend on the operating system type chosen for the
virtual machine.
Fields for Microsoft Windows operating systems
Under Local Settings, specify the following:
Computer name - Enter a name for the virtual machine or choose to

have the name auto-generated.
Administrator password - Enter a password for the Administrator user

account, and confirm the password by entering it again in the Confirm
password field.
Under Workgroup or Domain, choose to add the virtual machine to a

workgroup or a domain.
Workgroup - enter the name of the workgroup to which you want to

add 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.
VM Basic Config - Linux

The VM Basic Config panel for Linux operating systems lets you specify the guest
OS basic configuration information hostname and domain registration-related
information for VMware, Citrix XenServer, and Red Hat Enterprise Virtualization
platforms.
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 Computer Settings, specify the following:
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.
Under User Information, specify any of the following:

Name - Enter a name for the primary user of the virtual machine.
Organization - Enter a brief description of the organization to which the user

belongs.
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.
Virtual Guest Job - Schedule

On the Schedule panel, choose Execute Job Now or click Add ( ) to define a
schedule for this Virtual Guest Job.
Scheduling a job
The Schedule tab lets you schedule a job so it can run once, recur hourly,
information, see Scheduling jobs on page 1098.
a scheduled job runs. For more information, see Scheduled Job

Virtual Guest Job - Default Notifications

notifications. Default notifications can also provide information about Virtual Guest
Job results.
On the Notifications panel, optionally specify email or trap notifications for the Job.
Virtual Guest Job - ACL Wizard

Using the ACL Wizard panel, you can add individual permissions to a Virtual Guest
Job. You can also set permissions by adding ACL templates or ACL policies.
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.
Virtual Guest Job - Server ACL

Using the Server ACL panel, you can set the server access permissions for the virtual
guest. You can also set permissions by adding ACL templates or ACL policies.
Virtual Guest Job. ACLs control access to all objects, including the sharing of objects
between roles.

Virtual Infrastructure Discovery Job Wizard Panels
Virtual Guest Job - Instance Properties

The Virtual Guest Job Instance Properties panel lets you specify values for the local
editable properties defined in the Virtual Guest Package and Virtual Guest Job.
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.
Virtual Guest Job - Class Properties

The VGJ Class Properties panel lets you review and edit the properties associated
with the Virtual Guest Job property class.
Note
This panel appears only as a tab in the job editor.
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.
Virtual Guest Job - Server Properties

The Server Properties panel lets you review and edit the properties associated with
the virtual host server.
Virtual Infrastructure Discovery Job Wizard

Panels
inventory looks like, without having to manually find and register each virtual
machine. Being able to manage this inventory effectively enables you to control
resource waste and optimize the use of the available hardware.

The Virtual Infrastructure Discovery Job wizard consists of the following panels:

page 969
For general information about the Job, see About the Virtual Infrastructure
Discovery Job on page 896.
Virtual Infrastructure Discovery Job - General

The General panel lets you provide information that identifies a Virtual
Infrastructure Discovery Job and options for discovering, registering, and importing
properties for virtual machines.
Field definitions
Name
Identifying name.
Description
Save in


Job Settings
Choose from the following options:
Run Virtual Infrastructure Update: Ensures that the BMC Server

Automation inventory is consistent with the actual virtual environment.
This option updates the properties for all virtual entities that are present in
the Server workspace of the BMC Server Automation inventory. If there is
a discrepancy between servers available in the BMC Server Automation
inventory and servers which are present in the virtual environment, then
the servers are listed under the Missing Servers node of the Job Results.
The Missing Servers node lists the servers which are present in the BMC
Server Automation inventory but do not exist in the actual virtual
environment.
Selecting this option also enables the Run Virtual Infrastructure
Discovery and Auto-Register... options.
Run Virtual Infrastructure Discovery: Selecting this option discovers

servers in the target virtual environment. The option is selected by default.
This option includes the following sub-options:
Auto-Register Discovered ESX hosts/Virtual Systems: Selecting this

option automatically registers any discovered virtual machines that are
not currently being managed by BMC Server Automation. This option
connects to the targets selected in the job (the vCenter servers, global
zones, IBM frame server) and retrieves all the virtual systems, non-
Global Zones, or LPARs. It then compares the discovered systems to
the list of BMC Server Automation enrolled servers and registers the
systems in BMC Server Automation if they are not already registered.
Selecting this option also sets the IS_VIRTUAL job property to true for
all virtual machines and zones which are registered by the Virtual
Infrastructure Discovery Job.
Note: The Virtual Infrastructure Discovery Job registers discovered
servers with the server name, even if the server is registered with the IP
address under the Server workspace.
Discover Unregistered Virtual System Templates (VMware platforms

only): Unregistered templates are templates which are present on the
datastores but not registered with the vCenter. Selecting this option

discovers these unregistered templates on the target vCenter server and

presents the list in the Virtual Infrastructure Discovery Job results view,
under Unregistered Templates.
Discover Unregistered Virtual Systems (VMware platforms only):

Select this option to discover any virtual machines that are not
registered in the vCenter or BMC Server Automation.
Selection of this option enables the Auto Remediate Unregistered
Virtual Systems option, which will move the unregistered virtual
machines to a vCenter server that you specify.
Note: Ensure that the name of the vCenter (enrolled in BMC Server
Automation) matches the name of the CONNECTION_URL property
specified when the vCenter server was added to BMC Server
Automation.
General options
The Import Lifecycle Properties option imports the server lifecycle

properties for a virtual system from a pre-defined mapping file. The selected
XML file contains a list of mappings for the targets and VMware vCenter
servers against which the Virtual Infrastructure Discovery Job is run.
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:
If the Auto-register discovered ESX Hosts/Virtual Systems option is

selected.
If the Auto Remediate Unregistered Virtual Systems option is selected.
If the Run Virtual Infrastructure Update option is selected.
Virtual Infrastructure Discovery Job - Targets

The Targets panel lets you choose the host servers on which the Virtual
Infrastructure Discovery Job will search for undiscovered virtual guests.
On the Targets panel, choose the targets for virtual guest discovery, or select All
Servers. Click Next.

Virtual Infrastructure Discovery Job - Destination Selection

The Destination Selection panel lets you chose the remediation target for any
unregistered Virtual Machines that the job discovers. This panel appears only if you
selected the Auto Remediate Unregistered Virtual Systems option on the General
panel.
Selecting the remediation target

Note
This panel applies only to VMware environments.
Select the remediation target for any unregistered Virtual Machines by doing the
following:
1 Browse to a vCenter host.
2 Expand the VMware vCenter Server node.
3 Expand the Inventory node.
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.
Virtual Infrastructure Discovery Job - Select Lifecycle

Properties Mapping
The Select Lifecycle Properties Mapping panel lets you select a properties mapping
file that will be used as the basis for importing the lifecycle properties (such as
OWNER, EXPIRY_DATE, LOCATION) for the discovered virtual machines.
Selecting the lifecycle properties map file

This panel is displayed only if you selected the Import Lifecycle Properties option
on the General panel.

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:
1 Browse to the location of the mapping file in the Depot folder.
2 Select the mapping file.
3 Click OK.
4 Click Next.
Virtual Infrastructure Discovery Job - Notifications

notifications. Default notifications can also provide information about Virtual
Infrastructure Discovery Job results.
On the Notifications panel, optionally specify and email or trap notifications for the
Job.
Virtual Infrastructure Discovery Job - Schedules

On the Schedule panel, choose Execute Job Now or click the Add icon to define a
schedule for the Job.

Scheduling a job
The Schedule tab lets you schedule a job so it can run once, recur hourly,
Virtual Infrastructure Discovery Job - Properties

The Properties panel provides a list of properties automatically assigned to an
Virtual Infrastructure Discovery Job. In this list you can modify the value of any
properties that are defined as editable.
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.
Virtual Infrastructure Discovery Job - Permission

Virtual Infrastructure Discovery Job. ACLs control access to all objects, including the
sharing of objects between roles.
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.

Virtual Guest Template Enrollment Job Wizard Panels
Virtual Guest Template Enrollment Job Wizard

Panels
You can create a Virtual Guest Template Enrollment Job to automatically discover all
OS templates on the virtual entity managers that you select, create Virtual Guest
Packages for the discovered templates, and store the VGPs in the Depot folder that
you specify.
The Virtual Guest Template Enrollment Job wizard consists of the following panels:
New Virtual Guest Template Enrollment Job - General on page 972
New Virtual Guest Template Enrollment Job - Targets on page 973
New Virtual Guest Template Enrollment Job - Notifications panel on page 974
New Virtual Guest Template Enrollment Job - Schedule on page 975
New Virtual Guest Template Enrollment Job Properties on page 975
New Virtual Guest Template Enrollment Job - Permissions on page 976
For more information about the Virtual Guest Template Enrollment Job, see
Automatically creating a Virtual Guest Package on page 873.
New Virtual Guest Template Enrollment Job - General

The General panel lets you provide information that identifies the New Virtual
Guest Template Enrollment Job. You specify a name for the job, a description, and
the location for storing the job and the Virtual Guest Packages that the job creates.
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.
See Automatically creating a Virtual Guest Package on page 873.

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.

New Virtual Guest Template Enrollment Job - Targets

The New Virtual Guest Template Enrollment Job Targets panel lets you choose the
target systems for the job. The job then searches these targets for templates, from
which it will create the Virtual Guest Packages.
Selecting the targets

1 Choose a target server from the Available Targets section, or choose All Servers.

Note
3 Click Next.
New Virtual Guest Template Enrollment Job - Notifications

panel
notifications.

Send email to
Send SNMP trap to


New Virtual Guest Template Enrollment Job - Schedule

The Schedules panel lets you schedule a New Virtual Guest Template Enrollment
Job to execute immediately, at a specific time in the future, or on a recurring basis. It
also lets you define notifications that are issued when a job runs.
On the Schedule panel, choose Execute Job Now or click Add ( ) to define a
schedule for this New Virtual Guest Template Enrollment Job.
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.
New Virtual Guest Template Enrollment Job Properties

The Properties panel provides a list of properties automatically assigned to this job.

inherited.

Property .
New Virtual Guest Template Enrollment Job - Permissions

Ensure that your role has the required permissions for the job to create a VGP for a
discovered template.
Ensure that the VirtualGuestTemplateEnrollmentJob.* permission is listed. It is

required to create a VGP for the discovered templates.

21
Administrative tools
BMC Server Automation provides a number of tools and processes that
administrators can use to improve their efficiency.
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:
Launch a script or executable program on a target server. If necessary, the script

or program can execute against a file or directory on the target server.
Launch an application that resides on the users local computer.

Custom commands
Scripts, programs, or applications can execute in a command line interface, a

graphical user interface, or a tabular format, like a spreadsheet, that is displayed
within a separate tab.
A typical installation includes standard custom commands that are available by

default if your role has the appropriate permissions. The following table lists the
standard custom commands BMC Server Automation provides:
Custom Command Description

Agent Information Runs the Network Shell agentinfo command, which provides
information about specified servers.
Network Top Displays processes running on servers across a network. Information
appears in a shell and is updated on a periodic basis.
NSH Here Opens a Network Shell on specified servers.
Reboot Server Reboots specified servers.
Remote Desktop Connection Opens a connection with a remote Windows machine.
Secadmin Runs the secadmin utility, which returns the security settings for one or
more servers. Running this command on multiple servers determines
whether their security settings match.
Server Overview Displays information about the configuration of specified servers, such
as their speed, disk size, and memory.
View Disk Usage Displays statistics about disk usage on specified servers.
View Memory Usage Displays memory usage on specified servers.
View Processes Displays processes running on specified servers.
View Server Activity Displays overview information about activity on specified servers, such
as the number of processes running and the amount of memory used on
those servers.
The Custom Command Administration window lets you perform any of the
following procedures:
Creating or modifying a custom command on page 978
Deleting a custom command on page 981
Creating or modifying a custom command

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.

Custom commands
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 create or modify a custom command
1 Select Configuration => Custom Commands View. The Custom Commands

view opens. With this view you can create new custom commands or edit, delete,
or share existing commands.
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.
4 For Name, enter a name that identifies the custom command.
5 For Command, enter the command that is executed on a server.
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.
Macro Information Provided
%h The names of selected servers on which the command should run.
%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,

Custom commands
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.
7 Under Operating Systems, do one of the following:
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).
Check Use string delimiter if a delimiter encloses string fields in the

commands output. Specify the delimiter by entering it in the Delimiter field.
For Separator, select the character used to separate data fields in the
command's output.

Custom commands
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.
12 Depending on whether you are creating or modifying a custom command, click

Finish or OK.
Deleting a custom command

You delete a custom command using the Custom Command Administration window.
To delete an existing custom command
1 Select Configuration => Custom Commands. The Custom Commands view

appears.
2 Select the commands you want to delete and click Delete Custom Command .
A dialog prompts you to confirm the deletion.

Setting up communications with remote servers
Setting up communications with remote

servers
If you want to manage remote serversservers on a different network from your
BMC Server Automation system or outside your networks firewall, for example
you can set up your Application Server to communicate with those servers through
your SOCKS internet protocol proxy servers.
Note
A setup requirement is that the SOCKS 5 proxy servers must be installed.
To set up communications through a SOCKS proxy server
1 Develop a policy for routing to the remote servers by identifying the following:
The remote servers you want to manage.
SOCKS proxy servers to route communications. You should also decide

whether or not those servers resolve host names.
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.
2 Configure Application Servers to route traffic to Network Shell proxy servers.
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
5 Add the remote servers you want to manage. See Adding remote servers on page
988.

Creating SOCKS proxy server objects

To route communications through a SOCKS proxy server, you first create a proxy
server object in the BMC Server Automation infrastructure.
Note
To create and manage proxy server objects, your role must be granted the
BL_Administration.Read and BL_Administration.Write authorization in RBAC.
To create a proxy server object
2 In the Infrastructure Management window, right-click the Proxy Servers node.

Then select New Proxy Server from the pop-up menu. The New Proxy Server
wizard opens.
3 On the General panel, enter the following information for the SOCKS proxy
server:
Text Box / Button Description
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.
Description (Optional) Descriptive text about the proxy server.
Host Name of the host machine for the proxy server.
Port Port for the SOCKS proxy.
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.
Creating rules for routing to remote servers

To create rules for routing communications to remote servers through a SOCKS
proxy server, use the Network Routing wizard. This wizard creates a default SOCKS
proxy server routing policy and simple rules that the Application Server uses for
routing to remote servers.
Note
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.
To create rules for routing communications to remote servers
2 In the Infrastructure Management window, right-click the Network Routing

Rules node and select Network Routing Wizard. The General panel opens.
3 Complete the Network Routing Wizard, as described in the following sections:
Network Routing General on page 985
Network Routing - Rules on page 986
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.

5 Click Close to close the Infrastructure Management window.
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.
Network Routing General

The General panel lets you provide information that defines a server property on
which the routing rules will be based.
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
Optionally enter descriptive text about the property.
Network Routing - Rules

The Rules panel lets you create rules for routing communications to remote servers
through a SOCKS proxy server.
To create routing rules for routing communications to remote servers
1 Click Add Rule . The New Rule wizard opens.
2 Complete the information about the following wizard panels.
Network Routing General on page 985
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
Optionally enter descriptive text about the rule.

New Rule - Rule Definition (network routing)
The Rule Definition panel lets you create a property condition for a network routing
rule.
Note
This panel is displayed only if you selected the New Rule option from the Network
Routing Rules node to create a Creating complex routing rules on page 1016.
To create a property condition for a rule:
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
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.

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.)
When you have completed server selection, click Finish .
Adding remote servers

To enable access to remote servers through the SOCKS proxy server, add a server
object to the Servers folder for each remote server, as described in the following
procedure. Remote servers are servers on a different network from your BMC Server
Automation system or outside your networks firewall.
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.
To add a remote server
1 In the BMC Server Automation console, open the Servers folder.
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.
For Description, you can optionally provide descriptive text.
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.

Configuring servers to use repeaters during deployments
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.
Configuring servers to use repeaters during

deployments
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 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.
To configure servers to use repeaters during deployments
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.
1 In the Infrastructure Management window, create repeater server objects in the

BMC Server Automation infrastructure. See Creating repeater server objects on
page 991.
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
BL_Administration.Read Required to access repeater information.
Repeater.Read Required to perform repeater actions (Create, Delete, and

Modify).
Repeater.* Grants all repeater authorizations (Read, Create, Delete,

and Modify). Alternately, your role can be granted specific
authorizations:
Repeater.Create Authorization to create repeater server

objects.
Repeater.Delete Authorization to delete repeater server

objects.
Repeater.Modify Authorization to edit properties of

repeater server objects.
Creating repeater server objects

To use repeaters during deployments, you first create a repeater server object in the
BMC Server Automation infrastructure.
To create a repeater server object
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.
Description (Optional) Descriptive text about the repeater server.

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.
Creating rules to determine the repeater used for target

servers
To create rules that determine the repeater used for indirect staging to a target
server, use the Repeater Routing Wizard.

Note
To create, modify or delete repeater routing rules, your role must be granted the
To create rules to determine the repeater used for a target server
2 In the Infrastructure Management window, right-click the Repeater Routing

Rules node and select Repeater Routing Wizard.
3 Complete the Repeater Routing Wizard, as described in the following sections:
Repeater Routing - General on page 994
Repeater Routing - Rules on page 994
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.
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.
Repeater Routing - General

The General panel lets define basic information about the rule you are creating.
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
Optionally enter descriptive text about the property.
Repeater Routing - Rules

The Rules panel lets you create rules that determine the repeater used for indirect
staging to a target server.
To create a rule for a repeater server
1 Click Add Rule . The New Rule wizard opens.
2 Complete the New Rule wizard, according to the following topics:
New Rule - General (repeater routing) on page 995
New Rule Repeaters (repeater routing) on page 996

3 When you have finished selecting the repeater server for the rule, click Finish.
repeat the process.
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
Optionally, enter descriptive text about the rule.

New Rule - Rule Definition (repeater routing)
The Rule Definition panel lets you create a property condition for a repeater routing
rule.
Note
This panel is displayed only if you selected the New Rule option from the Repeater
Routing Rules node to create a Creating complex routing rules on page 1016.
To create a property condition for a rule:
1 Click Add Property Condition .

The Add Property Condition window opens.


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.
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.
Assigning repeaters to target servers

To perform indirect staging of a BL Package Deploy Job, you first must assign a
repeater to each target server. Use the new server property created when you created
the repeater routing rule.
Note
To use this procedure, you must have already created repeater server objects and
routing rules for determining which repeater to use for target servers. For
information, see Creating repeater server objects on page 991 and Creating rules to
determine the repeater used for target servers on page 992.
To assign a repeater to a target server
1 In the BMC Server Automation console, open the Servers folder.
2 Right-click the server and select Set Property. The Set Server Property dialog
opens.

Creating rules to determine Application Servers used for job execution
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.
Creating rules to determine Application

Servers used for job execution
A routing policy consists of an ordered list of routing rules.
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:
Creating routing rules for job execution on page 997
Enabling/disabling job routing rule evaluation on page 1000
Creating routing rules for job execution

To create rules that determine the Application Servers to use for executing a job, use
the Infrastructure Management window.

Note
To create, modify or delete job execution rules, your role must be granted the
To create rules to determine Application Servers to use for job execution
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.
3 In the Rules Management panel, click Add Rule .
4 Complete the New Rule Wizard, as described in the following sections:
New Rule - General (job execution) on page 998
New Rule - Rule Definition (job execution) on page 998
New Rule Application Servers (job execution) on page 999
5 Click Finish to close the New Rule wizard.
New Rule - General (job execution)

The General panel lets you provide basic information for the rules you create.
Field definitions
Name
Enter a name for the job execution rule.
Description
Optionally provide descriptive text for the rule.
Click Next to display the Rule Definition panel.
New Rule - Rule Definition (job execution)

The Rule Definition panel lets you create a property condition for a job execution rule.

To create a property condition for a rule
1 Click Add Property Condition . The Add Property Condition window opens.

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)
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.
New Rule Application Servers (job execution)

The Application Servers panel lets you select the target Application Servers to use
for a job execution rule.
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
JOB, NSH PROXY
ALL
Enabling/disabling job routing rule evaluation

By default, BMC Server Automation evaluates a target servers job execution routing
policy to determine the Application Server to use for executing the job. You can
disable this job rule evaluation.
To enable or disable job routing rule evaluation
1 Start the Application Server Administration console.
2 To enable or disable job execution rule evaluation, use the following command:
set RoutingConfig EvaluateJobRules true|false
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.
false Turns off job rule evaluation.
3 Restart all applicable Application Servers (for example, all Application Servers
that are job servers).

Infrastructure management from the BMC Server Automation Console
Infrastructure management from the BMC

Server Automation Console
The Infrastructure Management window provides a way to view and manage
Application Servers and other servers that support BMC Server Automation
operations.
From the Infrastructure Management window you can perform a variety of

infrastructure management tasks:
Getting information about Application Servers on page 1002
Reporting Application Server information on page 1003
Getting information about PXE servers on page 1004
Getting information about the database on page 1005
Managing SOCKS proxy servers on page 1005
Managing repeater servers on page 1007
Managing routing rules on page 1013
About the Infrastructure Management window

The Infrastructure Management window provides a way to view and manage
Application Servers and other servers that support BMC Server Automation
operations.
The Infrastructure Management window has these nodes:
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.
Getting information about Application Servers

Use the Infrastructure Management window to display information about an
Application Server and the services that it runs. This information can be useful for
diagnostic purposes.
Note
To display information about the Application Server, your role must be granted the
BL_Administration.Read authorization.
To display information about an Application Server
2 In the left pane, expand the hierarchy of the Application Servers node. Then click
the Application Server you want to see.

To display: Do the following:
A list of Application Servers on Expand the Application Servers node.

the host (using the same database) The left pane lists each Application Servers Display Name and
Authorization Port.
General information about an Click the Application Servers name in the left pane.
Application Server The right pane shows:
Software version
Number of jobs running
Host operating system
JVM memory usage
Information about the Application Server from Application Server

Launcher (shown if your role has authorization).
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
A menu of actions you can Right-click the Application Server.

perform on the Application Server
Reporting Application Server information

You can generate a report containing information about all of the Application
Servers on the host.
The report includes:
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.
Information about the database to which the Application Server is connected.

To generate a report about Application Servers
2 In the Infrastructure Management window, click Export Detail Report .
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.
4 On the dialog, enter the information for the report file:
a For Object Name, type a file name for the report.
b For Object Type, select a file format.
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.
Getting information about PXE servers

To get information about PXE servers in the BMC Server Automation infrastructure,
use the Infrastructure Management window.
To get information about PXE servers
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.

Getting information about the database

To get information about the database to which the Application Server is connected,
use the Infrastructure Management window.
To get information about the database
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.
Managing SOCKS proxy servers

The BMC Server Automation system lets you route communication to remote servers
through SOCKS proxy servers.
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.
Viewing and editing proxy server properties

You can use the Infrastructure Management window to display a proxy servers
properties and change them.
To display a proxy servers properties
2 In the Infrastructure Management window, expand the Proxy Servers hierarchy

and select the name of the proxy server whose properties you want to view. The
right pane of the window displays the properties.
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.
Deleting proxy server objects

You can use the Infrastructure Management window to delete proxy server objects
from the BMC Server Automation system.
To delete proxy server objects
2 In the Infrastructure Management window, expand the Proxy Servers hierarchy.
3 Right-click the proxy server and select Delete Proxy Server from the pop-up
menu.
Checking the status of a SOCKS proxy server

Through the Infrastructure Management window, you can check the proxy server to
see if it is running.
To check the status of a SOCKS proxy server
2 In the Infrastructure Management window, expand the Proxy Servers folder.
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 ( ).
Assigning SOCKS proxy servers to a routing rule

When you create routing rules, you can choose to assign SOCKS proxy servers to
them at a later time. To assign proxy servers to rules or to change assignments, use
the Infrastructure Management window.

To assign proxy servers to rules
2 In the Infrastructure Management window, expand the Network Routing Rules

hierarchy.
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.
Managing repeater servers

After you create repeater server objects, you can manage those objects through the
Infrastructure Management window of the BMC Server Automation console.
You can use the Infrastructure management window to perform the following
management tasks:
Viewing and editing repeater server properties on page 1008
Deleting repeater server objects on page 1008
Assigning a repeater server to a repeater routing rule on page 1009
Enabling/disabling repeater rule evaluation on page 1009
Updating a repeater server on page 1010

For information about creating repeater server objects, see Creating repeater server
objects on page 991.
Viewing and editing repeater server properties

You can use the Infrastructure Management window to display a repeater servers
properties and change them.
Note
To view repeater server properties, your role must be granted the
RepeaterServer.Read authorization. To edit repeater server properties, your role
must be granted both RepeaterServer.Read and RepeaterServer Modify authorizations.
To display a repeater servers properties
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.
If the repeater is configured as an advanced repeater server, there are additional

options that you can modify. For more information, see BMC technical
documentation at https://docs.bmc.com/docs/display/bsa82/Configuring+the
+file+server.
Deleting repeater server objects

You can use the Infrastructure Management window to delete repeater server objects
from BMC Server Automation.
To delete repeater server objects
Servers hierarchy.

3 Under the Repeater Servers node, right-click the repeater server and select Delete
Repeater Server from the pop-up menu.
Assigning a repeater server to a repeater routing rule

When you create a repeater routing rule, you can choose to assign the repeater
servers to it at a later time. To assign a repeater server to a routing rule or to change
assignments, use the Infrastructure Management window.
To assign a repeater server to a routing rule
2 In the Infrastructure Management window, expand the Repeater Routing Rules

hierarchy.
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.
Enabling/disabling repeater rule evaluation

By default, BMC Server Automation evaluates a target servers repeater routing
policy to determine the repeater to use for indirect staging to that server.
If no repeater routing policy is defined, the system uses the REPEATER_NAME

property on the server. You can disable repeater rule evaluation and have
REPEATER_NAME property determine the repeater.
To enable or disable repeater rule evaluation
1 Start the Application Server Administration console.
2 To enable or disable repeater rule evaluation, use the following command:
set RoutingConfig EvaluateRepeaterRules true|false
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).
Updating a repeater server

You can update the status or change the properties of a repeater server using the
Infrastructure Management window.
To update a repeater server
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 ( ).
Refresh Updates the status of the server.
Properties Launches the Properties dialog.
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.

Managing remote host authentication for agent installations

To use Agent Installer capabilities, you must set up remote host authentication
definitions and remote host authentication rules. Use the Infrastructure Management
window of the BMC Server Automation Console to manage remote host
authentication.
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
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.
To update remote host authentication status
This procedure does the following:
For remote host authentication based on PsExec, checks the following:
PsExec server is not decommissioned
Version of the RSCD agent on the PsExec server matches what is listed in its
server properties
Version of the RSCD agent on the PsExec server is 8.2 or higher
RSCD agent is running
PsExec command can be executed on the PsExec server
Designated automation principal is present
For remote host authentication based on SSH, confirms the presence of the
designated automation principal.

Host Authentications node.
The node shows existing remote host authentications.
3 Right-click a remote host authentication and select Update Remote Host

Authentication Status.
The information at right updates. The Status says "Success" if the update
completes successfully.
To delete an existing remote host authentication
Host Authentications node.
The node shows existing remote host authentications.
3 Right-click a remote host authentication and select Delete Remote Host

Authentication.
Note
If you delete a remote host authentication that is used in a remote host
authentication rule, the remote host authentication is deleted but the rule is not
deleted.
To assign a remote host authentication to a remote host authentication rule
Host Authentication Routing Rules node.
The node shows existing remote host authentications rules.
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.

To delete an existing remote host authentication rule
Host Authentication Routing Rules node.
The node shows existing remote host authentications rules.
3 Right-click a rule and select Delete Rule.
Managing routing rules

In the Infrastructure Management window, after you use a routing wizard to set a
routing policy and create rules for routing, you can use the Rules Management
window to manage those rules.
You can use the Rules Management window for:
Viewing and editing routing rules on page 1013
Changing the order of rule evaluation on page 1015
Deleting routing rules on page 1015
For information about setting routing policies and rules, see:
Network routing wizardCreating rules for routing to remote servers on page

984.
Repeater routing wizardCreating rules to determine the repeater used for target
Job execution routing wizardCreating rules to determine Application Servers

used for job execution on page 997
Remote host authentication wizardCreating or modifying rules for remote host

Viewing and editing routing rules

You can use the Infrastructure Management window to view or edit routing rules.

To view or edit routing rules
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.
How rules are evaluated

Routing rules of a policy are evaluated using a standard algorithm.
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.
Changing the order of rule evaluation

To determine which server to use for interaction with a target server, the Application
Server evaluates each request against the list of routing rules.
The order of rules on the list determines the order of evaluation. You can change the
order of rules in the Rules Management window.
To change the order of rule evaluation
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.
Deleting routing rules

You can use the Infrastructure Management window to delete routing rules.
To delete routing rules
for the routing rules you want to delete; for example, Repeater Routing Rules.
3 In the Rules Management panel, select the rule you want to delete and click
Delete Rule .
4 Click OK to close the Rules Management window.

Creating complex routing rules

To create complex routing rules, you can use the New Rule wizard. This wizard lets
you create routing rules with one or more conditions that can use the new server
property but are not limited to it.
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.
To add complex routing rules
1 Select Configuration => Infrastructure Management. The Infrastructure

Management window opens.
for the routing rules you want to manage; for example, Repeater Routing Rules.
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.
If you are creating SOCK proxy routing rules see:
New Rule General (network routing) on page 986
New Rule - Rule Definition (network routing) on page 987
New Rule Proxies (network routing) on page 987
If you are creating repeater routing rules, see:
New Rule - General (repeater routing) on page 995
New Rule - Rule Definition (repeater routing) on page 995
New Rule Repeaters (repeater routing) on page 996
If you are creating rules for job execution, see:

About troubleshooting tools
New Rule - General (job execution) on page 998
New Rule - Rule Definition (job execution) on page 998
New Rule Application Servers (job execution) on page 999
If you are creating rules for remote host authentcation, see:
Remote host authentication rule Remote Host Authentications on page

296
5 Click Finish to close the New Rule wizard.

BMC Server Automation provides two tools that you can use to collect data for
diagnosing issues and working with Support.
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.


22
Patch management
This chapter describes the patch management process for servers operating on
various platforms.
Patch management overview

Patch management refers to the acquisition, testing, and installation of patches.
The patch administrator analyzes individual servers to determine which patches

must be acquired and installed to comply with organizational standards. BMC
Server Automation automates the process of building and maintaining a patch
repository, analyzing target servers, and, if necessary, packaging and deploying
patches. At the end of the process, reports are available to show compliance.
BMC Server Automation supports the following operating systems:
Microsoft Windows
Oracle Solaris
Fujitsu Solaris
IBM AIX
Red Hat Enterprise Linux
SUSE Linux Enterprise
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.

Patch management workflow
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:
As part of a job in BMC Server Automation (Online mode)
Using a separate utility (Offline mode)
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.
BMC Server Automation includes two patch management modes:
Online modePatches are downloaded directly from the appropriate product site.
Offline modePatches are pre-downloaded to a local repository and patches are

applied from the repository.
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.

This section introduces the set of tasks required to prepare for, set up, and execute
patch management jobs.
Patch management consists of the following tasks:

1 Preparatory tasks
a Defining role-based permissions
b Configuring Global Configuration parameters
c Defining the location of Microsoft Windows installation media for Microsoft

Office patch deployment (Windows only)
2 (Offline mode only) Building an offline patch repository
a Downloading patch downloader utilities from BMC Software
b Preparing XML configuration files for downloading patch content
c Downloading patches to the offline patch repository
3 Patching tasks
a Creating and updating a Patch Catalog
b Creating and running a Patching Job and a Remediation Job
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:
All Operating Systems-Configuration parameter options for a proxy server.
Platform-specific groups for each platform (such as Windows and Solaris)

Parameters that apply only to that specific platform type
Shavlik URL ConfigurationConfiguration for connecting to Shavlik

Technologies to download patch-related metadata for patching Windows
software.
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.

Preparatory tasks
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
2 Packages the payload as a BLPackage
3 Creates a Deploy Job to apply the patches
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
Preparatory tasks
Before you can begin patch management-related tasks, you must perform the
following preliminary tasks:
Define role-based permissions required to create or update the catalog.
Set Global Configuration parameters to be used as default values during catalog

creation and update, as well as during Patching and Remediation Job creation.
(Microsoft Windows only) Identify the location of the installation media required by
Microsoft Windows servers.
Role-based permissions for patch catalog

To create or update a catalog, the patch administrator must be assigned a role that
includes the necessary permissions.
To facilitate division of responsibilities, you can assign permissions to one role or

split between several roles.
Define Role and ACL Policy definitions using role-based access control. For more
details, see Access management on page 165.

Preparatory tasks
To be able to view results of Patching Jobs created from a Patch Catalog, you must
have the DepotObject.Read permission enabled.
Ensure the patch administrator has the following permissions:
Defining permissions for Gives the user the ability to
PatchCatalog.* Manage the patch catalog

PatchSmartGroup.* Patch smart group management
WindowsSoftware.* Create, read, modify and delete permissions for the
SolarisSoftware.* software on the platforms that you are patching. Select
only the platforms that are relevant for your
AIXPatchSoftware.* environment.
LinuxSoftware.*
Server.* Access to the server on which the patch repository is
ServerGroup.* located.
DepotFolder.* If you create a catalog in offline mode, you need depot,

DepotFile.* depot file, and depot group permissions to select the
metadata files during catalog creation.
DepotGroup.*
Global Configuration parameters

Global configuration parameters provide basic information that is automatically
supplied as the default during catalog creation and update as well as during
Patching and Remediation Job creation.
Configuring Global Configuration parameters

To have basic information automatically supplied during catalog creation and
update as well as Patching and Remediation Job creation, configure global patch
configuration parameters.
To configure global patch configuration parameters
1 From the Configuration menu, select Patch Global Configuration.
The Patch Global Configuration tabs are displayed at the bottom of the console.
2 Update the parameters as necessary.
The parameters are divided into the following tabs:
All Operating Systems -- Configuration parameters options for a proxy server

Preparatory tasks
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
Shavlik URL Configuration -- Configuration for connecting to Shavlik for

downloading Microsoft Windows patch related metadata
Global Configuration parameter list

The parameters are described below:
All operating systems tab
Proxy Server Type
Select the type of proxy server used:
SQUID
NTLM
NTLM-V2
NoneSelect when you are not using a proxy server
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
Enter the domain name of the proxy server.
Host
Enter the IP Address or Host Name of the proxy server.

Preparatory tasks
Port
Enter the port number used for communication with the proxy server.
Platform specific parameters
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
(Solaris only) user name for accessing the Oracle website
Oracle Password
(Solaris only) password for accessing the Oracle website
Catalog Object Processor Batch Size
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.
Analysis Server Results Batch Size
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.

Preparatory tasks
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.
AbortEnd the job and start a rollback.
ContinueContinue despite the failure. The Deploy Job continues and

the results show the job as failing.
Note
On Linux platforms, patches are deployed using the blyum utility. As a result,
if you are applying a series of RPMs, and blyum fails to deploy any of the
RPMs, it stops at that point. The value set in Action on Failure is ignored.
Ldom option
(Solaris Only) Options to patch independent Solaris LDoms simultaneously.

For more information, see Patching Job Independent Solaris LDoms can be
patched simultaneously on page 1115. The following options are provided:
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).
Shutdown Ldoms using ldm-names as hostnameThis option executes

the shutdown command on the guests by using the nexec parameter, and
by using ldm-name as the hostname for nexec.
Single User Mode and Reboot Override File
(Solaris Only) The location in the Depot for the file used to override single-
user mode and reboot settings for a particular patch.
Solaris Updates List File
(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.

Preparatory tasks
Windows Filter Configuration File
(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 Service Packs List File
(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.
HTTP/HTTPS/FTP Connection Retry
(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.
HTTP/HTTPS/FTP Connection Timeout
(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 Updates List File
(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
(AIX Only) Select one of the following:
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.
Continue Analysis if any applied fileset foundAnalysis continues even if a

fileset in the applied state is found on the target server.
Precommit Option
(AIX Only) Select one of the following actions:
Commit All AppliedChanges the state of all currently installed filesets

from Applied to Commit.

Preparatory tasks
NoneThe state of all currently installed filesets in the Applied state does
not change.
Deploy Option
(AIX Only) Select one of the following actions:
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.
Patch deploy 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 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.
Patch deploy failure return codes
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.
Patch deploy warning return codes
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.
Patch deploy reboot return codes
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.

Preparatory tasks
Patch 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 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.
Patch undeploy failure return codes
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.
Patch undeploy warning return codes
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.
Patch undeploy reboot return codes
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.
Possible values are as follows:

Preparatory tasks
Normal
Below Normal
Default value is Normal.

Note
Changing this option affects all Windows Patching Jobs.
Shavlik URL Configuration tab
The Shavlik URL Configuration tab provides information about the two
configuration files required by Microsoft Windows.
PD5.cab or PD5.xmlWindows patch packaging information
HFNetChk7b.cab or HFNetChk7b.xmlWindows patch analysis SDK
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).
Shavlik URL Configuration Type
(Read-only) the name of the configuration file downloaded from the Shavlik
Technologies website.
URI (http URL/NSH path)
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
Select this to begin downloading from the Shavlik Technologies website

using the URL you provided in the URI box.
Description
Enter a description for the URL/NSH patch you entered in the URI box.
Check for updates
Select this to overwrite the PDF5.cab or HFNetChk7b.cab file downloaded

previously. If you click Download, it overwrites any previous copies of the file.

Offline Patch Downloader utility
Defining the location of Microsoft Windows installation

media for Microsoft Office patch deployment
To deploy Microsoft Office patches, BMC Server Automation must have access to a
network location containing installation media for Microsoft Office. Because target
servers can run different versions of Microsoft Office, you may need to specify a
different location for each target server.
Before you begin
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.
To define the location of Microsoft Windows installation media for Microsoft

Office patch deployment
1 In the Servers folder, right-click the target server or smart group and select Set
Property.
2 Enter the following information:
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.

In an air-gapped environment, Internet access is not available to any of the servers in
the environment.

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.
Downloading patch downloader utilities

From the BMC Software EPD site, download the appropriate utilities for building
your offline repository.
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.
build is the version number.
extension is the appropriate extension of the compressed file (.tar.gz or .zip).
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.

Patch Downloader utility for Microsoft Windows

The Patch Downloader utility for Microsoft Windows, provided by BMC Software,
uses a configuration file and downloads the following files.
The files downloaded are:
Patch Signature Information file: hfnetchk6b.xml
Information file: pd5.xml
The Patch Downloader is: windows_downloader.bat. To install, extract the file and
place in a directory on the server.
Preparing the configuration file for Microsoft Windows

In the configuration file, you provide information that is used by the Patch
Downloader utility.
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.
Before you begin
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.
windows_downloader.bat -encode passwordToEncrypt
To prepare the configuration file for Microsoft Windows
1 Edit the sample .XML configuration file (sample-windows-downloader-

config.xml) for use as the configuration file.
2 (Optional) Add proxy information using the following XML tags:

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
3 Define download settings using the following XML tags.
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>
5 Save the file.

The sample-windows-downloader-config.xml file is shown below and includes
sample data:
<windows-downloader-config>
<config>
<proxy-settings>

<payload-repository-location>d:\tmp\solaris</payload-repository-
location>
<metadata-override-file-path></metadata-override-file-path>
</config>
<subscription>
<cluster-filter>
<cluster-name>Solaris 9 SPARC Sun Alert Patch Cluster</cluster-name>
</cluster-filter>
<cluster-filter>
<cluster-name>Java ES Required OS Solaris 10 x86</cluster-name>
</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-ids-filter>
</subscription>
</solaris-downloader-config>
Downloading patches using defined filters for Oracle Solaris

The following procedure describes how to download patches from the Oracle
website using filters defined in the configuration file.
Note
You can run the Patch Downloader for Oracle Solaris on a Microsoft Windows,
Oracle Solaris, or Linux server.
The Patch ID filter does not download dependent patches and results in an
incomplete patch catalog. Remediation Jobs require that dependent patches be
available from the patch catalog so they can be applied as well. For this reason, BMC
Software does not recommend using this procedure to download patches from the
Oracle website.
To download patches for defined filters

solaris_downloader.bat|sh solarish_downloader.sh -configFile
-oracleUser oracleUserName -oraclePass oraclePassword
The location of the Configuration File used by the Patch Downloader.

Quotation marks around the path are required.
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.
Files used to correct the catalog for Oracle Solaris

Use the following files to correct information provided during creation and update
of the patch catalog:

Override file on page 1042
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.
Single user mode and reboot settings override file

To override single user mode and reboot settings for a particular patch, create an
XML file (the default name for this file is sum_reboot_info).
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>
<reboot-info>rebootafter</reboot-info>
<single-user>singleuser</single-user>
</patch>
<patch>
<reboot-info>rebootimmediate</reboot-info>
<single-user>singleusernone</single-user>
</patch>
<patch>
<reboot-info>rebootnone</reboot-info>
</patch>
<patch>
<reboot-info>reconfigimmediate</reboot-info>
<single-user>singleusernone</single-user>
</patch>
<patch>
<reboot-info>reconfigafter</reboot-info>
</patch>
</solaris-sumreboot-info>
Valid values for <reboot-info> are as follows:
rebootnone Do not reboot

rebootimmediate Reboot immediately after applying the patch.
rebootafter Reboot at the end of job execution, after all patches
are deployed.
reconfigimmediate Reconfiguration reboot (reboot and reconfigure
system devices) immediately after applying the patch.
reconfigafter Reconfiguration reboot at the end of job execution,
after all patches are deployed.
Valid values for <single-user> are as follows:
singleuser Install the patch in singleuser mode.

singleusernone Install the patch in normal mode.
Patch Downloader utility for IBM AIX

The Patch Downloader is available from the BMC Software Electronic Product
Distribution (EPD) site.

The downloader is either aix_downloader.bat (for running on Microsoft Windows)

or aix_downloader.sh (for running on AIX or Linux). To install, extract the file and
place it in a directory on the server.
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.
Preparing the configuration file for AIX

Downloader utility.
Before you begin
the Patch Downloader utility. You must specify the resulting encrypted password
within the <password></password> tag in the configuration XML file.
If running the downloader on Microsoft Windows:
aix_downloader.bat -encode passwordToEncrypt
If running the downloader on AIX or Linux:
sh aix_downloader.sh -encode passwordToEncrypt
To prepare the configuration file for AIX
1 Edit the sample .XML configuration file (sample-aix-downloader-config.xml) for

use as the configuration file.
Tag Description

Tag Description
proxy server
<password></password> the encrypted password for the specified user name
Valid values are:
None
NTLM
NTLM-V2
Squid
3 Add download information using the following XML tags:
Tag Description
download process
are stored
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:
<level-number> is a version identifier provided by AIX

FixCentral.
<level_type> is the filter type.

Valid values are:
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.
<apar-id> is the identifier for the APAR you want to install

on the servers.
<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
<ptf-id> is the identifier for the PTF you want to install on

the servers.

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
<update-type> can be one of three update types:
security
critical
latest
5 Save the file.

The sample-aix-downloader-config.xml file with sample data is shown below.
<aix-downloader-config>
<config>

<temporary-location></temporary-location>
<payload-repository-location></payload-repository-location>
</config>
<subscription>
<level-type-filter>
<level_number>V530011</level_number>
<level_type>TL</level_type>
</level-type-filter>
<level-type-filter>
<level_number>V53000007CSP</level_number>
<level_type>SP</level_type>
</level-type-filter>
<apar-ids-filter>
<currentoslevel>V610004</currentoslevel>
<apar-id>IZ62630</apar-id>
</apar-ids-filter>
<ptf-ids-filter>
<ptf-id>U497901</ptf-id>
</ptf-ids-filter>
<update-type-filter>
<update-type>security</update-type>
<update-type-filter>
<update-type>critical</update-type>

</subscription>
</aix-downloader-config>
Downloading AIX patches using defined filters

The following procedure describes how to download patches from the AIX
FixCentral website using filters defined in the configuration file and how to obtain a
list of all Technical Levels, Service Packs, and Concluding Service Packs available for
download.
Note
You can run the Patch Downloader for AIX on a Microsoft Windows, AIX, or Linux
server.
To download patches using defined filters on AIX

aix_downloader.bat|sh aix_downloader.sh -configFile
"downloaderConfigurationFilePath"

To downoad the list of available Technology Levels, Service Packs, and

Concluding Service Packs

aix_downloader.bat|aix_downloader.sh -listChannels
Downloading the Updates List

Use the following command to obtain a list of Technology Levels and Service Packs
from the vendor which is used to populate the filter selection list in the patch catalog
wizard.
To download the updates list

aix_downloader.bat/aix_downloader.sh -configFile
"downloaderConfigurationFilePath"
-generateUpdateList "updatesFilePath"


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.
Populating the latest Technology Levels and Service Packs

on AIX Catalog filters
Use the following procedure to populate the latest Technology Levels and Service
Packs at AIX Catalog filters.
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.
3 Add the updateListfileName.xml file to the Depot workspace.
4 Select Patch Global Configuration from the Configuration menu.
5 Go to the AIX tab.
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.
Obtaining information from the Patch Downloader utility

for AIX
Use the following commands to obtain additional information.

To display the downloader help file
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
To display version information for the downloader
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
To display a list of supported products and languages
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
Migrating patch repositories for AIX

The procedure described below generates an XML file that identifies the contents of
the repository by its operating system and architecture and provides the means for
BMC Server Automation to consolidate all of the AIX filesets in a single location so
that the repository can be used as a source for an offline, patch catalog.
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.
To create a repository for AIX
1 Enter the following command:

aix_downloader.bat|sh aix_downloader.sh -createRepo -repoLocation
"locationOperSysArch" -srcLocation locationExistingRepository -
fixgetFile locationFilesets.txt -renamepayload
This command uses the following parameters:

-repoLocation
location of the repository used by BMC Server Automation
-srcLocation
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 are stored.
os-arch is the operating system/architecture combination used during

download.
You can supply more than one combination using a semi-colon (;) between
each set of information. Quotation marks are required.
-fixgetFile
If migrating from a BMC BladeLogic Vendor Patch Content patch repository,

the Fileset.txt file is located in the Policy subdirectory of the AIX installation
directory. For the TL 6100-04, point to the file located in: vpcInstallDir\aixpu
\policies\6.1\Levels\6100-04. Quotation marks around the path are required.
-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.
Patch Downloader utility for Red Hat Enterprise Linux

You can download metadata and payload using the Patch Downloader utility for
Red Hat Enterprise Linux supplied by BMC Software or you can use a download
utility that you have on hand.
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:
Package Required version

createrepo 0.4.6
pythonurlgrabber 2.9.6
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.
The downloader is either redhat_downloader.bat (for running on Microsoft

Windows) or redhat_downloader.sh (for running on Red Hat Linux). To install,
extract the file and place it in a directory on the server.
Preparing the configuration file for Red Hat Enterprise Linux

Downloader utility.
Before you begin
the <password></password> tag in the configuration XML file.
If running the downloader on Microsoft Windows:
redhat_downloader.bat -encode passwordToEncrypt
If running the downloader on UNIX:
sh redhat_downloader.sh -encode passwordToEncrypt

To prepare the configuration file on Red Hat Enterprise Linux
1 Edit the sample .XML configuration file (sample-redhat-downloader-config.xml)

Tag Description
proxy server
Valid values are:
None
NTLM
NTLM-V2
Squid
Tag Description
download process
are stored

Tag Description
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>
<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>

<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>
<errata-ids>
<errata-id></errata-id>
</errata-ids>
</errata-ids-filter>
<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>
<update-level></update-level>
</update-level-filter>
<channel-label></channel- channel label you want to download
label>

<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.
5 Save the file.

The sample-redhat-downloader-config.xml file is shown below, including sample
data and parameter descriptions:
<redhat-downloader-config>
<config>
<port>8080</port>
<domain-name />
</proxy-settings>
<payload-repository-location>/home/repo/</payload-repository-
location>
</config>
<subscription>
<errata-type-filter>
<os>RHES5</os>
<arch>x86</arch>
<channel-label>rhel-i386-server-5</channel-label>
<errata-severity>
<critical>true</critical>
<high>true</high>
<moderate>true</moderate>
<low>true</low>
</errata-severity>
<errata-type>
<security>true</security>
<bugfix>true</bugfix>
<enhancement>true</enhancement>
</errata-type>
</errata-type-filter>
<errata-ids-filter>
<os>RHAS4</os>
<arch>x86</arch>
<channel-label>rhel-i386-as-4</channel-label>
</errata-ids>
<errata-id>RHSA-2009:0429</errata-id>
<errata-id>RHBA-2009:0388</errata-id>
</errata-ids>
</errata-ids-filter>


<update-level-filter>
<os>RHAS4</os>
<arch>x86</arch>
<channel-label>rhel-i386-as-4</channel-label>
<update-level>5</update-level>
</update-level-filter>

</subscription>
</redhat-downloader-config>
Running the Patch Downloader utility for Red Hat

Enterprise Linux
The following procedure describes how to run the Patch Downloader utility and
how to extract RPM packages from a file prepared using the ISO format.
Note
You can run the Patch Downloader for Red Hat Enterprise Linux on a Microsoft
Windows or Linux server.
To run the Patch Downloader utility on Red Hat Enterprise Linux

sh redhat_downloader.sh|redhat_downloader.bat
-configFile "downloaderConfigurationFilePath"
-rhnUser "rhnUserName" -rhnPass "rhnPassword"
location of the Configuration file used by the Patch Downloader
rhnUserName
user name required to log onto the Red Hat Network website
Quotation marks are required.
rhnPassword
password required to log onto the Red Hat Network website

Note
If the downloader fails to connect to the Red Hat Network website, an error
message is issued. This may happen, for example, if you provided an invalid user
name or password or if your user account is locked out.
To extract packages from ISO

redhat_downloader.sh|redhat_downloader.bat
-extractPackagesFromISO -repoLocation "patchRepositoryFilePath"

-isoLocation "isoFilePath"
-osArch "operatingSystemArchitecture"
Note
You must execute the extractPackagesFromISO command on a Linux computer
only.
patchRepositoryFilePath
location of the patch repository used by the Patch Downloader
isoFilePath
location of the ISO from which RPMs are extracted
operatingSystemArchitecture
An operating system/architecture combination; for example, RHAS4-x86 or

RHAS4-x86_64
For example:
redhat_downloader.bat
-extractPackagesFromISO -repoLocation "C:\redhat"
-isoLocation "\redhatDVD.iso"
-osArch "RHAS4-x86"

for Red Hat Enterprise Linux
Use the following procedures to obtain additional information.
To list available channels

redhat_downloader.bat|sh redhat_downloader.sh -listChannels [-configFile
configFile] -rhnUser RHNusername -rhnPass RHNpassword
where - configFile is optional; to be used for proxy settings.

To display help for the Patch Downloader

redhat_downloader.bat|sh redhat_downloader.sh -help
To display version information for the Patch Downloader

redhat_downloader.bat|sh redhat_downloader.sh -version
Downloading child channels using the Patch Downloader

utility
In the configuration file, you provide information about child channels that is used
by the Patch Downloader utility.
To download child channels on Red Hat Enterprise Linux
1 Obtain the list of supported base channels and their child channels.
1 Obtain the list of supported channels by running the listChannels command.
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.
3 Save the .XML configuration file.
4 Run the Patch Downloader Utility for Red Hat Enterprise Linux.
5 Save the file.

A sample output of the listChannels command is shown below:
Channel Name Channel Label OS Arch
Red Hat Enterprise Linux ES (v.4for32-bitx86) rhel-i386-es-4RHES4 x86
Red Hat Enterprise Linux AS (v.3forx86) rhel-i386-as-3RHAS3 x86
Red Hat Enterprise Linux Server (v.6for32-bit x86) rhel-i386-server-6 RHES6
x86
MRG Grid v.2(forRHEL6Server x86) rhel-i386-server-6-mrg-grid-2 RHES6 x86

MRG Grid v.2Debuginfo (forRHEL6Server x86) rhel-i386-server-6-mrg-grid-2-
debuginfo RHES6 x86
MRG Management v.2(forRHEL6Server x86) rhel-i386-server-6-mrg-
management-2RHES6

x86
...
Migrating patch repositories for Red Hat Enterprise Linux

the repository by its operating system and architecture and provides the means for
BMC Server Automation to consolidate all of the RPMs in a single location so that
the repository can be used as a source for an offline patch catalog.
Use this procedure in the following cases:
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.
To create a repository for Red Hat Enterprise Linux

redhat_downloader.sh/redhat_downloader.bat -createRepo -srcLocation
"locationOperSysArch"
-repoLocation
"repositoryPath"
This command uses the following variables:
locationOperSysArch
location of the metadata and payload you downloaded from the vendor site,
in 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 was stored.
os-arch is the operating system/architecture combination used during download.
repositoryPath
location of the repository, used by BMC Server Automation

The following example shows the command on a Linux machine:
./redhat_downloader.sh -createRepo -srcLocation "/opt/storage/patches/

redhat/rhel-x86_64-server-5,RHES5-x86_64"
-repoLocation /opt/storage/patches/redhat/test
where the source location is /opt/storage/patches/redhat/rhel-x86_64-server-5,

and,
the os-arch is RHES5-x86_64
The following example shows the command on a Microsoft Windows machine:
redhat_downloader.bat -createRepo -srcLocation "C:\opt\storage\patches

\redhat\rhel-x86_64-server-5,RHES5-x86_64"
-repoLocation D:\opt\storage\patches\redhat\test
Patch Downloader utility for SUSE Linux Enterprise

The Patch Downloader utility for SUSE Linux provided by BMC Software uses a
configuration file to download metadata and payload from the SUSE Linux
Enterprise website.
Creation of a patch catalog requires that the following packages be pre-installed on

the server that hosts the patch repository:

createrepo 0.4.6
Note
The packages must be of the versions listed here. Earlier or later versions may not
function properly.
The Patch Downloader is either suse_downloader.bat (for running on Microsoft

Windows) or suse_downloader.sh (for running on UNIX). To install, extract the file
and place it in a directory on the server.
Preparing the configuration file for SUSE Linux Enterprise

Downloader utility.

Before you begin
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.
sh suse_downloader.sh -encode passwordToEncrypt
To prepare the configuration file for SUSE Linux Enterprise
1 Edit the sample .XML configuration file (sample-suse-downloader-config.xml)

proxy server
Valid values are:
None
NTLM
NTLM-V2
Squid

Tag Description
download process
are stored
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:
<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
5 Save the file.

The sample-suse-downloader-config.xml file is shown below:
<suse-downloader-config>
<config>
<port>8080</port>
<host>ipAddress</host>
<domain-name />
</proxy-settings>
<payload-repository-location>/home/repo/</payload-repository-
location>
</config>
<subscription>
<os-arch-filter>
<os>SLES10</os>

<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.
Table 39: URLs for SUSE Linux Enterprise
OS Arch Level Online URL Update URL Pool URL

SUSE Linux x86 Base Not Applicable https:// Not Applicable
Enterprise nu.novell.com/
Server 10 repo/$RCE/
SLES10-
Updates/
sles-10-i586/
rpm/
SUSE Linux x86 SP1 https://nu.novell.com/ https:// Not Applicable
Enterprise repo/$RCE/SLES10-SP1- nu.novell.com/
Server 10 Online/sles-10-i586/rpm/ repo/$RCE/
SLES10-SP1-
Updates/
sles-10-i586/
rpm/
SUSE Linux x86 SP2 https://nu.novell.com/ https:// https://
Enterprise repo/$RCE/SLES10-SP2- nu.novell.com/ nu.novell.com/
Server 10 Online/sles-10-i586/rpm/ repo/$RCE/ repo/$RCE/
SLES10-SP2- SLES10-SP2-
Updates/ Pool/sles-10-
sles-10-i586/ i586/rpm/
rpm/
sles-10-i586/ i586/rpm/
rpm/
sles-10-i586/ i586/rpm/
rpm/


SUSE Linux x86_64 Base Not Applicable https:// Not Applicable
SLES10-
Updates/
sles-10-x86_64/
rpm/
SUSE Linux x86_64 SP1 https://nu.novell.com/ https:// Not Applicable
Server 10 Online/sles-10-x86_64/ repo/$RCE/
rpm/ SLES10-SP1-
Updates/
sles-10-x86_64/
rpm/
SUSE Linux x86_64 SP2 https://nu.novell.com/ https:// https://
Server 10 Online/sles-10-x86_64/ repo/$RCE/ repo/$RCE/
rpm/ SLES10-SP2- SLES10-SP2-
sles-10-x86_64/ x86_64/rpm/
rpm/
sles-10-x86_64/ x86_64/rpm/
rpm/
sles-10-x86_64/ x86_64/rpm/
rpm/
SUSE Linux s390x Base Not Applicable https:// Not Applicable
SLES10-
Updates/
sles-10-s390x/
rpm/


SUSE Linux s390x SP1 https://nu.novell.com/ https:// Not Applicable
Server 10 Online/sles-10-s390x/ repo/$RCE/
rpm/ SLES10-SP1-
Updates/
sles-10-s390x/
rpm/
SUSE Linux s390x SP2 https://nu.novell.com/ https:// https://
Server 10 Online/sles-10-s390x/ repo/$RCE/ repo/$RCE/
sles-10-s390x/ s390x/rpm/
rpm/
rpm/
rpm/
SUSE Linux x86 Base Not Applicable https:// Not Applicable
Enterprise you.novell.com
Server 9 /update/i386/
update/SUSE-
CORE/9/rpm/
SUSE Linux x86_64 Base Not Applicable https:// Not Applicable
Server 9 /update/x86_64/
update/SUSE-
CORE/9/rpm/
SUSE Linux s390x Base Not Applicable https:// Not Applicable
Server 9 /update/s390x/
update/SUSE-
CORE/9/rpm/


SUSE Linux x86 Base Not Applicable https:// https://
Enterprise nu.novell.com/ nu.novell.com/
Server 11 repo/$RCE/ repo/$RCE/
SLES11- SLES11-Pool/
Updates/sle-11- sle-11-i586/rpm/
i586/rpm/
SUSE Linux x86 SP1 Not Applicable https:// https://
Updates/sle-11- Pool/sle-11-i586/
i586/rpm/ rpm/
SUSE Linux x86_64 Base Not Applicable https:// https://
SLES11- SLES11-Pool/
Updates/sle-11- sle-11-x86_64/
x86_64/rpm/ rpm/
Running the Patch Downloader utility for SUSE Linux

Enterprise
The following procedures describe how to run the Patch Downloader utility and
how to extract RPM packages from files using the ISO format.
Note
You can run the Patch Downloader for SUSE Linux Enterprise on a Microsoft
Windows or Linux server.
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.
To download patches using defined filters for SUSE Linux Enterprise

sh suse_downloader.sh -configFile "downloaderConfigurationFilePath"
The location of the configuration file used by the Patch Downloader.

Note

suse_downloader.sh -extractPackagesFromISO -repoLocation
"patchRepositoryFilePath"
-isoLocation "isoFilePath" -osArch "operatingSystemArchitecture"
Note
only.
local location of the patch repository used by the Patch Downloader
isoFilePath
location of the ISO from which RPMs are extracted.
an operating system/architecture combination; for example, SLES10x86

for SUSE Linux Enterprise
The following procedures describe how to obtain additional information.

suse_downloader.bat|sh suse_downloader.sh -help

suse_downloader.bat|sh suse_downloader.sh -version

Migrating patch repositories for SUSE Linux Enterprise

the repository by its operating system and architecture. The file provides the means
for BMC Server Automation to consolidate all of the RPMs in a single location so the
repository can be used as a source for an offline patch catalog.
Content
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.
To create a repository for SUSE Linux Enterprise

suse_downloader.sh -createRepo -srcLocation "locationOperSysArch"
-repoLocation "repositoryPath"
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.

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.
Patch Downloader utility for Oracle Enterprise Linux

The Patch Downloader utility for Oracle Enterprise Linux provided by BMC
Software uses a configuration file to download metadata and payload from the
Oracle website.
Creation of a patch catalog requires that the following packages are pre-installed on
the server that hosts the patch repository:

createrepo 0.4.6
Note
function properly.
The downloader is either oel_downloader.bat (for running on Microsoft Windows)

or oel_downloader.sh (for running on UNIX). To install, extract the file and place it
in a directory on the server.
Preparing the configuration file for Oracle Enterprise Linux

Downloader utility.
of a local, temporary directory on the server that will be used by the Patch
Downloader utility during download, and download filter definitions.

Before you begin
Use the following command if you are running the downloader on Microsoft Windows:
oel_downloader.bat -encode passwordToEncrypt
Use the following command if you are running the downloader on UNIX:
sh oel_downloader.sh -encode passwordToEncrypt
To prepare the configuration file for Oracle Enterprise Linux
1 Edit the sample .XML configuration file (sample-oel-downloader-config.xml) for

use as the configuration file.
proxy server
Valid values are:
None: indicates that no proxy server is used
NTLM
Squid
Tag Description
download process

Tag Description
are stored
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:
<channel-label></channel-label> channel label to download
5 Save the file.

The following is an example of the sample-oel-downloader-config.xml file with data:
<oel-downloader-config>
<config>
<proxy-settings>
<port>8080</port>
<host>10.128.115.28</host>
</proxy-settings>
<temporary-location>/tmp</temporary-location>
<payload-repository-location>/home/repo</payload-repository-location>
</config>
<subscription>
<os-arch-filter>
<os>OEL5</os>
<arch>x86</arch>
<channel-label>el5_rds_i386_latest</channel-label>
</os-arch-filter>
</subscription>
</oel-downloader-config>

Running the Patch Downloader utility for Oracle Enterprise

Linux
The following procedures describe running the Patch Downloader utility and
extracting RPM packages from files using the ISO format.
To run the Patch Downloader utility for Oracle Enterprise Linux

sh oel_downloader.sh -configFile "downloaderConfigurationFilePath"
-oelUser "oelUserName" -oelPass "oelPassword"

oelUserName
The user name required to log onto the Oracle Enterprise Linux website.
oelPassword
The password required to log onto the Oracle Enterprise Linux website.

oel_downloader.sh -extractPackagesFromISO -repoLocation
"patchRepositoryFilePath" -isoLocation "isoFilePath" -osArch
"operatingSystemArchitecture"
Note
only.
The local location of the patch repository used by the Patch Downloader.
isoFilePath
The location of the ISO from which RPMs are extracted. Quotation marks
around the path are required.

An operating system/architecture combination; for example, OELES5x86.

Obtaining additional information using the Patch

Downloader utility for Oracle Enterprise Linux
The following procedures are used to obtain additional information.
To list available channels

sh oel_downloader.sh|oel_downloader.bat -listChannels -oelUser
"oelUserName"
-oelPass "oelPassword"
oelUserName
user name required to log onto the Oracle Enterprise Linux website
oelPassword
password required to log onto the Oracle Enterprise Linux website

oel_downloader.bat/oel_downloader.sh -help

oel_downloader.bat/oel_downloader.sh -version
Migrating patch repositories for Oracle Enterprise Linux

the repository by its operating system and architecture. The file provides the means
for BMC Server Automation to consolidate all of the RPMs in a single location so that
the repository can be used as a source for an offline patch catalog.

Content
Automation.
In this procedure, you define the location where the data is stored and where to
create the repository used by BMC Server Automation.
To create a repository for Oracle Enterprise Linux

oel_downloader.sh -createRepo -srcLocation "locationOperSysArch" -
repoLocation "repositoryPath"
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.
each set of information.
Note
repositoryPath
The local location where the repository, used by BMC Server Automation, is
stored.

Creating a patch catalog
Note

The patch catalog is used to maintain and work with the patch repository through
the BMC Server Automation Console.
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.
Before you begin
(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:

createrepo 0.4.6
Note
function properly.
To create a patch catalog
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.
Patch Catalog General on page 1077
Patch Catalog platform - one of the following
Patch Catalog Windows Catalog on page 1077
Patch Catalog Solaris Catalog on page 1080
Patch Catalog AIX Catalog on page 1084
Patch Catalog Red Hat Catalog on page 1088
Patch Catalog SUSE Linux Catalog on page 1091
Patch Catalog Oracle Enterprise Linux Catalog on page 1096
Patch Catalog Schedules on page 1098
Patch Catalog Properties on page 1100
Patch Catalog Permissions on page 1100
Patch Catalog General

The General tab, where you name the patch catalog and write a description of its
contents, is common to all platforms. The only difference is the actual name of the
catalog which changes depending upon the platform.
Patch Catalog Windows Catalog

The Windows Catalog tab determines whether the catalog operates in Online or
Offline Mode and defines a number of options
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.

Before you begin

Prior to creating the Patch Catalog for Windows, you must ensure that the
hfnetchk6b.cab or hfnetchk6b.xml and pd5.cab or pd5.xml files exist in the depot.
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:
Windows Helper Server Path
(Mandatory) NSH path to a user-defined, temporary directory on a Microsoft

Windows server
The temporary directory is used by BMC Server Automation to extract

metadata. BMC Server Automation must have write access to this location.
Payload Source Location (NSH Path)
(Offline only) 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.
Note
Payload files are not required to create the patch catalog.
Payload Repository Location (NSH Path)
NSH path to the location of the patch repository
BMC recommends that this location have ample free space. Repositories
typically contain many files, usually totaling gigabytes of data.

Patch Signature File Location
(Offline only) depot location of the signature file, either hfnetchk7b.cab or

hfnetchk7b.xml, originally downloaded from Shavlik Technologies
Note
For the offline mode, you must add the hfnetchk7b.cab or hfnetchk7b.xml
file to the depot workspace.
Package Info file Location
(Offline only) depot location of the Information File, either pd5.cab or

pd5.xml, originally downloaded from Shavlik Technologies
Note
For the offline mode, you must add the pd5.cab or pd5.xml file to the depot
workspace.
Depot Object Options

Network URL type for payload deployment
(default) Copy to agent at staging: The BMC Server Automation

Application Server copies patch payloads to a staging directory on the
target server during the Deploy Job staging phase.
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
deploy patch payloads directly to the agent

If you select this 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.
Network URL for payload deployment
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
Browse to and select a predefined ACL Policy. Permissions defined by the

ACL Policy are assigned to all Depot Objects created in the catalog.
Download from Vendor
(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
Select a product from the list provided.
Language
Select the appropriate language for the product.
Patch Catalog Solaris Catalog

The Solaris Catalog tab determines whether the catalog operates in Online or Offline
Mode and defines a number of options.
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
Source from Oracle (Online Mode): Use this mode if the BMC Server Automation
Application Server is installed on a server with Internet access.
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
(Offline only) location where existing metadata and payload files are stored
Note
Payload files are not required to create the patch catalog.
Payload Repository Location (NSH Path)
NSH path of the patch repository

Source patchdiag.xref File
(Offline/Oracle Solaris only) (read only) depot location of the patchdiag.xref

file downloaded from the Oracle website
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.
Metadata Corrections File
(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
Single User Mode and Reboot Override File
depot location of the file used to override single user mode and reboot
settings for a particular patch

(Default) Copy to agent at staging: The BMC Server Automation

Deploy Job instructs the agent on a target server to do the following:
Mount the device specified in the URL.
Deploy patch payloads directly to the agent.
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.
Network URL for Payload Deployment
The value entered here depends on your selection in the Network URL type
for payload deployment box.

is autopopulated based on the repository location.
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.
Download patches from Oracle
(Offline Only) To download the payload at the same time as the

patchdiag.xref file, select the Download patches from Oracle 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.
A filter defines:
a specific combination of operating system and architecture
a list of Patch IDs
a specific or custom Oracle Solaris cluster
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

filter such as an operating system-architecture combination, a specific patch

identifier, or a cluster name, and then click OK.
To begin, click Add Filter and select one of the following options:
Os-Architecture
Identify a particular operating system and architecture.
Patch IDs
Create a list of specific patch identifiers.
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.
Patch Catalog AIX Catalog

The AIX Catalog tab defines a number of options including locations (such as
location of the source files and the repository), as well as filters and whether local
copies of the files are created on the target server or downloaded directly during
deployment.
Catalog Mode
Source from IBM Network (Online Mode): Use this mode if the BMC Server
Credentials are not required.
the environment.
Repository Options

Payload Source Location (NSH path)
location where existing metadata and payload files are stored
Repository Location (NSH path)
NSH path to the location where the patch repository is located
(Offline Only)
Either this location must be hosted on an AIX platform, or the downloader

must be run on an AIX platform. If both are not on AIX platforms, you cannot
create an AIX patch catalog.
(Online Only)
This location must be hosted on an AIX platform.

Note
As you do not need to specify the URL of the patch files, the Payload Source
Location (NSH path) option appears grayed out.
Base Repository Location

Base Repository Location
NSH path to the location where base-level payload files are stored. Base-level
payload files are not copied to the repository location.
Base Repository Network URL
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.

Network URL Type For Payload Deployment
(Default) Copy to agent at staging: The BMC Server Automation

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.
Network URL For Payload Deployment
The value entered here depends on your selection in the Network URL Type
for Payload Deployment box.
RBAC Policy
A predefined ACL 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 Update Level Select either Technology Level or Service Pack

(which includes Concluding Service packs). The
corresponding list is enabled. You can include more
than one Technology Level or Service Pack in the
patch catalog.
Note: The list of available Technology Levels and
Service Packs depends on a file downloaded from
the vendor and stored on your server. To see the
identifier list in the patch catalog, you must identify
the location of the file in the AIX Updates List File
box. For more information see the AIX Updates List
File field in Global Configuration parameter list on
page 1025.
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.

By Fix ID Create an individual filter for a specific APAR or

PTF. Multiple filters of this type are permitted in the
patch catalog.
Type: Select either APAR or PTF. Multiple filters

of this type are permitted in the patch catalog.
APAR Id/PTF Id: Enter the identifier for the

APAR/PTF.
If the patch catalog contains this type of filter, you

can create an Include/Exclude list as part of the
analysis options for a Patching Job based on this
patch catalog.
Patch Catalog Red Hat Catalog

The Red Hat Catalog tab determines whether the catalog operates in Online or
Offline Mode and defines a number of options including locations (such as location
of the source files and the repository) as well as filters and whether local copies of
the files are created on the target server or downloaded directly during deployment.
Catalog Mode
Source from Red Hat Network (Online Mode): Use this mode if the BMC Server
the environment.
Red Hat Network Credentials

If you selected Source from Red Hat Network (Online Mode) enter the user name
and password supplied by the vendor and required to access the Red Hat Network
website.
Repository Options

(Offline Only) location of existing metadata and payload files
Repository Location (NSH Path)
NSH path 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.
Note
(Online Mode) You can copy pre-existing Errata and RPMs manually into this
directory. BMC Server Automation does not download duplicate files from
the Red Hat Network site.

Network URL Type for Payload Deployment
(default) Copy to agent at staging: The BMC Server Automation

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.
Network URL for Payload Deployment
for Payload Deployment box:

RBAC Policy
Browse to and 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. Available types of
filters are:
Errata Type
Errata Advisory
Update Level
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:
Online Mode (Red Hat Network is Selected Automatically)
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
For Errata Type, choose:
Bug Fix Advisory
Product Enhancement Advisory

Security Advisory
For Errata Severity, choose:
Critical
Important
Moderate
Low
By Errata Advisory
Create an Include List by entering the names of individual Errata Advisories.
By Update Level
Select the Update Level from the list provided.
Offline Mode (Disk Repository is Selected Automatically)
Enable Update Level
Select an Update Level that you previously downloaded.
Update Level
Select an Update Level identifier; only one can be included for each filter.
Patch Catalog SUSE Linux Catalog

The SUSE Linux Catalog tab defines a number of options including locations (such
as location of the source files, the repository, the signature file) as well as filters and
whether local copies of the files are created on the target server or downloaded
directly during deployment.
Catalog Mode
Source from Vendor (Online Mode): Use this mode if the BMC Server

the environment.
SUSE Linux Network Credentials

If you selected Source from Vendor (Online Mode), enter the user name and
password used to access the vendor website. Select one or both of the following options:
Novell Credentials: Set these credentials to connect to SUSE Linux Enterprise 9

URLs.
Novell Mirror Credentials: Set these credentials to connect to SUSE Linux

Enterprise 10 and SUSE Linux Enterprise 11 mirror URLs.
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
(Offline Only) Location of the XML files generated by the downloader and the
corresponding payload files
To support sourcing of vendor-supplied media, run the BMC Patch

Downloader utility using the -createRepo option. This option creates the
repository with the necessary metadata file. Then identify the source location
here.

Repository Location (NSH Path)
NSH path to 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.
(Online Only)
Novell Networks provides the following repositories per Service Pack

release: Updates, Online, and Pool. For details about the repositories, see the
following link: http://www.novell.com/support/search.do?
cmd=displayKC&docType=kc&externalId=7005899&sliceId=1&docTypeID=
DT_TID_1_1&dialogID=104000207&stateId=0%200%20207543595.

Network URL Type for Payload Deployment
(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.
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.
if you chose Agent mounts source for direct use at deployment (no local

RBAC Policy
Browse to 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. 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
(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:
Import the file into the Depot workspace
Point to this Depot path on the Patch Global Configuration tab.
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.

Patch Catalog Oracle Enterprise Linux Catalog

The Oracle Enterprise Linux Catalog tab defines a number of options including
locations (such as location of the source files and the repository) as well as filters and
whether local copies of the files are created on the target server or downloaded
directly during deployment.
Catalog Mode
The Source from Disk Repository (Offline Mode) option is already selected.
Repository Options
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.
To support sourcing of vendor-supplied media, run the BMC_supplied patch

downloader utility using the -createRepo option. This option creates the
repository with the necessary metadata file. Then identify the source location
here.
Repository Location (NSH path)
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.
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.
if you chose Agent mounts source for direct use at deployment (no local
RBAC Policy
Browse to 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. 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.
must be at least one. Only RPMs that match the combinations you define (and their
dependent RPMs) are added to the catalog.
To begin, click Add Filter:
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


Patch Catalog Schedules

Scheduling a job
Scheduling jobs
To schedule jobs

Mean Time.
Scheduled Job Notifications

completes.
Send email to
Send SNMP trap to


Patch Catalog Properties


inherited.
Property .
Patch Catalog Permissions

this object.
you want to add.

Modifying patch catalog definitions


Modifying patch catalog definitions

After you create the patch catalog, you can open it and modify it using the BMC
Server Automation Console. One additional tab, the Results tab, is included. It
shows results of update catalog actions.
To modify patch catalog definitions
1 Right-click a patch catalog in the Depot and choose Open.
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.
Patch Catalog General on page 1077
The catalog tab is platform-specific:

Smart Groups in the patch catalog
Patch Catalog Windows Catalog on page 1077
Patch Catalog Solaris Catalog on page 1080
Patch Catalog AIX Catalog on page 1084
Patch Catalog Red Hat Catalog on page 1088
Patch Catalog SUSE Linux Catalog on page 1091
Patch Catalog Oracle Enterprise Linux Catalog on page 1096
2 To see or modify properties or permissions, select the Properties or Permissions

tab group at the bottom left of the console.
Smart Groups in the patch catalog

Smart groups are a dynamic means of organizing content within the patch catalog
according to user-defined criteria.
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:
For this platform The following smart groups are defined

Microsoft Windows Bulletins, Hotfixes, and Irrelevant Patches
Solaris Patches, Clusters, and Irrelevant Patches
AIX Filesets and Irrelevant Patches. A third smart group, determined by the
type of filter defined for the patch catalog, is one of the following:
Technology Level
Service Packs
APARs
PTFs
Critical Fixes Package
Security Fixes Package
Latest Fixes Package

Updating an existing catalog
For this platform The following smart groups are defined

Red Hat Enterprise Linux Erratas, RPMs, and Irrelevant Patches
SUSE Linux Enterprise RPMs and Irrelevant Patches
Oracle Enterprise Linux RPMs and Irrelevant Patches
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.
Updating an existing catalog

Actions performed during update are platform-dependent:
For this platform The following actions occur
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.
To update the existing catalog
1 On the BMC Server Automation Console, right-click the patch catalog and select
Update Catalog.

Downloading patch payloads to the 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.
To view patch catalog update job results
After the patch catalog is updated, you can do the following to view the results of a
Patch Catalog Update Job:
1 Right-click the catalog and select Open.
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.

(Microsoft Windows and Solaris) If you choose not to download the payloads at the
same time as the metadata, you can download them individually or you can use the
following procedure to select a group of patches and initiate download of the
payload for patches that already have metadata in the patch catalog.
Tip
Use this procedure if the amount of data to download is significant and would
impact performance. You can schedule the download in advance of deployment,
during off-peak hours, to make more efficient use of maintenance windows.
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.
To download selected patches to the catalog
1 In the Depot folder, navigate to the patch catalog for which you want to
download patches.
2 Right-click and choose Download.
3 Provide information for the New Patch Download Job as described in the
following sections:
New Patch Download Job General on page 1105

New Patch Download Job Download Options on page 1105
New Patch Download Job Default Notifications on page 1106
New Patch Download Job Schedules on page 1107
New Patch Download Job Properties on page 1107
New Patch Download Job Permissions on page 1108
To view download job results
1 After the patches are downloaded, you can right-click a Download Job and select
Show Results.
New Patch Download Job General

On the general tab, you can enter basic information about the New Patch Download
Job.
Name
Enter the name of the Download job.
Description
Enter a description of the Download Job.
Save in
Select a location where the Download Job is stored.
Specify a Catalog
(Read only) Displays the hierarchical location in the Folders pane where the
patch catalog is stored.
New Patch Download Job Download Options

Click Add and select patches from the provided list.
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.
New Patch Download Job Default Notifications

notifications.

Send email to
Send SNMP trap to


New Patch Download Job Schedules

Scheduling a job

New Patch Download Job Properties



inherited.
Property .
New Patch Download Job Permissions

this object.
you want to add.


Removing irrelevant patches from an existing catalog

Removing irrelevant patches from an existing

catalog
The clean up process presents a list of patches and their dependencies in the catalog,
which do not match the specified filters and require removal.
To remove irrelevant patches from an existing catalog
1 Right click the catalog and select Removing Irrelevant Patches.
2 To begin removal, click OK.
Progress is shown. If dependencies for a particular patch are discovered, BMC

Server Automation requests instructions. Click OK to remove dependencies as
well or Ignore to keep the dependent patches in the catalog.
3 Click Close.
Deploying directly from the patch catalog

(AIX only)
After creation of the patch catalog, you can deploy directly to the target server in
either the apply or the commit state without first performing analysis.

Creating a Patching Job
To deploy directly from the patch catalog in the apply state
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
To deploy directly from the patch catalog in the commit state
ID, PTF, Critical Fix, Security Fix, or Latest Fix and select Open.
2 In the Install Command box, enter the following command:

installp -ac -Y -d . all
3 Save and close the AIX Container Properties panel.
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.

A Patching Job performs patch analysis on a group of target servers based on a patch
catalog. You have the option of using either the entire catalog or one or more smart
groups from within the patch catalog.
A Patching Job includes the following:
Analysis The Patching Job checks the configuration of target servers and
determines which patches are needed.
(Optional) Create Remediation Artifacts The Patching Job performs the

following actions:

1 (Microsoft Windows, Solaris only) downloads the required payload
2 packages the payload as a BLPackage
3 creates a Deploy Job

Note
The Patching Job creates the Deploy Job. The Deploy Job executes according to
the schedule you define for Deploy Jobs. The Patching Job does not wait for the
Deploy Job to finish.
By default the patching job creates the deploy job but does not run it.
If you have permission for the analysis part of a Patching Job, then you also
have permission for the remediation part of the job.
Before you begin
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:
Enable NFS client services on the target server.
Change the server property setting, DEPLOY_ALLOW_NFS_DURING_SUM, to

true.
For more information, see Using NFS to mount a location while running single-user
mode on page 771
To create a Patching Job
1 In the Jobs folder, navigate to the folder where you want to create a Patching Job.
2 Do one of the following actions:
Right-click and select New => Patching Job > platformName Patching Job.
For example, Microsoft Windows Patching Job, Solaris Patching Job.
Right-click a specific server and select Patch Analysis.
Right-click a catalog and select Analyze Using This Catalog.
3 Provide information for the Patching Job as described in the following sections.

Patching Job General on page 1112
The Analysis Options tab is platform-specific:
Patching Job Analysis Options for Microsoft Windows on page 1113
Patching Job Analysis Options for Solaris on page 1114
Patching Job Analysis Options for AIX on page 1119
Enterprise Linux, and SUSE Linux Enterprise on page 1120
Patching Job Remediation Options on page 1121
Patching Job Targets on page 1121
Patching Job Default Notifications on page 1123
Patching Job Schedules on page 1124
Patching Job Properties on page 1127
Patching Job Permissions on page 1127
Patching Job General

On the general tab, you can enter basic information about the Patching Job.
Name
Enter the name of the Patching Job.
Description
Enter some information about the Patching Job.
Specify a Catalog
Browse to and select a patch 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.

Set Execution Override
Select when the Patching Job will always execute as the user, BLAdmin, and
the role, BLAdmins.
Clear Execution Override
Select when the Patching Job will always execute using the user and role that
scheduled the job.
Patching Job Analysis Options for Microsoft Windows

A Patching Job checks the configuration of patches on specific servers according to
the filters defined as part of the job definition.
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 patches (Recommended)
Analyze patches that address security vulnerabilities. The Patching Job

performs analysis against all patches in the Patch Catalog. Any patch that is
missing from the catalog during analysis shows as missing in the Job Log.
Security tools
Analyze patches that prevent or clean up malicious software.

Non-security patches
Analyze performance-related fixes, fixes for known bugs, and hardware

drivers.
Exclude Service Packs
(Optional) Select when you do not want to include service packs in the
analysis results.
Patching Job Analysis Options for Solaris

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 all Patches
Select to analyze all patches contained in the patchdiag.xref file.
Analyze Recommended patches
Select to analyze patches that were recommended by the vendor according to

information contained in the patchdiag.xref file.
Analyze Security patches
Select to analyze patches that address security vulnerabilities.
Analyze Without Dependencies
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.

Patching Job Independent Solaris LDoms can be patched

simultaneously
In versions earlier than BMC Server Automation version 8.2, administrators needed
to patch primary and guest Oracle Solaris Logical Domains (LDoms) separately. If
they added primary and guest LDoms to the same Patch Analysis Job, the Deploy
Jobs conflicted with the patch installation on the guest LDoms that occurred during
primary LDom patching. Starting with BMC Server Automation version 8.2,
administrators can add primary and guest Solaris LDoms to the same Patching
Analysis Job, and remediate both LDoms simultaneously. If the Analysis or
Remediation Job contains both primary and guest LDoms, then patching proceeds
by first creating separate Batch Jobs for the primary and guest LDoms, and then by
creating a master Batch Job that patches the guest LDoms before the primary LDoms.
Creating a master Batch Job avoids Deploy Job conflicts with installation of patches
on the guest LDoms.
Analyzing and deploying Solaris LDom patches
Starting with BMC Server Automation version 8.2, administrators can
Create Batch Jobs for primary and guest LDoms
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.
Setting up Patch Global Configuration to stop and restart LDoms
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).
Shutdown Ldoms using ldm-names as hostname: This option executes the

shutdown command on the guests using the nexec parameter, using ldm-name as
the hostname for nexec.
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.
LDom patching workflow

The Master Deploy Job executes LDom patching in the following sequence:
1 The guest LDoms Deploy Job is executed.
2 An NSH Script Job to shutdown the guest LDoms from the Application Server
using the shutdown command is executed.
3 The primary LDoms Deploy Job is executed.

Note
To use the Solaris LDom patching functionality, administrators must have NSH
Script create and read permissions, and NSH Script Job create, read, and execute
permissions.
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.
Known Issues in Solaris LDom patching
The following known issues remain in Solaris LDom patching:
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.
Guidelines for Solaris LDom patching
BMC specifies the following guidelines for Solaris LDom patching:
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.
Patching Job Analysis Options for AIX

Note
A Patch Analysis Job on AIX does not show any rpm dependency issues in the
analysis log files and the Deploy Job might fail. You must ensure that all the required
rpm packages are installed on the target computer.
You can create an Include/Exclude List for specific patch containers (PTFs or
APARs) or choose from one of the following options:
Stop Analysis if any applied fileset found
Use this option to stop analysis on any target server that has filesets in the
applied state (installed but not committed).
Use Patch global configuration settings
The Patching Job uses the settings in the Global configuration parameters.
Continue Analysis if any applied fileset found
Use this option to continue analysis on any target server that has filesets in
the applied state (installed but not committed).
Group
Select to use the entire patch catalog for patch analysis.
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.
Analysis of a specific APAR or PTF includes the entire service pack.

Therefore, the version of the target server is upgraded to the same version as
the service pack that was analyzed.

Note
Exclusion is the only action you can perform at the fileset level.
Patching Job Analysis Options for Red Hat Enterprise Linux,

Oracle Enterprise Linux, and SUSE Linux Enterprise
filters defined as part of the job definition.
You can create an Include/Exclude list for specific patches, to override the default of
including the entire patch catalog in the analysis.
In addition, choose from one of the following options:
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).

Patching Job Remediation Options

If the Patching Job autoremediates after completion of analysis, enter the following
information:
Create remediation artifacts
Select to remediate on completion of analysis. All other options are available

only if Create remediation artifacts is selected.
Package name prefix
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.
Save package(s) in:
Enter a depot location where the remediation package is stored. By default,

the location is the same one used to store the Patching Job.
Save batch/deploy job(s) in:
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.
ACL Policy for Package(s)/Deploy Job(s):
Browse to and select the ACL policy to assign to each BLPackage, Deploy Job,
and Batch Job created by the Patching Job.
Deploy Job Options
Select to open Deploy Job Options. The options defined here are the same
ones defined for any Deploy Job.
Deploy Job Properties
Select to open a list of Deploy Job properties. The properties defined here are
the same ones defined for any Deploy Job.
Patching Job Targets

Use the Targets panel to choose the servers where this job runs. When first defining
and saving a job, you do not have to specify target servers. You can specify target
servers at a later time.

Field definitions
Available Servers
By Group, By Name
servers.
Patching Job Output

The Output panel lets you capture job completion status for the current job and use
it to populate a predefined property that you created in the Property Dictionary,
within the built-in property class for the job targetsthe Server, Component, or
Device property class.
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.
Patching Job Default Notifications

notifications.

Send email to
Send SNMP trap to


Enhanced Default Notifications panel

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
Patching Job Schedules

Enter Approval Information dialog. For more information, see Patching Job
Execute on approval and Approval type settings on page 1126.
Scheduling a job
information, see Patching Job Scheduling on page 1125.
a scheduled job runs. For more information, see Patching Job Scheduled

Patching Job Execute on approval and Approval type settings on page
1126.

Patching Job Scheduled Job Notifications

completes.
Send email to
Send SNMP trap to

Patching Job Scheduling


To schedule jobs
Mean Time.
Patching Job Execute on approval and Approval type

settings

create a schedule for a job that you are creating
schedule an existing job for execution
set a schedule in an execution task
page 617.
Patching Job Properties


inherited.
Property .
Patching Job Permissions


Modifying Patching Jobs
this object.
you want to add.


Modifying Patching Jobs

Use this procedure to modify an existing Patching Job using the BMC Server
Automation Console.

Viewing Patching Job results
To modify a Patching Job
1 Take one of the following actions:
To modify the definition of an existing Patching Job, open the Jobs folder and
Patching Job General on page 1112
The Analysis Options tab is platform-specific:
Patching Job Analysis Options for Microsoft Windows on page 1113

Patching Job Analysis Options for Solaris on page 1114
Patching Job Analysis Options for AIX on page 1119
Enterprise Linux, and SUSE Linux Enterprise on page 1120
Patching Job Remediation Options on page 1121
Patching Job Targets on page 1121
Patching Job Default Notifications on page 1123
Patching Job Schedules on page 1124
These tabs correspond to panels in the New Patching Job wizard. Use them to


On completion, results for the Patching Job are shown on the right side of the
window. If create remediation artifacts is included in the Patching Job
configuration, remediation results are included as well as analysis results.
Note
(Solaris and Linux only) If the Analysis Job is set to Debug mode on the Appserver
level, the Analysis logs are included in the Appserver logs. The Analysis logs specify
the location on the target in which the results and the error logs of the Analysis are
stored.

To view Patching Job analysis results
1 Right-click the Patching Job and select Show Results.
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
type of job run
final status of the job
starting and ending date/time for the job
user that ran the job
Note
For a description of menu options available from the root job node, see
Managing jobs on page 605.
3 Expand the root node.
A list of run dates and times for the Patching Job is displayed.
4 Expand one of the job run nodes.
Analysis and remediation results are displayed on separate lines.
5 Select the analysis results node.
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:
Microsoft Windows: bulletins and hotfixes
Solaris: clusters and patches
AIX: containers and filesets

examples of containers: Technology Level, Service Pack, APAR ID, PTF,
Critical Fix, Security Fix, or Latest Fix
Red Hat Enterprise Linux: RPMs and Erratas
SUSE Linux Enterprise, and Oracle Enterprise Linux: RPMs
To view Patching Job remediation results
1 Right-click the Patching Job and select Show Results.
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.
3 Expand the root node.
A list of run dates and times for the Patching Job is displayed.
4 Expand one of the job run nodes.
Analysis and remediation results are displayed on separate lines.

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.
Managing patches through the analysis results view

In results view, you can perform several patch-specific actions.
To deploy selected patches (Microsoft Windows or Solaris)
1 In the Jobs folder, right-click the Patching Job and select Show Results.
2 Expand the Job Run Node.
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.
To download selected patches (Microsoft Windows or Solaris)
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.
To open the patch (all platforms)

3 In Object View, right-click a patch and select Open Patch.
BMC Server Automation opens the Depot Software Properties box with a two-
page, read-only description of the metadata for the selected patch.
To remediate all servers (all platforms)
3 Right-click Server View and select Remediate All Servers.
BMC Server Automation opens a Remediation Job to install all missing patches on
all target servers listed in the Patching Job.
To download all missing patches (Microsoft Windows or Solaris)
3 Right-click Server View and select Download All Missing Patches.
BMC Server Automation downloads payload for all patches that only have
metadata in the patch catalog.
Viewing Batch Job results for remediation

After the Patching Batch Job has completed, you can use the following procedure to
view the results:
To view manual Batch Job results for remediation
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.

Manually remediating servers

Remediation is the process of downloading the payload for patches determined to be
missing on one or more target servers and then applying that payload to the
identified target servers to bring each one up to the required level.
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.
To manually remediate a server
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).
3 Provide information for the remediation job as described in the following

sections.
Patch Remediation Job General on page 1134
Patch Remediation Job Packaging Options on page 1135
Remediation Jobs Deploy Job Options on page 1135
Patch Remediation Job Default Notifications on page 1136
Patch Remediation Job Schedules on page 1137
Patch Remediation Job General

Enter some basic information about the patching job.
Name
Enter the name of the Patch Remediation Job.

Description
Enter some information about the Patch Remediation Job.
Save In
If not already displayed, enter or browse to the location where the Patch
Remediation Job is stored.
Set Execution Override
Select if the Patching Job always executes as the user, BLAdmin, and the role,
BLAdmins.
Clear Execution Override
Select if the Patching Job always executes using the user and role that
scheduled the job.
Patch Remediation Job Packaging Options

Package Name Prefix
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.
Remediation Jobs Deploy Job Options

Save batch/deploy job(s) in
Enter a job folder where the Batch and Deploy Jobs created by the
Remediation Job are stored.

ACL Policy for Package(s)/Deploy Job(s)
Browse to and select the ACL Policy which assigns predefined permissions to
each BLPackage, Deploy Job, and Batch Job created by the Remediation Job.
Deploy Job Options
Select a set of predefined, parameter definitions that are applied to each

Deploy Job created by the Remediation Job.
Patch Remediation Job Default Notifications

notifications.

Send email to
Send SNMP trap to



Patch Remediation Job Schedules

Scheduling a job


Patch Remediation Job Scheduled Job Notifications

completes.
Send email to
Send SNMP trap to

Patch Remediation Job Scheduling


Viewing manual remediation job results
To schedule jobs
Mean Time.
Viewing manual remediation job results

When remediation is run as a separate job, results are displayed in the window.
To view manual remediation job 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.

Patch Deployment
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.
You can set 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:
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.

Patch Deployment
Note
On Microsoft Windows 2008 and Microsoft Windows Vista, the Microsoft update
service must be running for patching to work.
Enhanced view of Patching Job status

A typical scenario for administrators is the need to provision, patch, and run
compliance on their servers in sequence, so that they can make the compliance
results and the compliant servers available to their business unit. However, if they
lack accurate information about whether or not the Patching Job completed (and
about when it completed, if it did complete), administrators cannot schedule the
Compliance Job correctly.
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.
Viewing the status of Deploy Jobs
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.

Additional Information on installed patches, configuration data, and more
Additional Information on installed patches,

configuration data, and more
The following methods can be used to obtain additional information:
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
Note
Live Browse on a server does not list non-security patches.
Snapshot Jobs Snapshots can record the configuration of patches on a target

server at a specific point in time. To take a snapshot, you must run a Snapshot Job.
For more information, see Snapshot Jobs on page 649.
Reports For information about patch management reports, see the BMC
BladeLogic Decision Support for Server Automation.

23
Provisioning basics
This section describes the BMC Server Automation provisioning process and gives
an overview of tasks you perform to provision servers.
Operating systems supported for provisioning

The BMC Server Automation provisioning solution is available for SPARC, Intel,
and PA-RISC architectures.
BMC Server Automation can provision the following operating systems:
Microsoft Windows
Linux
VMWare ESX and WMWare ESXi
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.
The BMC Server Automation provisioning process uses four provisioning

technologies. The phases of the provisioning process differ for each technology. The
technology that you use depends on the operating system being provisioned.
PXE environment For provisioning Microsoft Windows and Linux servers
JumpStart environment For provisioning Oracle Solaris servers
IBM Network Installation Manager (NIM) environment For provisioning IBM

AIX servers
Ignite environment For provisioning HP-UX servers
Provisioning process for Windows and Linux

For provisioning Microsoft Windows and Linux servers, the BMC Server
Automation system uses the Pre-boot Execution Environment (PXE) technology.
This topic describes the phases of provisioning with PXE.
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.

1 Preparation of the target machine

Prepare all necessary cabling and install a PXE-enabled NIC card in the machine
to be provisioned. Configure the machines BIOS so it boots to network first and

reboot the target machine. Ensure that both the NIC and the BIOS firmware are up-
to-date.
2 Target Machine Broadcasts to Network

The target machine broadcasts a DHCP packet with its MAC address to the
network requesting an IP address for itself and the IP address of the PXE Server.
3 DHCP Server Replies

The DHCP Server replies, giving the target machine an IP address. If the DHCP
server and the PXE server are running on the same physical device, the DHCP
server tells the target server that it is also running the PXE server. If the DHCP
server and the PXE server are running on separate physical devices, the PXE
server replies to the initial broadcast, letting the target server know that it is the
PXE server.
4 Target Machine Contacts PXE Server

Using the supplied IP address, the target machine contacts the PXE Server using
either a multicast or a broadcast.
5 PXE Server Checks Database

Using the MAC address of the machine, the PXE Server checks a database that
contains server configuration information. The database provides instructions for
provisioning the server.
6 PXE Server Delivers Instructions for Bootstrap Program

Based on information obtained from the database, the PXE server responds with
DHCP scope options 43, 66, and 67 (pxe menu, next-server and filename),
instructing the target to boot either from its local disk or a boot image obtained
from the TFTP server. The PXE server provides the TFTP server address and
location of the boot image to the target server.
7 Target Machine Runs Bootstrap and Connects to the Application Server

The target machine boots from the boot image and contacts the BMC Server
Automation Application Server for instructions.
8 Application Server Checks Database

Using the MAC Address of the target machine, the Application Server checks its
database to obtain instructions for the target machine.
9 Application Server Delivers Provisioning Instructions

Based on information obtained from the database, the Application Server sends a
set of provisioning instructions, called a system package, to the target machine.

10 Target Machine Requests OS Files

Using the instructions from the Application Server, the target machine requests
the full operating system files from an HTTP server for Linux or an SMB server
for Windows.
11 RSCD Agent is Installed

Optionally, the RSCD agent is installed, which is necessary for managing the
server with BMC Server Automation. A registration event occurs to enter the
target machines information into BMC Server Automation system so the server
can be managed from the BMC Server Automation Console.
12 Provisioning Runs Batch Job for Additional Configuration

Optionally, the provisioning process can run a job that performs additional
provisioning of the target machine. For example, a Batch Job can install and
configure all necessary applications on the target machine.
Provisioning process for AIX

For provisioning IBM AIX servers, the BMC Server Automation system uses IBM
Network Installation Manager (NIM) software. This topic describes the phases of
provisioning with NIM.
BMC Server Automation provisioning integrates with existing NIM environments

for remote provisioning. Key NIM resources used in the provisioning process
include Shared Product Object Tree (SPOT), lpp_source, mksysb, script, fb_script,
resolve_conf, and bosinst_data.

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.
Create and run the Provision Job.
2 Reboot the Target

If your provisioning job is not set up to automatically reboot the AIX target,
connect to the service console on the AIX target and boot the target to the SMS
menu. From the SMS menu, configure the IPL settings to point at the NIM master.
Then boot the target to the network.

3 Target Contacts NIM Master

The AIX target contacts the NIM master for its base operating system installation
instructions.
4 NIM Master Begins Operating System Installation

The NIM master begins the base operating system installation as defined by the
files shipped to the NIM master by the BMC Server Automation Application Server.
5 Application Server Monitors Operating System Installation

The BMC Server Automation Application Server monitors the base operating
system installation job on the NIM master and moves the target to provisioned
upon its completion.
6 Target Reboots to New Operating System

The AIX target reboots and comes up to the new operating system, or to the SMS
menu, from which you can then boot it to the new operating system.
Optionally, the NIM master installs the RSCD agent, which is necessary for
managing the server with BMC Server Automation. A registration event occurs to
enter the target machines information into the BMC Server Automation system so
the server can be managed from the BMC Server Automation Console.

configuration of the target machine. For example, a Batch Job can install and
Provisioning process for Solaris

For provisioning Oracle Solaris SPARC and x86 servers, BMC Server Automation
uses JumpStart software.
Provisioning SPARC devices
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.
To prepare a specific device for the provisioning process:
Install all necessary cabling.
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.
Schedule the Provision Job to run.
2 Provision Job runs

The Provision Job registers the target with the JumpStart boot server so that the
boot server is prepared to respond to the targets BOOTP request with the
add_install_client command. The Job also pushes all necessary JumpStart control
files including sysidcfg, profile, and rules to the JumpStart config server.
3 JumpStart Server Causes target to Reboot

After registering the target and pushing JumpStart scripts, the Provision Job
instructs the JumpStart server to run the reboot script. The reboot script connects
to the target device and forces it to reboot from the network and send a BOOTP
request to the JumpStart server. You can use a program such as expect(1) to
control the execution of a reboot script.
4 JumpStart Server Pushes Config Files to Target

The JumpStart config server pushes required configuration files (sysidcfg, profile,
and rules) to the target.
5 JumpStart Server Installs Operating System

The JumpStart install server installs the operating system on the target device,
following the configuration instructions in the system package/provisioning
wizard.
6 JumpStart Server Installs RSCD Agent

Optionally, the JumpStart server installs the RSCD agent, which is necessary for

7 Provision Job Starts a Batch Job to Perform Additional Configuration

Provisioning x86 devices
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.
To provision a Solaris x86 operating system:
Configure the target machines BIOS to boot to the network.
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.
Provisioning process for HP-UX

For provisioning HP-UX servers, the BMC Server Automation system uses Hewlett-
Packard Ignite software. This topic describes the phases of provisioning in the Ignite
environment.
BMC Server Automation provisioning integrates with existing Ignite environments

for remote provisioning. Key Ignite resources utilized in the provisioning process
include the Ignite master server, Igniteboot helper server, config files, INDEX file,
and INSTALLFS.

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.
Create and run the Provision Job.
2 Reboot the Target

If your Provision Job is not set up to automatically reboot the Ignite target, you
need to reboot the target by doing one of the following things:
Run the bootsys command, using the following syntax:

bootsys -a <target machine name>
for example: bootsys -a itanium1

On the booting menu, select network boot on an active LAN device.
3 Target Contacts Ignite Master

The HP-UX target contacts the Ignite master for its base operating system
installation instructions.
4 Ignite Master Begins Operating System Installation

The Ignite master begins the base operating system installation as defined by the
files shipped to the Ignite master by the BMC Server Automation Application Server.
5 Application Server Monitors Operating System Installation

The BMC Server Automation Application Server monitors the base operating
system installation job on the Ignite master and moves the target to provisioned
upon its completion.
6 Target Reboots to New Operating System

The HP-UX target reboots and comes up to the new operating system.
Optionally, the Ignite master installs the RSCD agent, which is necessary for

Integration of provisioning and server management

The BMC Server Automation system integrates provisioning with BMC Server
Automation server management functions to allow for provisioning higher layers of
the server stack after the operating system is installed.
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.
To set up and enable provisioning (overview of tasks)
Each step in this list includes a reference to more information.
1 Install all required components for the provisioning system.
Specifically, you need:
A PXE environment for provisioning Windows and Linux servers.
A JumpStart environment for provisioning Solaris servers.
A NIM environment for provisioning AIX servers.
An Ignite environment for provisioning HP-UX servers.
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.
2 Set up authorizations related to the provisioning tasks.
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.
Grant role access to servers after they are provisioned.
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.
5 Configure provisioning to work with the other components in the provisioning

process.
This step establishes the connection to the data store and other functional
software components. For information, see Configuring provisioning on page
1184.
6 Set up post-install jobs.
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.
7 Create system packages.
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.
8 Create a Provision Job.
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.
For information, see Creating a Provision Job on page 1354.
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.
10 Select devices to provision and run the Provision Job.
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.
11 Check the Provision Job results.
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.
For JumpStart, NIM, and Ignite provisioning technologies, if the system

package includes a reboot script, the target devices reboot automatically from
the network. If the system package does not include a reboot script, you must
arrange to reboot the target by other means.


24
Provisioning servers
To provision servers, you create and run Provision Jobs. This section describes how
to create the components required for Provision Jobs, configure provisioning, and
create and run Provision Jobs.
Boot image files and placeholders

To provision Microsoft Windows and Linux machines, you must create boot image
files specific to BMC Server Automation. The system contains placeholders for these
files.
The type of boot image file you create depends on the types of machines you plan to
provision.
If you plan to provision... You need to create...

Windows machines Create WinPE image files. See Creating WinPE 2.0 and later
boot image files on page 1160
Linux machines Create a Gentoo Linux image file. See Creating a Gentoo
Linux image file on page 1179.
A placeholder is a pointer to a BMC Server Automation-specific image file. After you

create the image files and put them in the correct places on the TFTP server, you can
use the default placeholders built into the system.
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.
BMC Server Automation contains the following default placeholders:
Boot image file Description

blade.img Used only when working with legacy system packages.
gentoo32 Used to provision x86 Linux machines.

Creating WinPE 2.0 and later boot image files

gentoo64 Used to provision AMD64 Linux machines.
Skip Linux Pre-Install Used to provision a device with the Red Hat, VMware ESX, or
SUSE operating system when you want to skip the Gentoo pre-
installation image. For information, see Using the Skip Linux
Pre-Install image option on page 1183.
ESXi 4.0 (vmkboot.gz) Used to provision AMD64 machines with ESXi 4.0. For
information, see Provisioning target servers with ESXi 4.0 on
page 1382.
WindowsPE_2_x_Image Used to provision x86 Windows machines.
WindowsPE_2_x_x64_Image Used to provision AMD64 and Windows machines.
WindowsPE_2_x_ISO_Image Used to provision x86 Windows machines from removable or
CD-ROM media connected to the machine. For information,
see Provisioning Windows 2003 or 2008 servers from a local
data store on page 1374.
WindowsPE_2_x_x64_ISO_Image Used to provision AMD64 and Windows machines from
removable or CD-ROM media connected to the machine. For
information, see Provisioning Windows 2003 or 2008 servers
from a local data store on page 1374.
Boot image configurations

In addition to pointing to an image file, a placeholder provides default configuration
settings for the image in the BMC Server Automation system. These configuration
settings include: image type, image file name, description, image path (kernel name),
and whether the image is the default boot image.
To view configuration settings for an image, in the BMC Server Automation Console,
select Configurations => Provisioning Configurations. Then click the Image Files
tab.

You create a WinPE 2.0 and later image file to prepare a target machine for Microsoft
Windows installation during provisioning.
After it boots from the image, the machine can obtain instructions for installing the
operating system.
To create the boot image file
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.

2 Create image files using one of the following methods:
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.
Preparing a machine for WinPE 2.0 and later image creation

You must prepare the machine you use to create the image files by installing
required software and ensuring that files are in the appropriate locations.
Note
These instructions include steps for creating a boot image file using the image
creation tool or the CreateWinPE2_x.vbs script. If you are using only the image
creation tool, some of these steps do not apply (and are so noted).
To prepare the machine for image creation
1 Download and install the following items from the Microsoft website:
.NET Framework Version 2.0
Microsoft Core XML Services (MSXML) 6.0
2 Download the appropriate Microsoft Windows Automated Installation Kit

(WAIK) from the Microsoft download website:
To create WinPE 3.0 images, download the Windows Automated Installation

Kit for Windows 7.
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.

4 Extract the winpe.cab file to the desktop.
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.
6 Locate the following BMC Server Automation file: current_release-provision-

files.zip
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.
This file unzips to create the following subdirectory:
\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
Add the following line to the Driver.txt file:
Drivers= fullPathToINFDriver fullPathToINFDriver ...
For example:
Drivers= E:\vmwaredriv\vmd\vmxnet.inf E:\vmwaredriv\vmd\vmx_svga.inf E:

\vmwaredriv\vmd\vmware-nic.inf
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
These files are located in the provisioning\winpe subdirectory. For example, if

you placed provision-files.zip in C:\BMC_BL and unzipped to that same
location, CreateWinPE2_x.vbs and extractpxeboot.vbs are located here:
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.

Creating WinPE 2.0 and later images using the Image

Creation wizard
You use the Image Creation wizard to create WinPE 2.0 and later x86 or x64 boot
image files from the BMC Server Automation Console.
Before you begin
Prepare the machine on which boot images will be created.
If you plan to create image files for booting from media local to the target server,
create a network.ini file.
To create the boot image file
1 Select Configuration => Provisioning Image Creation.
2 Specify information for creating the image, as described in the following sections:
Toolkit Select on page 1164
Driver Selection on page 1166
Custom Script on page 1167
Configuration Details on page 1167
3 Click Finish to begin image file creation.
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
Image Toolkit Host
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.
ISO Image: Creates an image in ISO format (bootImageName.iso) for

booting from media connected to the target 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.
Win AIK Directory Path
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
Create WinPE Script Directory Path
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.
Boot Image Target Directory
Specifies the target directory for the new image file.

Note
The target directory must be on a server running a licensed RSCD agent and
the user creating the image file must be logged into that server using a role
that has Write authorization.
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
Boot Image Name
Specifies the new boot image file name. Spaces are not supported in the boot
image name.
For PXE or ISO image types:
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:
boot_2_0_x86 for 32-bit images
boot_2_0_x64 for 64-bit images
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.
Specify an external script using one of the following methods:
Click Browse to select the script file in the Select Custom Script dialog. Then
click OK after selecting the file.
Type the script in the text box.
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.
Click Browse to select the network.ini file.
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.
Application Server IP Address
Specifies the IP address of the Application Server with which the target
server communicates.
Application Server Port
Specifies the port that the target server uses to communicate with the
Application Server.
Configuration Components for Local Data Store
Specifies the location to which these components (bmiwin.exe, RSCD Agent

installer, and operating system drivers) are copied on local media. Select
either of the following.
Copy to root of ISO/UFD: Copies configuration components to the root of

ISO image or UFD directory on the media.

Copy to WinPE image: Copies configuration components to a pre-defined

directory (LDS) in the WinPE image.
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.
RSCD Installer Path
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.
Creating a network.ini file

You can create a network.ini file to provide network details for each target server in
provisioning environments where there is no DHCP server.
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.

To create a network.ini file
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:
All keys are optional. Their sequence does not matter.
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 ([ ]).
Separate sections with Microsoft Windows line separators.
For DNS_SERVER_SEARCH_ORDER, type a comma-separated list of DNS

server IP addresses. The list specifies the order in which the target server
searches for a DNS server.

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.
Before you begin
Prepare the machine on which boot images will be created.
If you plan to create image files for booting from media local to the target server,
create a network.ini file.
To create the image file with the script:
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.
Creating the input parameters .ini file

You create the input parameters file to provide the CreateWinPE2_x.vbs script with
parameters for the boot image: architecture, location of image creation tools, location
of the files to be included in the image, and image type.
To create the input parameters file:
1 In a text editor, create a new file with the name filename.ini.
2 Use the following syntax to specify parameters in the input file.
Arch (Required) Specifies the architecture of the server for which you are
creating the boot image (x86 or x64).
BLDir (Required) Specifies the full path to the \provisioning\winpe

subdirectory, for example: C:\BMC_BL\provisioning\winpe

DestDir (Required) Specifies the path to the temporary local directory to

hold the image files you are about to create. For example: C:\BMC_BL
\tmp
This directory must already exist before you run the
CreateWinPE2_x.vbs script.
BootDir (Required) Specifies the boot image name, for example:

boot_2_0_x86 or boot_2_0_x64. This name is also the name of the
directory containing the image files.
Note: Names containing spaces are not supported.
In general, you can set BootDir to:
boot_2_0
so that you can use the default placeholders in provisioning.
When you run CreateWinPE2_x.vbs, it creates a directory in the
path specified by DestDir. This new directory has the name specified
by BootDir and contains the image files.
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.

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

WAIKRootDir Specifies a path to the Microsoft Windows Automated Installation

Kit (WAIK).
Specify a value if you want to overwrite the default path. The
default path is:C:\Program Files\Windows AIK
Debug Specifies whether the script displays output messages as it runs.

Specify Debug=Y to display this information.
Specify Debug=N to suppress the display of this information. (This
is the default.)
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:
boot_2_0_x86.iso An ISO image for booting from CD/DVD
boot_2_0_x86_UFD A UFD image for booting from USB flash drive
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
Running the CreateWinPE2_x.vbs script

Run the CreateWinPE2_x.vbs script to create a WinPE 2.0 and later x86 or x64 image
file.
Before you begin

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
To run the script
1 At the command prompt, enter the cscript command with the following arguments:
cscript //nologo createWinPEScriptPath inputFilePath
Where:
cscript Calls the Visual Basic (.vbs) script without displaying a message box
type of user interface.
//nologo (Optional) Hides the MicroSoft copyright information.
createWinPEScriptPath Specifies the path to the CreateWinPE2_x.vbs script.

Enclose this path in double quotation marks ().
inputFilePath Specifies the path to the input file containing the image creation
parameters.
For example:
cscript //nologo C:\Program Files\WinAIK\Tools CreateWinPE2_x.vbs C:

\winpe_x86.ini
Copying image files to a location for provisioning

You copy the WinPE 2.0 and later image files to a location so the provisioning
process can use them. The location to which you copy files depends on the image
type of the WinPE image you created (PXE, ISO, or UFD).
To copy image files of the PXE image type
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.
To copy image files of the ISO image type
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.
To copy image files of the UFD image type
1 Format a USB drive for the FAT32 file system.
2 Copy the all of the files and folders in the bootImageName_UFD directory to the
root of the USB drive.
Copying image files to the TFTP server (PXE)

You copy the WinPE 2.0 and later boot image to the TFTP server so that the
provisioning process can use it with the PXE provisioning technology.
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
To copy boot image files to the TFTP server
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.
Extracting boot files for WinPE 2.0 and later images

After creating the images with CreateWinPE2_x.vbs, you extract the pxeboot.0 and
bootmgr.exe files and copy them to the TFTP server.
To extract boot files
1 Create a temporary local directory to store the files you are about to extract, for
example:
C:\BMC_BL\tmpboot
2 Open a command window and change directories to the \Tools\PETools

subdirectory of the Microsoft Windows AIK installation directory. For example: C:
\Program Files\WinAIK\Tools\PETools
3 Start the WinPE command prompt by typing:
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
5 Take a look at the contents of C:\BMC_BL\tmpboot. You should see pxeboot.0

and bootmgr.exe.
Copy these files to the following locations on the TFTP server:
Copy pxeboot.0 into tftproot \x86pc\pxelinux, for example:

C:\tftproot\x86\pxelinux\pxeboot.0

Copy bootmgr.exe into tftproot, for example:

C:\tftproot\bootmgr.exe
Configuring WinPE security settings

If the server that contains your data store does not support the Microsoft NT Lan
Manager (NTLM) settings for NTLMv2 Level 3, you must change the NTLM settings
for the WinPE image on the TFTP server.
Before you begin
The TFTP server must have the Microsoft Windows Automated Installation Kit
(WAIK) installed.
To change the NTLM settings
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.
b Create a mount directory under C:\new, for example:
C:\new\mount
c Open a command window and change directories to the \Tools\PETools

subdirectory of the Windows AIK installation directory. For example: C:
\Program Files\WinAIK\Tools\PETools
d Start the WinPE command prompt by typing:
pesetenv.cmd
e On the WinPE command line enter:
imagex /mountrw C:\new\WinPE.wim 1 C:\new\mount
2 Open the registry editor (regedit).
3 Click HKEY_LOCAL_MACHINE.
4 Choose File => Load Hive.

Creating a Gentoo Linux image file
5 Select the file:
%Mounted WinPE Image folder in step1%\Windows\System32\config\SYSTEM
6 Enter the following key name:
WinPE_Image_SYSTEM
7 Browse to: HKEY_LOCAL_MACHINE\WinPE_Image_SYSTEM

\ControlSet001\Control\Lsa
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 Name: LMCompatibilityLevel
Data Type: REG_DWORD
Value: 3
Valid Range: 0,3
9 Click HKEY_LOCAL_MACHINE\WinPE_Image_SYSTEM.
10 Choose File => Unload Hive.
11 Use imagex to unmount the mounted WinPE image:
imagex /unmount /commit MountFolder

You can create a Gentoo Linux image file for booting target Linux machines during
the provisioning process.
BMC Software recommends that you execute the image creation script on a Red Hat
system. Place the resulting image on the TFTP server.

To create a Gentoo Linux image file
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
2 Locate the BMC Server Automation file:
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
5 Open a command window and change directories to the /provisioning/linux

subdirectory that you created in the previous step.
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:
a Create a new subdirectory under /provisioning/linux and name it driver.
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.
For example, the directory structure should be similar to the following:
/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
8 Run the mkgen2img.sh script.
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.
To create an x86 Gentoo image...
General syntax mkgen2img.sh location gentooMinimalIsofile

outDirectory
location The full path to the location of the bmi executable.

For example: /tmp/bmc_bl/provisioning/linux/x86/
bmi32

To create an x86 Gentoo image...
gentooMinimalIsofile The full path to the minimal ISO file you

downloaded from the Gentoo site. For example: /tmp/
bmc_bl/install-x86-minimal-20100907.iso
Note: Gentoo updates its minimal ISO files
frequently. For best results, always use the most
current minimal ISO file.
outDirectory The location for the generated image file. Typically,

this value is: /tftproot/x86pc/pxelinux/gentoo32
Note: The BLAdmin role must have Read and Write
access to the TFTP root directory and its contents,
including boot image folders and all image files in
the folders.
Example: /bin/sh mkgen2img.sh /tmp/bmc_bl/provisioning/

linux/x86/bmi32 /tmp/bmc_bl/install-x86-
minimal-20100907.iso /tftproot/x86pc/pxelinux
(Type this command all on one line.)
This command creates the files gentoo and
gentoord.gz, which collectively make up the Gentoo
image file entity.
To create an AMD64 Gentoo image...
General syntax mkgen2img.sh location gentooMinimalIsofile

outDirectory
location The full path to the location of the bmi executable.

For example: /tmp/bmc_bl/provisioning/linux/
amd64/bmi64
gentooMinimalIsofile The full path to the minimal ISO file you

downloaded from the Gentoo site. For example: /tmp/
bmc_bl/install-amd64-minimal-20100907.iso
Note: Gentoo updates its minimal ISO files
frequently. For best results, always use the most
current minimal ISO file.
outDirectory The location for the generated image file. Typically,

this value is:/tftproot/x86pc/pxelinux/gentoo64
Note: The BLAdmin role must have Read and Write
access to the TFTP root directory and its contents,
including boot image folders and all image files in
the folders.

Using the Skip Linux Pre-Install image option
To create an AMD64 Gentoo image...
Example: /bin/sh mkgen2img.sh /tmp/bmc_bl/provisioning/

linux/amd64/bmi64 /tmp/bmc_bl/install-amd64-
minimal-20100907.iso /tftproot/x86pc/pxelinux
(Type this command all on one line.)
This command creates the files gentoo and
gentoord.gz, which collectively make up the Gentoo
image file entity.
9 Check the log file to verify results.
If you included drivers in the image, messages confirm driver injection. For
example:
Bladelogic : gentoo image : Injecting x86 additional drivers

Bladelogic : gentoo image : Configuring autoload for device drivers
Using the Skip Linux Pre-Install image option

To skip the Gentoo pre-installation image during provisioning of the Red Hat
Enterprise Linux, VMware ESX, SUSE, or Citrix operating system to target devices,
use the Skip Linux Pre-Install placeholder image.
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.
When you select the Skip Linux Pre-Install image option:
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.
There is no autodiscovery of devices associated with the Skip Linux Pre-Install

image.
System package pre-installation scripts are ignored in provisioning a device

associated with the Skip Linux Pre-Install image. To execute pre-installation
scripts, use the %pre section of the Kickstart file or the pre-install section of
AutoYaST.

Configuring provisioning
To use the Skip Linux Pre-Install image in provisioning:
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.
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.
Before you begin
Each provisioning technology requires supporting components. Verify that the

required components are installed before proceeding. For information about setting
up the components for each technology, see BMC technical documentation at https://
PXE provisioning requires a DHCP server, a PXE server, a TFTP server, data
stores, and agent installation files.
JumpStart provisioning requires a working JumpStart environment, configured

for and stocked with all of the operating system installation files for provisioning
your target machines, including RSCD agent installation files.
NIM provisioning requires a working NIM environment, configured for and

stocked with all of the operating system installation files for provisioning your
target machines, including RSCD agent installation files.
Igniteprovisioning requires a working Ignite environment, configured for and

stocked with all of the operating system installation files for provisioning your
target machines, including RSCD agent installation files.
To configure the provisioning environment
1 Each provisioning technology requires a set of configuration tasks, as listed in the

following table.

Provisioning Technology Tasks
PXE Configuring the data store on page 1185

Creating custom system package types on page 1201 (optional)
Changing the location of installation files on page 1200
Configuring the PXE server on page 1202 (if you did not do so when you
installed the PXE server)
Configuring the TFTP server on page 1204 (if you did not do so when
you installed the TFTP server)
Configuring boot image files on page 1206
JumpStart Configuring the data store on page 1185

NIM Configuring the data store on page 1185

Ignite Configuring the data store on page 1185

Configuring the data store

You configure the data store to set required values for accessing the data sources for
provisioning.
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.
Before you begin
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

To configure the data store
1 Select Configuration => Property Dictionary View.
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.
3 In the right panel, click the Instances tab.
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 on page 1186
JumpStart properties on page 1188
NIM properties on page 1189
Ignite properties on page 1190
PXE Properties
To configure a data store instance for PXE provisioning, set the following property
values.

PXE Property Name Description
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:
To provision Linux systems, set the LOCATION property to the IP

address (not the host name).
To provision Windows systems, set the LOCATION property to the

host name (not the IP address).
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.

PXE Property Name Description
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.
Property Name Description
BOOT_SERVER Host name of the boot server. This server must have a
running RSCD agent that is licensed for both NSH and the
BOOT_SERVER_FULL_PATH Full path to the Jumpstart root folder on the boot server.

BOOT_SERVER_DOCUMENT_ROOT_PATH (For WAN boot installation) Path to the document root

directory of the web server on the boot server.
BOOT_SERVER_URL (For WAN boot installation) URL for accessing the
document root directory using HTTP.
BOOT_SERVER_CGI_BIN_PATH (For WAN boot installation) Path to the cgi-bin directory on
the boot server.
BOOT_SERVER_CGI_BIN_URL (For WAN boot installation) URL for accessing the cgi-bin
directory on the install server using HTTP.
CONFIG_SERVER Host name of the configuration server. This server must
have a running RSCD agent that is licensed for both NSH
and the BMC Server Automation Console.
CONFIG_SERVER_FULL_PATH Full path to the configuration root on the configuration server.
INSTALL_SERVER Host name of the install server. This server must have a
running RSCD agent that is licensed for both NSH and the
INSTALL_SERVER_FULL_PATH Full path to the installers on the install server. This is the full
path to the directory that functions as a data store.
INSTALL_SERVER_DOCUMENT_ROOT_P (For WAN boot installation) Full path to the document root
ATH directory of the web server on the install server.
INSTALL_SERVER_URL (For WAN boot installation) URL for accessing the
document root directory using HTTP.
INSTALL_SERVER_CGI_BIN_PATH (For WAN boot installation) Path to the cgi-bin directory on
the install server.
INSTALL_SERVER_CGI_BIN_URL (For WAN boot installation) URL for accessing the cgi-bin
directory on the install server using HTTP.
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.
Configuring a system package type

The System Package Types tab lists the available system package types and lets you
edit their definitions or create your own custom system package type.
To configure a system package type
1 In the menu bar, select Configuration > Provisioning Configurations.
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.
3 Complete the configuration window that appears.

The fields in the configuration window are specific to the OS of the system
package type:
Windows system package type configuration on page 1191
Red Hat system package type on page 1193
VMware ESX and ESXi system package type on page 1195
SUSE Linux system package type on page 1194
Solaris system package type configuration on page 1197
AIX system package type configuration on page 1198
HP-UX system package type configuration on page 1198
Citrix XenServer system package type on page 1199
4 When you finish adding or editing system package types, click OK on the System
Package Types tab.
Windows system package type configuration

The System Package Types configurations window lets you add a system package
type or change configuration information for a Windows system package type.
WIM Based System Package
Check this box if this system package type is for creating system packages
based on a WIM image in a data store.
Windows 2008 and above
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.
System package type
Name of the system package type.

OS Installer location
Directory where the operating system installer is located.
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:
C:\Program Files\BMC Software\BladeLogic\PXE\pxestore
and the OS installer files reside in:
C:\Program Files\BMC Software\BladeLogic\PXE\pxestore\win2k8
you would enter win2k8

Note
WIM-based system packages: Enter the path to the WIM image, including the
image name. Specify a path relative to the full path of the data store. For
example, if the image resides in:
C:\Program Files\BMC Software\BladeLogic\PXE\pxestore\WIMimages
you would enter WIMimages\Win2008standard.wim
RSCD agent installer location
Directory where the RSCD agent installer files reside.
Initial Partition Size (MB)
Size of the initial disk partition (in MB).
Default: 2000
Set this value according to Microsofts available disk space recommendations

for the operating system type.
To ensure that the operating system installation completes successfully, the

provisioning process requires the following values for initial partition size:
For Windows 2008 and Windows 2008 R2 operating systems: At least

10000 MB for an x86 system package type and at least 15000 MB for an x64
For all other Windows operating systems: At least 2000 MB.
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.
Red Hat system package type

The System Package Types window lets you create a custom system package type or
change configuration information for the Red Hat system package type.
Red Hat version
(For creating a custom system package type.) Select the Red Hat version for
which you want to create a system package type.
System package type
OS installer location
C:\Program Files\BMC Software\BladeLogic\PXE\pxestore\RedHat5
you would enter
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
RSCD agent installer Location
Directory where the installer for the RSCD agent resides.
Boot kernel file name
The name assigned to the boot kernel file stored in the X86PC\pxelinux
directory on the TFTP server.

By default, the boot kernel file is named vmlinuz.
Boot image file name
The name assigned to the boot image file stored in the X86PC\pxelinux
By default, the boot image file is named initrd.img.
SUSE Linux system package type

type or change configuration information for the SUSE Linux system package type.
SUSE/SLES Version 10.x or higher
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.
System package type
C:\Program Files\BMC Software\BladeLogic\PXE\pxestore\suse9
you would enter
suse9
of the following two directories, for the version of SUSE that you are
provisioning:
boot
suse

RSCD agent installer Location
By default, the boot kernel file is named linux.
By default, the boot kernel file is named initrd.
VMware ESX and ESXi system package type

The System Package Types window lets you add a system package type or change
configuration information for the ESX and ESXi system package type.
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.
System package type
C:\Program Files\BMC Software\BladeLogic\PXE\pxestore\VMWare

\esx3_5
you would enter

VMWare\esx3_5
of the following two directories, for the version of VMWare that you are
provisioning:
isolinux (does not apply to ESXi 4.1)
VMWare
(Does not apply to ESXi 4.1) RSCD agent installer Location

Note
ESXi 4.1 does not require the RSCD agent.
By default, the boot kernel file is named:
vmkernel.gz for VMware ESXi 4.1.
vmlinuz for all other VMware versions.
By default, the boot image file is named:
vmkboot.gz for VMware ESXi 4.1.
initrd.img for all other VMware versions.
ESXi additional images
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
Solaris system package type configuration

type or change configuration information for the Solaris system package type.
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.
System package type
Relative path to the Tools directory of the installer tree. The location you
specify should be relative to the data store install server root.
For example, if the full path to the Tools directory is /jumpstart/solaris10/

Solaris10 (meaning there exists a Tools directory under /jumpstart/solaris10/
Solaris10) and the install server root is set up as /jumpstart, then enter
solaris10/Solaris10.
Archive location (WAN boot only)
Path to the Solaris Flash archive on the install server, relative to the install
server document root directory.

Miniroot location (WAN boot only)
Path to the miniroot file on the boot server, relative to the boot server
document root directory.
WAN Boot location (WAN boot only)
Path to the wanboot installation program on the boot server, relative to the
boot server document root directory.
AIX system package type configuration

type or change configuration information for the AIX system package type.
System package type
SPOT name
Name of the NIM Shared Product Object Tree (SPOT) resource.
Lpp_source name
Name of the NIM lpp_source resource.
Mksysb name
Name of the NIM mksysb resource.
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
HP-UX system package type configuration

type or change configuration information for HP-UX system package type.

HPUX architecture
The type of machine you plan to provision with this system package type.
System package type
Index file
Click Browse to select the Ignite index file you want to use for this system
package.
Citrix XenServer system package type

The System Package Types window lets you add a system package type or change
configuration information for the Citrix XenServer system package type.
System package type
Directory where the Citrix XenServer installer is located.
and the installer files reside in:
C:\Program Files\BMC Software\BladeLogic\PXE\pxestore\XenServer56
you would enter
XenServer56
For example: \XenServer\vmlinuz.

For example: \XenServer\install.img.
Xen kernel file name
The name of the Xen hypervisor kernel stored in the X86PC\prelinux

directory on the TFTP Server. For example: XenServer\xen.gz.
Changing the location of installation files

The System Package Types tab on the Provisioning Configurations window
identifies the system packages you can use for provisioning. In some situations, you
may want to modify the location where you store installation files for a particular
system package.
This information applies to applies to PXE, JumpStart, NIM, and Ignite environments.
Before you begin
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:
PXEspecifying the FULL_PATH property in the Data Store system object.
JumpStartspecifying the INSTALL_SERVER_FULL_PATH property in the Data

Store system object.
NIMspecifying the NIM_MASTER property in the Data Store system object.
Ignitespecifying the IGNITE_SERVER property in the Data Store system object.
For information, see Configuring the data store on page 1185.
To change the location of installation files
1 Choose Configuration => Provisioning Configurations.
2 Click the System Package Types tab.

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.
5 Click OK on the System Package Types tab to have your provisioning

configuration changes take effect.
Creating custom system package types

The System Package Types tab on the Provisioning Configurations window lists the
available system package types. If necessary, you can create your own custom
For example, you might create a custom system package type to deploy an operating
system based on an earlier Microsoft service pack.
This procedure applies to PXE, JumpStart, NIM, and Ignite environments.
Before you begin
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:
PXEspecifying the FULL_PATH property in the Data Store system object.
JumpStartspecifying the INSTALL_SERVER_FULL_PATH property in the Data

Store system object.
NIMspecifying the NIM_MASTER property in the Data Store system object.
Ignitespecifying the IGNITE_SERVER property in the Data Store system object.
For information, see Configuring the data store on page 1185.
To create a custom system package type:
1 Select Configuration => Provisioning Configurations.

2 Click the System Package Types tab.
3 Under Relative Paths for OS Images, click Add .
The System Package Type window opens.
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.
6 Click OK on the System Package Types tab to have your provisioning

configuration changes take effect.
Configuring the PXE server

You configure the PXE Server so the BMC Server Automation system can
communicate with the target server during provisioning in the PXE environment.
Before you begin
To see the PXE configuration tab, you must have, at minimum, the
ProvisionConfig.Read authorization.
To configure the PXE Server:
2 Click the PXE tab.
3 Provide information about the tab. Then click OK to save the current values. See
PXE Server tab on page 1203.
4 Stop and restart the PXE server.

Note
You can also configure the PXE server by editing the pxe.conf file. By default, this
file resides in the following location:
Windows: installDirectory\PXE\br\pxe.conf
UNIX: installDirectory/NSH/br/pxe.conf

PXE Server tab

The PXE tab on the Provisioning Configurations window lets you provide
information about the PXE server, such as its listening port and the address of the
multicast group to which the PXE server connects.
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
The domain of the PXE server.
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.
Starting and stopping the PXE server

You stop and restart the PXE server to have configuration settings take effect.
Before you begin
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.
To start the PXE server
1 Perform the step appropriate for your operating system type.
Windows:
1 The PXE server is a Windows service, so choose Start => Settings =>
Control Panel => Administrative Tools => Services.
2 Right-click BladeLogic PXE Server and select Start.
Linux: Type the command: /etc/init.d/blpxe start
To stop the PXE server
Windows:
1 The PXE server is a Windows service, so choose Start => Settings =>
Control Panel => Administrative Tools => Services
2 Right-click BladeLogic PXE Server and select Stop
Linux: Type the command: /etc/init.d/blpxe stop
Configuring the TFTP server

You configure the TFTP Server so the BMC Server Automation system can
communicate with it to download the bootstrap program needed to initiate the PXE
provisioning process.

(This information applies to the PXE provisioning environment only.)
Before you begin
To see the TFTP configuration tab, you must have, at minimum, the
ProvisionConfig.Read authorization.
To configure the TFTP server
2 Click the TFTP tab.
3 Provide information on the TFTP tab. See The TFTP Server tab on page 1205.
4 Click OK to save the current values.
5 Stop and restart the TFTP server.

Note
You can also configure the TFTP server by editing the tftp.conf file. By default,
this file resides in the following location:
Windows: installDirectory\PXE\br\tftp.conf
UNIX: installDirectory/NSH/br/tftp.conf
The TFTP Server tab

The TFTP tab on the Provisioning Configurations window lets you provide
information, such as an IP address for the TFTP server. The TFTP server downloads
the bootstrap program needed to initiate the provisioning process.
Field definitions
TFTP Settings -- IP Address
The IP address that the TFTP server listens on.
TFTP Settings -- Base Directory
The base directory of the file system used to store operating system bootstrap
programs to be downloaded.

Starting and stopping the TFTP server

You stop and restart the TFTP server to have configuration settings take effect.
To start the TFTP server
Windows:
1 The TFTP server is a Windows service, so choose Start => Settings =>
2 Right-click BladeLogic TFTP Server and select Start.
Linux: Type the command: /etc/init.d/bltftp start
To stop the TFTP server
Windows:
1 The TFTP server is a Windows service, so choose Start => Settings =>
2 Right-click BladeLogic TFTP Server and select Stop.
Linux: Type the command: /etc/init.d/bltftp stop
Configuring boot image files

For provisioning in the PXE environment, you must create boot image files
specifically for use with BMC Server Automation provisioning. You can review and
change configuration settings for each image file type.
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:

blade.img Used only when working with legacy system packages.

gentoo32 Used to provision x86 Linux machines.
gentoo64 Used to provision AMD64 Linux machines.
Skip Linux Pre-Install Used to provision a device with the Red Hat, VMware ESX, or
SUSE operating system when you want to skip the Gentoo pre-
installation image. For information, see Using the Skip Linux
Pre-Install image option on page 1183.
ESXi 4.0 (vmkboot.gz) Used to provision AMD64 machines with ESXi 4.0. For
information, see Provisioning target servers with ESXi 4.0 on
page 1382.
WindowsPE_2_x_Image Used to provision x86 Windows machines.
WindowsPE_2_x_x64_Image Used to provision AMD64 and Windows machines.
WindowsPE_2_x_ISO_Image Used to provision x86 Windows machines from removable or
CD-ROM media connected to the machine. For information,
see Provisioning Windows 2003 or 2008 servers from a local
WindowsPE_2_x_x64_ISO_Image Used to provision AMD64 and Windows machines from
removable or CD-ROM media connected to the machine. For
information, see Provisioning Windows 2003 or 2008 servers
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.
In addition, to provision a device that requires a custom image file containing

specialized network drivers, you can register the custom image file. After you
register the custom image file, you can assign it to the specific device you want to
provision.
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.
DOS image: tftproot/X86PC/pxelinux

To configure a boot image file:
2 Click the Image Files tab.
3 Add or edit the information for the image type. For information, see The Image
Files tab on page 1208.
4 Click OK to save the current values.
The Image Files tab

The Image Files tab lets you view and change configuration settings for each image
file type or register a custom image file.
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:
WinPE 2.0 and above image type on page 1208
WinPE 1.6 image type on page 1209
Linux image type on page 1210
DOS image type on page 1211
WinPE 2.x ISO image type on page 1212
ESXi 4.0 image type on page 1211
When you finish adding or image file types, click OK on the Image Files tab.
WinPE 2.0 and above image type

The Add/Edit Image dialog box lets you define or edit the configuration settings of a
WinPE 2.0 or later 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
(Optional) Description of the boot image file.
Image path
The tftproot subdirectory that contains this image file.
For example, if this image file resides in this TFTP directory:
You would set the Image path field to 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.
Set as default 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.
WinPE 1.6 image type
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
Description of the boot image file.
Image path
C:\tftproot\boot
You would set the Image path field to boot.
If this image file resides in this TFTP directory:
C:\tftproot\boot64
You would set the image path field to boot64.
64 bit image
Check this field if this is the default image for your environment.
Linux image type
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
Command line arguments that the kernel requires at boot time.
64 bit image
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
example, when an unknown device PXE boots on your network, the systems
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
The path to the folder containing the vmkboot.gz image file.

For example, the image folder should reside at: /tftproot/X86PC/pxelinux. If

the image folder is named ESX4i, then you would set the Image file field to:
ESX4i/vmkboot.gz
Description
(Optional) Description of the image file
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.
For example: ESX4i/mboot.c32
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:
--- ESX4i/vmk.gz --- ESX4i/sys.vgz --- ESX4i/cim.vgz --- ESX4i/

oem.tgz --- ESX4i/license.tgz ipappend 2
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.
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
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.

Including a Batch Job in a system package
Image file
The name of the image file.
Description
Image path
You would set the Image path field to boot_2_0.
64 bit image
Because auto-discovery is not supported for the WinPE 2.x ISO image, you
cannot set this image as the default.
Including a Batch Job in a system package

You can create a system package that runs a Batch Job.
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.
To include a Batch Job in a system package
1 Create the Batch Job. For information, see Creating a Batch Job on page 803.

Creating a system package
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.
Solaris system packages: Specify a Batch Job in Finish Script/Agent Install

settings.
AIX system packages: Specify a Batch Job in Agent Install/First Boot Script
settings.

To perform an unattended installation of an operating system, you must create a
system package for each server configuration that you want to install.
A system package contains the following types of information:
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.

Before you begin
In the Depot, create one or more folders for your system packages.
To create a system package
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:
System Package Creation General on page 1216
System Package Creation Properties on page 1216
System Package Permissions on page 1217
3 Click Finish. The system package opens in the content editor.
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
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.
System Package Creation General

The General panel lets you provide information that identifies the system package,
including the type of operating system.
Field Definitions
Name
Enter an identifying name for the system package. This name appears in the
Depot.
Description
(Optional) Enter descriptive text for the system package.
Member of
Verify the folder in the Depot under which this system package belongs. To
change the displayed folder name, click Browse.
System Package Type
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.
System Package Creation Properties



inherited.
Property .
System Package Permissions

The Permissions panel is an access control list (ACL) granting roles access this
system package.
Using the Permissions panel, you can add individual permissions to the system
package. You can also set permissions by adding ACL templates.
this object.
you want to add.

ACL template, you can add a group of authorizations to this object.

Defining settings for Windows servers
To add an ACL template to this job, click Use ACL Template in the Access
If you want the contents of the selected ACL templates to replace all entries in the
this option, the contents of the selected ACL templates are appended to any existing

In a system package, you define settings for the Windows server so the provisioning
process can set them during the unattended installation of the Windows operating
system.
In addition to providing installation settings, a system package can also define a

Batch Job that installs software and performs other configurations on the target server.
To define Windows server settings
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.
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:
Pre-install scripts Windows on page 1219
Disk partition Windows on page 1219
Post-disk partition Windows on page 1222
Basic configuration Windows on page 1222
Computer settings Windows 2008 on page 1224
Computer settings all Windows operating systems except Windows 2008 on

page 1227
OS components Windows 2008 on page 1233
OS components all Windows operating systems except Windows 2008 on

page 1234

Network Windows on page 1235
Unattend entries Windows 2008 on page 1236
Unattend entries all Windows operating systems except Windows 2008 on

page 1238
Post-install configuration Windows and Windows R2 on page 1239
Local properties Windows on page 1243
3 When you finish defining settings for the system package, click the system
package tab and select File => Save.
Pre-install scripts Windows

You can use the Pre-Install Scripts tab to provide custom DiskPart scripts for disk
cleanup, hardware configuration, disk array configuration, and pre-disk partitioning.
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.
Network-enabled Windows PE scripting Windows

A Windows PE image is used for provisioning servers when you create WinPE-
based Windows system packages. When writing scripts for the Pre-Install Scripts
and Post-disk Partition options, you can use the full functionality of Windows PE
batch scripting. Enter any Windows PE-based command in the text box. When your
script runs as part of the provisioning process, it is network-enabled, meaning you
can map network drives and execute Windows PE commands over those mapped
drives. The following is an example of some custom commands used for disk
cleanup in a Pre-Install Script:
net use z: \\server_name\netboot >> %log%
echo Running Configuration Replication Utility >> %log%
z:\tools\conrep /l z:\dl360\server.hwr /p >> %log%
echo Configuring the Array Controllers... >> %log%
z:\tools\acr /i z:\dl360\server.ary /o /p >> %log%
Disk partition Windows

The Disk Partition tab lets you define partitions for provisioned servers. You can
define partitions using a script or fields in the GUI.

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.
Defining partitions using a script

If you are creating a WinPE-based Windows system package, the script must use
DiskPart syntax.
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.)
Defining partitions using the GUI fields

If you use the GUI-based approach and you define the primary partition and other
partitions, the primary partition (that is, the C drive), is provisioned during the Disk
Partition stage of provisioning.
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 script directly in the input box.
Type the name of a local property that contains the script, enclosing the
property name with double question marks.
Click Select Property to display a drop-down menu of available

properties. Select the property that contains the script from the list. For
information, see Using properties to reference scripts on page 1414.

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 create a new partition, click Add .
To modify an existing partition, select the partition in the Disk Partition

list and click Open .
To save your changes, click OK. The new or changed partition appears
in the Disk Partitions list.
Label
Select a drive letter for the partition.
Primary partition
Check this option if the partition is the primary partition.
Type
The type of file system. Select one of the following:
FAT32An enhanced version of the file allocation table file system.

FAT32 offers compatibility with other operating systems, so if you are
configuring a dual-boot system, you may want to use FAT32. If you are
configuring a dual-boot partition with another Microsoft operating
system, the primary partition must be FAT32. The maximum size you can
specify for a FAT32 partition is 32 GB.
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.
To ensure that the operating system installation completes successfully, the

provisioning process requires the following primary disk partition values:
For Windows 2008 and Windows 2008 R2 operating systems: At least

10000 MB for an x86 system package type and at least 15000 MB for an x64

For all other Windows operating systems: At least 2000 MB.
Fill all unused space on disk
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:).
Post-disk partition Windows

The Post-disk Partition tab lets you specify commands or scripts to execute after disk
partitioning.
On the Post-disk Partition tab, you can do any of the following:
In the text box, enter Windows PE-based commands.
In the text box, type the name of a local property that contains a script, enclosing
the property name with double question marks.
Click Select Property to display a drop-down menu of available properties.

Select the property that contains the script.
This tab also displays a check box for rebooting the server after those commands
execute.
Basic configuration Windows

The Basic Config tab lets you provide local information about a server, such as its
name, workgroup, domain, and user account.

Field Definitions
Computer Name
The unique name that should be assigned to the server. Enter a name or
check Auto-generate computer name.
Auto-generate computer name
Check this option to generate a name automatically using the Windows

algorithm.
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
(Optional) Specifies a different name for this server to display when it

appears in the BMC Server Automation Console.
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.
Windows server domain
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.

Create a computer account in the domain
Check this option to create an account so the computer can be added to a

domain.
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
The user name for the account you are creating.
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.
Computer settings Windows 2008

The Computer Settings tab lets you provide information about users, plug-and-play
drivers, software license keys, and localization of the Windows 2008 or Windows
2008 R2 operating system that you are installing.
Field definitions
Name
The user name.
Organization
Name of the users organization.
PnP driver paths
Specifies the location of plug-and-play (PnP) drivers and mass storage

drivers in your data store.
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
For PnP drivers, you can alternatively enter a semicolon-delimited list of

paths in the field. Each path should be relative to the root of the data store.
This example shows selection of two PnP drivers:

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:
If the license is granted on a per-server basis, select Per server. For

Number of concurrent connections, enter the number of users that can use
a license simultaneously. This number must be set higher than 5.
If the license is granted on a per-seat basis, select Per seat.
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
Select a time zone for the server.
Locale
Select a language option. For example, in the United States, select English
United States.
Selecting drivers Windows 2008

As part of defining computer settings for Windows 2008 or Windows 2008 R2, you
use the Driver Selection windows to specify the location of drivers in the data store.
To select drivers for Windows 2008
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.
4 Use arrow keys to further select folders. Then click OK.
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.

Computer settings all Windows operating systems except

Windows 2008
The Computer Settings tab lets you provide information about users, plug-and-play
drivers, software license keys, and localization for Windows operating systems other
than Windows 2008.
Field definitions
Name
The user name.
Organization
Name of the users organization.
Specify path to $OEM$ directory
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.
PnP driver paths
Specifies the location of plug-and-play (PnP) drivers in your data store. To

enter paths, do one of the following:
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.
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.
Type a semicolon-delimited list of the paths to the directories holding plug-

and-play drivers.
If you specified a path in the Path to $OEM$ directory field, the paths you
enter here must be relative to the $OEM$\$1 directory. If you did not
specify a path in the Path to $OEM$ directory field, the paths you enter
must be relative to the root of the data store.
Mass storage drivers
Specifies the location of mass storage drivers in the data store.
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
the key. Then do one of the following:
If the license is granted on a per-server basis, select Per server. For

Number of concurrent connections, enter the number of users that can use
a license simultaneously. This number must be set higher than 5.
If the license is granted on a per-seat basis, select Per seat.
Time zone
Select a time zone for the server.
Locale
Select a language option. For example, in the United States, select English
United States.

When to use Specify path to $OEM$ directory

To define computer settings in a system package for Windows operating system
other than Windows 2008, you must specify whether your $OEM$ directory resides
directly under the i386 or amd64 directory in the data store.
Note
This information applies to Windows operating systems other than Windows 2008.
To specify the location of Windows 2008 drivers, see Computer settings Windows
2008 on page 1224.
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

Using the driver selection GUI: PnP driver paths

In defining computer settings for a Windows system package, you can use the driver
selection GUI to browse to the data store and select PnP drivers.
Note
For information about specifying the location of Windows 2008 PnP drivers, see
Computer settings Windows 2008 on page 1224.
To select PnP driver paths
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.)
Using the driver selection GUI: mass storage drivers

You use the driver selection GUI to browse to the data store and select mass storage
drivers.
Note
For information about specifying the location of Windows 2008 mass storage drivers,
see Computer settings Windows 2008 on page 1224.
To select 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.)
Error to check in txtsetup.oem

An error of incorrect case in entries in the txtsetup.oem file can cause mass storage
drivers not to be displayed in the driver selection GUI.
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.

For example, consider the following incorrectly formatted txtsetup.oem:
[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
The error here is that in the [Defaults] section, SCSI is in uppercase:
SCSI = 5x6x
However, in the [Files] section, SCSI is in lowercase:
[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].
OS components Windows 2008

The OS Components tab lets you choose individual components to include in the
provisioning of Windows 2008 or Windows 2008 R2 operating systems.
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
Guidelines for specifying Windows 2008 roles:

The Windows 2008 Web Server supports only the Web Services role; system
packages for this server install the role by default.
Hyper-V role:
Only Windows 2008 x64 system package types support the Hyper-V role.
Installation of the Hyper-V role requires multiple reboots. If you specify a

script to install the Hyper-V role, the script controls provisioning; therefore,
you must manually restart the target server each time. However, if under
Select Server Roles/Features you check Hyper-V, the provisioning process
installs the role and restarts the target server.
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.
OS components all Windows operating systems except

Windows 2008
The OS Components tab lets you choose individual components that you want
included in a Windows operating system type other than Windows 2008.
Component options
IIS
To install all IIS components, check IIS. To install a subset of all IIS
components, check individual IIS components.

MSMQ (Message Queuing Service)
Check this option to install tools for creating distributed messaging

applications that can communicate across heterogeneous networks, including
computers that might be offline.
Terminal Services
Check this option to install 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.
If you want Terminal Services to exhibit different behavior, do not install it

using Component Selection. Instead install Terminal Services by adding the
appropriate entries to the Unattended Entries tab. For example:
[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 obtain an IP address

automatically from a DHCP server.
Use the following IP address
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
The static IP address that the network connection should use.
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
The address of the IP router that is used to forward traffic to destinations

outside of the local network.
Obtain DNS server automatically
Specifies that the DHCP server should provide the addresses for DNS servers.
Use the following DNS server address
Specifies that addresses are manually provided. Select this option and then
enter IP addresses for Primary DNS server and Secondary DNS server.
Primary DNS server
The IP address of the primary DNS Server.
Secondary DNS server
The IP address of the secondary DNS Server.
Unattend entries Windows 2008

The Unattend Entries tab lets you modify the contents of the unattend.xml file,
which is a file used in unattended installations of Windows 2008 and Windows 2008
R2.
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.
You can modify the unattend.xml file in two ways:

Add to or replace automatically converted entries in the unattend.xml file. For

example, you might add an operating system component not covered by the
system package tabs or you might replace the entries for the out-of-the-box
display component.
If you use the system package tabs to modify the system package, these additions
and replacements are always added to the automatically converted entries of the
unattend.xml file. In addition, you can edit and delete these additional entries.
Create a custom unattend.xml file by editing it in the Customize Unattend Entries

text box. The System Package tool always uses this file exactly as shown in the
Customized Unattend Entries text box, instead of generating the file from the
System Package fields at deploy time.
Note
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.
To add or replace entries

1 In the Additional Unattend Entries area, click Add a new additional unattend
script .
2 In the Generated Unattend area, expand the nodes and select the component to
change. The component appears in the Selected XML Component area.
3 In the Add/Replace XML Component area, do one of the following:
Type the entry to add or replace using XML conventions.

For special characters such as &, <, >, , or , use escape form, that is: &
< > ' &quote.
Click Select Property to select a property reference to a script.
4 Click Add to selected node or Replace selected node.

The Add operation is not available for a leaf node.
You can change only the values for an existing or already-added component. Note
that you can add a component as the direct child of the node selected in the
Generated Unattend Area only.

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.
To edit an entry from the Additional Unattend Entries list

1 Select the entry in the Additional Unattend Entries list and click Edit .
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.
To create a custom version of unattend.xml

1 In the Customized Unattend Entries area, select Customize the Unattend Entries
file. A message appears, saying that if you choose to customize the file, it will not
be generated from the system package fields at deploy time. The message asks if
you want to customize the file.
2 Click Yes on the message.
3 Modify the unattend.xml file displayed in the Customized Unattend Entries text
box.
Unattend entries all Windows operating systems except

Windows 2008
The Unattend Entries tab lets you modify the contents of the unattend.txt file, which
is a file used in unattended installations of Windows operating system other than
Windows 2008.
The unattend.txt file is used in unattended installations to provide answers to the

prompts that would be provided interactively in a live installation. When you define
settings of system package, your input is automatically converted into entries in the
first edit box of the Unattend Entries tab.
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.

To leave existing unattend.txt entries unchanged and add

entries
To leave the automatically generated entries in the first edit box unchanged and add
entries for configuration elements that are not covered by the system package tabs,
use this procedure.
1 Leave Customize the Unattend Entries file unchecked.
2 Add your new entries in the Additional entries for the unattend.txt file box.
(Make sure to include entry headers, for example [Display].)
To change existing unattend.txt entries

To modify the automatically generated entries in the first edit box and also add
entries, use this procedure.
1 Check Customize the Unattend Entries file.
2 Modify the entries in the first edit box.
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.
Post-install configuration Windows and Windows R2

The Post-Install Configuration panel lets you specify processes to run after the
operating system is installed on the server. For Windows R2 operating systems, you
must provide a post-install script to complete the R2 portion of the installation.
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.

For example: INSTALLDIR="C:\Program Files\RSCD" KEYLOGS=0

MAPUSER=Administrator RSCDPORT=4400
The following table lists the properties:
Property Description Possible values
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.
Selecting this option automatically translates the permissions you have

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.
Run post-install batch job
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.
Force Post-install 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.
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.
IP addressEnter the IP address of the Application Server or click Select

Property to specify a property that contains the value.
PortAccept the default (9831) or enter a different port number.

Post-install script
Enter any commands to include in the runonce.bat file, or click Select

Property to insert a parameter.
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.
Post-install script for Windows R2 installations
Use the following lines to complete the R2 portion of a Windows 2003 R2

installation. The last line, disabling the Windows firewall, is optional.
For Windows 2003 R2:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ServerOOBE
\SecurityOOBE/v DontLaunchSecurityOOBE /t REG_DWORD /d 0 /f
r:\data_store_folder_name\CMPNENTS\r2\setup2 /q /a
netsh.exe firewall set opmode DISABLE
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.
For Windows 2008 R2:
Use the following lines to complete the R2 portion of a Windows 2008 R2

installation. The last line, disabling the Windows firewall, is optional.
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ServerOOBE
\SecurityOOBE/v DontLaunchSecurityOOBE /t REG_DWORD /d 0 /f
netsh.exe advfirewall set domain profile state off

Defining settings for Red Hat Linux servers
Post-install script for Windows 2008 Server Core installations
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
2 In the Post-Install Script field, enter the following line:

SHUTDOWN r t 01
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.
Local properties Windows

The Local Properties tab lets you add properties to an individual system package
and modify its existing properties.
If you are adding a new property, click Add .
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.

In the system package, you specify settings for the provisioning process to use for
unattended installations of a Red Hat Linux operating system.

To define settings for unattended installation of a Red Hat Linux server

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
Pre-install scripts Red Hat Linux on page 1244
Disk partition Red Hat Linux on page 1245
Basic configuration Red Hat Linux on page 1247
Computer settings Red Hat Linux on page 1248
OS components Red Hat Linux on page 1249
Network Red Hat Linux on page 1250
Kickstart entries Red Hat Linux on page 1251
Post-install configuration Red Hat Linux on page 1252
Local properties Red Hat Linux on page 1254
Pre-install scripts Red Hat Linux

Use the Pre-Install Scripts tab in the Red Hat Linux system package to provide
custom scripts for disk cleanup, hardware configuration, disk array configuration,
and pre-disk partitioning.
Here is an example of a pre-install script:
echo "Pre PARTED partitions" >> /root/log.txt

parted /dev/sda print >> /root/log.txt
#Remove all existing partitions
echo "Creating new partition table" >> /root/log.txt
parted /dev/sda mklabel gpt
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.

Network-enabled Gentoo scripting

A Gentoo agent is used for provisioning servers when you create Gentoo-based
Linux system packages. When writing scripts for the Pre-Install Scripts and Post-
Disk Partition options, you can use the full functionality of Gentoo batch scripting.
Enter any Gentoo-based command in the text box. When your script runs as part of
the provisioning process, it is network-enabled, meaning you can map network
drives and execute Gentoo commands over those mapped drives. The following is
an example of some custom commands used for disk cleanup in a Pre-Install Script:
mkdir ~/blprov cd ~/blprov wget http://supwin2k3serv2/pxestore/utility/

someutility chmod 700 ./someutility
Disk partition Red Hat Linux

The Disk Partition tab lets you define partitions for the servers being provisioned.
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:

If you want to reboot after script execution, click Reboot after the script is
executed.
To use the GUI to define a partition, do one of the following:
To modify an existing partition, select the partition in the Disk Partition list and
click Open .
Provide information in the Disk Partition window and click OK.

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
Select one of the following file system types:
ext2Supports standard UNIX file types and allows file names up to 255
characters.
ext3Supports all features of ext2 plus journaling.
reiserSupports all features of ext2 plus journaling.
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
If you are creating a Gentoo-based system package, enter the physical

volume (hda, hdb, hdc, etc.) on which to place the partition.

Basic configuration Red Hat Linux

name and the password needed to access the machine.
Field definitions
Computer name
The unique name that should be assigned to the server.
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
password field.
Kickstart network device or AutoYast device
The name of a Kickstart network device or AutoYast device.
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.
Boot Kernel Parameters
Additional boot time kernel parameters you would like to use for the server.
Some commonly used parameters include:

nofbThis command disables frame buffer support and allows the

installation program to run in text mode. This command may be necessary
for accessibility with some screen reading hardware.
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.
Computer settings Red Hat Linux

The Computer Settings tab lets you provide information about peripheral devices
and localization settings.
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
Do either of the following:
Select a time zone from the drop-down list.
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).
Key Setup (Red Hat Enterprise Linux, versions 5 and 6)
For Installation Number, do one of the following:
Enter the 16-character alpha-numeric key that can be used during the
installation process.


properties. Select the property that contains the installation number.
Leave the Installation Number field blank. If you do not enter an

installation number (subscription number), the provisioning process
installs the core operating system without the packages that require the
subscription number. You can install these packages separately when you
get the number.
OS components Red Hat Linux

The OS Components tab lets you specify individual components to include in the
operating system being provisioned.
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:
@NFS File Server

@Windows File Server
@Anonymous FTP Server
@Web Server
@Emacs
@Utilities
Note
When you script your own OS components, you must include wget, either by itself
or by including a package that contains it.
Required entries for Red Hat Enterprise Linux 6 custom

system package types
If a Red Hat Enterprise Linux 6 (RHEL6) system package references a custom system
package type, you must add the following components on the OS Components panel:
@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.
Network Red Hat Linux

and DNS configuration.
Field definitions

IP address
Subnet mask
Default gateway
DNS server
IP address
Subnet mask
Default gateway


Specifies that you want to manually configure a DNS server. Select this
option and enter an IP address for DNS Server.
DNS server
The IP address of the DNS Server.
Kickstart entries Red Hat Linux

The Kickstart Entries tab lets you modify the contents of the kickstart file, which is a
text file used in unattended installations of Red Hat Linux.
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.
To leave existing Kickstart entries unchanged and add

entries
do the following:
1 Leave Customize the Kickstart file unchecked.
2 Add your new entries in the Additional entries for the kickstart file box.
To change existing Kickstart entries

To modify the automatically generated entries in the first edit box and add entries,
do the following:
1 Check Customize the Kickstart file.

3 Then, still in the first edit box, add your additional entries.
Portion of a Kickstart file for Red Hat Enterprise Linux 6

install
text
timezone --utc Africa/Abidjan
lang fr_FR
key --skip
keyboard us
network --bootproto dhcp --device NET_DEVICE --hostname HOST_NAME
url --url http://DATA_STORE_IP/DATA_STORE.VIRTUAL_DIR/RHEL6
firewall --disabled
zerombr
clearpart --all
bootloader --location=mbr
part / --size 1 --grow --fstype ext4 --ondisk sda
rootpw --iscrypted ROOT_PASSWORD
auth --useshakow --enablemd5
rebooot
%packages
@french-support
...
Post-install configuration Red Hat Linux

The Post-install Configuration tab lets you specify the installation of a BMC Server
Automation RSCD agent on the target server, specify a Batch Job that runs after the
operating system is installed on the server, and enter commands that are included in
the Kickstart file.
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
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.
configure the server. Then, for Path to post-install job, enter the path to the
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.
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.
completion status.

Post-install Script
Commands to add to the post-install section of the Kickstart or AutoYast file,

which runs once after a server reboots for the first time after an unattended
installation of a Red Hat or SUSE operating system.

Defining settings for SUSE Linux servers
Enter commands in the box or click Select Property to insert a

parameter.
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.
Local properties Red Hat Linux


In a system package, you specify settings for the provisioning process to use for
unattended installations of a SUSE Linux operating system.

To define settings for unattended installation of a SUSE Linux server
Pre-install scripts SUSE Linux on page 1255

Disk partition SUSE Linux on page 1256
Basic configuration SUSE Linux on page 1257
Computer settings SUSE Linux on page 1258
OS components SUSE Linux on page 1259
Network SUSE Linux on page 1260
AutoYaST entries SUSE Linux on page 1261
Post-install configuration SUSE Linux on page 1264
Local properties SUSE Linux on page 1265
Pre-install scripts SUSE Linux

Use the Pre-Install Scripts tab in the SUSE Linux system package to provide custom
scripts for disk cleanup, hardware configuration, disk array configuration, and pre-
disk partitioning.
Here is an example of a pre-install script:
echo "Pre PARTED partitions" >> /root/log.txt

#Remove all existing partitions
echo "Creating new partition table" >> /root/log.txt
parted /dev/sda mklabel gpt
To add a pre-install script, click Add , then specify the scripts name, contents,
Network-enabled Gentoo scripting

A Gentoo agent is used for provisioning servers when you create Gentoo-based
Linux system packages. When writing scripts for the Pre-Install Scripts and Post-
Disk Partition options, you can use the full functionality of Gentoo batch scripting.
Enter any Gentoo-based command in the text box. When your script runs as part of
the provisioning process, it is network-enabled, meaning you can map network
drives and execute Gentoo commands over those mapped drives. The following is
an example of some custom commands used for disk cleanup in a Pre-Install Script:

mkdir ~/blprov cd ~/blprov wget http://supwin2k3serv2/pxestore/utility/

someutility chmod 700 ./someutility
Disk partition SUSE Linux

There are two ways to define a partition for Gentoo-based system packagesby
supplying a script or using fields in the GUI:
following:

executed.
To use the GUI to define a partition, do one of the following:
To modify an existing partition, select the partition in the Disk Partition list and
click Open .
Provide information in the Disk Partition window and click OK.
Field definitions
Mount point
Type
characters.

reiserSupports all features of ext2 plus journaling.
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.
operating system.
Disk
If you are creating a Gentoo-based system package, enter the physical

volume (hda, hdb, hdc, etc.) on which to place the partition.
Basic configuration SUSE Linux

Field definitions
Computer name
OM Server Name


Root password
password field.
Kickstart network device or AutoYast device
The name of a Kickstart network device or AutoYast device.
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.
Some commonly used parameters include:
nofbThis command disables frame buffer support and allows the

installation program to run in text mode. This command may be necessary
for accessibility with some screen reading hardware.
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.
Computer settings SUSE Linux


Field definitions
Keyboard
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
Key Setup (Red Hat Enterprise Linux, versions 5 and 6)
For Installation Number, do one of the following:
Enter the 16-character alpha-numeric key that can be used during the
installation process.

properties. Select the property that contains the installation number.
Leave the Installation Number field blank. If you do not enter an

installation number (subscription number), the provisioning process
installs the core operating system without the packages that require the
subscription number. You can install these packages separately when you
get the number.
OS components SUSE Linux

The OS Components tab lets you choose individual components that you want
included in the operating system being provisioned.

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.
Network SUSE Linux

Field definitions

IP address
Subnet mask
Default gateway
DNS server
IP address

Subnet mask
Default gateway

DNS server
AutoYaST entries SUSE Linux

The AutoYaST Entries tab lets you modify the contents of the AutoYaST file, which
is an XML file used in unattended installations of SUSE Linux.
When you define settings of a SUSE system package, an AutoYaST file is

automatically generated at deploy time that incorporates all of the options you
defined for the system package. You do not have to edit the AutoYaST file. However,
the AutoYaST Entries panel gives advanced users the option of manually editing the
AutoYaST file.
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
You can use the panel to edit the custom AutoYaST file for the Provision Job.

Tokens in the AutoYaST file

The AutoYaST file includes tokens that represent information needed to provision a
server. This information is presented in the form of tokens because it is either not
available until the provisioning process of a server actually begins or it is derived
from provisioning configuration settings. For example, a token might represent a
servers MAC address. Or, a token might represent the DNS server specified in the
Network panel of the provisioning wizard. The following table describes all the
possible tokens that can be used in an AutoYaST file.
Token Description
??APP_SERVER_IP?? The IP address of the Application Server, which is set

using the bl-server option when you configure a
Linux-based DHCP server. For more information,
see BMC technical documentation at https://
docs.bmc.com/docs/display/bsa82/Configuring+a
+DHCP+Server+on+Linux.
??MAC_ADDRESS?? The MAC address of the server being provisioned.
??IP_ADDRESS?? The IP address that was specified in the Network
panel of the system package wizard. This value is
overridden during provisioning using the value you
enter in the Network panel of the provisioning wizard.
??SUBNET_MASK?? The subnet mask that was specified in the Network
??DEF_GATEWAY?? The default gateway that was specified in the
Network panel of the system package wizard. This
value is overridden during provisioning using the
value you enter in the Network panel of the
provisioning wizard.
??DNS_SERVER?? The DNS server that was specified in the Network
??HOST_NAME?? The computer name that was specified in the Basic
Config panel of the system package wizard. This
value you enter in the Basic Config panel of the
??ROOT_PASSWORD?? The root password that was specified in the Basic

Token Description
??NET_DEVICE?? The network device that was specified in the Basic

??RSCD_DIR?? The path of the RSCD installer for a system package
type. This path is specified using the System Package
tab of the Provisioning Configurations window (see
Changing the location of installation files on page
1200).
??DATA_STORE_BASE_DIR?? The virtual directory for the data store. You specify
this location when you configure the VIRTUAL_DIR
property in the Data Store system object (see
Configuring the data store on page 1185).
??DATA_STORE_IP?? The IP address that the Application Server resolves
from the server name specified in the LOCATION
property in the Data Store system object (see
Configuring the data store on page 1185).
To edit the AutoYaST file

1 Check Customize the AutoYaST file.
A message warns that the AutoYaST file will be generated using your current
settings in the system package wizard.
2 Edit the XML of the AutoYaST file.

The BMC Server Automation system provides basic editing tools, including cut,
copy, paste, select all, undo, and redo. To access a menu of these tools, click in the
body of the file and right-click.
The text editor utility also provides a search and replace feature. To access it, right-
click in the file and select Find.
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.

Post-install configuration SUSE Linux

The Post-install Configuration tab lets you: specify the installation of a BMC Server
Automation RSCD agent on the target server, define a Batch Job that runs after the
the AutoYast file.
Field definitions
Install RSCD agent
Check this option to install an agent on the target servers. (An agent must be
Automation Console or Network Shell.)
Push ACLs
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.
completion status.

Post-install Script
Commands to add to the post-install section of the Kickstart or AutoYast file,

which runs once after a server reboots for the first time after an unattended
installation of a Red Hat or SUSE operating system.
Enter commands in the box or click Select Property to insert a

parameter.
Commands that you enter into the post-install script are appended to
Local properties SUSE Linux


Defining settings for ESXi 4.1 and 5.0 servers

In the system package, you specify settings for the provisioning process to use for
unattended installations of the ESXi 4.1 and 5.0 operating system.
Before you begin
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 architecture must use 64-bit CPUs.
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.
content editor. Each tab represents a category of settings, as described in the
following sections:
Pre-install script ESXi 4.1 and 5.0 on page 1267
Disk partition ESXi 4.1 and 5.0 on page 1267
Basic configuration ESXi 4.1 and 5.0 on page 1268
Computer settings ESXi 4.1 and 5.0 on page 1270
Network ESXi 4.1 and 5.0 on page 1270
Kickstart entries ESXi 4.1 and 5.0 on page 1271
Post-install configuration ESXi 4.1 and 5.0 on page 1274
Local properties ESXi 4.1 and 5.0 on page 1275
package tab at the top of the content editor and select File => Save.

Pre-install script ESXi 4.1 and 5.0

The Pre-Install Script tab lets you provide custom scripts for disk cleanup, hardware
configuration, disk array configuration, and pre-disk partitioning.
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 the script.
Type the name of a local property that contains a script name, enclosing the

Select the property that contains the script name from the list.
3 For Script Contents, do one of the following:
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.

Select the property that contains the script from the list.
4 (Optional) Select Reboot after the script is executedto reboot the server after the
script commands execute.
Disk partition ESXi 4.1 and 5.0

The Disk Partition tab lets you define partitions on the servers being provisioned.

Field definitions
Auto Partition Disk Selection
To specify where to install the hypervisor and which disks to clear, choose
Use First Disk for InstallationThe generated kickstart command clears

the first local disk and installs the OS on that disk.
Specify Disk for InstallationProvide the name of a specific disk in the

next field. The generated kickstart command clears the named disk and
installs the OS on that disk.
Installation Disk Name
Provide a specific disk name.
Additional Disk Part Script
To add a script to the installation to configure additional partitions, select the

Use Additional Disk Part Script check box. Provide the script in any of the
following ways:

properties. Select the property that contains the script from the list.
Click Browse to navigate to a file that contains the script.
Basic configuration ESXi 4.1 and 5.0

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
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
password field. The password must consist of at least 6 characters and cannot
exceed 64 characters.
Kickstart network device
Provide the MAC address of a Kickstart network device or the network

interface name connected to the device. For MAC address, the colon-
separated format is required. You can use any of the following:
Type vmnic0.
Type the MAC address, using a colon-separated format (for example:

00:22:19:50:5E:AB).

properties. Select the MAC_ADDRESS_CD property for the colon-
separated MAC address.
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.

Computer settings ESXi 4.1 and 5.0

The Computer Settings tab lets you set the keyboard type and the license key.
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
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.
Network ESXi 4.1 and 5.0

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.


IP address
Subnet mask
Default gateway
IP address
Subnet mask
Default gateway

option and enter an IP address for the DNS Server.
DNS server
Kickstart entries ESXi 4.1 and 5.0

The Kickstart Entries tab lets you modify the contents of the Kickstart file. The
Kickstart file is a text file used in unattended installations.
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.

entries
use this procedure.

Kickstart entries example for ESXi 4.1 and 5.0

For ESXi, kickstart file entries have a format and syntax similar to that used for ESX
4.0.
The following are the characteristics of the ESXi kickstart file:
Kickstart entries have key=value entries.

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 value for MAC_ADDRESS_CD must be a colon-separated MAC address.

In addition, the MAC_ADDRESS and DEVICE.MAC_ADDRESS properties
are not supported for the ESXi system package type. Both properties resolve
to a hyphen-separated MAC address, which is not supported by ESXi.
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.
For the clearpart entry:
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.
Kickstart for ESXi does not support the following:
mouse
lang
lang support
text

Example: Part of an ESXi 4.1 kickstart file
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
Post-install configuration ESXi 4.1 and 5.0

The Post-Install Configuration tab for ESXi 4.1 and 5.0 system packages lets you
enter commands for the post-install section of the Kickstart file.

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
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.
Local properties ESXi 4.1 and 5.0


Defining settings for ESX servers

In a system package, you specify settings so the provisioning process can set them
during the unattended installation of the ESX operating system.

To define settings for ESX servers
Pre-install script ESX on page 1276
Disk partition ESX on page 1277
Basic configuration ESX on page 1280
Computer settings ESX on page 1281
Network ESX on page 1282
Kickstart entries ESX on page 1283
Post-install configuration ESX on page 1286
Local properties ESX on page 1287
Pre-install script ESX

The Pre-install Script tab lets you provide custom scripts for disk cleanup, hardware
configuration, disk array configuration, and pre-disk partitioning.

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:

Enter Gentoo Linux commands.

4 (Optional) Select Reboot after the script is executed to reboot the server after the
script commands execute.
Disk partition ESX

The Disk Partition tab lets you define partitions for the servers being provisioned. In
addition, for ESX 4.0 system packages, you can create a storage partition and virtual
disk partitions.
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:


To reboot after script execution, click Reboot after the script is executed.
To define a disk partition using the Disk Partition dialog:
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
.
2 Provide information in the Disk Partition window and click OK.
Field definitions
Mount point
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
characters.
vmfs3 Supports the Virtual Machine File System version 3. VMFS is a

clustered file system that lets virtual machines access shared storage
resources concurrently. Version 3 has a directory structure in the file system.
vmkcoreHolds the core dump file for the VMkernel.
vmfs2Supports the Virtual Machine File System version 2. VMFS is a

clustered file system that lets virtual machines access shared storage

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.
operating system.
Disk
Enter the device name and optionally, parameters related to the device name.
For example:
cciss/c0d0 --asprimary
For ESX 4.0 system packages, note the following:
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 physical partitions for /boot, vmkcore, or vmfs3, for Disk/

Virtual Disk, type an option for a real hard disk drive, such as sda.
To create virtual disk partitions for / and /swap, for Disk/Virtual Disk,
select the virtual disk from the drop-down menu.
See Creating Virtual Disk Partitions on page 1279.
Creating Virtual Disk Partitions

If you created a data store (storage partition) for the vmfs3 file system, you can
create a virtual partition on it. (ESX 4.0 system packages only.)
To create a virtual disk partition
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.
2 In the Virtual Disk Partitions area, do either of the following:

To define a new virtual disk partition, click Add .
To modify an existing virtual partition, select the partition in the Virtual Disk
Partition list and click Edit .
The Virtual Disk Partition window opens.
3 On the Disk Partition panel:
For Virtual Disk, enter a name for the virtual disk.
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.
Basic configuration ESX

Field definitions
Computer name
OM Server Name


Root password
password field.
Kickstart network device
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.
Type the MAC address, using a colon-separated format (for example:

00:22:19:50:5E:AB).

properties. Select the MAC_ADDRESS_CD property for the colon-
separated MAC address.
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.
Computer settings ESX

Field definitions
Keyboard

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
The ESX 4.0 system package type does not include this option.
License key (ESX 4.0 only)
the key. Use the format: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX.
Network ESX
Field definitions

IP address

Subnet mask
Default gateway
IP address
Subnet mask
Default gateway

DNS server
Kickstart entries ESX

The Kickstart Entries tab lets you modify the contents of the Kickstart file, which is a
text file used in unattended installations of ESX.
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
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.

entries
use this procedure.

Kickstart entries example for ESX 4.0

For ESX 4.0, kickstart file entries have a format and syntax different from all other
ESX platforms.
The following are the characteristics of the ESX 4.0 kickstart file:
Kickstart entries have key=value entries instead of space-separated entries.

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 value for MAC_ADDRESS_CD must be a colon-separated MAC address.

In addition, the MAC_ADDRESS and DEVICE.MAC_ADDRESS properties
are not supported for the ESX 4.0 system package type. Both properties
resolve to a hyphen-separated MAC address, which is not supported by ESX
4.0.
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.
Kickstart for ESX 4.0 does not support the following:
mouse
lang
lang support
text
Example: Part of an ESX 4.0 kickstart file
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

part /boot --fstype=ext3 --size=1100 --ondisk=sdb

part Storage1 --fstype=vmfs3 --size=10000 --grow --ondisk=sdb
virtualdisk myconsole --size=8000 --onvmfs=Storage1
part swap --fstype=swap --size=600 --onvirtualdisk=myconsole
part / --fstype=ext3 --size=5120 --grow --onvirtualdisk=myconsole
firewall --allowIncoming --allowOutgoing
timezone --utc Asia/Calcutta
rootpw --iscrypted ROOT_PASSWORD
auth --useshadow --enabled
install url http://??DATA_STORE_IP??/??DATA_STORE_VIRTUAL_DIR??/ISO/ESX4/
ESX4GA
Post-install configuration ESX

The Post-install Configuration tab lets you specify the installation of a BMC Server
Automation RSCD agent on the target server, specify a Batch Job that runs after the
the Kickstart file.
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
Push ACLs


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
Local properties ESX


Defining settings for Citrix XenServers

In a system package, you define settings for an unattended installation of the Citrix
XenServer virtual server platform.
To define settings for unattended installation of Citrix XenServer
Pre-install scripts Citrix XenServer on page 1289
Disk partition Citrix XenServer on page 1289
Basic configuration Citrix XenServer on page 1290
Computer settings Citrix XenServer on page 1291
Network Citrix XenServer on page 1292
Unattend entries Citrix XenServer on page 1293
Post-install configuration Citrix XenServer on page 1295
Local properties Citrix XenServer on page 1295

Pre-install scripts Citrix XenServer

The Pre-Install Scripts tab lets you specify scripts to be executed before the
unattended installation of the Citrix XenServer operating system.
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,
Disk partition Citrix XenServer

The Disk Partition tab lets you specify the disk on the target server on which the
Citrix XenServer is installed.
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:
To supply a script for configuring the disk

1 To supply a script, click Use script for disk partitioning.
Type the name of a local property that contains the script, enclosing the property
Click Select Property .
executed.

To use the GUI to configure the disk

1 To create a new partition, click Add . To modify an existing partition, select the
partition in the Disk Partition list and click Open .
2 In the Disk Specifications dialog, provide information and click OK.
Type
Select the type of disk you want to configure.
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.
To include storage media options supported by Citrix XenServer, supply all

disk partition options in a custom disk partition script. Then specify the
script in the Use script for disk partitioning area. For information about the
commands, see the Citrix XenServer Administrators Guide
Enable Guest (Primary Disk only)
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.
Basic configuration Citrix XenServer

Field definitions
Computer name

OM Server Name

Root password
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.
Computer settings Citrix XenServer

Field definitions
Key map
Select a country from the drop-down list.
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.

License Key Path
(Optional) Specify the path to the Citrix XenServer license key, relative to the
data store. For example: CitrixXen/XenServer-Enterprise-license.xslic
Network Citrix XenServer

The Network tab lets you provide networking information for a Citrix XenServer,
such as its IP and DNS configuration.
Field definitions

IP address
Subnet mask
Default gateway
DNS server
IP address
Subnet mask
Default gateway


DNS server
Unattend entries Citrix XenServer

The Unattend Entries tab lets you modify the contents of the unattend.xml file,
which is a file used in unattended installations of Citrix XenServer.
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.
You can modify the unattend.xml file in two ways:
Add to or replace automatically converted entries in the unattend.xml file. For

example, you might add an operating system component not covered by the
system package tabs or you might replace the entries for the out-of-the-box
display component.
If you use the system package tabs to modify the system package, these additions
and replacements are always added to the automatically converted entries of the
unattend.xml file. In addition, you can edit and delete these additional entries.
Create a custom unattend.xml file by editing it in the Customize Unattend Entries

text box. The System Package tool always uses this file exactly as shown in the
Customized Unattend Entries text box, instead of generating the file from the
System Package fields at deploy time.
Note
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.

To add or replace entries

1 In the Additional Unattend Entries area, click Add a new additional unattend
script .
2 In the Generated Unattend area, expand the nodes and select the component to
change. The component appears in the Selected XML Component area.
3 In the Add/Replace XML Component area, do one of the following:
Type the entry to add or replace using XML conventions.

For special characters such as &, <, >, , or , use escape form, that is: &
< > ' &quote.
Click Select Property to select a property reference to a script.
4 Click Add to selected node or Replace selected node.

The Add operation is not available for a leaf node.
You can change only the values for an existing or already-added component. Note
that you can add a component as the direct child of the node selected in the
Generated Unattend Area only.
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.
To edit an entry from the Additional Unattend Entries list

1 Select the entry in the Additional Unattend Entries list and click Edit .
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.
To create a custom version of unattend.xml

1 In the Customized Unattend Entries area, select Customize the Unattend Entries
file. A message appears, saying that if you choose to customize the file, it will not
be generated from the system package fields at deploy time. The message asks if
you want to customize the file.
2 Click Yes on the message.
3 Modify the unattend.xml file displayed in the Customized Unattend Entries text
box.

Post-install configuration Citrix XenServer

The Post-Install Configuration tab lets you specify processes you would like to run
after the Citrix XenServer operating system is installed on the server.
The Citrix XenServer is managed by Agentless Managed Objects (AMOs). The

provisioning process does not install an RSCD Agent or specify a Batch Job as part of
the post-installation configuration. Therefore these options are disabled.
Field descriptions
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.
Enter commands in the box or click Select Property to insert a parameter.

See Using properties to reference scripts on page 1414.
Local properties Citrix XenServer


Defining settings for Solaris servers

In the system package, you define settings for the provisioning process to use for
unattended installations of the Oracle Solaris operating system.

To define settings for Solaris servers
A tab for the system package appears in the content editor view.
Disk partition Solaris on page 1297
Basic configuration Solaris on page 1299
Computer settings Solaris on page 1300
Network Solaris on page 1301
Package specifications Solaris on page 1303
Additional sysidcfg entries Solaris on page 1303
Add install client script Solaris on page 1304
Rules file script Solaris on page 1305
Begin script Solaris on page 1305
Finish script/agent install Solaris on page 1306
Reboot script Solaris on page 1307
x86 parameters Solaris on page 1308
Preview Solaris on page 1310
Local properties Solaris on page 1310

Disk partition Solaris

The Disk Partition tab lets you define partitions for the provisioned servers. The
information you provide here becomes part of the JumpStart profile file.
There are two ways to define a partitionby supplying a script or using the wizard:
following:

Select the property that contains the script from the list. For information, see
Using properties to reference scripts on page 1414.
To use the wizard, follow this procedure:
1 Select the type of partition to define: Explicit Partition, Default Partition, or

Existing Partition.
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.
Anyplace the file system on any disk.

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.
Existinguse the current size of the existing file system.
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.
Explicit Partitionpartition the file system explicitly, using the format:

start:size
where start is an integer specifying the cylinder where the slice begins, and
size is the number of cylinders for the slice.
5 Under File System Settings (Optional), select one of the following optional
settings:
Swapmake this slice the swap slice.
Overlapdefine this slice as a representation of a disk region.
Unnameddefine this slice as a raw slice without a mount point name.
Ignoretell JumpStart not to use or recognize this slice.
Mount Pointuse this mount point name for the file system, for example /
var.
6 Under Optional Parameters, select one of the following:
Preservepreserve the file system on this slice.

Mount Optionsone or more mount options for the mount point name you
specified in Mount Point.
7 Click Finish. The partition appears in the Disk Partitions list.
Basic configuration Solaris

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

appears in the BMC Server Automation Console. 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.
Root password
password field.
Specify install type
(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.

Computer settings Solaris

The Computer Settings tab lets you provide information about localization settings.
Field definitions
Timezone
Select a time zone from the list.
If the time zone you need is not on the list, check Use parameter or specify
an unlisted timezone.
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.
Use a parameter or specify an unlisted system locale
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.

Type in an encoding scheme or click Select Property to insert a parameter. (If

you created a property for the unlisted encoding scheme(s), you can insert a
parameter that references this property.)
For information about system locales supported in the Solaris environment,

see the Oracle documentation.
Network Solaris
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.
Initialize the Primary interface using DHCP

Use the following settings
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
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

outside of the local network. Enter an address or click Select Property to
insert a parameter that refers to a local property to supply the value for this
field.
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.
Name service type
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.
Name Service Associated Fields
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.
You can specify up to six domain names to search.
Use CSV format (separate domain names with commas).
The total length of this field (including commas) cannot exceed 250 characters.

Name Service Associated Fields
LDAP Domain Name: Name of the group of systems using LDAP.

Profile Name: Name of the LDAP profile server.
Profile Server IP Address: IP address of the LDAP profile server.
Proxy DN: Domain name of the LDAP proxy server.
Proxy Password: Password to access the LDAP proxy server. This password must
not include the following character string:
??
Package specifications Solaris

The Package Specifications tab lets you choose which Meta Cluster you want to use.
A Meta Cluster contains packages that specify what operating system software
components to install on the machine.
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.

Additional sysidcfg entries Solaris

The Additional sysidcfg tab lets you add or modify the keyword/value statements
in the system identification configuration file (sysidcfg).
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.
To modify or add keyword/value statements, enter them in the text box.
Sample keyword/value pair statements for this file include:
security_policy=NONE
timeserver=localhost
terminal=vt100
nfs4_domain=dynamic
Additional profile entries Solaris

The profile file uses keyword/value statements to specify the type of installation,
which packages are to be installed, how disks should be partitioned and so on.
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.
Sample keyword/value pair statements for this file include:
install_type initial_install
system_type standalone
Add install client script Solaris

The Add Install Client Script tab lets you customize the add_install_client command.
A default add_install_client command appears in this panel. If you want to

customize the command, check Customize add_install_client script. Then do one of
the following:
Type your customized script directly in the input box.


To return to the default add_install_client command, clear the Customize

add_install_client script option.
Rules file script Solaris

The Rules File Script tab lets you customize the contents of the rules file. This file
becomes the Jumpstart rules file.
Check Customize rules file and then do one of the following:
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
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.
The rules are included in the Jumpstart rules file.
To return to the default rules file contents, clear the Customize add_install_client
script option.
Begin script Solaris

The Begin Script tab lets you specify a script that JumpStart runs just after the target
device boots from the network.
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.
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.

Click Browse to select the script.
Finish script/agent install Solaris

The Finish Script/Agent Install tab lets you specify processes to run after the
operating system is installed on the server.
Using this tab, you can:
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.
(For a Solaris WAN boot installation, this option is not available.)
Push ACLs

authorizations on all of the Jobs contained in the Batch Job.
Application server for BMI callback IP address
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:

properties. Select the property that contains the script. For information, see
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.
Reboot script Solaris

The Reboot Script tab lets you specify a script that connects to the target device and
forces it to reboot from the network and send a BOOTP request to the JumpStart
server. This starts the actual installation of the operating system.
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.


Select the property that contains the script. For information, see Using properties
to reference scripts on page 1414.
x86 parameters Solaris

The x86 Parameters tab lets you define fdisk partitions and kernel parameters for
provisioning x86 servers.
The fdisk information you provide here becomes part of the JumpStart profile file.
The x86 kernel parameters are passed to add_install_client.
Specify fdisk partition information, as described in FDisk Partitions on page 1308.
Specify kernel parameters, as described in Kernel Parameters on page 1309.
FDisk Partitions
This section lets you create or modify fdisk partitions for provisioning x86 servers.
For FDisk Partitions, do one of the following:
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

Root DiskPlace the partition on the systems root disk.
AllPlace the partition on all the disks.
2 The Type panel lets you specify what type of fdisk partition this is. Select one of
the following options and then click Next.
SolarisA Solaris fdisk partition (SUNIXOS fdisk type).
Dos PrimaryAn alias for primary DOS fdisk partitions.
Integer PartitionAn integer fdisk partition. Specify a value between 1 and

255 inclusive.
Hexadecimal PartitionA hexadecimal fdisk partition. Use format 0xHH

where HH is a hexadecimal number between 01 and FF inclusive.
3 Under Size, select one of the following settings:
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.
4 Click Finish. The partition appears in the FDisk Partitions list.
Kernel Parameters
This section lets you add new or modify existing kernel parameters for x86 servers
being provisioned.
For Kernel Parameters, do one of the following:
To create a new kernel attribute/value pair, click Add .
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.

Defining settings for AIX servers
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.
The Preview panel displays the following files:
sysidcfg file
profile file
rule entry to add to the rules file
add_install_client command options
This panel is display only.
Local properties Solaris


In a system package, you define settings for the AIX server so the provisioning
process can set them during the unattended installation of the operating system.

To define settings for AIX servers

A tab for the system package appears in the content editor view.
system package tab. Each tab represents a category of settings, as described in the
following sections:
Basic configuration AIX on page 1311
Target disk AIX on page 1312
Localization settings AIX on page 1313
Network config AIX on page 1315
NIM scripts on page 1318
Control flow on page 1319
Optional bos_inst attributes on page 1319
Agent install/first boot script AIX on page 1316
Pre-machine definition scripts on page 1320
Pre-bos_inst script on page 1321
Post bos_inst Script on page 1321
Preview AIX on page 1321
Local properties AIX on page 1322
Basic configuration AIX


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

appears in the BMC Server Automation Console. 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.
NIM Machine name
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
password field.
Target disk AIX

The Target Disk tab lets you provide information about the disks in the target
machine where you plan to install the operating system. The information you
provide here is stored in the target_disk_data stanza(s) of the bosinst.data file.
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.
To use the GUI fields, do one of the following:
To create a new entry/stanza, click Add .
To modify an existing entry/stanza, highlight the entry and click Edit .
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.
Localization settings AIX

The Localization Settings tab lets you provide localization information.
Field definitions
BosInst Locale
Select a locale from the list.
If the locale you need is not on the list, check Use parameter or specify an
unlisted timezone.
Use a parameter or specify an unlisted locale for use during bosinst
Check this option if the locale you need is not on the list for BosInst Locale.
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
Select a cultural convention from the list.
If the convention you need is not on the list, check Use parameter or specify
an unlisted locale for the cultural convention.
Use a 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.
For information about the cultural conventions supported in the AIX

environment, consult the AIX documentation.
Messages Catalogs
Select the name of the messages catalogs from the list.
If the name of the messages catalogs is not on the list, check Use parameter or
specify an unlisted locale for the messages catalogs.
Use a 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.
For information about the messages catalogs supported in the AIX

environment, consult the AIX documentation.
Keyboard
Select a keyboard map from the list.
If the keyboard you need is not on the list, check Use parameter or specify an
unlisted locale for the keyboard map.
Use a 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.

In the field, type the name of a keyboard map or click Select Property to
keyboard map.
For information about the keyboards supported in the AIX environment,

consult the AIX documentation.
Network config AIX

The Network Configuration tab lets you provide networking information for a server.
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
(For use with the find_net keyword.) Specify a 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.
Network Adapter Name
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
(Optional) The NIM client IP address to use to restart logical partitions

(LPARs) created in a virtual guest job.
Agent install/first boot script AIX

The Agent Install/First Boot Script tab lets you specify processes you would like to
run after the operating system is installed on the server.
You can use this tab to:
Choose whether you want to install a BMC Server Automation RSCD agent. An
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
Check this option to install an agent on the server being provisioned.

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:
The /tmp partition
The partition on which the agent is to be installed (for example, /opt)
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
To show information about the logical volume, including its volume

group nam, enter:
lslv logicalVolumeName
For information about required space for RSCD agent installation, see BMC
System+requirements.
Push ACLs

the server not only through the BMC Server Automation console but also

Firstboot Script
Specify the contents of the NIM first boot script by doing one of the following:

properties. Select the property that contains the script.
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 define a new script, click Add .
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.
For Script Name, do one of the following:

Select the property that contains the script name.
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.
For Script Contents, do one of the following:
Type the contents of the script.

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.
To modify the default settings, do one of the following:
Type your changes directly into the text box.
Type the name of a local property that contains a setting, enclosing the property

Select the property that contains the setting.
Optional bos_inst attributes

The Optional bos_inst Attributes tab lets you specify additional bos_inst attribute/
value pairs, which are passed on to the nim -o bos_inst operation.
The nim -o bos_inst operation lets you specify attributes to customize the
operating system installation.
The Optional Bos_inst Attributes tab has two sections:
Bosinst attributesLists the attributes specified by the system package type on

which your system package is based.
Other optional attributesLists the bos_inst attributes to add to the nim -o

bos_inst operation. Use this section to further customize the installation by

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 add or edit attribute/value pairs, do one of the following:
To define a new attribute/value pair, click Add .
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.
For Bosinst attribute name, do one of the following:
Type the name of the attribute.
Type the name of a local property that contains an attribute name, enclosing the

Select the property that contains the attribute name from the list.
For Value, do one of the following:
Type the value.
Type the name of a local property that contains a value, enclosing the property
To display a drop-down menu of available properties, click Select Property

. Select the property that contains the value from the list.
Pre-machine definition scripts

The Pre-Machine Definition Script tab lets you specify a script to run on the NIM
master before the targets machine object is defined in NIM. You can leave this tab
empty or specify a script.
All machines to be provisioned must be defined as machine objects in the NIM

environment. From the settings you define in the system package, the system
package wizard creates the machine definition command that defines the machine
object on the NIM master. (You can view this command on the Preview tab.)
However, there might be settings you want to make on the machine before its
machine object is defined in NIM. For such settings, you can specify a script on this
tab.

To specify a script, do one of the following:
Type the script in the text box.
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.
Specify a property that references an existing script. Click Select Property to

display a drop-down menu of available properties. Select the property that
contains the attribute name from the list. For more information, see Using
properties to reference scripts on page 1414.
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.
Post bos_inst Script

The Post bos_inst Script tab lets you specify a script to be executed on the NIM
master after the bosinst operation is executed.
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.
The tab displays the contents of the following files:
bosinst.data file

Defining settings for HP-UX servers
Machine definition command
NIM resource definition
Bosinst command
Local properties AIX


In a system package, you define settings for the HP-UX server so the provisioning
process can set them during the unattended installation of the operating system.

To define settings for HP-UX servers
Basic configuration HP-UX on page 1323

Disk partition HP-UX on page 1324
Computer settings HP-UX on page 1324
Network settings HP-UX on page 1326
Ignite commands/scripts HP-UX on page 1327
Optional Ignite parameters HP-UX on page 1328
Software selection HP-UX on page 1328
Boot script HP-UX on page 1328
Post-install configuration HP-UX on page 1329
Preview HP-UX on page 1330
Local properties HP-UX on page 1331
Basic configuration HP-UX

Field Definitions
Computer Name
A unique name that should be assigned to 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.
OM Server Name
(Optional) You can choose a different name for this server to display when it

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
Type the password used to access the root account.
Confirm password
Type the password again to confirm it.
Disk partition HP-UX

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.
Computer settings HP-UX

The Computer Settings tab lets you provide information about localization settings.
Field definitions
Timezone
Select a time zone from the list.

If the time zone you need is not on the list, check Use parameter or specify
an unlisted timezone.
Use parameter or specify an unlisted timezone
Check this option if the time zone you need is not on the list for Timezone.
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
This directory contains both file names and subdirectory names.
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
Select a keyboard map from the list.
If the keyboard you need is not on the list, check Use parameter or specify an
unlisted locale for the keyboard map.
Use a 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.
In the field, type the name of a keyboard map or click Select Property to
keyboard map.
For information about the keyboards supported in the HP-UX environment,

consult the HP-UX documentation.

Network settings HP-UX

The Network Settings tab lets you provide networking information for a server.
Field definitions

IP address
Subnet mask
Default gateway
IP address
Subnet mask
Default gateway

DNS server

Hardware Address
The MAC address of the server.
Use Network Configuration Script
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.
Ignite commands/scripts HP-UX

Ignite scripts are shell scripts that the Ignite master runs on the client when the base
operating system installation is finished. The Ignite Commands/Scripts tab lets you
define Ignite scripts to customize the target machines operating system before it
reboots for the first time.
To define an Ignite script, do one of the following:
To define a new script, click Add .
To modify an existing script, select the script in the list and click Update or Edit
.
A script dialog box appears.
In the script dialog box:
1 For Script Name, do one of the following:

Type the contents of the script.


3 Click OK.
Optional Ignite parameters HP-UX

The Optional Parameters tab lets you add parameter entries to Ignite configuration
scripts.
On this tab, you can add entries to the following scripts:
Client parameters script
Installation control parameters script
Kernel parameters script
Variables script
To add entries to a script, do one of the following:
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

Select the property that contains the setting from the list.
Software selection HP-UX

The Software selection tab lets you install the default software from the Ignite depot.
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.
Boot script HP-UX

The Boot script tab provides instructions to automatically reboot the target during
provisioning.

To specify a Boot script, type the script into the box, or use a property to reference
the script.
Post-install configuration HP-UX

The Post-Install Configuration tab lets you specify processes you would like to run
after the operating system is installed on the server.
On this tab you can:
Choose to install a BMC Server Automation RSCD agent. An agent must be

Automation Console or Network Shell.
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
Push ACLs


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.
The tab displays the contents of the following files:
Complete configuration script
Software selection script
Other configuration script
Disk partition script
Network configuration script

Folders, access control, and system package sharing: an example
Local properties HP-UX

Folders, access control, and system package

sharing: an example
This is an example of how you can use system package folders and access control to
appropriately share access to a system package at different stages of development.
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.

Importing and managing devices
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.

To provision a device, you must first import, or register, the device in BMC Server
Automation. You can import one device or a list of devices, and you can assign
configuration attributes during the import. You can organize devices in device smart
groups and you can delete devices before or after they are provisioned.
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:
ImportedRegistered with BMC Server Automation, but not yet provisioned.
ProvisionedProvisioned with an operating system and possibly additional post-

installation software.
In a PXE environment, devices are imported in two ways:
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.
There are many administrative advantages to manually importing devices in all

environments. For example, if you know the MAC addresses of devices you plan to
provision, you can perform a significant portion of the provisioning process even
before the physical hardware arrives at your location. You can import a list of MAC
addresses only, which begins the process of bringing these assets under BMC Server
Automation control, or you can import the MAC addresses and one or more
configuration values using properties. This can make the actual provisioning process
more streamlined and efficient.

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.
To manually import devices, use one of these procedures:
Add devices one at a time, as described in Manually adding one device on page
1333.
Import a list of devices, as described in Preparing to import a list of devices on

page 1338 and Importing a list of devices on page 1344.
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.
Manually adding one device

You add a device to the BMC Server Automation Console so that you can provision
it later.
To manually add one device
1 Right-click the Devices folder and select Add Device.
2 Specify information about the device, as described in the following sections:
Add Device on page 1333
Permissions on page 1337
3 Click Finish. The device appears in the Imported folder under Devices in the
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
Optionally provide descriptive text about this device.
(PXE only) Boot Image File
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
Set values for properties for this device.
Different provisioning environments let you edit different default property

values for a device, as shown in the table below.

Provisioning Property Value Required or Optional?

Environment
PXE ARCHITECTURE Set ARCHITECTURE to Required

x86
x64
JumpStart ARCHITECTURE Set ARCHITECTURE to Required

one of the following
using all lowercase letters
as shown:
sun4u
sun4v
x86 JumpStart ARCHITECTURE Set ARCHITECTURE to: Required
i86pc
Use all lowercase letters.

NIM CABLE_TYPE You can set Optional
CABLE_TYPE to one of
the following values:
tp
bnc
dix
N/A
NIM PLATFORM You can set PLATFORM Optional

to one of the following
values, using the drop-
down list:
chrp
rs6k
rspc

Provisioning Property Value Required or Optional?

Environment
NIM NETBOOT_KERNEL You can set Optional

KERNEL_TYPE to one of
the following values,
using the drop-down list:
mp
up
NIM NET_SETTINGS You can set Optional

NET_SETTINGS to one of
the following values,
using the drop-down list:
100 full
100 auto
100 half
1000 full
1000 auto
1000 half
10 full
10 auto
10 half
auto full
auto half
auto auto
Ignite ARCHITECTURE Set ARCHITECTURE to Required

one of the following
values:
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.

this object.
you want to add.


Preparing to import a list of devices

You can import multiple devices at the same time by listing MAC addresses in text
files and importing those files. These MAC address import files can optionally
include property values for the imported devices.
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.
Creating a MAC address file

A MAC address file lets you specify lists of MAC addresses and properties
associated with them for bulk provisioning and configuration.
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.
A MAC address file is a text file that contains:
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.
Provisioning Method Required Properties Additional Notes

PXE MAC, ARCHITECTURE Architecture must be one of the following:
x86
x64
Blank is valid; the import process sets the

architecture to match the selected boot
image.
JumpStart MAC, ARCHITECTURE Architecture must be one of the following:
sun4u
sun4v
i86pc
Ignite MAC, ARCHITECTURE Architecture must be one of the following:
Itanium
PA_RISC

NIM MAC Additional predefined but optional

properties are:
CABLE_TYPE
PLATFORM
NETBOOT_KERNEL
NET_SETTINGS
Examples
The following examples show only the required properties for each provisioning type.
NIM MAC address file

MAC
00-2B-CD-1B-E0-44
00-22-B3-B1-1E-E3
00-02-C3-B2-00-C3
PXE MAC address file

MAC,ARCHITECTURE
00-0B-CD-1B-E0-44,x86
00-C0-9F-4B-9E-1B,x64
JumpStart MAC address file

MAC,ARCHITECTURE
00-3C-CD-2E-E0-36,sun4u
00-4D-6F-9C-3E-4B,sun4v
Ignite MAC address file

MAC,ARCHITECTURE
00-0C-4B-D4-CD-3A,Itanium
00-C0-1B-D5-8B-33,PA-RISC
The following examples show how to include an optional COMPUTER_NAME

property in a MAC address file.

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.)
NIM MAC address file with optional property values

MAC,COMPUTER_NAME
00-2B-CD-1B-E0-44,"Sales1"
00-22-B3-B1-1E-E3,"Sales2"
00-02-C3-B2-00-C3,"Sales3"
PXE MAC address file with optional property values

MAC,ARCHITECTURE,COMPUTER_NAME
00-0B-CD-1B-E0-44,x86,"SalesA"
00-C0-9F-4B-9E-1B,x64,"SalesB"
Assigning configuration values during device import

You can assign configuration values to devices at the time of the import by adding
property values in the MAC address file.
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.
To manually import a list of MAC addresses and assign configuration values
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.
3 Edit a system package to use your newly created local property.
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:
Basic configuration Windows on page 1222
Basic configuration Red Hat Linux on page 1247
Basic configuration SUSE Linux on page 1257
Basic configuration ESX on page 1280
Basic configuration Citrix XenServer on page 1290
Basic configuration Solaris on page 1299
Basic configuration AIX on page 1311
Basic configuration HP-UX on page 1323
5 Import the MAC address file into BMC Server Automation.
For information, see Importing a list of devices on page 1344.
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...
Basic Config COMPUTER_NAME LOCAL_COMPUTER_N On the Basic Config

Computer name AME panel of the system
Set Default value field to: package, fill in the
Computer name field
DEVICE.COMPUTER_N
like this:
AME
??
LOCAL_COMPUTER_N
AME??
Basic Config OM_NAME LOCAL_OM_NAME On the Basic Config

OM Server name Set Default value field to: panel of the system
package, fill in the OM
DEVICE.OM_NAME
server name field like this:
??LOCAL_OM_NAME??
Creating a local property in the system package

You can add a local property to the system package you plan to use to provision
your manually imported devices.
This local property makes use of the COMPUTER_NAME Device property you
created earlier in this process.
In this example, assume you call your local property:
LOCAL_COMPUTER_NAME
To add a local property
1 In the Depot folder, navigate to the system package, right-click and select Open
2 Click the Local Properties tab.
3 Click Add to add a new property. The Add Property dialog box appears.
4 For Name, type:

LOCAL_COMPUTER_NAME
5 For Type, click Simple, then choose String from the drop-down list.
6 For Default value, type:
??DEVICE.COMPUTER_NAME??
This value is made up of the following parts:
The first part is the name of the built-in system package property (DEVICE)
that references the Device class.
Followed by a dot (.)
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??
Importing a list of devices

You import a device to register it with the BMC Server Automation system. You can
import multiple devices at the same time by importing a file that contains a list of
MAC addresses. Optionally, the file can include configuration values for the devices.
Before you begin
1 (Required) Create a MAC address import file. See Preparing to import a list of
devices on page 1338.
To import a list of devices
1 Right-click the Devices folder and select Import. A wizard starts.
2 Specify information about the import file, as described in the following sections:
Import Devices (MAC Addresses) on page 1345
Select File on page 1345

3 Click Finish.
You can view the imported devices in the Imported folder under the Devices folder.
Import Devices (MAC Addresses)

The Import Devices panel lets you create a list of MAC addresses to import.
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.
(Applies to PXE provisioning only) Boot Image File
Select the boot image file to provision on these devices. For information, see
Boot image files and placeholders on page 1159.
MAC address file
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.

Results of bulk import
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:
ARCHITECTURE Architecture Resulting attributes set by the import

property for a device associated with process (for each device)
(set in the MAC address boot image file
import file)
32-bit or 64-bit Matches the Values set as specified.

device value
64-bit 32-bit Values set as specified. (It is valid to

provision a 32-bit boot image over a
64-bit architecture.)
32-bit 64-bit Device architecture set as specified.

Because it is not valid to provision a
64-bit boot image over a 32-bit
architecture, the system sets the boot
image file to the default 32-bit boot
image file. For information about
default boot images, including how
to set them, see Configuring boot
image files on page 1206.
not provided 32-bit or 64-bit Device architecture set to match the

specified boot image file.
Permissions
The Permissions panel lets you associate access control lists (ACLs) and ACL policies
to the devices in the MAC address file.


this object.
you want to add.

Device smart groups

After devices are imported, you can create smart groups to organize them.
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.
In working with device smart groups, you can:
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.
Deleting a device has the following effects:
The device is removed from the Devices folder.
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 detailed message appears that includes:

Monitoring the provisioning status of devices
A list of Jobs that include the device you are trying to delete, if applicable.
A reminder that deleting a device decommissions any associated servers.
A prompt to verify that you want to delete the device.
2 To continue with the deletion, click Yes. Otherwise, click No.

During provisioning, you can monitor device status to see which devices are
provisioned, review device provisioning history, or review all of the devices
provisioned with a system package.
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).
View a devices properties, permissions, and manufacturer settings (see Viewing

device information on page 1350).
Examine device provisioning history (see Viewing device provisioning history on

page 1352).
Examine a system packages provisioning history, to view all of the devices a

system package has provisioned (see Viewing a system packages provisioning
history on page 1352).
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).
Viewing imported devices

Imported devices are registered with BMC Server Automation, but are not yet
provisioned. You can view these imported devices.
In a PXE environment, imported devices include both devices that you add
manually and devices that automatically appear when they boot up.

In a JumpStart, NIM, or Ignite environment, you add all devices manually.
To view imported devices
1 In the Devices folder, open the Imported folder.
Viewing provisioned devices

You can view provisioned devices to see if they completed the provisioning process.
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.
To view provisioned devices
1 In the Devices folder, open the Provisioned folder.
Viewing device information

You can view information about a specific device. Depending on the device, you can
also change information such as its description, architecture, or associated boot
image file.
To view device information
1 In the Devices folder, right-click the name of the device and select Open.
A tab for the device displays the following information:
Information about the device (MAC address, device type, description, boot
image file, and architecture).
The devices settings (PXE devices only).
Setting Description
System Manufacturer The manufacturer of the server, such as Dell or HP.
System Model The model number of the server.
CPU Count The number of CPUs in the server.
CPU Family The generation of the CPU, such as Pentium III.
CPU Speed The speed of the CPU in megahertz.

Setting Description
RAM The amount of random access memory in megabytes.
2 To view the devices properties, permissions, or a record of who has sought

authorization for actions on the device, use the views of the Properties,
Permissions, and Audit Trail tab group:
a Open the Devices folder and select the device.
b To display a view, click its tab in the Properties, Permissions, and Audit Trail
tab group.
Viewing and changing device properties

You can view and change a devices properties in the Properties view.
To view or change device properties
1 Open the Devices folder and select the device.
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.
question mark delimiters (for example, ??MyPARAMETER??) or click Select
Property.
. The value of the property is reset to the value it inherits from a built-in
property class .

Viewing device provisioning history

The device provisioning history shows all system packages that were applied to a
device. It also shows detailed log information for each Provision Job that ran on a
device.
To view a devices provisioning history
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.
The tab shows:
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.
Viewing a system packages provisioning history

You can display provisioning history for a system package. The output lists every
provisioning job that ran using that system package.

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.
To view a system packages provisioning history
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.
Manually classifying devices as provisioned

You can manually reclassify a device from the Imported folder to the Provisioned
folder. A provisioned server boots locally from its operating system.
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.
To manually classify a device as provisioned
1 In the Devices folder, open the Imported folder.
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.
Deleting a device has the following effects:

Creating a Provision Job
The device is removed from the Devices folder.
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 detailed message appears that includes:
A list of Jobs that include the device you are trying to delete, if applicable.
A reminder that deleting a device decommissions any associated servers.
A prompt to verify that you want to delete the device.
2 To continue with the deletion, click Yes. Otherwise, click No.

A Provision Job applies a system package to a server and begins an unattended
installation of the operating system.
Before you begin
Before creating a Provision Job, you must:
Configure an appropriate system package type. The system package type

identifies the specific OS to install (for example, Windows 2003 Enterprise or Red
Hat Enterprise Linux release 6.0). By configuring the system package type, you
identify the path name of the installers, including the installers for the OS and for
associated RSCD agents. For information, see Configuring a system package type
on page 1190.
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.

To create a Provision Job
1 To start the Provision Job wizard, do either of the following:
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.
2 Define the Provision Job, as described in the following sections.
Provision Job General on page 1356
Provision Job System Package Properties on page 1356
Provision Job Devices on page 1357
Provision Job Job Settings (PXE only) on page 1359
Provision Job Server Settings on page 1360
Provision Job Default Notifications on page 1361
Provision Job Schedules on page 1362
Provision Job Properties on page 1364
Provision Job Permissions on page 1364
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.

Provision Job General

The General panel lets you provide information that identifies a Provision Job.
Field definitions
Name
Identifying name.
Description
Save in
Provision Job System Package Properties

The System Package Properties panel lets you select the system package and set
system package properties.
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.
Provision Job Devices

The Devices panel lets you specify the devices, identified by MAC address, to
provision the next time this Job executes. The panel also lets you provide network
information, such as IP addresses and the DNS configuration, for those devices.
Note
You can create and save a Provision Job without specifying any devices. You can
open a saved Provision Job, add or change devices information, and save the
changes. Then execute the Job to provision the new list of devices.
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.
Obtain IP address automatically

Specify IP Manually (for each device)
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
Specifies the subnet mask for the IP addresses in the range.

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

Associated boot image
(PXE devices only) From the Selected Boot Image list, select the boot image
for provisioning the servers.
Skip Linux Pre-Install
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.
(Windows only) Auto-generate Computer Name
Select this option to allow the Windows installer to auto-generate the

computer names. If you select this option, the Computer Name field is ignored.
OM server name
(Optional) Enter a different name to use in the BMC Server Automation

Console for this server. This name must be resolvable to the IP address of the
server.

Available and Selected Devices
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.
In the Available Devices list on the left:
Select one or more devices and click the right arrow, which moves your
selections to the Selected Devices list in the right panel.
Use Control-click or Shift-click to select multiple devices.
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.
When you are finished adding devices, click OK.
Provision Job Job Settings (PXE only)

The Job Settings panel lets you pause a PXE-based provisioning job after each logical
step. These options are useful for troubleshooting.
Note
If you selected Skip Linux Pre-Install on the Devices Selection panel, the options on
this panel are not valid for provisioning Linux, VMWare ESX, or Citrix operating
systems.
Field definitions
Pause and Continue
Tells the provisioning process to wait a specified number of seconds after

each logical step in the provisioning job. Type the number of seconds to wait
under Pause Duration. The pause duration should be between 0 and 30
seconds.
For example, if you specified a Pause Duration of 5 seconds, a provisioning

job might proceed like this:
pre-disk partition -> pause 5 seconds -> disk-partition-> pause 5 seconds ->
post-disk partition... and so on

Prompt user after each step
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.
Stopping and restarting a provisioning job

As part of the debugging process, you can tell BMC Server Automation system to
stop a job to let you debug, then start the job again after the last successfully
completed logical step.
To stop a Provision Job, at the target console, press Ctrl+C.
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.
Provision Job Server Settings

The Server Settings panel lets you apply ACL templates and properties on the server
objects that are added to the BMC Server Automation Console.
Field definitions
Server Properties
Browse to an instance of the PROVSERVER class and select the server

properties whose values you want to apply to all of the devices being
provisioned. The properties that you select must be members of an instance
of the PROVSERVER class. For information, see Provisioning server
properties using the PROVSERVER class on page 1411.
Choose ACL Template
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

granted to roles. Using an ACL template, you can add a group of

authorizations to the server objects.
Provision Job Default Notifications

The Default Notifications panel provides options for defining notifications that are
generated when a Provision Job completes.
Field definitions

Send email to
Send SNMP trap to


Provision Job Schedules

The Provision Job Schedules panel lets you schedule a job to execute immediately or
at a specific time in the future. The interface does not allow you to schedule a
Provision Job for recurring executions. You can also define notifications that are
issued when a job runs.
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.
Schedules
To add a new schedule, click Add New Schedule . To delete an existing

schedule, select it and click Remove Schedule . To modify an existing
schedule, click Edit Schedule .
Use the tabs on the scheduling window to provide the following categories of
information:
Provision Job Scheduling on page 1362
Provision Job Scheduled Job Notification on page 1363
Providing approval information The Approval Information tab lets you

provide required approval information. This tab only appears when your
system is configured to require approval information for this job type.
Provision Job Scheduling

The Schedule tab lets you schedule a specific day and time for the Provision Job to run.
Field definitions
The only scheduling option allowed for Provision Jobs is Once.

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
Select the time zone in which the job should run.
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.
Provision Job Scheduled Job Notification

The Scheduled Job Notifications tab lets you generate emails and SNMP traps when
a scheduled job completes. Any notifications defined here override default job
notifications.
Job Run Notification
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 sysadmin@bmc.com;sysmgr@bmc.com.
After entering email address information, check the statuses that cause an
email to be generated.
Send SNMP trap to
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.


that integrate traps into your own trap collection system. The MIB can be
found at installDirectory/Share/BladeLogic.mib.
Provision Job Properties

The Properties panel lets you edit property values for the Provision Job.
Controlling Job Time-outs

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.

inherited.
Property .
Provision Job Permissions


Selecting devices and executing a Provision Job
this object.
you want to add.



You can select devices to provision and execute the Provision Job.

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.
To be provisioned, a device must be imported into the BMC Server Automation

Console and appear in the Devices folder.
Changing or adding devices in a Provision Job

You can add or delete devices for an existing Provision Job. You can also view and
edit device settings such as Computer Name, OM Server Name, IP address, and so on.
To add or delete devices for a Provision Job
1 Open the Jobs folder, navigate to a Provision Job, right-click the job and select
Open.
2 Click the Devices tab.
3 See Provision Job Devices on page 1357 for information about adding and
deleting devices.
4 Consider whether to change the scheduling information on the Schedules tab.
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.
Executing a Provision Job

You execute an existing Provision Job from the Jobs folder.
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.
What Happens When a Provision Job Executes

When you execute a Provision Job, the provisioning environment determines the
actions the system takes.
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 JumpStart, NIM, and Ignite Environments:

For both bare metal and existing servers, if your system package contains a reboot
script, the server is provisioned automatically. (If your system package does not
contain a reboot script, you must manually force the server to boot from the
network, and 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.
The newly provisioned or re-provisioned server is part of the BMC Server

Automation system.

Managing Provision Jobs

You can take the following actions to view and manage Provision Jobs:
Execute a job. See Executing a Provision Job on page 1366.
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.
Re-provision one or more servers. See Reprovisioning servers on page 1371.
Viewing the results of a Provision Job

After running a Provision Job, you can display results in a tab in the content editor.
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.
To view results of a Provision Job:
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.
3 On the Show Results tab, you can do the following:
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.
Canceling a Provision Job in progress

You can cancel a Provision Job in progress.
Note
You can cancel only one Provision Job at a time.
To set up a Provision Job to cancel automatically after a certain amount of time,

define a time-out period for the job using the JOB_TIMEOUT property.
Permissions required to cancel a Provision Job
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
To cancel a Provision Job
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 .

Viewing the log for a Provision Job

To view the messages generated by a Provision Job run, you can display its log.
To view the log for a job in progress
1 Double-click the job node in the Task in Progress panel.
The job run log appears.
To view the log for a completed job
Show Results.
The hierarchy on the left side of the Results tab lists the job runs.
2 Select a job run, right-click and select Show Log.
The log of events for the job appears.
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.
Exporting the log for a Provision Job

You can export the log generated by a run of a Provision Job so you can import its
contents into spreadsheets and databases.
To export the log of a Provision Job run
Show Results.
The hierarchy on the left side of the Results tab lists the job runs.
2 Select a job run, right-click and select Export Log.
The Export Results dialog box opens.
3 Specify the location where you want to store the exported results.
4 For Object Name, provide a file name.

Reprovisioning servers
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.
You reprovision a server by re-executing the Provision Job associated with the server.
You can reprovision servers in either of two ways:
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
Reprovision from a provisioned device. Use this reprovisioning method to

provision the same devices but with a different system package. See
Reprovisioning from a device on page 1372
Permissions required for reprovisioning servers
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

Reprovisioning from the Provision Job

To execute the same Provision Job on the same devices, with the same system
package as before, you execute the job from the Jobs folder.
To reprovision from the Jobs folder
Execute.
When the Provision Job starts, the provisioning process does the following:
Automatically decommissions the server, if it is part of the BMC Server

Automation environment.
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.
Reprovisioning from a device

You can reprovision servers directly from a device by executing the Provision Job
associated with the device.
You might use this reprovisioning method to provision the same devices using a
different system package.
To reprovision from a device
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:
Automatically decommissions the server, if the server is part of your BMC

Server Automation environment. In some situations this can take a few
moments.

Provisioning multiple servers tips
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.
If you click Re-Provision Later, the device is automatically decommissioned

and appears as a device in the imported state. (It is moved from the
Provisioned folder to the Imported folder.) However, the Provision Job does
not execute automatically.
To execute the Provision Job, open the Imported folder and right-click the
server. Then select Provision from the drop-down menu.
Provisioning multiple servers tips

The Provision Job wizard has several features that automate the process of creating
unique values for Computer Name and OM Server Name.
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.

Provisioning Windows 2003 or 2008 servers from a local data store
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 Windows 2003 or 2008 servers

from a local data store
You can provision Windows 2003 or 2008 servers from a local data store, instead of a
PXE server.
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.
Before you begin
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.
To provision target servers from a local data store:
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
3 Associate the local data store instance with the system package. See Associating
the LocalDataStore instance with the system package on page 1381.

About provisioning from a local data store

A local data store is a data store that resides on CD/DVD media connected to the
target server. Windows 2003 or 2008 operating system installation files reside in the
local data store, instead of the PXE data store elsewhere in the network.
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).
Configuration components required for BMC Server Automation provisioning

(operating system driver files, RSCD agent installers, and bmiwin.exe) can reside:
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).
In the WinPE image file. (PXE boot)
You specify the location of these components using the CONFIG_STORE property.
Creating a WinPE image for booting from local media

You can create a WinPE 2.0 or later image file for booting a target server from a
locally available WinPE image mounted on a virtual or physical CD-ROM drive or
removable media (local boot).
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.
Using the image creation wizard to create a local boot image

You can use the image creation wizard to create the image files for booting from
media connected to the target server (local boot).
To use the image creation wizard to create the image for local boot
1 Select Configuration => Provisioning Image Creation.
2 In the Toolkit Select window, do the following:
1 For the following options, provide information as you normally would in

creating a WinPE 2.0 and later boot image:
Image Toolkit Host
Architecture
Win AIK Directory Path
CreateWinPE Script Directory Path
2 For Image Type, select one or more of the following:
ISO Image: Creates an image in ISO format (bootImageName.iso) for booting

from media connected to the target server. You can burn this ISO image to
CD/DVD or use it directly through iLO (integrated Lights-Out server
management technology), virtual CD-ROM, or a mapped network drive.
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.)
4 In the Configuration Details window, do the following:
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.
This step is optional. If you do not select a file, you can:
Manually copy the 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 serverif

there is no DHCP server present in the provisioning environment.
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.)
c Select Copy to root of ISO/UFD.
d Specify the location of Configuration Components (bmiwin.exe, RSCD agent

installers, and operating system driver files) to be copied.
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.
Using the BMC Server Automation script to create a local

boot image
You can use the CreateWinPE2_x.vbs script to create the image files for booting from
media connected to the target server (local boot).
To use the script to create an image for local boot
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
2 Run the CreateWinPE2_x.vbs script as described in Running the

CreateWinPE2_x.vbs script on page 1174.

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.
Creating an image for booting from the PXE server

You can create a WinPE 2.0 or later image file for booting from the PXE server
during provisioning from a local data store.
To create the image for a PXE boot
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.
On the Configuration Details panel, select Copy to WinPE 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.
In the input file for the script:
Specify all required parameters and other parameters as you normally would
to create a WinPE image.
Specify this parameter: CopyToISO=N
Specify this parameter: CreatePXEFlag=Y
Creating a Windows system package for use with a local data

store
To use a local data store for provisioning Windows machines, you create a system
package that points to the local data store as the location of the operating system
installation files.

To create a system package that points to a local data store
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.
a Select Configuration => Provisioning Configurations.
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.
During image creation, if you selected Copy to root of ISO/UFD or Copy to

WinPE image, specify the name of the leaf directory that you provided for
RSCD Installer Path. (This directory contains the rscd.msi file.) For example, if
the RSCD Installer Path specified during image creation was:
D:\DataStore\RSCD\rscd_76_x86
you would type: rscd_76_x86
2 Create the system package.
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.)
During image creation, if you selected Copy to root of ISO/UFD or Copy to

WinPE image, specify the name of the leaf directory that you provided for OS
Drivers Path. For example, if the OS Drivers Path specified during image
creation was:
D:\DataStore\Drivers
Then for PnP driver paths:
Windows 2008 and 2003 system packages: If D:\DataStore\Drivers contains

PnP drivers WinPE image at:
D:\DataStore\Drivers\Dell
D:\DataStore\Drivers\VmDrivers
Then for PnP driver paths, type: Drivers\Dell;Drivers\VmDrivers
Windows 2003 system packages: If D:\DataStore\Drivers contains PnP

drivers at:
D:\DataStore\Drivers\$OEM$\$1\Dell
D:\DataStore\Drivers\Drivers\$OEM$\$1\VmDrivers
Then you would select Specify path to $OEM$ directory and for the Path to
$OEM$ directory, you would type: Drivers. For PnP driver paths, you
would type: Dell;VmDrivers
Mass Storage Drivers:
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:
a Click the Unattend Entries tab.

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]
"VMware SCSI Controller" = "OEM"
[OEMBootFiles]
vmscsi.sys
vmscsi.inf
vmscsi.cat
txtsetup.oem
8 When you finish defining system package settings, select File => Save.
Associating the LocalDataStore instance with the system

package
The BMC Server Automation installation creates an instance of a local data store. To
provision from the local data store, you must associate that instance with a system
package.
Associating the LocalDataStoreInstance with a system package tells the provisioning

system to search the local media for the operating system installation files required
for provisioning the target servers.
To associate the LocalDataStoreInstance with a system package:
1 Create the Provision Job, as described in Creating a Provision Job on page 1354.
2 Provide information to the Provision Device wizard as you normally would.
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.
5 Select LocalDataStoreInstance and click OK.

Provisioning target servers with ESXi 4.0
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.
The CONFIG_STORE property

The CONFIG_STORE 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.
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.
Media The provisioning process searches all supported removable media

connected to the target server. For example:
The WinPE ISO image on CD/DVD
The media containing the local data store
Any other media, such as a USB flash drive (UFD)
All (The default value) The provisioning process searches both locations in this
order:
1 In the LDS directory inside the WinPE image.
2 On all supported removable media connected to the target server.
To change the default value of CONFIG_STORE, use the Local properties panel of
the Windows system package.

The BMC Server Automation installation provides an ESXi 4.0 boot image that you
can use to perform a stateless (scriptless) installation of ESXi 4.0 on 64-bit devices.

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.
To perform a stateless installation of ESXi 4.0
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:
a In the BMC Server Automation Console, select Configuration =>

Provisioning Configuration. Then click the Image Files tab.
b Select the ESXi 4.0 image type and click Edit .
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

You can perform a statefull installation of ESXi 5.0.
To provision servers with ESXi 5.0
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.
2 Create a folder for ESXi 5.0 on the TFTP server.
For example: tftproot/esxi5.
3 Download and extract the ISO for ESXi 5.0 to the above folder on the TFTP server.
4 In the extracted ISO folder:
a Open the file BOOT.CFG.
b Replace all slashes (/) with spaces.
c Save the file.
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.

Provisioning Solaris servers using a WAN boot installation
7 Configure the boot configuration paths to point to the MBOOT.C32 and

BOOT.CFG files in the extracted ISO folder, under your ESXi 5.0 folder in
tftproot. For example, the tftproot/esxi5 folder you created in step 2.
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.
Provisioning Solaris servers using a WAN boot

installation
You can use the WAN boot installation method to provision the Solaris operating
system over a public network to SPARC target servers.
Before you begin
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:
BOOT_SERVER: The host name or IP address of the boot server.
BOOT_SERVER_DOCUMENT_ROOT_PATH: The path to the document root

directory of the web server on the boot server.
BOOT_SERVER_URL: (Optional) The URL through which the document root

directory can be accessed via HTTP. If you do not specify a value, the system
uses http:// bootServer .
BOOT_SERVER_CGI_BIN_PATH: The path to the cgi-bin directory on the boot

server.
BOOT_SERVER_CGI_BIN_URL: (Optional) The URL through which the cgi-

bin directory on the install server can be accessed via HTTP. If you do not
specify a value, the system uses http:// bootServer /cgi-bin.
INSTALL_SERVER: The host name or IP address of the install server.
INSTALL_SERVER_DOCUMENT_ROOT_PATH: The full path to the

document root directory of the web server on the install server.
INSTALL_SERVER_URL: (Optional) The URL through which the document

root directory can be accessed via HTTP. If you do not specify a value, the
system uses http:// installServer .
INSTALL_SERVER_CGI_BIN_PATH: The path to the cgi-bin directory on the

install server.
INSTALL_SERVER_CGI_BIN_URL: (Optional) The URL through which the cgi-

bin directory on the install server can be accessed via HTTP. If you do not
specify a value, the system uses http:// installServer /cgi-bin.
3 Configure the system package type for the Solaris SPARC WAN Boot:
a Select Configuration => Provisioning Configurations.
b On the System Package Types tab, click Add .
c On the Configurations tab, for Operating System Type, select Solaris. Then
check WAN Boot.

d For Wan Boot Parameters, provide the following information:
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.
4 Create the system package.
5 In the system package, define settings on the Disk Partition, OS Components,

Network, and Post-Install Config tabs as described in Defining settings for Solaris
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.)
Authenticate Client after the installation (automatically selects Authenticate

Server during the installation): Specifies that a trusted certificate is provided
to the client. If you select this option, you must manually extract the server and
client certificates in the trust store and cert store using the p12split command.
(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-

Capturing WIM images for use in provisioning
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.
10 Create a provisioning job, as described in Creating a Provision Job on page 1354.

To provision Microsoft Windows servers using a Windows image (WIM), you first
must capture the image using Microsoft ImageX. This procedure gives the steps of
WIM image capture and provides an example using a Microsoft Windows 2003 WIM
image.
In general, the steps of WIM image capture are:
1 Create a WinPE ISO image and copy it to a CD.
2 Use Microsoft Sysprep to prepare a reference machine for capturing the WIM image.
3 Capture the WIM image with ImageX.
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.
This procedure is not intended to provide comprehensive information about using

the Sysprep and ImageX tools. For information about these tools, see the Microsoft
Technet Library.
Before you begin
Install and configure the provisioning infrastructure. See the topics on setting up
the provisioning system in BMC technical documentation at https://
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.
To capture a WIM image for use in provisioning
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.
b Install additional applications. For example, on a virtual machine, you might

install VMware tools.
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:
"Sysprep Tools and Settings": http://technet.microsoft.com/en-us/library/

cc785213(WS.10).aspx
"Choosing Sysprep Settings": http://technet.microsoft.com/en-us/library/

cc758953(WS.10).aspx
3 To remove any unique information and reseal the operating system, run the
Sysprep tool on the reference machine.
a Copy the Sysprep executable (sysprep.exe) to a directory on the reference

machine. For example: C:\sysprep.
b Change directory to the sysprep directory and run Sysprep. For example, for
Windows 2003, you would enter: sysprep.exe /mini /reseal
The system automatically shuts down.

Note
You may encounter issues with creating the WIM images using Microsoft
Sysprep. For information about these issues, see the Microsoft knowledge base.
4 Capture the WIM image on the reference machine.
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.

Using WIM images to provision Windows servers
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:
net use driveLetter pathToDataStore /user:administratorUser

password
For example: net use k: \\serverA\pxestore /user:Administrator

adminpwd
f Use ImageX to capture the WIM image from the drive. Use the format:
imagex /capture driveToCapture wimImagePathAndName

"wimImageName"
For example, this command creates a Windows 2003 Standard WIM image
(W2K3STDx86.wim) in the WimImages directory in the data store:
imagex /capture C: k:\WimImages\W2K3STDx86.wim "Windows 2003

Standard"
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.
Using WIM images to provision Windows

servers
You can use Windows Image Format (WIM) images in a data store to provision the
Windows 2003, Windows 2008, and Windows 2008 R2 operating systems to target
devices.

Before you begin
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
To use a WIM image in provisioning
1 Configure the WIM system package type:
a Select Configuration => Provisioning Configurations. Then click the System

Package Type tab.
The BMC Server Automation system provides these system package types for
use in provisioning with a WIM image:
WIM Based Windows 2003
WIM Based Windows 2003 x64
WIM Based Windows 2008
WIM Based Windows 2008 x64
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:
The C.wim image is used by default.
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:
The OS Components tab is not included because OS components present in the

WIM image itself are applied on the provisioned server.
On the Disk Partition tab:
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.

Setting up auto-discovery of iDRAC devices
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.
a On the General and Choose Devices panels, provide information as you

normally would for a Windows Provision Job.
b On the System Package Selection panel:
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.
5 Execute the Provision Job.
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.

You can set up BMC Server Automation provisioning to automatically discover
Integrated Dell Remote Access Control (iDRAC) devices when they are plugged into
your network.
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.

Before you begin
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.
3 Enable the iDRAC Provisioning service on the BMC Server Automation

Application Server. See Enabling the iDRAC provisioning service 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.
Configuring the DHCP server for iDRAC auto-discovery

To enable auto-discovery of iDRAC devices by BMC Server Automation , you must
set the iDRAC scope option on the DHCP Server.
Perform this task in addition to configuring the DHCP Server for provisioning. For
display/bsa82/Configuring+the+DHCP+server.
To set iDRAC scope options on a Windows 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.
3 Click Add and provide the following information:
For Display Name, enter LifecycleController.
For ASCII, enter LifecycleController.
4 Click OK and then click Close.

5 Select the default server, right-click and select Set Predefined Options.
6 From Option Class, select LifecycleController.
7 Click Add and provide the following information. Then click OK.
For Name, enter LifecycleController.
For Data type, enter String.
For Code, enter 1.
8 Expand the hierarchy for the default server and then expand the hierarchy for
Scope.
9 Select Scope Options, then right-click and select Configure Options.
10 On the Advanced tab, from Vendor class, select LifecycleController.
11 Under Available Options, check 001 LifecycleController.
12 For String value, enter the provisioning server string, in the following format:
ApplicationServer:port
Where:
Application Server is the Application Server's host name or IP address.
port is the port on which the iDRAC auto-discovery service on the Application
Server listens.
To set iDRAC scope options on a Linux or UNIX DHCP server
1 Open the dchpd.conf file in a text editor.
2 Add the following entry to the end of the file:

option space DELL;
option DELL.provsvr code 1 = string;
class LifecycleController {
match if option vendor-class-identifier = LifecycleController;
vendor-option-space DELL;
option DELL.provsvr ApplicationServer:port;
}
Where:
Application Server is the Application Server's host name or IP address.

port is the port on which the iDRAC auto-discovery service on the Application
Server listens.
Importing Dell certificates into the keystore

For the iDRAC device to use the iDRAC provisioning service, you must import the
dellkeystore and delltruststore certificates into the bladelogic.keystore.
To import the certificates
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
2 Run the DellCertImport script. Enter: DellCertImport InstallDirectory

KeyStorePassword
Where:
installDirectory is the BMC Server Automation installation directory.
KeyStorePassword is the certificate password provided during installation of the

Application Server.
Enabling the iDRAC provisioning service

For an iDRAC device to use the iDRAC provisioning service, you must enable the
service on the BMC Server Automation Application Server.
To enable the iDRAC provisioning service
1 On the Application Server, start the Application Server Administration console

(the blasadmin utility).
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

2 Enable the iDRAC provisioning service. Enter:
set appserver EnableIDRACService true
3 Set the https port on which the iDRAC auto-discovery service listens. (The default
is 4433.) Enter:
set appserver HttpsIDRACPortNumber 4433
Creating the configuration file for the iDRAC provisioning

service
To allow the iDRAC provisioning service to respond to requests from the iDRAC
device, you must add information to the iDRAC provisioning service configuration
file (idrac-config.xml).
The configuration file (idrac-config.xml) resides in this location: installDirectory

\NSH\br\deployments\default\tomcat\provapps
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.
Before you begin
Gather the following information for each iDRAC device:
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.
To set up the configuration file
1 Open the idrac-config.xml file in a text editor.
2 Add an entry for each iDRAC device, using the format:

<IDRACS>
<IDRAC ServiceTag=XXXX>
<username></username>
<password></password>

Provisioning iDRAC devices
</IDRAC>
<IDRAC ServiceTag=YYYY>
<username></username>
<password></password>
</IDRAC>
</IDRACS>

You can provision servers equipped with the Integrated Dell Remote Access
Controller (iDRAC).
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.
Note the following about iDRAC provisioning:
iDRAC devices must be equipped with iDRAC6 Express or later.
The Stage ISO to vFlash option requires iDRAC 6 Enterprise with vFlash and
Firmware 1.3.
Only provisioning of the Windows operating system is supported.
Only a network ISO boot image and booting from vFlash are supported. Booting
from a PXE server is not supported.
Provisioning from a local data store 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, \
To provision iDRAC devices
1 Import the iDRAC devices into the BMC Server Automationsystem.
For information, see Importing an iDRAC device on page 1399.
2 Create a WinPE 2.x ISO image file.
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.
For information, see Downloading an ISO image to vFlash on page 1403.
5 Create a Windows system package.
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.
Importing an iDRAC device

To provision an iDRAC device, you must import the device into the BMC Server
Automation system.

To import an iDRAC device
1 Right-click the Devices folder and select Add iDRAC device.
2 Specify information about the device, as described in the following sections:
Add iDRAC device on page 1400
Select MAC Address on page 1400
Add Device on page 1401
Add iDRAC device

The Add iDRAC device panel lets you specify the connection information for an
iDRAC device.
Field Definitions
iDRAC Host/IP
The host name or IP address of the iDRAC device.
Username
The user name to connect to the device.
Password
The password to connect to the device.
Select MAC Address

The Select MAC Address panel lets you select a MAC address identifier for the
iDRAC device.
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
Optional descriptive text about the device.
Boot image file
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.

this object.
you want to add.


Copying iDRAC drivers to a data store

You can copy drivers from an iDRAC device to a data store so they can be shared for
provisioning other iDRAC devices in the BMC Server Automation system.
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.
Before you begin
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.

To copy iDRAC drivers to a data store
1 In the Devices folder, navigate to the iDRAC device whose drivers you want to
share.
2 Right-click the device and select Copy Drivers to Data Store.
3 Provide the following information:
Select the Operating System specific driver set to share
The operating system drivers to share with other iDRAC devices. Select the
driver set from the drop-down menu.
Select the Datastore instance
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 an ISO image to vFlash

You can download an ISO image file from a data store to the vFlash firmware of an
iDRAC device.
Downloading the ISO image file to vFlash lets you boot the iDRAC device locally
during the provisioning process.
Before you begin
This option requires iDRAC6 Enterprise with vFlash and Firmware 1.3.
To download an ISO image to vFlash
1 From Devices folder, select the device.
2 Right-click and select Stage ISO to vFlash.
3 On the dialog, select the data store where the ISO is stored. Then select the .iso file.

4 Click OK.
The iDRAC panel

The iDRAC panel in the Provision Job lets you select the operating system drivers to
install on the iDRAC device.
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.
Use drivers present on the Dell iDRAC device
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
If you are provisioning an iDRAC device with Windows 2008 x64 or

Windows 2008 R2 x64, do not select this option. If you do, the job does not
complete, due to a limitation with iDRAC.
Selecting this option can add up to 20 minutes to overall provisioning

time. (When BMC Server Automation sends the initialization command to
iDRAC, it can take the iDRAC device up to 20 minutes to extract drivers
and make them available for provisioning.)

Provisioning Citrix XenServer to target servers
Boot to network ISO
Boots the device from the ISO image in the data store. You can specify an ISO
image different from the one on the vFlash.
Boot to iDRAC vFlash ISO
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.)
Provisioning Citrix XenServer to target servers

You can perform an unattended installation of the Citrix XenServer server
virtualization platform to target servers.
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.
To provision the Citrix XenServer
1 Set up the TFTP Server for XenServer provisioning:
a In the tftproot/x86pc/prelinux directory, create a directory for the XenServer

files. For example: tftproot/X86PC/prelinux/XenServer
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.
2 Stock the data store for XenServer provisioning:
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.

Provisioning the Red Hat KVM hypervisor
To install just the base package, specify the path to XenServer/packages.main.
To have the XenServer support Linux VMs: In addition to packages.main, copy

the package.linux directory to the XenServer_5.6.0 directory.
b Copy the License Key file (XenServer-Enterprise-license.xslic) to a location of

your choice in the data store.
3 Configure the data store for Citrix XenServer provisioning.
4 Configure the Citrix XenServer system package type:
a From the BMC Server Automation Console, select Configurations =>

Provisioning Configurations. Then click the System Package Type tab.
b Under Relative Paths for OS Images, click Add .
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.
Provisioning the Red Hat KVM hypervisor

You can install the Red Hat KVM hypervisor when you provision the Red Hat
Enterprise Linux operating system to a target server.
You install the Xen hypervisor by selecting it as an operating system component

when you create a system package for Red Hat Linux.
The following Red Hat operating system versions include support for the KVM
hypervisor:
Red Hat Enterprise Linux version 5.4 and later, x64 architecture.
Red Hat Enterprise Linux 6, x86 and x64 architectures.
Because only one hypervisor can be active at a time, you can install either the Xen
hypervisor or the KVM hypervisor on a server.

Provisioning the Red Hat Xen hypervisor
Before you begin
Set up and configure the data store for Red Hat Linux provisioning.
To install the Red Hat hypervisor
1 Configure the Red Hat system package type.
2 Create a RHL 5 system package and select Red Hat as the system package type.
3 Define the settings for the system package:
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
b On the OS Components tab, in the Virtualization section, select the hypervisor

component:
For a Red Hat Linux 5 system package, select KVM.
For a Red Hat Enterprise Linux 6 system package, select Virtualization.
1354.
Provisioning the Red Hat Xen hypervisor

You can install the Red Hat Xen hypervisor when you provision the Red Hat
Enterprise Linux operating system to a target server.
You install the Xen hypervisor by selecting it as an operating system component

when you create a system package for Red Hat Linux version 5.3 or later. There is no
support for Red Hat Enterprise Linux 6 as a Xen host.
The Xen hypervisor uses the kernel-xen hypervisor.
Because only one hypervisor can be active at a time, you can install either the Xen
hypervisor or the KVM hypervisor on a server.
Before you begin
Set up and configure the data store for Red Hat Linux provisioning.

Provisioning Solaris servers using a Solaris Flash archive file
To install the Red Hat Xen hypervisor
1 Configure the Red Hat system package type.
2 Create a RHL 5 system package and select Red Hat as the system package type.
3 Define the settings for the system package:
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
b On the OS Components tab, in the Virtualization section, select Xen. Then

select other components as you normally would for a Red Hat system package.
1354.
Provisioning Solaris servers using a Solaris

Flash archive file
You can provision Solaris servers from a Solaris Flash archive file.
To provision a Solaris server using a Solaris Flash archive
1 Create the Flash archive image.
On a Solaris master system, use the UNIX flarcreate command, as follows:
flarcreate archiveName path/filename
Where:
archiveName is the name of the Flash archive.
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.

Properties and provisioning
The following example creates a Flash archive named archive-server1-20120125 in /

var/tmp, with a file name of server1-20120125-1659.flar.
server1# flarcreate archive-server1-20120125 /var/tmp/
server1-20120125-1659.flar
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:
a Select Specify Install Type.
b On the Install Type pulldown list, select Flash Install.
c For Archive Location, type the path to the archive file or specify a property
that contains the value.
4 Save the Provision Job.
5 Add devices to the Job, and run the Job.

Provisioning uses three types of system objectsdevices, system packages, and data
store instances. In addition, a provisioned device is represented as a sever object.
Like other system objects in BMC Server Automation, these system objects have
properties.
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.
For information about assigning values to server properties in the provisioning

process, see Provisioning server properties using the PROVSERVER class on page
1411.
Inserting parameters that refer to properties can streamline the provisioning process.
For information about using parameters during provisioning, see:
Streamlining the wizard with parameterized properties: an example on page 1412

Inserting a parameter in a system package field on page 1413
Using properties to reference scripts on page 1414
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.
System package properties

Unlike properties for many other system objects, properties defined for the system
package built-in class in the Property Dictionary cannot be changed. To add
properties, define them in the Local Properties of the system package.
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 an example of how to use parameters to refer to system package properties,

see Streamlining the wizard with parameterized properties: an example on page
1412.
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.

Provisioning server properties using the PROVSERVER class

You can use the PROVSERVER class of properties to assign property values to
servers during the provisioning process. You can use this feature for predefined
server properties that are marked editable and for custom server properties.
The PROVSERVER class is a subclass of the Server class of properties. The

PROVSERVER class has exactly the same set of properties as the Server class.
To use PROVSERVER properties to automate server property assignments, you must

create an instance of the PROVSERVER class and assign values to the properties in
the instance. Then, in a Provision Job, you select the instance you want and the
properties in that instance. When the Provision Job executes, it assigns the value in
the selected PROVSERVER property to the property of the same name in the Server
class, for each of the target servers.
To provision server properties
1 To open the property dictionary, select Configuration > Property Dictionary

View.
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.
For example, create a property named Site.
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.
For example, notice the Site property in the PROVSERVER subclass.
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.
For example, create an instance named Austin_Windows_Servers.
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.
Streamlining the wizard with parameterized properties: an

example
This example shows how set up a field in the provisioning wizard so that it displays
a drop-down menu of valid choices for that field. This frees the provisioning
operator from needing to know the exact syntax required for the field.
To set up a field in the provisioning wizard so that it displays a menu of choices:
Add a local property to the system package.
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:
1 Create your Red Hat system package.

2 On the Local Properties panel, add a local property called ACTIVE_NIC_PORT to

your system package. Make this property a String enumeration that contains the
following name/value pairs:
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.
Inserting a parameter in a system package field

You can insert properties, including parameterized properties, in many fields in
system package definitions.
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.
For an example of how to use a parameterized property reference in a system

package field, see Streamlining the wizard with parameterized properties: an
example on page 1412.

To insert a parameterized reference to a property in a system package field
1 In the field where you want to insert the reference to the property, do either of the
following:

properties. Then click the property you want to insert.
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??.
Using properties to reference scripts

To insert a script in a system package, you can create a local property to reference
the script.
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.
To use a local property to insert a script in a system package
1 Create the local property:
a Click the Local Properties tab.
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.
d Type your script in the 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??
or you could click Select Property and select PARTITION_SOLARIS_8 from

the drop-down menu of available properties. (When you use the Select Property
icon, the double question marks are filled in automatically.)
Data store instance properties

A data store instance has properties that point to the location of a data store, which is
where you store sets of installation files that are used for provisioning operating
systems.
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.
Data store instances and provisioning strategies

You can create data store instances that point to different physical machines on your
network, different directories on a machine, or the same configuration setting in
different ways (for example, host name vs. IP address).
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.
Efficient provisioning over the network

If you are provisioning servers in different LANs, you might improve network and
provisioning efficiency by setting up two instances of the data store, one for each
LAN. For example, consider the following network topology:

The example shows two data store instances:
VLAN1 Data Storepoints to data store 1 on VLAN 1
VLAN2 Data Storepoints to data store 2 on VLAN 2
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.
Data stores for different operating systems

You can create data store instances to store the files for provisioning different
operating systems.
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:
Linux Data Store VLAN1

Windows Data Store VLAN1
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.


25
SCAP compliance analysis
This section describes how to import SCAP benchmarks, create and run SCAP
Compliance Jobs, and access Job results.
About the Security Content Automation

Protocol
BMC Server Automation version 8.2 implements the Security Content Automation
Protocol (SCAP) from the National Institute of Standards and Technology (NIST).
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.
Overview of SCAP features

The SCAP features in BMC Server Automation comply with the Technical
Specification for the Security Content Automation Protocol (SCAP): Version 1.0.
Using features in the BMC Server Automation Console, you import SCAP content
from third-party sources.
The imported content, known collectively as an SCAP Benchmark, is an organized

collection of the following SCAP components: security checklists in Extensible
Configuration Checklist Description Format (XCCDF), configuration assessments in
Open Vulnerability and Assessment Language (OVAL), platform-specific content in
a Common Platform Enumeration dictionary (cpe-dictionary) file, and, optionally, a
patches file.

About the Security Content Automation Protocol
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.
Supported SCAP capabilities

The SCAP protocol defines several security capabilities.
BMC Server Automation version 8.2 supports the following SCAP capabilities:
Authenticated Configuration Scanner
Authenticated Vulnerability and Patch Scanner
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

Red Hat Enterprise Linux 4, 5, and 6
Oracle Solaris 8, 9, and 10
SUSE Linux Enterprise 9, 10, and 11
SCAP content components

This section describes how the SCAP content components are used in BMC Server
Automation.
The XCCDF component

BMC Server Automation supports the Extensible Configuration Checklist
Description Format (XCCDF).
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.
To prepare for SCAP scanning, an administrator assembles an SCAP source data

stream, including XCCDF content, into a folder on a server that is accessible to BMC
Server Automation. Well-formed XCCDF content from any source is acceptable.
Using the BMC Server Automation Console, the administrator navigates to the
XCCDF file and imports all SCAP content for a benchmark in a single import action.
The import process validates all content against appropriate schemas and
schematrons. It captures validation errors in a log file which is accessible from the
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.
The OVAL component

BMC Server Automation supports the Open Vulnerability and Assessment
Language (OVAL).

OVAL is an SCAP XML language for representing system configuration information,

assessing machine state, and reporting assessment results. BMC Server Automation
version 8.2 supports schemas for OVAL version 5.9 and earlier.
A proprietary OVAL interpreter based on the open-source OVAL Definition

Interpreter (ovaldi) processes the OVAL tests. The OVAL interpreter is bundled with
the RSCD agent, a BMC Software component installed on every server managed by
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
To initiate an SCAP scan, administrators create an SCAP Compliance Job. On each

target server selected in the job, an OVAL interpreter performs the vulnerability
processing and creates an OVAL results file that is compliant with the OVAL results
schema.
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.
The CPE component

BMC Server Automation supports the Common Platform Enumeration (CPE).
CPE is an SCAP nomenclature and dictionary of hardware, operating systems, and

applications. The SCAP source data stream that BMC Server Automation uses for
SCAP compliance scans must include CPE content. In the SCAP result data stream
produced by BMC Server Automation, when a rule applies to a specific hardware,
operating system, or application, those objects are identified using CPE nomenclature.
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

report shows the entire cpe string; for example: cpe:/

a:microsoft:msn_messenger_service:6.2.
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.
The CCE component

BMC Server Automation supports the SCAP Common Configuration Enumeration
(CCE).
CCE is an SCAP nomenclature and dictionary of software security configurations.

The SCAP source data stream that BMC Server Automation uses for SCAP
compliance scans should include CCE content. The XCCDF result data stream
includes CCE IDs.
BMC Server Automation provides drill-down features for researching rule

noncompliance on each target server. To implement those features, 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 expand the results for a specific target server, find failed
rules, and click a rule to see details about it, including a list of CCE IDs associated
with the rule. Using the CCE IDs, the user can research commonly accepted
configurations that pass the rule. The CCE IDs in the report are links to http://
cce.mitre.org, where users can obtain the most recent CCE lists.
The CVE component

BMC Server Automation supports the SCAP Common Vulnerabilities and Exposures
(CVE) enumeration.
CVE is an SCAP nomenclature and dictionary of security-related software flaws and

vulnerabilities. The SCAP source data stream that BMC Server Automation uses for
SCAP compliance scans should include CVE IDs. The SCAP result data stream
includes CVE IDs.
BMC Server Automation provides drill-down features for researching vulnerabilities

associated with each rule, on each target server. To implement those features, 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 specific Benchmark rule to view details
about the rule, including a list of CVE IDs associated with the rule. Each listed CVE
ID is an active link to the specific web page about that CVE ID on http://
cve.mitre.org. The web pages display the CVE description and links to technical
references.

Setting up the SCAP environment
The CVSS component

BMC Server Automation displays the Common Vulnerability Scoring System (CVSS)
impact-metric value associated with a rule in the exported results file.
CVSS is an SCAP specification that describes the characteristics and impacts of IT

vulnerabilities. The SCAP source data stream that BMC Server Automation uses for
SCAP compliance scans can optionally include impact-metric values for rules. If a
rule in the imported benchmark includes an impact-metric value, that value is
included in the SCAP result data stream.
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.
SCAP Benchmarks and profiles

An SCAP Benchmark is a collection of SCAP content organized in XCCDF format.
An SCAP Benchmark can optionally include profiles.
An SCAP Benchmark is an SCAP source data stream, also known as an XCCDF

expressed data stream. The XCCDF file contains references to other files, such as the
OVAL definitions and patches. All of these files comprise the SCAP Benchmark.
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.

To use SCAP features, you must obtain or prepare benchmark content, install the
latest RSCD versions on your target servers, and grant appropriate permissions to
user roles.

Obtaining SCAP benchmark content

SCAP benchmark content is a set of XML files that defines checklists and rules for
SCAP compliance scanning.
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.
Benchmark content typically includes the following XML files:
XCCDF file (xxx-xccdf.xml)
Generic OVAL file (xxx-oval.xml)
Platform-specific OVAL file (xxx-oval-cpe.xml)
(Optional) Patches file (xxx-patches.xml)
Source-specific platform dictionary (xxx-cpe-dictionary.xml)
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.
To prepare SCAP benchmark content
1 Download benchmark files from a website or other source to a system that is a

BMC Server Automation managed server. Alternatively, you can create custom
benchmark files and place them on a managed server.
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.

Installing the RSCD agent version 8.2

All target servers that you want to include in an SCAP Compliance Job must be
running an RSCD agent version 8.2.
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.
To install the RSCD agent and OVAL interpreter
1 See one of the following documents:
See BMC technical documentation at https://docs.bmc.com/docs/display/

bsa82/Installing for RSCD agent installation information.
See the BMC technical documentation at https://docs.bmc.com/docs/display/

bsa82/Upgrading for RSCD agent upgrade information.
The OVAL interpreter is bundled with the RSCD agent. No special actions are
required to install the OVAL interpreter.
Establishing role-based permissions for SCAP

To import SCAP content, create and run SCAP Compliance Jobs, and view results,
administrators must be assigned a role that includes the necessary permissions.
To facilitate division of responsibilities, you can assign all required permissions to

one role or divide them between several roles. See Access management on page
165 for more details.

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.
The following permissions control SCAP activities:
Define permissions for Controls the ability to
ScapContentFile.* Import SCAP benchmarks and access the CPE and

OVAL files after import.
XccdfBenchmark.* Access the XccdfBenchmark file after import. (This
permission set is a subset of ScapContentFile.*
permissions.)
Note: The permission set for XccdfBenchmark should
be equal to OR a subset of the SCAPContentFile
permission set.
SCAPComplianceJob. * Create, Edit, Modify Targets, Modify Schedules,

Jobfolder.* Modify Properties, Execute Job permissions for SCAP
Compliance Jobs.
Server.* Create SCAP Jobs against servers.
ServerGroup.*
DepotFolder.* Import objects into the Depot and access objects after
DepotGroup.* import.
Sample Permission Sets

A role with the following permissions has full SCAP abilities:
BatchJob.*
DepotFolder.*
DepotGroup.*
ExecutionTask.*
JobFolder.*
JobGroup.*
SCAPComplianceJob.*
SCAPContentFile.*
Server.*
ServerGroup.*
XCCDFBenchmark.*
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

Importing SCAP content
A role with the following permissions can create SCAP Compliance Jobs:
DepotFolder.Read
DepotGroup.Read
XccdfBenchmark.*
SCAPContentFile.*
Server.*
ServerGroup.*
JobFolder.*
ScapComplianceJob.*

To create an SCAP Benchmark object, you import SCAP content into the BMC Server
Automation Console.
Before you begin
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.
To import content for an SCAP benchmark
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:
New XCCDF Benchmark General on page 1428
New XCCDF Benchmark Permissions on page 1429
3 Click Finish.
If the import is successful, the new SCAP benchmark object appears in the BMC
New XCCDF Benchmark General

The General panel lets you select the XCCDF file that defines the new SCAP benchmark.

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.
New XCCDF Benchmark Permissions

this object.
you want to add.



Viewing SCAP schema errors

You can view schema errors from SCAP validation in the BMC Server Automation
Application Server log.
To view SCAP benchmark validation errors
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.
2 In the Content panel, expand the File System node.

Creating an SCAP Compliance Job
3 Navigate to the Application Server installation directory, expand the br subfolder,

and locate the appserver.log file.
For example, using the default installation directory, the file path is:
<C:\Program Files\BMC Software\BladeLogic\br\appserver.log
4 Double-click appserver.log.
Viewing an imported SCAP benchmark

You can view summary level information about an imported benchmark in the BMC
To view summary information about a benchmark
1 In the Depot, right-click the benchmark name and select Open.
The XCCDF tab opens in the Content panel showing summary information about
the benchmark. All information comes from elements in the imported XCCDF file.
NameA short phrase that identifies the benchmark.
TitleA more descriptive longer name.
DescriptionThe purpose of the benchmark.
PlatformThe CPE identifier that describes the operating system platform for
which this benchmark is intended.
VersionThe benchmark version, as identified in the version tag in the XCCDF

file.
Profile identifiers and descriptionsThe profile identifier and description.

These values are obtained from the XCCDF file.

An SCAP Compliance Job selects an imported SCAP Benchmark, a profile, and
target servers.
Before you begin

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.
To create an SCAP Compliance Job
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.
Use the File menu.
2 Complete the panels in the SCAP Compliance Job wizard using the following
instructions:
SCAP Compliance Job General on page 1433
SCAP Compliance Job Profile Selector and Advanced Settings on page

1433
SCAP Compliance Job Targets on page 1435
SCAP Compliance Job Default Notifications on page 1436
SCAP Compliance Job Schedules on page 1437
SCAP Compliance Job Properties on page 1439
SCAP Compliance Job Permissions on page 1439
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.

SCAP Compliance Job General

The General panel lets you provide information that identifies an SCAP Compliance
Job.
Field definitions
Name
Identifying name.
Description
Save in
SCAP Compliance Job Profile Selector and Advanced Settings

The Profile Selector panel lets you select the SCAP benchmark and profile for the
SCAP Compliance Job. The Advanced Settings button on this panel lets you control
run parameters such as logging levels and whether detailed result files are created
and retained on target servers.
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.
Click Browse , select an SCAP benchmark name, and click OK.

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
(Optional) Provides options for changing the OVAL interpreter execution

parameters. The OVAL interpreter is a process that runs on each target server
to perform the compliance evaluations. The default settings are typical for
normal operations.
Run Mode
Controls the type of result files produced by the OVAL interpreter and the
level of cleanup. Modes are:
Default modeRecommended in typical situations.

The OVAL interpreter creates the custom OVAL result files to send to the
Application Server and cleans up all files and folders on the target server.
File retention modeUseful for debugging.

Application Server and retains files on the target server. The retained files
include the customized OVAL result files used by BMC Server
Automation, a customized log file, the benchmark source files, and the
SCAP external variables, list, and log files.
Certification modeRequired during certification and other situations for

which the full OVAL result files are needed.
Application Server and retains all files as described for file retention
mode. In addition, it creates and saves the complete set of SCAP OVAL
results files and sys-char files. These additional files contain the machine
state information and all of the rules and classes from the source benchmark.
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
Ovaldi Log Level
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.
Recursion Level (applies to Windows only)
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.
SCAP Compliance Job Targets

The Targets panel lets you select the servers and server groups to include in this job.
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.
SCAP Compliance Job Default Notifications

notifications.

Send email to
Send SNMP trap to


SCAP Compliance Job Schedules

Scheduling a job
information, see SCAP Compliance Job Scheduling on page 1438.
a scheduled job runs. For more information, see SCAP Compliance Job
SCAP Compliance Job Scheduled Job Notifications

completes.
Send email to
Send SNMP trap to


SCAP Compliance Job Scheduling

To schedule jobs
Mean Time.

SCAP Compliance Job Properties

For example, the DEBUG_MODE_ENABLED property is set to False by default but
you can change it to True.

inherited.
Property .
SCAP Compliance Job Permissions

this object.
you want to add.

Managing SCAP Compliance Jobs


Managing SCAP Compliance Jobs

An SCAP Compliance Job is a saved object in the BMC Server Automation Console.
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.
Modifying an SCAP Compliance Job

You can open an SCAP Compliance Job, change it, and save the changes.
To change an SCAP Compliance Job
1 In the Jobs folder, right-click the SCAP Compliance Job name and select Open.

Viewing SCAP results
The job opens in the Content View.
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.
Running an SCAP Compliance Job

You can run a Job immediately or schedule it to execute in the future.
You must have SCAPContentFile and XccdfBenchmark permissions to create an

SCAP Compliance Job and execute it. For information, see Establishing role-based
permissions for SCAP on page 1426.
To run or rerun an SCAP Compliance Job
1 Use any of the following methods to run a Job:
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.

You can view the XCCDF results of SCAP compliance jobs in the console. The
XCCDF results include appropriate CPE terminology and CVSS metrics. You can

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.
SCAP Rule Result States

A rule can have nine result states.
State Description
Pass The server complies with the condition in the rule.

Fail The server does not comply with the condition in the
rule.
Error The rule could not be evaluated on the server
because the checking engine encountered a system
error and could not complete the test.
Unknown The rule could not be evaluated on the server
because the checking engine encountered some
problem and the result is unknown.
Not applicable The rule could not be applied on the server, possibly
because it is specific to a different version of the
target OS, or because it is a test against a platform
feature that was not installed.
Not checked The rule could not be evaluated on the server by the
checking engine because the rule has a role of
"unchecked" or has no check properties. This status
might also correspond to a status returned by a
checking engine.
Not selected The rule was not selected in the Benchmark.
Informational The rule was checked, but the output from the
checking engine is informational for the auditor or
administrator.
Fixed The rule failed, but was then fixed, possibly by the
checking engine that automatically applied
remediation, or possibly by a human auditor.
Viewing SCAP rule results in the Console

You can view the rule results of an SCAP Compliance Job in the BMC Server
Automation Console. A rule can have nine states, such as Pass, Fail, Error,
Unknown, and so on.

To view SCAP rule results
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.
Bold rules indicate a failed result.

Viewing configuration issues and CCE descriptions

You can research the configuration issues discovered by an SCAP Compliance Job in
the exported results. The results include Common Configuration Enumeration (CCE)
IDs and links to the descriptions.
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
1 Open the exported XCCDF results file.
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.
4 To see more information about a CCE ID, click the ID.
A web page from www.mitre.org opens that includes details about the CCE.
Viewing vulnerability issues, CVE descriptions, and patches

You can research vulnerability issues and patch non-compliance discovered by an
SCAP Compliance Job by using the exported results. The results include patch
numbers and Common Vulnerabilities and Exposures (CVE) IDs associated with rules.
To view software flaws, patches, and associated CVE information
1 Open the exported XCCDF results file.
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.
4 To see more information about a CVE ID, click the ID.
A web page from www.mitre.org opens that includes details about the CVE.
5 To see more information about a patch ID, click the ID.
A web page from the issuing vendor opens with details about the patch.
Viewing CVSS impact metrics

The exported XCCDF result file displays a rule's CVSS impact-metric element, if
applicable.
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.
CVSS scoreIf the source benchmark content includes an <impact-metric>

element for a rule, the exported SCAP results file shows the impact-metric value
in the CVSS score field for that rule. An example impact-metric value is: AV:L
\AC:H<1. For information, see the CVSS specification.
WeightIf the source benchmark content does not include an <impact-metric>

element for a rule, then the results file shows the value from the <weight>
element in the Weight field for that rule.
Viewing OVAL result files

You can export OVAL result and log files from the target servers to a location of
your choice.
To create detailed OVAL result files, an SCAP Compliance Job must be configured to
run in Certification mode or File Retention mode.

To configure a job to run in Certification mode
1 To configure a new job to run in Certification mode, click Advanced Settings on

the SCAP Compliance JobProfile Selector panel, and change the Run mode
setting to Certification mode.
2 To change an existing job to run in Certification mode:
1 Right-click the job in the Jobs folder and select Open.
2 Click the Profile Selector tab.
3 Click Advanced Settings, and change the Run mode setting to Certification mode.
4 On the menu bar, select File > Save.
5 To run the job, right-click the job name and select Execute.
To view OVAL result files
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.
To view OVAL result files on the target server
1 To access OVAL result files in the target server's native file system, navigate to
the following location:

Exporting SCAP results
For example:

\SCAPCompliance_2000001_96_localhost\20000301-2000001_72cf9500-6f4f-4fb0
Exporting SCAP results

You can export the SCAP Compliance Job results to an XCCDF-compliant XML file
and view the XML file in human-readable form in a web browser.
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.
To export an XCCDF results file
1 Right-click the SCAP Compliance Job name in the Jobs folder and select Show
Results.
One or more job run instances appear in the Content View.
2 Expand the job run instance of interest.
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.
4 In the Export SCAP Results dialog box:
a Select the server on which you want to store the exported file.
b Select a drive on that server.
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.
d For the Split files checkbox:
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.
e Type a file name.

Analyzing SCAP results
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
5 To start the export, click Save.
To view XCCDF results in human-readable form
1 Export the XCCDF results as described in the previous procedure.
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.
3 Allow ActiveX requests.
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.

The SCAP analyzer creates a report that helps you identify the underlying reasons
for failed rules in an SCAP Compliance Job for a selected target server.
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.
Information and tips to help system administrators identify ways to manually

remediate the problems.

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.
Running the SCAP analysis and creating the report

You initiate the SCAP analyzer on the results of an SCAP Compliance Job run, for a
selected target server.
To run the SCAP analyzer
1 In the Jobs folder, right-click an SCAP Compliance Job and select Show Results.
2 In the Job results tab, expand the Job Run of interest.
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.
d To start the analyzer process, click Save.
5 In the Tasks in Progress panel, you can:
Watch the progress and status of the analysis.
Cancel the analysis using the Cancel button to the right of the progress bar.
Understanding the SCAP analyzer report

Open the SCAP analyzer report in a web browser.
The SCAP analyzer report contains five sections:
Scoring Shows the total compliance score, copied from the XCCDF results file
Target Details Shows system details about the target server
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
Rule Results Shows the results details for each rule
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.
Color coding indicates rule status:
Rules, definitions, and tests that produced a status of Pass, Not Applicable, Not
Selected, Informational, or Not Checked appear in blue.

SCAP troubleshooting and tips
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.

Use this section to help you resolve issues with SCAP processing.
Correcting SCAP import validation errors

When you import SCAP content, validation errors might appear.
To research and correct validation errors on SCAP imports
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)?
Some common causes for validation errors on SCAP content are:

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.
Researching a failed OVAL interpreter process

The OVAL interpreter running on a target server might fail.
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.
To research a failed OVAL interpreter process
1 Right-click the Job Run and select Show Log.
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:
For example:

\SCAPCompliance_2000001_96_localhost\20000301-2000001_72cf9500-6f4f-4fb0

5 Find error messages at the end of the log.
Researching SCAP Compliance Job error messages

You can view SCAP Compliance Job error messages in the Job run results and job logs.
The following topics provide general information about viewing job run results and
job logs in the BMC Server Automation Console.
Viewing the status of a job on page 638
Managing job logs on page 642
Benchmark not applicable to the target

This error message indicates a mismatch between the selected benchmark and a
selected server.
Each SCAP benchmark is intended for a specific operating system, as described in

the CPE definition associated with the benchmark. If an SCAP Compliance Job
includes a target server with a different OS, the job log reports the mismatch as an
error.
To research names of mismatched targets
1 In the Jobs folder, right-click the SCAP Compliance Job and select Show Results.
2 Right-click the Job run and select Show Log.
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
Too many open files

This messages indicates that the Application Server does not have enough available
file descriptors to proceed.

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.
The number of file descriptors available on a Windows server is fixed.
This account is currently not available

This message indicates problems with the user account on the target server.
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.

A
Windows security settings
This section provides a list of policy names that differ between Windows 2003 or
2008 and Windows 2000.
Windows security settings list

Policy names may differ between Windows 2003 or 2008 and Windows 2000.
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.
Windows 2003 or 2008 Setting Windows 2000 Setting
Accounts: Administrator account status Not available

Passprop.exe is used for this setting on Windows 2000.
Accounts: Guest account status Not available
Accounts: Limit local account use of blank Not available
passwords to console logon only
Accounts: Rename administrator account Rename administrator account
Accounts: Rename guest account Rename guest account
Audit: Audit the access of global system objects Audit the access of global system objects
Audit: Audit the use of Backup and Restore privilege Audit the use of Backup and Restore privilege
Audit: Force audit policy subcategory settings Not available
(Windows Vista or later) to override audit policy
category settings

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
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
Do not allow anonymous enumeration of SAM

accounts and shares
No access without explicit anonymous permissions
However, the system shows the first option as

Disabled and the other two as Enabled.
Network access: Do not allow storage of credentials Not available
or .NET Passports for network authentication

Network access: Let Everyone permissions apply to Not available

anonymous users
Network access: Named Pipes that can be accessed Not available
anonymously
Network access: Remotely accessible registry paths Not available
and sub-paths
Network access: Restrict anonymous access to Not available
Named Pipes and Shares
Network access: Shares that can be accessed Not available
anonymously
Network access: Sharing and security model for local Not available
accounts
Network security: Do not store LAN Manager hash Not available
value on next password change
Network security: Force logoff when logon hours Automatically log off users when logon time expires
expire
Network security: LAN Manager authentication level LAN Manager authentication level
Network security: LDAP client signing requirements Not available
Network security: Minimum session security for Not available
NTLM SSP based (including secure RPC) clients
Network security: Minimum session security for Not available
NTLM SSP based (including secure RPC) servers
Recovery console: Allow automatic administrative Recovery console: Allow automatic administrative
logon logon
Recovery console: Allow floppy copy and access to Recovery console: Allow floppy copy and access to
all drives and all folders all drives and all folders
Shutdown: Allow system to be shut down without Allow system to be shut down without having to log
having to log on on
Shutdown: Clear virtual memory page file Clear virtual memory page file when system shuts
down
System cryptography: Force strong key protection Not available
for user keys stored on the computer
System cryptography: Use FIPS compliant Not available
algorithms for encryption, hashing, and signing
System objects: Default owner for objects created by Not available
members of the Administrators group
System objects: Require case insensitivity for non- Not available
Windows subsystems

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


B
Content format
This appendix describes the XML-based content format that you can use to author
BMC Server Automation content. This content format is aimed primarily at enabling
the creation of rules and policies outside of the BMC Server Automation product so
that they are available for import into BMC Server Automation using the version-
neutral import and export processes.
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.
Content format XML files overview

Content format files are structured hierarchically. At the top level, you can choose to
include root nodes for the following entities:
Entity in content format Description

operators A list of available operators used within rules or signatures.
grammars A list of grammar files used by configuration files and extended objects.

Content format XML files overview
Entity in content format Description

packages Definitions of the BLPackages available for compliance rule remediation. Each
defined package in the content format file corresponds to a single BLPackage in the
types Definitions for the following types of data used in BMC Server Automation (as
accepted, for example, by rules, properties, or configuration objects):
primitivesbuilt-in data types, such as Date or Boolean
enumerations
ranges
lists
property classes
configuration objects
data instances Definitions of a property class instance.

rule library A library of compliance rules or discovery signatures.
No corresponding entity exists in the BMC Server Automation Console.
services A group of definitions for a component template. Each defined service corresponds
to a single component template.
service instances Each service instance corresponds to an instance of a local property set defined for a
component template.
policies A group of compliance rules associated with a component template. Each policy
contains all compliance rules defined for a single component template.
The following example presents a block of XML code at its highest level within a
content format file, with all subordinate nodes collapsed:
<?xml version="1.0" encoding="UTF-8"?>

<content locale="en">
<operators>
<grammars>
<packages>
<types>
<data-instances>
<rule-library>
<services>
<service-instances>
<policies>
</content>

Operators node
Note
Attribute values in the XML file are enclosed in quotation marks. Therefore, to
include a quotation mark within an attribute value, use the &quot 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.
Operators are referenced in the following nodes:
Data types under the types node
Compliance rules in the policies node
Discover signatures in the signature node of a service
Note
The operators node is optional in the content format file.
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

Packages node
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>

Types node
Note the following about elements under the packages node:
The path element specifies the path to the BLPackage within the Depot folders in
The payload-path element specifies the physical location of the BLPackage

payload.
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:
primitivesBuilt-in data types, such as Date or Boolean
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 data type
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.

Types node
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 primitive always begins with the Primitive: prefix.
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>
Enumerations data type
The enumeration data type enforces a choice of values from a closed list. The ID of
an enumeration always begins with the Enumeration: prefix.
The following XML code defines an enumeration data type.
<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>
Ranges data type
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.
The ID of a range always begins with the Range: prefix.

Types node
The following XML code defines supported ranges.
<ranges>
<range name="Integer Range" id="Range:Primitive:Integer Range"
<operators>
</operators>
</range>
<range name="Date Range" id="Range:Primitive:Date Range"
type="Primitive:Date">
<operators>
</operators>
</range>
<range name="Decimal Range" id="Range:Primitive:Decimal Range"
type="Primitive:Decimal">
<operators>
</operators>
</range>
</ranges>
Lists data type
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
The following XML code defines two lists.
<lists>
<list type="Class://SystemObject/Device">
<operators>
<operator-ref rhs-type="Class://SystemObject/Device" id="contains"/>
</operators>
</list>
<list type="Primitive:Encrypted String">
<operators>
<operator-ref rhs-type="Primitive:Encrypted String" id="contains"/>
</operators>
</list>
</lists>
Property-classes data type

Types node
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
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).
The following XML code defines a property class.
<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"/>
</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"
<description>Number of failed logins</description>
<default>
<value>0</value>
</default>
</property>
required="false" used-in-report="false" id="MY_INTEGER_ENUM"
type="enumeration">
<enumeration type="Primitive:Integer">
<value name="intvalue1" id="intvalue1">1</value>
</enumeration>
<default>
<value>1</value>
</default>
</property>
</properties>
</class>
</property-classes>
Configuration-objects data type

Data instances node
The configuration-objects data type defines extended objects, server objects, and
configuration files, as defined in the Configuration Object Dictionary.
The following XML code defines several configuration objects.
<configuration-objects>
<extended-objects>
<extended-object id="Groups">
<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">
<path>??TARGET.WINDIR??/desktop.ini</path>
</configuration-file>
</configuration-files>
</configuration-objects>
Data instances node

Under the data-instances node in the content format file, you can list various
property class instances grouped by property class. The data instances that you list
are available for specification as values or default values of properties elsewhere in
the content format file or as values of properties in rule expressions. For each data
instance, you provide an ID, an optional description, and any unique property
values that are defined for the instance.
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>

Rule library node
</property>
<property id="LOCATION">
</property>
<property id="VIRTUAL_DIR">
</property>
</instance>
</class-ref>
</data-instances>
Rule library node

The rule library is unique to the content format file, and does not correspond to any
existing entity in the BMC Server Automation GUI. Under the rule-library node
in the content format file, you can list various compliance rules or discovery
signatures so that they are available for referencing from the policies node (in the
case of compliance rules) or from the signature node of a service (in the case of a
discovery signature).
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
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.
The following XML code lists allowed operations.
<allowed-operations>
<operation id="Discover"/>
<operation id="Snapshot"/>
<operation id="Audit"/>
<operation id="Deploy"/>
<operation id="Compliance"/>

Services node
<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">
<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">
<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>
required="false" used-in-report="false" id="MY_INTEGER_ENUM"
type="enumeration">

Services node
<enumeration type="Primitive:Integer">
</enumeration>
<default>
<value>1</value>
</default>
</property>
required="false" used-in-report="false" id="TEST_INTEGER"
<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>
<operation id="Discover"/>
<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>
<operation id="Browse"/>
<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.

Service instances node
The following XML code defines a signature.
<signature>
<rule name="Template Signature" service="xml test service">
<expression><![CDATA[??TARGET.OS?? is one of ["AIX", "Linux", "HP-UX",
"Windows"]]]></expression>
</rule>
</signature>
Service instances node

A service instance in the content format file represents an instance of a local property
set for a component template.
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">
<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">
<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
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">

Policies node
<rule-ref id="Rule 1 in library" />

<rule-ref id="Rule 2 in library" />
<description>Description of Referenced Rules rule group</
description>
<notes>Notes for Referenced Rules rule group</notes>
</folder>
</rules>
</policy>
</folder>
</policies>

C
System authorizations
You can grant authorizations to roles for almost every action and object in BMC
Server Automation.
See https://docs.bmc.com/docs/display/bsa82/System+authorizations for a list of

all possible system authorizations.
Appendix C System authorizations 1477

D
Intrinsic properties
This section lists BMC Server Automation intrinsic properties.
Intrinsic properties list

The following table lists intrinsic properties that can be assigned to BMC Server
Automation system objects.
Properties ending in an asterisk were introduced in version 8.0 or later. Properties

that do not end in an asterisk were introduced in version 8.0 or earlier.
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

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
BMC Server Automation Glossary

A
ACL
Access control list. A set of permissions that is defined for every system object. An objects ACL
specifies which roles are granted access to the object and what types of actions those roles can
perform on the object. Using the ACL defined for any server, you can generate an agent ACL.
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 Push Job

A job that converts the permissions defined for a server into entries in an access control list for
that server and then copies the ACL to the agent on that server.
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
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.
agentless managed object (AMO)

A managed object that does not have an RSCD agent installed. An IBM frame is an example of
an AMO.
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
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:
Checks for presence, absence, or number of occurrences of the configuration object (a

cardinality condition on page 1499).
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.

built-in property class

A group of properties that are automatically associated with a type of object in BMC Server
Automation. For example, all properties in the Jobs built-in property class are automatically
associated with all jobs.
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).
certificate authority (CA)
A trusted party issuing digital certificates (especially X.509 public-key certificates).
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
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
Multiple conditions organized in an if-then-else logical sequence within a signature or

compliance rule of a component template.
configuration files
Files used for either of the following:
Storing configuration information for a program or operating system, such as a

Windows .INI file.
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.
custom configuration object

A user-definable object that you can add to the Configuration Object Dictionary. In earlier
releases BMC Server Automation referred to these objects as custom server objects.
custom property class

A hierarchical group of user-defined property classes and sub-classes. To each class and sub-
class you can assign properties. A sub-class inherits all the properties of its parent class. Using
inheritance, you can create complex property structures built from custom classes and sub-
classes. Then, you can create multiple instances of these property structures. For each instance,
individual properties may be set to particular values. You can assign an instance of a custom
property class to a system object using a property class property.
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
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.
discretionary access control (DAC)

A system of granting permissions to perform actions on individual system objects. To
accomplish this you define an access control list (ACL) for every system object created in BMC
Server Automation. The ACL specifies which roles are granted access to the object and what
types of actions those roles can perform on the object
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
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 part time-out

A property assigned to jobs that specifies a maximum period of time for a job part to run before
that job part is automatically canceled.
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
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
The left-hand-side portion of a condition defined in a signature or compliance rule of a

component template, which represents the configuration object or property to be compared
against the value in the right-hand-side (RHS) 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.
local users and groups

Accounts that can be granted permissions on a Windows server. Local users and groups are
represented as server objects in the BMC Server Automation Console.
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.
Network Shell Proxy Server

An Application Server configured as a proxy server that manages authentication and
encryption for all traffic between Network Shell and remote servers.
Network Shell Proxy Service

A service implemented within the BMC Server Automation Application Server that is used for
accessing the functionality of a Network Shell Proxy Server.
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
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

See public key infrastructure (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.
Post-install Configuration wizard

A wizard that consolidates the minimum configuration steps needed to set up an Application
Server. Usually, the Post-install Configuration wizard is invoked after installing the
Application Server.
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 class property

A property that refers to a property class or sub-class. To assign values for a property class
property, you must select an instance of the property class or sub-class.
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
public and private keys
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.
public key cryptography
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.
public key infrastructure (PKI)
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
The right-hand-side portion of a condition defined in a signature or compliance rule of a

component template, with the value against which to compare the configuration object or
property of the left-hand-side (LHS) 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.
role-based access control

A system of granting permissions for certain types of actions to a role and then assigning users
who need those permissions to the role. In this way you can define a set of permissions that
might be used by an entire class of users, such as expert administrators or help desk personnel.
The RBAC Manager folder contains a utility that lets you define roles.
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
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.
secure remote password (SRP)
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
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.
Tasks in Progress view

A view that allows you to view and cancel pending jobs.
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.
Transport Layer Security (TLS)

A protocol providing confidentiality, authentication, and integrity for stream-like connections.
TLS is typically used to secure HTTP connections. TLS is the successor to the Secure Socket
Layer (SSL) protocol. BMC Server Automation uses the TLS protocol for all of its
communication legs.
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
The Microsoft Windows UNC (Universal Naming Convention or Uniform Naming

Convention) specifies a common syntax to describe the location of a network resource, such as
a shared file, directory, or printer.
Glossary 1515
undo
The act of rolling back a deployment to a server.
users and users.local file

BMC Server Automation configuration files that set access permissions for individual users
communicating with a server. Typically, the values specified in the users file are automatically
generated to implement decisions made in RBAC Management. The users.local file overrides
permissions defined in the users file.
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
agent bundle 296 asymmetric encryption

modifying 303 defined 1496, 1497
agent bundle default configuration files 298 Audit Jobs 672, 677, 682, 684, 694, 697, 698, 701, 702, 704,
agent installation scenarios 315 706, 707, 709
Agent Installer Job 303 creating 677
Agent Installer Jobs modifying 694
modifying 315 audit options
AGENT_PLATFORM* 313 for component templates 366
agentless managed objects 716 audit results 672, 694, 697, 698, 701, 702, 704, 706, 707,
agentless objects 259 709
agents 35, 259 exporting 675, 710
installing 260, 261, 265, 269, 272, 273, 287, 296, 303, Audit Trail view 115, 117
313, 316 audit trails
AIX for system authorizations 177, 179
packages 482 managing 173
patches 482 viewing 117
AIX patches audits 672, 677, 682, 684, 694, 697, 698, 701, 702, 704, 706,
deploying directly 1109 707, 709
AIX system package and symbolic links 650
basic configuration 1311 exporting results 675, 710
control flow 1319 of component 382
firstboot script/agent install 1316 of components 382, 383
localization settings 1313 understanding 650
network settings 1315 Authentication Profiles
NIM scripts 1318 setting up 44
optional Bosinst attributes 1319 authorization profiles
Post bos_inst script 1321 creating 168, 180
Pre bos_inst script 1321 modifying 183
Pre machine definition scripts 1320 authorizations 172
target disk 1312 command 177179
All perspective 67 creating policies for managing 189
AMO 259 creating profiles of 180
AMOs 716 effective 168
Application Servers enforcing 172
connecting to BMC Server Automation console managing 168
46 modifying profiles of 183, 195
information about 1002 object-based 166
introduced 37 resource-based 167
reporting information about 1003 role 166
tier 36 setting up 168, 177
Approval Information panel system 177, 179
setting approval type 618 understanding 165
setting change request parameters 617 viewing a summary for an object 236
Using existing Change Ticket option 619 auto-discovery
Approval type settings 311, 737, 788, 799, 810, 847, iDRAC devices 1393
1126 auto-remediation
approvals for Compliance Jobs 442
ITSM 311, 737, 788, 799, 810, 847, 1126 automation principals
architecture creating 169, 195, 200
of BMC Server Automation 36 modifying 200
asset groups 546 autoremediation
in BLPackages 545 for Patching Jobs 1121
assets AutoYaST entries
importing into BLPackages 539 Linux system package 1261

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
BMC Server Automation broken dependencies

administrative tools 977 finding 115
architecture 3638
BLPackages 477
component templates 351 C
components 351
deploying BLPackages 713 canceling
deploying files 773 jobs 621
deploying packages 713 cardinality conditions
deploying software 713 defined 1499
described 31 in compliance rules 389, 396
exporting 118, 120 in signatures 376
folders 101 certificate authority
getting started 43, 51 defined 1499
importing 118, 123 certificates
managing access 165 defined 1499
managing jobs 607 LDAP server 203
managing properties 143 untrusted 50
managing servers 319 viewing or deleting 53
managing the console 83 viewing untrusted 50
overview 35, 39 change tracking 661
snapshots 649 changes
software packages 477 removing 670
starting 46 tracking internal and external 668
Tasks in Progress view 77, 621 using the compare editor 670
viewing dependencies 78, 117 changing the sort order of a column 98
BMC Server Automation Console 101 character encoding
content editor 63 for text files 79, 80
customizing preferences 84 choosing editors 83
editors 64 Citrix XenServer
elements 59 browsing 924
global menu bar 62 creating a Virtual Guest Job 884
global toolbar 62 managing 923, 926
managing 83 provisioning 1405
menus 65 system package for 1291
perspective 62 system package for provisioning 1288
perspectives 64 Classic perspective 67, 68
Quick Access 63 Classic2 perspective 67
quick tour 64 clearing filters 74
tab group 63 client tier 36
title bar description 61 of BMC Server Automation 36
toolbars 65 columns
view 63 changing sort order 98
views 64 customizing 95
BMC Support 33 formatting 98
boot image files COM+ objects 534
assigning to a device 1333 commands
configuring 1206, 1208 adding 178
copying WinPE image to a location for deleting 179
provisioning 1175 modifying 178
creating WinPE 2.0 and later images 1160 commit options
for booting from local media 1375 for deploying packages 746
placeholders for 1159 Compare Editor
for viewing changes 670

compliance component templates 351

and remediation 410 adding local properties 413
exceptions 429, 432 adding parts 362
of components 387, 411, 458 and Compliance Jobs 384
Compliance Job results 458, 467, 469, 471 auto-remediation 410
acting on remediation results 466 compliance 411
defining exceptions 464 compliance rule groups 387
undoing remediation 466 compliance rules 387389, 411
viewing by rule 461 creating 359
viewing by server 461 defining a signature 375
viewing for compliance rules 462 defining in a content format file 1471
viewing remediation results 466 discovering 375, 417, 418, 420, 421, 423, 424
Compliance Jobs 452 editing 371
and component templates 384 includes and excludes 364
automatically remediating results 442 list of snapshot and audit options 366
component templates list 441 local properties 412
creating 439 modifying parts 363, 374
exporting results 471 parts 361, 362, 370, 374
manually remediating results 467 remediation options 410
modifying 458 snapshots and audits 382, 383
remediating results 469 testing a signature 379
results 458, 467, 471 Component Templates folder 40, 101, 359
setting deploy values for remediation jobs 445 adding folders 106, 107
viewing and using results 458 adding smart groups 359
Compliance Rule Editor copying, cutting, and pasting 359
General panel 388 creating component templates 359
Remediation panel 410 deleting 359
Rule Definition panel 389 editing component templates 371
compliance rules organizing contents 359
commenting and uncommenting 411 smart component template groups 108
conditions within 389 component templates list
copying, cutting, and pasting 411 for Compliance Jobs 441
creating or editing 387, 389 components 339, 351
defining exceptions 434, 464 adding manually 425
editing 388, 389 adding to component groups 437
operand data types 402 browsing 381
operators 402 checking compliance 439, 441, 458
viewing as part of Compliance Job results 462 compliance exceptions 432
Component Discovery Jobs 356, 417, 418, 420, 421, 423, compliance of 441
424 defining exceptions to compliance rules 434,
creating 416 464
modifying 425 discovering 356, 425
component groups 106, 107 exporting 118, 120
adding components 437 importing 118, 123
smart 108 installing and uninstalling 357
modifying 432
packaging and deploying 470
process for using 353
running audits on 382, 383
snapshots of 382, 383, 652
templates for 359, 371
Index 1521
Components folder 40, 101, 359 console

adding groups 106, 107 BMC Server Automation 101
adding smart groups 359 Component Templates folder 101
copying, cutting, and pasting 359 Components folder 101
deleting 359 content editor 63
organizing contents 359 customizing preference settings 84
smart component groups 108 Depot folder 102
computer settings Devices folder 102
HP-UX system package 1324 editors 64
Linux system package 1248, 1258 elements 59
Solaris system package 1300 global menu bar 62
VMware system package 1270, 1281 global toolbar 62
Windows system package 1224, 1227 Jobs folder 102
conditional constructs managing 83
defined 1500 menus 65
defining for compliance rule or signature 399 perspectives 62, 64
in compliance rules 389, 390, 399 Quick Access 63
in signatures 376, 377 quick tour 64
conditions RBAC Manager folder 103
in compliance rules 389, 390, 396 Search 103
in signatures 376, 377 Servers folder 103
configuration files 559, 560, 570, 574 tab group 63
exporting 118, 120 Tasks in Progress view 77, 621
grammars for creating 570 title bar description 61
importing 118, 123 toolbars 65
paths to 57 views 63, 64
configuration for provisioning content editors 63
image files 1206 BL Editor 79
installation file locations 1200 selecting 83
PXE server 1202 setting preferences 82
TFTP server 1204 ShellEd 80
configuration for provisioning servers 1184 working with 78
Configuration menu 256 content format 1461
Configuration Object Dictionary 560, 581 conventions
adding custom configuration objects 567 documentation 32
creating extended objects 578 createrepo 1051, 1061, 1070, 1076
deleting custom configuration objects 569 creating a maintenance window 192
extended objects 577 creating folders or groups 107
grammar files 570 creating new objects 103
identifying configuration files 574 custom actions
configuration objects 559, 561 for BLPackage assets 541
in content format files 1465 custom commands
local 414 administering 977
creating and modifying 978
defining 977
deleting 981
executing 347
custom configuration object tables
customizing 97

custom configuration objects 559, 561, 564566 Deploy Jobs 713

adding 567 commit options 746
BLPackages 772 controlling 767
deleting 569 controlling for servers 769
deregistering 597 default values for 754
distributing 583 deploying to multiple components 726
upgrading 590 modifying 754
using jobs to manage 582 phase scheduling 733
versioning 563 phase selection 732
custom icons pre/post commands 749
defining 581 Properties panel 751
custom property classes rebooting servers 769
adding 150 running after packaging component 470
deprecating properties 157 servers not targeted by 770
removing 157 setting options 445
custom software simulate and stage options 746
adding to Depot 482 states 764, 768
customizing taking actions on 765, 766
columns from a pop-up menu 98 to agentless managed objects 716
custom configuration object tables 97 undoing 768
fixed-column tables 96 using for uninstalling 762
Group Explorer tables 96 using results 764
keystroke combinations 94 DEPLOY_ALLOW_NFS_DURING_SUM server
perspectives 69 property 771
preferences 84 Deploying AIX patches directly 1109
tables and columns 95 Depot
customizing keystroke combinations 94 adding BLPackages 509
adding custom software 482
adding files 556, 557
D adding folders 106, 107
adding hotfixes 496, 498
data adding Network Shell scripts 549, 550
refreshing 99 adding software packages 482, 485
data store folder 41, 102
configuring 1185 modifying Network Shell scripts 554
data store instances smart depot groups 108
local data store 1374 Depot folder
properties 1415 Folders view 102
provisioning strategies 1415 depot objects
databases adding depot files 556
connecting to Application Server 37 creating 477
information about 1005 Deregister Configuration Object Jobs
decommissioning creating 597
servers 335, 336 modifying 597
deleting device
groups and folders 113 properties 1410
system objects 113 viewing permissions for 1350
dependencies viewing properties of 1350
between properties 153 viewing settings for 1350
broken 115 Devices folder 41
viewing 117 Folders view 102
deploy activity DHCP server
and internal changes 670 configuring for iDRAC auto-discovery 1394
showing 670
Index 1523
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
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

iDRAC devices InstallShield packages

auto-discovery 1393 adding to Depot 482
importing 1399 installing 718
provisioning 1398 instances
sharing drivers for 1402 deprecating property class 157
imported devices of component template local properties 413
adding 1333 of property classes 146, 155
viewing 1349 removing property class 157
importing 118, 129, 130 internal changes
contents 126 removing 670
destination grammars 126 tracking 668
destination group 127 intrinsic properties 320, 321, 1409, 1479
file format for servers 266, 267 Irrelevant patches
iDRAC devices 1399 Removing 1109
import source directory 125 IS_DEPLOYABLE server property 770
MAC address list and configuration values ITSM approval 311, 737, 788, 799, 810, 847, 1126
1341
Map Missing BLPackages 132
Map Missing Compliance Jobs 134 J
Map Missing Component Discovery Jobs 134
Map Missing Component Templates 133 job completion status 1122
Map Missing Deploy Jobs 135 job parts
Map Missing Network Shell Scripts 135 time-outs for 644, 646
map missing properties 129 Job priority
Map Missing Servers and Server Groups 128 about 609
Map Missing System Packages 131 setting 646
objects 118, 123 job results
Property Values Mapping 130 paging 75
remediation group 127 job schedule log for change management approval
servers 265 jobs 620
system packages 131 job schedules 454, 845
includes list 365, 656, 683, 690, 846 viewing in list 644
for component templates 364
Index Term 382, 391, 677, 1190, 1252, 1254, 1264, 1265,
1333, 1337, 1338, 1346, 1348, 1352, 1353, 1360,
1362, 1364, 1365, 1373, 1384, 1400, 1401, 1411,
14191426, 14281431, 1433, 14351437,
14391442, 1444, 1445, 1447, 14501454
indirect push
for File Deploy Jobs 779
infrastructure management
Application Servers 1002
database 1005
job execution 997
PXE servers 1004
routing rules 1013
SOCKS proxy servers 982, 983
Infrastructure Management window 1001, 1005
install and uninstall
for component templates 415
of components 438
installer packages 269
Index 1527
jobs 607 keystroke combinations

aborting 621 customizing 94
and properties 609, 616 kickstart entries
canceling 621 Linux system package 1251
defining an execution override 616 VMware system package 1271, 1283
dragging and dropping 100 KVM hypervisor 1406
executing 612, 997, 1000
executing a job with change management
approval 617 L
executing against failed targets 614
executing against specific targets 612 LDAP
executing as specific role and user 616 connections 170, 201, 205
exporting 118, 120 queries 170, 206, 207, 210
exporting logs 642 synchronizing with RBAC 229
for managing custom configuration objects 582 LDAP servers
importing 118, 123 certificates 203
in progress 77, 621, 623 synchronizing with RBAC 227
managing 607, 611 LHS operand
opening 611 defined 1506
setting approval type 618 limiting objects using a text filter 73
time-outs for 644 Linux system package
viewing activity 638 AutoYaST entries 1261
viewing definitions 611, 641 basic configuration 1247, 1257
viewing history 637 computer settings 1248, 1258
viewing logs 642 disk partition settings 1245, 1256
viewing schedules 644 kickstart entries 1251
Jobs folder 41, 102 network settings 1250, 1260
adding folders 106, 107, 608 OS components for Red Hat Linux 1249
adding smart groups 608 OS components for SUSE Linux 1259
copying, cutting, and pasting 608 Live Browse Results Option 88
deleting 608 Live node
Folder view 102 contents 339
managing jobs 607 contents for virtual environments 858
organizing jobs 608 local boot 1375
smart job groups 108 local configuration objects
JumpStart provisioning adding to component templates 414
overview of 1149 local data store 1374
Jumpstart rules file local groups
customizing 1305 viewing properties 345
local properties
adding to BLPackages 532
K adding to component templates 412, 413
creating in system package 1343
Kerberos local users
defined 1506 viewing properties 345
kernel parameters localization settings
x86 1309 AIX system package 1313
key bindings logon 46
customizing 94 logs
keyboard combinations exporting for jobs 642
customizing 94 viewing for jobs 642
keyboard shortcuts
viewing 94

loops network definition

defined 1507 AIX system package 1315
defining for compliance rule 401 HP-UX system package 1326
in compliance rules 389, 390, 400 Network Routing Wizard 984
Network Shell 35
creating script jobs 791
M Network Shell Proxy Server 349
Network Shell Script Jobs 791
MAC addresses creating 791
creating file of 1338 modifying 554, 801
macros Network Shell scripts
%f 550 adding to Depot 301, 549551, 553
%h 550 New Component wizard 425428
maintenance window 624, 770 New Patch Download Job 11051108
creating 192 New Virtual Guest Template Enrollment Job
specifying the time window 192 Additional wizard panels 974
managing virtual environments 853, 854 General panel 972
managing with the BMC Server Automation Permissions panel 976
Console 83 Properties panel 975
maximizing a view or tab group 71 Schedule panel 975
menus Targets panel 973
quick tour 65 nexec commands
Microsoft Hyper-V adding 178
browsing 915 deleting 179
managing 914, 916 modifying 178
middle tier NIM provisioning
of BMC Server Automation 36, 37 overview of 1147
Migrating patch repositories no access nodes 173
AIX 1050 nouser option 240
Oracle Enterprise Linux 1074
Red Hat Enterprise Linux 1060
SUSE Linux Enterprise 1069 O
minimizing a view or tab group 71
minimum disk space object-based permissions 166, 230
for deploying files 782 objects
mistakes assigning permissions 171
when defining permissions 239 creating new 103
monitoring compliance in virtual environments 892 custom 567, 577
MSI packages custom configuration 567
adding to Depot 482 exporting 120
deploying 718 extended 577
multiple objects importing and exporting 118
paging 74, 75 refreshing 99
searching for 106
user-defined 577
N online documentation 33
operating systems
network configuration supported by provisioning 1143
Linux system package 1250, 1260 operations
Solaris system package 1301 running in background 77
VMware system package 1270, 1282 operators
when provisioning servers 1357 in content format files 1463
Windows system package 1235
Index 1529
options list Patch Catalog

for component templates 366 AIX 1084
for Snapshot Jobs 657, 658 Creating 1076
organizing folder content 104 General 1077
OS components Modifying definitions 1101
Linux system package for Red Hat Linux 1249 Oracle Enterprise Linux 1096
Linux system package for SUSE Linux 1259 Permissions 1100
Windows system package 1233, 1234 Properties 1100
Override file Red Hat Enterprise Linux 1088
Patch management 1042 Schedules 1098
overview Smart Groups 1102
of access control 165 Solaris 1080
of BMC Server Automation 35, 39 SUSE Linux 1091
Updating 1103
Windows 1077
P Patch Deployment 1140
Patch Downloader utility 1032
package specifications Microsoft Windows 1034, 1037
Solaris system package 1303 AIX 1043, 1044, 10481050
packages 477 Downloading 1033
adding to Depot 482 Oracle Enterprise Linux 1070, 1073, 1074
creating 477 Red Hat Enterprise Linux 1051, 1052, 10571060
deploying 713 Solaris 1038, 1041, 1042
in content format files 1464 SUSE Linux Enterprise 1061, 10671069
modifying software 505 Patch Management 311, 422, 455, 594, 602, 663, 691, 737,
modifying software contents 505 788, 799, 809, 810, 1019, 1020, 10231025, 10321034,
overview 478 1037, 1038, 10411044, 10481052, 10571061,
paging 10671070, 1073, 1074, 1076, 1077, 1080, 1084, 1088,
through job results 75 1091, 1096, 10981110, 11121115, 11191129, 1132,
through multiple objects 74, 75 11341142, 1437
Paging Options 88 Global Configuration parameters 1024
parameters 320 Permissions 1023
adding to BLPackages 521 Windows software locations 1032
using for extended objects 580 Workflow 1020
using in provisioning 1409, 1413 patches
using to reference scripts 1414 adding to Depot 496, 498
parts Patching AIX 1049
component template 361, 362, 370, 374 Patching Job
modifying component template 363, 374 Creating 1110, 11121115, 11191124, 1127, 1141
specifying for compliance 385 Patching Jobs
passwords modifying 1128
changing 55 results 1129, 1132
defining 220 Patching Remediation Jobs 11341137
providing for BLPackages 535 Results 1139
paths
rules for entering 56
Perl scripts 550

permissions 117 post-install configuration

assigned when cutting and pasting 113 AIX system package 1316
assigning to multiple objects 171, 235 HP-UX system package 1329
assigning to objects 117, 170, 231, 239 in Windows system packages 1239
assigning to property classes 159 Solaris system package 1306
avoiding mistakes 239 VMware system package 1274, 1286
default 113 Pre Install scripts
delegating authority 230 VMware system package 1267, 1276
enforcing 172 Pre-install scripts
filters when displaying summary 238 Windows system package 1219
for system objects 173 pre/post commands
managing 168 for Deploy Jobs 749
modifying 117 for File Deploy Jobs 783
object-based 166, 230 preferences
pushing to servers 242, 243 BMC Display Options 86, 87
resource-based 167 BMC File Deploy Options 87
role-based 166 BMC Live Browse Results Option 88
understanding 165 BMC Paging Options 88
updating for groups 171 BMC Tail File Options 88
updating for objects 171 customizing 84
viewing 117 private keys
viewing a summary for an object 236 defined 1510
viewing for a device 1350 process
Permissions for using components 353
Patch Management 1023 profile entries
Permissions view 115, 117 Solaris system package 1304
perspectives 62, 64, 67 profiles
All 67 creating authorization 168
changing 66 properties 116, 143, 320, 325, 1409
Classic 67, 68 adding or modifying 152
Classic2 67 and jobs 609
customizing 69 and parameters 163
detaching a view 70 changing for one or more objects 161
Explorer 67 creating instances of property classes 155
Help Desk 67 dependencies 153
navigating 69 deprecating 157
opening 69 importing 129, 130
preconfigured 67 intrinsic 320, 321, 1409, 1479
reattaching a view 71 local 412, 532
resetting defaults 69 modifying 161
saving a customized 70 overview 143
working with 68 property class 152
phases referencing scripts 1414
for deploying packages 732, 733, 767 removing 157
PKI server 322324
defined 1510 setting values 161
platforms using in provisioning 1409
supported by provisioning 1143 using to rename servers 324
post-disk partition viewing 116, 161
Windows system package 1222 viewing for a device 1350
Properties panel
for Deploy Jobs 751
Properties view 115, 116
property class properties 152
Index 1531
property classes provisioning servers

adding custom 150 Citrix XenServer 1405
built-in 143 classifying servers as provisioned 1353
creating instances of 155 configuration for 1184, 1200, 1202, 1204, 1206
custom 143, 146, 147 configuring data store for 1185
defining permissions for 159 creating a Provision Job 1354
example 147 creating system packages 1214
in content format files 1465 data store instances 1415
removing custom 157 device properties for 1410
Property Dictionary iDRAC devices 1398
adding custom property classes 150 integration with server management 1154
adding properties 152 job properties 1364
deprecating custom classes 157 monitoring provisioning status 1349
deprecating instances 157 network configuration 1357
deprecating properties 157 preparing jobs for 1213
modifying properties 152 process overview 1144
removing 157 re-provisioning servers 1371
removing custom classes 157 starting and stopping provisioning jobs 1360
removing instances 157 strategies for 1415
using 143 supported operating systems 1143
using custom property classes 146 system package properties for 1410
Provision Job system package selection 1356
creation of 1354 task flow for 1155
provisioned servers using a WIM image 1388, 1390
classifying 1353 using parameterized properties in wizard 1412
viewing 1350 viewing system package history 1352
provisioning provisioning strategies
properties for 1409 using data store instances 1415
provisioning history provisioning wizard
viewing system package history 1352 using 1354
PsExec server 272
public key cryptography
defined 1510
public key infrastructure
defined 1510
public keys
defined 1510
PXE server
configuring 1202
in provisioning process 1144
information about 1004
starting and stopping 1204
pythonurlgrabber 1051, 1061, 1070, 1076
Q
Quick Access 63

quick tour RedHat KVM

changing perspectives 66 browsing 918
content editor 64 creating a Virtual Guest Job 881, 883
menus 65 managing 921
of console 64 refreshing the data 99
toolbars 65 registry
views 64 editing multi-value 529
viewing properties 345
viewing security 345
R remediation
creating packages for 469
RBAC 38, 172 of Compliance Job results 442, 445, 467, 469
audit trails 173 Remediation 11341137, 1139
authorizations 165168 remediation jobs
automation principals 195, 200 setting values for 445
built-in roles 174 undoing 466
built-in users 174, 177 Remediation panel
creating ACL templates 184 for Compliance Rule Editor 410
creating authorization profiles 180, 189 remediation view
creating roles 210 of Compliance Job results 466
creating users 220 remote host authentication 288
LDAP connections 201, 205 remote servers 982
LDAP queries 206, 210 rename
Manager folder 103, 168 of servers 324
managing 165 repeaters
modifying ACL templates 189 deleting 1008
modifying authorization profiles 183, 195 for indirect pushes 779
modifying roles 218 for indirect staging 990
modifying users 226 managing 1007
overview 165 routing rules for 992
pushing agent ACLs 240 rule evaluation for 1009
setting up authorizations 177 server objects for 991
synchronizing users with Active Directory 227, status of 1010
229 viewing 1008
synchronizing users with LDAP servers 227, required fields 77
229 resizing a view 71
RBAC Manager folder 103 resources
RBACAdmin user 174, 177 creating 103
adding 252 restoring a view 71
RBACAdmins role 174 results
re-provisioned servers 1371 of Audit Jobs 675, 710
reboot script of Batch Jobs 814
Solaris 1307 of change tracking 666, 669
Reboot settings 1042 of Compliance Jobs 458, 467, 469, 471
reboots of Deploy Jobs 764
for servers 769 of Snapshot Jobs 666, 669, 675, 710
setting in BLPackages 525 of Workflow Jobs 851
Red Hat RHS operand
adding RPMs to Depot 482 defined 1511
KVM hypervisor provisioning 1406 role-based access control 38
provisioning 1243
Xen hypervisor provisioning 1407
Index 1533
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

servers Servers folder 40, 103, 319

and properties 320 adding a new virtual machine 861, 863
assigning to a server group 334 adding remote servers 988
browsing 338 adding servers 261
communicating through SOCKS proxy server assigning servers to server groups 334
982 browsing servers 338
configuring for use of repeater servers 990 components 339
decommissioning 335, 336 copying, cutting, and pasting 333
defining properties for VMware servers 323 deleting 333
dragging and dropping 100 extended objects 339
executing custom commands on 347 Folders view 103
import file format 266, 267 importing servers 265
importing 265 managing jobs 611
limiting access 38 managing server objects 342
monitoring provisioning status 1349 organizing servers 333
mounting with NFS 771 saving a virtual servers state 906
moving and copying between server groups server objects 339
335 smart server groups 108
organizing 333 starting and stopping services 344
provisioned 1353 viewing file properties 345
provisioning 1354 viewing local groups 345
re-provisioned 1371 viewing local user properties 345
rebooting 769 viewing registry properties 345
removing from system 335 viewing security settings 345
renaming 324 viewing server objects 344
system package history 1352 viewing services 345
taking snapshots of 652 service packs
tracking BLPackage deployments 772 adding to Depot 496, 498
updating properties 322, 323, 325 deploying 718
modifying 505
services
starting and stopping 344
viewing properties 345
session credentials
deleting 52
viewing 52
session key
defined 1513
setting job priority 646
setting preferences for text editors 82
sharing
objects 231
ShellEd
editing Network Shell Scripts 80
viewing Network Shell Scripts 80
showing deploy activity 670
signatures
conditions within 376
creating or editing 377
for components 375, 379
operand data types 402
operators 402
testing 379
Index 1535
simulate options SNMP notification options

for deploying packages 746 for Execution Tasks 631
simultaneous execution for Snapshot Jobs 661
for Deploy Jobs 751 SOCKS proxy servers
single-user mode 741, 771 assigning to routing rules 1006
setting in BLPackages 523 creating objects for 983
Single-user mode 1042 deleting 1006
Skip Linux Pre-Install image 1183 setting up 982
slashes status of 1006
in paths 57 viewing properties of 1005
trailing 57 soft links
smart groups using in BLPackages 522
and properties 145, 320 software
component 108 adding to Depot 482, 485, 674
component template 108 changing network deploy options 527
copying, cutting, and pasting 112, 113 deploying 713, 718, 771
defining 108 exporting 118, 120
deleting 113 importing 118, 123
depot 108 matching with depot item 507
exporting 118, 120 modifying package contents 505
importing 118, 123 modifying packages 505
job 108 ordering by dependency in BLPackage 535
server 108 overview of packaging 478
Smart Groups uninstalling 762
Patch Catalog 1102 Software Deploy Jobs 724
Snapshot Jobs 652, 660, 684 creating 718
adding software to Depot 674 default values for 754
bundling results into BLPackages 671 modifying 754
creating 652 Solaris
email notification options 661 creating a Virtual Guest Job for Solaris
modifying 665 environments 880
options list 657, 658 packages 482
removing changes 670 patch clusters 482
results 666, 669 patches 482
server objects list 655 provisioning 1385
SNMP notification options 661 rules file customization 1305
viewing changes using Compare Editor 670 system package for 1296
snapshot options WAN boot installation of 1385
for component templates 366 Solaris system package
snapshots 649, 684 Add Install Client script 1304
adding results to Depot 674 additional profile entries 1304
and symbolic links 650 additional sysidcfg entries 1303
bundling results into BLPackages 671 basic configuration 1299
change tracking 666, 669 begin script 1305
contents of 650 computer settings 1300
exporting results 675, 710 disk partition settings 1297
location of contents 650 network settings 1301
of components 382, 383, 652 package specifications 1303
of server objects 652 post-install configuration settings 1306
storing 650 reboot script 1307
understanding 650 rules file 1305
viewing results 666, 669 x86 parameters 1308

Solaris Zones system packages

browsing 908 AIX settings 13111313, 1315, 1316, 13181321
managing 909 creating 1214
sort order defining Citrix XenServer settings 1288
changing 98 defining ESX settings 1276
SP1 1448 defining ESXi 4.1 settings 1266
specifying parts defining Linux settings 1243, 1254
compliance 385 defining Solaris settings 1296
SQL Server disk partition 1219
installing 718 HP-UX settings 1323, 1324, 13261329
SRP importing 131
defined 1512 inserting parameters 1413
staging directory 716 Linux settings 1245, 1247, 1248, 1250, 12561258,
staging options 1260, 1261
for deploying packages 746 permissions 1217
states properties 1410
of Deploy Jobs 764, 767, 768 Red Hat 1243
status selecting for provisioning 1356
applicable status types for jobs requiring setting access control on folders 1331
approval 640 Solaris 1307
SuSE Solaris settings 1297, 12991301, 13031306,
provisioning 1254 1308
switching roles 54 SuSE 1254
symbolic links VMware 1271, 1283
in BLPackages 509 VMware settings 1267, 1268, 1270, 1274, 1276,
in snapshots and audits 650 1277, 12801282, 1286
synchronized Windows settings 1218, 1219, 1222, 1224, 1227,
pushes for files and directories 778 12331236, 1238, 1239
syntax
for network data transmission 492
sysidcfg entries T
Solaris system package 1303
system authorizations 177 tab groups 63, 115
audit trails 177, 179 maximizing 71
system objects minimizing 71
assigning permissions 170 moving 70
copying, cutting, and pasting 112, 113 Properties, Permissions, and Audit Trail 115
defining permissions for 117, 231, 235, 239 tables
deleting 113 customizing 95
permissions for 166168 customizing columns from a pop-up menu 98
setting property values 161 customizing custom configuration object 97
customizing fixed-column 96
customizing Group Explorer 96
Tail File Options 88
targets
dragging and dropping 100
Tasks in Progress view 77, 621
closing 623
pausing 622
templates
ACL 184, 189
for components 359, 371
Index 1537
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

Virtual Guest Job

creating for Citrix XenServer environments 884
creating for IBM environments 879 W
creating for RedHat KVM environments 881
creating for RHEV environments 883 WAN boot installation 1385
creating for Solaris environments 880 WIM image
creating for VMware environments 878 in provisioning 1388, 1390
modifying 887 Windows Hyper-V
overview 876 specifying in Windows system package 1234
rolling back a deployment 892 Windows registry
Virtual Guest Package editing multi-value 529
creating 868 Windows security settings 1455
editing 876 editing 530
overview 868, 872, 878 Windows system package
Virtual Guest Template Enrollment Job basic configuration settings 1222
overview 873 computer settings 1224, 1227
Virtual infrastructure disk partition 1219
deploying virtual assets 861 DOS scripting 1219
Virtual Infrastructure Discovery Job network settings 1235
Auto-register discovered ESX Hosts/Virtual OS components 1233, 1234
Systems 966 post-disk partition 1222
creating 896 pre-install scripts in 1219
Discover Unregistered Virtual Systems 966 settings for 1218
Import Lifecycle Properties 929, 968 unattended entries 1236, 1238
overview 895 Windows user mapping 169
viewing results 900 automation principals 195, 200
virtual machines WinPE files
adding 861 creating WinPE 2.0 and later images 1160
adding, based on existing virtual system 863 Workflow Jobs
cloning 519 creating 842
saving a virtual servers state 906 modifying 850
virtualization reports workflows
generating 931 viewing results 851
virtualization sprawl working with content editors 78
identifying 896
managing 928
overview 928 X
VMware
browsing virtual machines 902 x86 kernel parameters 1309
creating a Virtual Guest Job 878 x86 parameters 1308
discovering virtual machines 895 Xen hypervisor 1407
managing 902, 905 XML content format files 1461
saving a virtual servers state 906 XML instruction file 480
viewing server properties 907 editing 517
VMware system package
basic configuration 1268, 1280
computer settings 1270, 1281
disk partition settings 1267, 1277
kickstart entries 1271, 1283
network settings 1270, 1282
post-install configuration settings 1274, 1286
Pre Install script 1267, 1276
Index 1539

49532
*223480*

BMC Server Automation User Guide

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BMC Server Automation User Guide

Hochgeladen von

Copyright:

Verfügbare Formate

BMC Server Automation User

United States and Canada

Outside United States and Canada

Copyright 2002-2012 BladeLogic, Inc.

Linux is the registered trademark of Linus Torvalds.

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC

product error messages

4 BMC Server Automation User Guide

Chapter 2 BMC Server Automation overview 35

Chapter 3 Getting started with server automation 43

Chapter 4 BMC Server Automation Console 59

Chapter 5 Properties 143

6 BMC Server Automation User Guide

Chapter 6 Access management 165

8 BMC Server Automation User Guide

Chapter 7 Agent installation 259

Chapter 8 Managing servers 319

10 BMC Server Automation User Guide

Chapter 9 Components and component templates 351

Chapter 10 Creating packages and other depot objects 477

12 BMC Server Automation User Guide

Chapter 11 Configuration objects 559

Chapter 12 Managing jobs 605

14 BMC Server Automation User Guide

Chapter 13 Snapshot Jobs 649

Chapter 15 Software and BLPackage Deploy Jobs 713

16 BMC Server Automation User Guide

Chapter 16 File Deploy Jobs 773

Chapter 17 Network Shell Script Jobs 791

Chapter 18 Batch Jobs 803

Chapter 19 Workflow Jobs 819

Chapter 20 Working with virtual environments 853

18 BMC Server Automation User Guide

Chapter 21 Administrative tools 977

20 BMC Server Automation User Guide

Chapter 22 Patch management 1019

Chapter 23 Provisioning basics 1143

22 BMC Server Automation User Guide

Chapter 24 Provisioning servers 1159

24 BMC Server Automation User Guide

26 BMC Server Automation User Guide

Chapter 25 SCAP compliance analysis 1419

28 BMC Server Automation User Guide

Appendix A Windows security settings 1455

Appendix B Content format 1461

Appendix C System authorizations 1477

Appendix D Intrinsic properties 1479

Introduction to BMC Server Automation

BMC Server Automation is part of the BMC BladeLogic Automation Suite.

Using BMC Server Automation, system administrators can:

View and manage configurations

Compare servers to detect discrepancies in their configurations

Measure and enforce compliance to organizational standards

Administer configuration changes to servers and other devices

Share routine server management tasks between functional teams in an organization

Perform many other data center automation tasks

BMC Server Automation lets system administrators provision operating systems

System administrators can also take advantage of many virtualization features.

Together, the capabilities of BMC Server Automation let system administrators

User action required

UNIX and Windows path separators